30 0 5MB
Etude et réalisation de la migration d’un réseau intelligent IN
SOMMAIRE SOMMAIRE……………………………………………………………………………..I DEDICACE…………………………………………………………..……………….…..II REMERCIEMENTS………………………………………………………..…………..III AVANT-PROPOS……………….……………………………………………………...IV LISTE DES FIGURES….…………………………………………………………….… V LISTE DES TABLEAUX………………………………………………………….......VI RESUME (Abstract)………………………………………………………………….........VII INTRODUCTION……………………….…………………………………….…………1 PARTIE 1: ETUDE PREALABLE……………………………………………..………2
CHAPITRE I : PRESENTATION DE LA STRUCTURE D’ACCUEIL………….……...3 1.1-
Présentation du cadre référence………………….……………………………….3
1.2-
Cadre spécifique d’étude……………………………………………...…………..5
1.3-
Environnement informatiques………………………………….…………………6
CHAPITRE II : PRESENTATION DU PROJET…………………………………………9 2.1-
Définition des termes……………………………………….………………..…..9
2.2-
Présentation du cahier des charges……………………………………..………...10
CHAPITRE III : ETUDE DE L’EXISTANT………………………………………..……12 3.1-
Descriptif de l’existant …………...………………………….…..……………...12
3.2-
Diagnostic de l’existant…………………………………………………………..18
3.3-
Proposition de solutions………………………………………………………….19
PARTIE 2: ETUDE DE LA MIGRATION……………………....……………………21 Mémoire de fin de cycle Master Génie Informatique et Réseaux
I
Etude et réalisation de la migration d’un réseau intelligent IN
CHAPITRE IV : ETUDE TECHNIQUE DE LA SOLUTION…………..………………22 4.1-
Généralité sur les Réseaux Intelligents…………………………………………22
4.2-
Architecture nouvelle du Réseau Intelligent…………………………………….27
CHAPITRE V : ANALYSE DES ELEMENTS A MIGRER…………..………………29 5.1-
Présentation des abonnés Orange CI…………………………………………...29
5.2-
Présentation des abonnés à migrer ……………………………………………..30
5.3-
Description des services à migrer……………………………………………….33
CHAPITRE VI : IMPACT DE LA MIGRATION SUR LA PLATEFORME CIBLE....41 6.1-
Dimensionnement actuel de la plateforme cible…………...................................41
6.2-
Actions à prendre pour absorber le surplus……………………………………...44
PARTIE 3 : REALISATION DE LA MIGRATION…………………………………48 CHAPITRE VII : MISE EN OEUVRE TECHNIQUE…………………………….…....49 7.1-
Configuration des services existants surla nouvelle plateforme ………………....49
7.2-
Tests de validation des services…………………...……………………..………..68
7.3-
Détermination de la stratégie de migration………………………………………..70
CHAPITRE VIII: LES ETAPES SUIVANTES ET PERSPERCTIVES DU PROJET….73 8.1-
Etapes suivantes du projet .......................................................................................73
8.2-
Perspectives du projet……………..…………………………….............................75
CONCLUSION…………………………………………………………………….……76
Mémoire de fin de cycle Master Génie Informatique et Réseaux
I
Etude et réalisation de la migration d’un réseau intelligent IN
REFERENCES BIBLIOGRAPHIQUES …..…………………………………………77 GLOSSAIRE…………………………….………………………………………………78 ANNEXES………………………………….……………………………………………80
DEDICACE
A DIEU TOUT PUISSANT,
Mémoire de fin de cycle Master Génie Informatique et Réseaux
I
Etude et réalisation de la migration d’un réseau intelligent IN
REMERCIEMENTS
Nous tenons à manifester notre gratitude à des personnes particulières qui ont permis la réalisation de ce travail et grâce à qui nous sommes parvenus à la fin de notre formation. Sans être exhaustif, nous aimerions citer : Toute l’équipe de ATOS Cote d’Ivoire et, en particulier le Directeur Général, Monsieur Boukary OUEDRAOGO pour l'opportunité qui nous a été donnée de faire ce projet au sein de ORANGE Cote d’Ivoire ; Mme TRA ZIE Abina Caroline, Chef du département informatique à PIGIER Côte d'Ivoire, pour sa disponibilité ; M. Arsène YAPO, mon professeur encadreur, pour sa disponibilité, la pertinence de ses remarques et tous les efforts consentis ; Mémoire de fin de cycle Master Génie Informatique et Réseaux
I
Etude et réalisation de la migration d’un réseau intelligent IN
Tout le corps professoral et administratif de PIGIER Côte d'Ivoire, pour le savoir transmis au prix de sacrifices personnels ; Ceux qui nous ont soutenus et continuent de nous soutenir par leurs prières et leurs pensées.
AVANT PROPOS
De nombreux établissements de l’enseignement professionnel ont vu le jour ces dernières décennies dans le fichier du ministère de tutelle. Ces nouveaux établissements n’ont pas la maestria des établissements traditionnellement reconnus dans le domaine de la formation tel que PIGIER Côte d’Ivoire. Cette école de par son travail et son sérieux a réussi à mettre d’accord tout le monde sur la qualité de ses formations. La reconnaissance Africaine de ses diplômes par leurs certifications CAMES n’est donc pas fortuite. Le statut de la formation adoptée par PIGIER Côte d’Ivoire est celui de la formation initiale avec le système LMD (Licence Master Doctorat). A PIGIER Côte d’Ivoire, la formation est donnée dans diverses filières parmi lesquelles nous pouvons citer :
Mémoire de fin de cycle Master Génie Informatique et Réseaux
I
Etude et réalisation de la migration d’un réseau intelligent IN
La filière Informatique ; La filière Comptable ; La filière Communication ; La filière Gestion Commerciale ; La filière Bureautique.
A la fin du cycle de Master, l’auditeur est appelé à mener un projet de fin d’études, comme celui-ci sous la direction de ses professeurs et éventuellement des personnes externes. Ce projet lui permettrait de mettre en application les différentes connaissances théoriques et pratiques acquises lors de son cycle.
LISTE DES FIGURES Figure 1 : Organigramme globale de Orange Côte d’Ivoire Figure 2 : Organigramme spécifique de la Direction des Etudes et Développement Figure 3 : Architecture du réseau informatique d’Orange Côte d’Ivoire Figure 4 : Architecture actuelle de la plateforme de valorisation Figure 5 : Architecture de la solution proposée Figure 6 :Modèle conceptuel d’un réseau intelligent Figure 7 :Architecture modulaire du réseau intelligent Figure 8 :Architecture fonctionnelle du réseau intelligent IN ZTE
Mémoire de fin de cycle Master Génie Informatique et Réseaux
I
Etude et réalisation de la migration d’un réseau intelligent IN
Figure 9 :le flux de valorisation des abonnés Postpaid Figure 10:Mapping PricePlan IN ZTE –BSCS Figure 11:Mapping service Alert Conso et Limit Conso IN ZTE-BSCS Figure 12: Mapping service CUG IN ZTE-BSCS Figure 13 : Architecture du module SDP Figure 14 : serveurs à dimensionner Figure 15 : Différence capacité machine CAPS-CPS Figure 16 : Configuration de zoning sur IN ZTE Figure 17 : Configuration de destination sur IN ZTE Figure 18 : Configuration d’événement sur IN ZTE Figure 19 : Configuration de PricePlan sur IN ZTE Figure 20 : Association d’événement au PricePlan sur IN ZTE Figure 21 : Paramétrage de tarif sur IN ZTE Figure 22 : Interaction IN ZTE et plateformes externes Figure 23 : Architecture de provisionnement de services Figure 24 : Architecture de la stratégie globale de migration Figure 25 : Etapes de réalisation de projet Figure 20 : Architecture de la stratégie de migration réelle
Mémoire de fin de cycle Master Génie Informatique et Réseaux
I
Etude et réalisation de la migration d’un réseau intelligent IN
LISTE DES TABLEAUX
Tableau 1: Equipements matériels d’Orange Cote d’Ivoire Tableau 2: Liste des paramètres Alert Conso Tableau 3: Configuration actuelle des serveurs Tableau 4: Tableau prévisionnel du trafic des abonnés Postpaid Tableau 5:Tableau prévisionnel de capacité des serveurs Tableau 6: Liste des machines disponibles Tableau 7: Caractéristiques des serveurs additifs Tableau 8: Spécification des paramètres de la commande ModSubsProfile
Mémoire de fin de cycle Master Génie Informatique et Réseaux
I
Etude et réalisation de la migration d’un réseau intelligent IN
Tableau 9: Spécification des paramètres de la commande AddCUG Tableau 10: Spécification des paramètres de la commande DelCUG Tableau 11 : Spécification des paramètres de la commande ExitCUG Tableau 12 : Spécification des paramètres de la commande JoinCUG Tableau 13 : Spécification des paramètres de la commande QueryCUG Tableau 14 : Spécification des paramètres de la commande SetBalShareRule Tableau 15 : Description des champs d’un CDR Tableau 16 : Exemple de CDR généré
RESUME
Ce mémoire de fin de cycle détaille la migration de la plateforme de valorisation d’Orange Côte d’ Ivoire Telecom du Réseau Intelligent IN ALCATEL vers le Réseau Intelligent IN ZTE. L’objectif de ce projet est de mettre à la disposition du groupe Orange Côte d’Ivoire Télécom (OCIT) une plateforme de tarification performante et flexible assurant à la fois la prise en compte de tous les abonnés prépayés comme post payés, des services actuels et éventuellement des services futurs du marketing. L’entreprise souhaite par ailleurs conforter sa place de leader de la téléphonie mobile en Côte d’Ivoire et gagner toujours plus de part de marché par la qualité du service offert à ces clients pour y parvenir elle a décidé d’unifier son réseau intelligent qui passe par la migration de IN Alcatel vers l’IN ZTE.
Mémoire de fin de cycle Master Génie Informatique et Réseaux
I
Etude et réalisation de la migration d’un réseau intelligent IN
L’étude globale des deux plateformes de tarification nous a permis de proposer des solutions appropriées. Nous avons procédé dans un premier temps à la configuration des différents services sur la nouvelle plateforme, le dimensionnement de celle-ci s’en est suivi. Ensuite des tests de vérification ont été effectués puis pour finir une stratégie de migration s’adaptant au mieux au cas de notre projet a été élaborée. Ces différentes étapes participeront à la mise à disposition du groupe Orange et Côte d’Ivoire Télécom et de ses partenaires un outil de valorisation unique permettant de faire face aux nouveaux enjeux.
Mémoire de fin de cycle Master Génie Informatique et Réseaux
I
INTRODUCTION Face à la mondialisation et à la concurrence grandissante, assurer la recherche de profit en valorisant les services est devenue cruciale pour les dirigeants d’entreprise. En effet, les performances des entreprises ne dépendent plus uniquement de facteurs tels que la qualité des produits et services, le marché ou la localisation, mais aussi d’une politique adéquate de valorisation de ses produits et services. L’efficacité de cette politique repose sur la mise à disposition d’outils adaptés. Toutes les entreprises sont dotées d’une politique de valorisation précise de leurs prestations, les entreprises de télécommunications ne sont pas en reste. Cependant cette politique ne devient stratégique pour les entreprises que lorsqu’elle permet à la fois la satisfaction des clients et l’accroissement du chiffre d’affaire de ces entreprises. Dans le cas de Orange Cote d’Ivoire cette politique est mise en œuvre par deux plateformes de réseau intelligent dont une assurant la valorisation des clients prépayés et l’autre celle des clients post payés. L’exploitation de ces deux plateformes entrainant des coûts exorbitants de maintenance et nécessitant également une mobilisation d’importantes ressources matérielles et humaines, Orange Cote d’Ivoire a donc décidé d’unifier ses deux plateformes pour optimiser les moyens utilisés. C’est dans cette optique que nous avons été reçus à la Direction Générale d’Orange Côte d’Ivoire où le thème suivant nous a été confié : « Etude et réalisation de la migration d’un Réseau Intelligent IN ». Pour mener à bien ce projet notre étude s’articulera autour de trois grandes parties :
La première partie intitulée « Etude Préalable » aura pour mission de présenter la structure d’accueil, le cahier de charges et la description de l’existant ;
La seconde partie « Etude de la migration » fera la lumière sur les différents éléments à migrer ensuite le dimensionnement à réaliser sur la nouvelle plateforme ;
Et enfin la dernière partie « Réalisation de la migration » présentera les différentes configurations et paramétrages des services qui aboutira à la mise en place d’une stratégie de migration adéquate puis à la migration proprement dite.
15
PARTIE 1 : ETUDE PREALABLE
Nous allons décrire l’environnement de travail dans lequel nous avons évolué, Nous présenterons ensuite le thème étudié, et la méthode de travail adoptée, Pour finir nous présenterons l’étude du système existant.
15
CHAPITRE I : PRESENTATION DE LA STRUCTURE D’ACCUEIL
1.1- Présentation du cadre de référence
1.1.1- Historique et présentation d’Orange Côte d’Ivoire
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. France Télécom décide de dénommer « Orange » toutes les filiales mobiles dans lesquelles elle est majoritaire afin de leur faire bénéficier de l’expertise commerciale et de la notoriété dont jouit la marque. C’est ainsi que le 18 mars 2002, la Société Ivoirienne de Mobile change de dénomination sociale et commerciale : elle devient Orange Côte d’Ivoire 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 Côte d’Ivoire SA est à cette date, la première représentation de la marque Orange en Afrique. C’est une société anonyme au capital de 4.136.000.000 F CFA. Son siège social est à l’immeuble « QUARTZ » situé sur le boulevard Giscard d’Estaing à Abidjan. France Télécom ainitié depuis 2004 une synergie entre ses filiales en Côte d’Ivoire : Orange et Côte d’Ivoire Télécom. Cette synergie se traduit par la mise en commun des ressources physiques et matérielles dans le but de permettre aux deux entreprises d’améliorer la qualité de service, proposer les meilleures offres et améliorer ainsi la relation client.
15
1.1.2- Mission et Compétence Orange Côte d’Ivoire, premier opérateur mobile en Côte d’Ivoire avec une plus large couverture réseau s’est donné pour mission de satisfaire les clients et leur apporter tous les bénéfices inhérents au changement qu'il s'agisse de la qualité du réseau, des tarifs, de l'accueil ou des services conçus pour leur faciliter la vie. Orange Côte d’Ivoire place l’innovation au cœur de sa stratégie à travers : -
La démocratisation de l’accès à internet. Pour cela Orange investit massivement dans:
des projets de câbles sous-marins et terrestres ;
des réseaux d’accès sans fil, quelle que soit la technologie (WIMAX, CDMA, HSPA) ;
-
des offres diverses : internet prépayé et clé USB pour le grand public.
Des services à valeur ajoutée autour de la voix, du multimédia et portails ainsi que des offres dédiées aux segments professionnels. 1.1.3- Organigramme d’Orange Côte d’Ivoire
Orange Côte d’Ivoire compte plus de 700 employés répartis dans onze grandes directions, gérées par un Conseil d’administration et chaque direction joue un rôle bien déterminé. On dénombre plusieurs services qui suivent la hiérarchie décrite dans l’organigramme approximatif de la Figure 1
15
CONSEIL D’ADMINISTRATION
DG
DMG
DRH
DJR
DRSI
DF
DO
DED
DRL
DMC
DC
DAQ
Figure 1 : Organigramme globale de Orange Côte d’Ivoire
Par ordre d’apparition sur l’organigramme nous avons : DG : Directeur général DMG : Direction des Moyens Généraux DRH : Direction des Ressources Humaines DJR : Direction Juridique et de la réglementation DRSI : Direction du Réseau de Système d’Information DF : Direction Financière DMC : Direction Marketing et Communication DC : Direction Commerciale DAQ : Direction Audit et de la qualité DO : Direction des Opérations DED : Direction Etudes et Développement DRL : Direction des Réseaux Locaux
15
1.2- Cadre spécifique d’étude Parmi toutes ces directions citées plus haut, nous nous intéresserons particulièrement à la Direction Etudes et Développement. Pour le bon fonctionnement de l’entreprise la DED a pour missions de :
Définir les Roadmap IT et Network ;
Réaliser les études;
Elaborer le budget de CAPEX;
Etre à l’écoute des besoins des directions de Orange et Côte d’Ivoire Télécom et trouver la meilleure solution technique pour y répondre ;
Assurer l’ingénierie et la gestion de projets lors de la mise en œuvre de :
L’évolution du réseau ;
Nouveaux équipements ;
L’extension de capacité ;
Nouvelles fonctionnalités ;
Assurer le déploiement des infrastructures: Radio mobile, réseau IP, ADSL, …
Automatiser les processus de gestion ;
Mettre en œuvre les OSM
15
DIRECTION ETUDES ET DEVELOPPEMENT
SERVICE PLANIFICATION ARCHITECTURE ET DIMENSIONNEMENT
SERVICE RESEAU INTERNE
PROJETS SI
INNOVATION & CONTENUS
INGENIERIE RESEAU D’ACCES MOBILE ET DEPLOIEMENT
TRANSMISSION IP & RESEAUX D’ACCES
RESEAU STRUCTURANT ET PLATES-FORMES DE SERVICE
Figure 2 : Organigramme spécifique de la Direction Etudes et Développement De cet organigramme nous retenons le département Innovation et Contenus. C’est ce dernier qui nous a reçus pendant la période de ce stage de fin de cycle. Il a pour objectif, l’innovation en matière de projets ainsi que la réalisation de ceux-ci en aidant les autres directions d’Orange et Côte d’ Ivoire Télécom à trouver les meilleures solutions techniques.
1.3- Ressources informatiques Avant de concevoir tout système informatique il est indéniable de bien connaître la structure qui l’utilisera. Présentons donc un aperçu du matériel informatique et logiciel d’Orange Côte d’ Ivoire. 1.3.1- Equipements matériels
15
Orange Côte d’Ivoire dans le but de satisfaire ses clients s’est doté de matériels informatique de dernière génération. L’on ainsi dénote des serveurs, des ordinateurs portables, des imprimantes…dont les caractéristiques sont consignées dans le tableau suivant :
TYPE
CARACTERISTIQUES
MARQUES
D’EQUIPEMENTS Ordinateurs
100, 160, 200 Go de DD et 1Go, 2
portables
Go de RAM
Ordinateurs bureau
2,60 GHz, 1 Go de RAM, 160 Go de
DELL, HP, IBM
DELL, IBM
DD Serveurs
Mémoire Vive 16Go,4CPU BI core,
SUN,HP, ALCATEL
292 Go de DD Imprimantes
Laser, Jet d’encres, Simple 230 Couleur17Multifonction 16
Lexmark, HP, Brover,Canon,Xerox
Tableau 1 : Equipements matériels d’Orange Côte d’ Ivoire 1.3.2- Equipements logiciels En plus des équipements matériels, Orange Côte d’Ivoire dispose d’une gamme complète de logiciels. Parmi lesquels nous pouvons citer : Les systèmes d’exploitation : Debian ; IBM AIX ; Ubuntu; Sun Solaris ; Windows Server 2003, XP Professionnel SP2, SP3… Les outils de bureautique : Microsoft Office 2003 et 2007. 15
Les logiciels métiers : SAARI. Les systèmes de gestion de base de données : ORACLE (8i, 9i, 10g, 11g) ; MYSQL; PostgreSQL 8.4 ; SQL SERVER (2000, 2005). Et des outils de Business Intelligence : Ascential Data Stage ; Business Object. 1.3.3- Architecture du réseau informatique Le réseau de OCIT présente une architecture en étoile autour du site principal CIRP (Centre d’Information de la République). Il est constitué de l’ensemble des directions de OCIT reparties dans plusieurs bâtiments et d’un ensemble de sites directement reliés à CIRP aux moyens de connexions réseaux. Le débit de ces connexions varie entre 2 Mbps (Mégabits par seconde) à 128 Kbps (Kilobits par seconde).
Dans le cadre de la synergie, l’interconnexion des deux entreprises est faite via une liaison à fibre optique assurant une haute disponibilité. Elle est faite à partir de liaisons spécialisées entre le site principal de OCI « Lumière » et le site principal CIRP de Côte d’Ivoire Télécom. La figure ci-dessous présente l’architecture fonctionnelle du réseau informatique de CIT et son interconnexion avec celui de OCI.
15
Figure 3 :Architecture du réseau informatique de Orange Côte d’Ivoire
15
CHAPITRE II : PRESENTATION DU PROJET 2.1- Définition des termes Notre thème intitulé « Etude et réalisation de la migration d’un Réseau Intelligent IN »fait ressortir plusieurs concepts à savoir : La migration Réseau Intelligent. sValorisation 2.1.1 –La migration La migration est le passage d’un état existant d’un système d’information ou d’une application vers une cible définie dans un projet. Lors du passage vers une nouvelle version d'une base de données ou d'une application, ou lors de la migration vers un nouveau système, les données doivent être préservées dans ce nouveau système. Le but de la migration de données ou d’application est de transférer les données existantes dans le nouvel environnement. Celles-ci doivent être transformées sous un format approprié pour le nouveau système et ce, tout en préservant l'information stockée dans l'ancien système. Plusieurs cas de figure nécessitent la migration d'applications ou de bases de données : une mise à jour dans une nouvelle version du système, un changement de technologie de base de données ou d'application, etc. Après une fusion ou acquisition, les applications redondantes sont la plupart du temps abandonnées mais les données qu'elles contiennent doivent être préservées dans le système subsistant. Après une migration, il peut aussi arriver que l'ancien et le nouveau système aient besoin de coexister.
15
Un projet de migration informatique est critique dans la vie d’un Système d’information. Il s’agit de passer d’un système à un autre, d’une solution qui fonctionne techniquement mais est obsolète, couteuse à maintenir à une solution qui fonctionnera et qui est couteuse à installer, à apprendre.
2.1.2–Le Réseau Intelligent Intelligent Network (IN) ou Réseau Intelligent (RI) en français est une application dédiée à la valorisation des clients prépayés en temps réel. Elle utilise une base de données Oracle et contient les informations sur l’état des crédits de chaque client. Lorsque des opérations (appels, transferts...) provenant des clients prépayés ou post payés lui sont transférés par les autocommutateurs, elle se charge de la vérification des comptes des clients, leurs statuts et leurs crédits afin de décider de la validité ou non de ces opérations. Lorsque le compte a suffisamment de crédit, elle autorise l’opération et assure un décompte automatique durant toute la session. 2.1.3 –La valorisation La valorisation consiste à donner de la valeur à une chose, dans le cadre de notre thème cette valorisation se fait par application de tarif à un service mis à la disposition d’un client ou d’un abonné.
2.2- Contexte et opportunité
Avant toute proposition ou étude, il est opportun de présenter la situation ayant motivé notre thème. De ce fait, nous allons décrire son contexte, exposer ses objectifs et avancer les résultats attendus. 2.2.1- Contexte et Justification Orange CI, possède à ce jour deux plateformes de Réseau Intelligent (IN) à savoir :
15
Le Réseau Intelligent IN ALCATEL en production depuis 2004 utilisé actuellement pour la gestion des abonnés «Postpaid» et le Réseau Intelligent IN ZTE en production depuis 2009 s’occupant de la valorisation des services pour les clients «Prepaid».
2.2.2- Contexte et Justification L’objectif général est de mettre en production une plateforme unique de valorisation convergente en vue d’optimiser l’exploitation. Par ailleurs dans le contexte mondial de réduction des coûts, ce projet est une aubaine pour Orange Côte d’Ivoire dans sa politique de rationalisation des dépenses.
2-2.3- Objectifs spécifiques Ce thème a pour objectifs essentiels :
De mieux suivre les anomalies dans la taxation et dans la valorisation des services ;
D’exploiter aisément la plateforme ;
D’être en phase avec le marketing en termes d’application de tarifs ;
Faire face aux concurrents en termes de qualité de services ;
D’accroitre la confiance des clients à Orange CI.
2-2.4-Travail à faire Pour atteindre ces différents résultats repartis à travers les objectifs précédemment définis nous avons pour tache de :
Déterminer les services à migrer de la plateforme ALCATEL vers la plateforme ZTE ;
Concevoir l’architecture de la nouvelle plateforme de valorisation d’Orange CI ;
15
Etudier le dimensionnement pour s’assurer que la plateforme peut supporter les prévisions du marketing en termes de croissance du parc (nombre d’abonnés) et du trafic (nombre d’appels, de SMS, etc…)
Implémenter, configurer et tester les offres représentatives du marketing sur une plateforme de test (Test Bed)
Déterminer une stratégie de migration de l’ancienne plateforme vers la nouvelle.
CHAPITRE III : ETUDE DE L’EXISTANT
3.1 Descriptif de l’existant Orange CI possède en ce jour deux plateformes de réseau intelligent à savoir le Réseau Intelligent IN Alcatel, en charge de l’ensemble des clients post payés et le Réseau Intelligent IN ZTE pour la valorisation du trafic des clients prépayés. 3.1.1 Architecture actuelle L’architecture ci-dessous nous permet de mieux présenter l’existant et de ressortir ses insuffisances.
15
Figure 4: Architecture actuelle de la plateforme de valorisation
3.1.2 Protocoles utilisés Un protocole est une méthode standard qui permet la communication entre des processus c'est-à-dire un ensemble de règles et de procédures à respecter pour émettre et recevoir des données sur un réseau. Cette standardisation a pour but principal de permettre à deux programmes s'exécutant généralement sur différentes machines de communiquer et de se comprendre mutuellement et de manière harmonieuse. Il en existe plusieurs selon ce que l'on attend de la communication. Nous allons dans les lignes qui suivent présenter ceux utilisés dans l’architecture présentée à la figure 4 :
15
Le protocole CAP CAP (CAMEL Application Protocol) est un protocole de signalisation dans l'environnement SS7 .CAMEL (Customised Applications for Mobile networks Enhanced Logic Application Part) a pour objet de permettre à un usager d’accéder aux services spécifiques offerts par son opérateur même lorsqu’il est accueilli sur un réseau tiers et de spécifier une architecture et des mécanismes entièrement basés sur les Réseau Intelligent. Dans le cadre de CAMEL, le SCP est appelé CSE (Camel Service Environment). Il peut y avoir plusieurs CSE dans le réseau. Chaque abonné qui a accès à un service spécifique dispose, dans son profil, d’un CSI (Camel Subscription Information), qui identifie le service ainsi que l’appellation globale du CSE concerné. Il existe trois phases de CAMEL à savoir CAMEL Phase1, CAMEL Phase2 et CAMEL Phase3. CAMEL Phase 1 à part les fonctions décrites au dessus, il permet de lever pour les services spécifiques opérateurs les problèmes d’interfonctionnement entre réseaux mobiles. Les mécanismes réseau Camel phase 1 portent sur :
le traitement des appels départ (à l’exclusion des appels d’urgence GSM) ;
le traitement des appels arrivés ;
e traitement des appels renvoyés ;
l’interrogation à tout moment du HLR du réseau nominal ;
La mise en œuvre de CAMEL Phase 1 repose sur un principe fondateur, l’externalisation de la commande du traitement d’appel des commutateurs mobiles, permettant d’homogénéiser les services spécifiques opérateur offerts aux abonnés mobiles, notamment lorsque ceux-ci se retrouvent en situation de roaming international. C’est pour réaliser cela qu’un serveur Camel (CAMEL SERVER ; CSERV ou gsmSCF) a été défini. CAMEL Phase 2, constitue une extension de CAMEL Phase 1. Cette étape prévoit, entre autres :
introduction et commande d’un périphérique intelligent ;
de rajouter de nouveaux point de déclenchement (DP) ;
15
d’introduire des critères de déclenchement conditionnels, pour ne faire appel au serveur
Camel que si certaines séquences de numéro sont composées;
contrôle de taxation.
CAMEL Phase 3, intégré à l’UMTS, constitue une extension de la phase 2. La partie voix est sensiblement la même. La partie donnée s’appuie sur la notion de session qui se modélise par 2 modèles d’état sur lesquels sont développés les mécanismes RI :
Le modèle d’état GPRS attach/detach,
le modèle d’état des contextes PDP individuels.
Le protocole INAP La recommandation Q.1218 spécifie le protocole d’application de réseau intelligent (INAP, Intelligent Network Application Protocol) utilisé afin de prendre en charge l’ensemble des capacités CS-1. Ce protocole supporte les interactions entre les quatre entités fonctionnelles SSF, SCF, SRF et SDF. INAP utilise le protocole de signalisation SS7. En effet les messages INAP sont encapsulés dans des messages du protocole TCAP (Transaction Capabilities Application Part). Ce dernier est structuré selon les principes de la couche application OSI et inclut notamment le protocole ROSE (Remote Operations Service Element) comme un des éléments d’applications.
L’architecture du protocole INAP, se décrit de la façon suivante : Une entité physique peut avoir une interaction unique ou des interactions multiples cordonnées avec d’autres entités physiques. Dans le cas d’interaction unique, une fonction de contrôle d’association unique (SACF, Single Association Control Function) coordonne l’utilisation de l’ensemble des ASE. Dans le cas d’interactions multiples coordonnées, une fonction de contrôle d’association multiple (MACF ; Multiple Association Control Function) assure la fonction de coordination de plusieurs objets d’association unique (SAO ; Single Association Objects). Un SAO est ensemble d’ASE avec leur SACF. Ainsi TCAP est un ASE d’un SAO. TCAP utilise les services sans 15
connexion du sous-système de connexion de signalisation (SCCP ; Signaling Connection Control Part). Le protocole DCC Le DCC ou Diameter Credit Control successeur du protocole RADIUS est un protocole AAA (Authentication, Authorization, Accounting). Il permet aux opérateurs d’authentifier des utilisateurs, de leur autoriser certains services et de collecter des informations sur l’utilisation des ressources. Il fournit les mécanismes de base pour établir un transport fiable, délivrer les messages et gérer les erreurs ainsi que les services de sécurité que toutes les implémentations doivent supporter. Il s’agit du protocole le plus à même de satisfaire les nouveaux besoins suscités par la mobilité. En particulier, il permet aux opérateurs d’authentifier un utilisateur ayant souscrit un abonnement auprès d’un autre opérateur. À ce protocole de base s’ajoutent les applications : Mobile IP, NAS et CMS. L’application Diameter Mobile IPv4 permet de faire du AAA avec un utilisateur utilisant Mobile IPv4 ; l’application Diameter NAS permet l’accès au réseau via PPP/EAP, il s’agit de l’amélioration de RADIUS ; l’application Diameter CMS permet de protéger les échanges Diameter au niveau applicatif entre serveurs ou entre un serveur et son client.
Le protocole SOAP SOAP (Simple Object Access Protocol) est un protocole d’invocation de méthodes sur des services distants. Basé sur XML, SOAP est un format de communication pour assurer communication de machine à machine. Le protocole permet d’appeler une méthode RPC (Remote Procedure Call) et d’envoyer des messages aux machines distantes via HTTP. Ce protocole est très bien adapté à l’utilisation des services web car il permet de fournir au client une grande quantité d’informations récupérées sur un réseau de serveurs tiers. La version 15
actuelle de SOAP est la 1.1. Cette version a été proposée au W3C en 2000 par User Land, Ariba, Commerce One, Compaq, Development or, HP, IBM, IONA, Lotus, Microsoft, SAP.
SOAP permet donc l’échange d’informations dans un environnement décentralisé et distribué, comme Internet par exemple. Il permet l’invocation de méthodes, de services, de composants et d’objets sur des serveurs distants et peut fonctionner sur de nombreux protocoles (des systèmes de messagerie à l’utilisation de RPC). Cependant, il fonctionne particulièrement bien avec le protocole HTTP, protocole très souvent utilisé avec SOAP. SOAP utilise les protocoles HTTP et XML. HTTP comme mécanisme d’invocation de méthodes en utilisant un des balises spécifiques pour indiquer la présence de SOAP comme « ». Cela permet de franchir aisément les firewalls et proxy et facilite le traitement en cas de filtrage. XML joue un rôle prépondérant dans SOAP, on peut distinguer plusieurs éléments :
une enveloppe, expliquant comment la requête doit être traitée et présentant les éléments contenus dans le message.
un ensemble de règles de codage, permettant de différencier les types de données transmises.
Une convention de représentation, permettant de représenter les appels aux procédures de traitement et les réponses.
3.1.3 Description des composants de l’architecture actuelle L’architecture actuelle est composée des équipements suivants :
BTS / BSC - La station de base est l'élément central, que l'on pourrait définir comme un ensemble émetteur/récepteur pilotant une ou plusieurs cellules. C’est elle qui fait le relais entre le mobile et le sous-système réseau.
15
- Le contrôleur de station de base BSC gère une ou plusieurs stations de base et communique avec elles par le biais de l'interface A-bis. Ce contrôleur remplit différentes fonctions tant au niveau de la communication qu'au niveau de l'exploitation.
La MSC (Mobile Switching Center) est un commutateur qui réalise les fonctions de connexion et de signalisation pour les mobiles localisés dans une zone géographique appelée zone de localisation du MSC. La différence principale entre un MSC et un commutateur d'un réseau fixe est qu'un MSC doit prendre en compte l'impact de l'allocation des ressources radio aux mobiles et la mobilité des mobiles
Le HLR (Home Location Register) contient les informations relatives aux abonnés du réseau. Un réseau peut posséder plusieurs bases pour mettre en œuvre le HLR en fonction des capacités de ces bases de données. Dans un HLR, chaque abonné est décrit par un enregistrement contenant le détail des options d’abonnement et des services complémentaires accessibles à l’abonné. A ces informations statiques se rajoutent des informations dynamiques telles que la dernière localisation connue du mobile (localisation permettant la taxation et le routage des appels vers le MSC sous lequel le mobile est localisé) et son état. Le HLR contient par ailleurs le GT associé au numéro de l’abonné.
IN ZTE / IN ALU représentent les plateformes IN en charge de valoriser les services des abonnés Orange Côte d’Ivoire Telecom.
Les plateformes externes sont les plateformes annexes implémentant les services à valeur ajouter il s’agit entre autres de ZEBRA, GEMALTO etc.…
ZEBRA est la plateforme qui permet de faire le rechargement virtuel (e-recharge). Elle contient toutes les transactions effectuées et les informations sur chaque distributeur (son demi-grossiste et son grossiste auxquels il est rattaché). GEMALTO est une application qui permet la sauvegarde automatique du répertoire d’un abonné. 3.1.4 Principe de fonctionnement
15
Le trafic effectué par un abonné sur le réseau doit être valorisé par un le Réseau Intelligent hébergeant le compte de celui. Pour ce fait la connaissance du GT (Global Title) associé à son numéro permet de définir le Réseau Intelligent qui le prend en charge. En effet le MSC interroge le HLR pour avoir les informations telles que le GT associé au numéro de l’appelant et le profil qui décrit les services auxquels ce appelant à droit avant de router son appel vers la destination. Par ailleurs les plateformes externes comme ZEBRA, GEMALTO qui communiquent avec les deux IN par SOAP interrogent en priorité le réseau intelligent INZTE deux cas de figures peuvent se présentent : soit le compte de l’abonné ne se trouve pas dans celui-ci soit il s’y trouve. Dans le premier cas les plateformes externes s’adressent à la seconde plateforme c’est-à-dire l’IN Alcatel. Dans le second cas la plateforme une copie du compte de l’abonné est faite pour que lors d’une nouvelle transaction concernant ce même abonné, les opérations de recherche de compte soient écartées.
3.2 Diagnostic de l’existant Des conséquences se dégagent donc de ce principe de fonctionnement de l’existant notamment :
Au plan technologique
-La plateforme IN ALCATEL présente des insuffisances telles que l’impossibilité de l’étendre en termes de dimensionnement (Limité à six Million d’abonnés), complexité voire impossibilité de paramétrer de nouvelles offres du marketing ;
-l’architecture d’exploitation des deux plateformes s’avère complexe et engendre d’importante incohérence dans la tarification ; -Existence d’un même compte sur les deux plateformes par conséquent une incohérence et une redondance de données sont observées ; -Lenteurs voir échecs dans la réponse des requêtes adressées aux deux plateformes par depuis les plateformes externes ; 15
- Nécessité perpétuelle de mise à jour des bases de donnés des deux plateformes du à la migration
de certains abonnés d’une plateforme vers une autre.
Au plan Stratégique
-L’exploitation de deux plateformes demande un grand nombre de ressources humaines, par conséquent engendre des coûts de maintenance et d’entretien considérables (énergie, climatisation) ; -Perte de crédibilité vis-à-vis des clients due à de nombreuses plaintes.
3.3 Proposition de Solutions Imprégnés des Limites de l’existant nous proposons des solutions ci-après. Il ne s’agit pas de présenter des détails techniques de la réalisation mais il est simplement question de définir les axes essentiels de notre solution. Primo nous proposons la mise en production et l’exploitation d’une unique plateforme de valorisation qui passe par la migration de l’un vers l’autre et cette unique plateforme doit être capable de combler les insuffisances précédemment citées. Nous procéderons comme suit :
Déterminer les services et données à migrer sur la plateforme cible ;
Paramétrer ces différents services sur cette plateforme ;
Etudier le dimensionnement de la plateforme cible afin de s’assurer de sa capacité à prendre en charge le surplus ;
Déterminer une stratégie de migration qui s’adapte au mieux au cas de Orange Cote d’Ivoire Telecom
Effecteur des tests de migration sur la plateforme de test puis procéder à la migration proprement dit. Après avoir énuméré les caractéristiques de notre future plateforme il convient de présenter
son architecture et de décrire également son fonctionnement.
15
Figure 5: Architecture de la solution proposée
La nouvelle plateforme ne présente plus qu’un seul Réseau Intelligent celui de ZTE. En effet le réseau intelligent de ZTE en plus de sa flexibilité et de sa robustesse est la plateforme de valorisation retenue dans la stratégie globale du groupe France Telecom. Avec la mise en place de cette nouvelle architecture, les opérations supplémentaires de recherche de compte de l’abonné dans le cas de l’existence deux plateformes est mise à l’écart.
Désormais les plateformes externes s’adresseront uniquement à la plateforme IN ZTE pour toute opération car tous les abonnés auront pour GT celui du Réseau Intelligent de ZTE.
15
15
PARTIE 2: ETUDE DE LA MIGRATION
Cette partie nous allons de prime à bord, présenter l’architecture de la nouvelle plateforme ensuite les différentes entités concernées par la migration et nous terminerons par le dimensionnement de la plateforme cible.
15
CHAPITRE IV : ETUDE TECHNIQUE DE LA SOLUTION PROPOSEE 4.1 Généralité sur les Réseaux Intelligents Dans les années 80, les différents opérateurs américains tentent de résoudre un certain nombre de problèmes liés à la réalisation de services par la modification des programmes tournant sur chaque commutateur du réseau. L’opérateur de réseau désirant introduire un nouveau service dépend fortement de ses fournisseurs qui sont seuls à même de modifier les programmes forts complexes faisant fonctionner leur commutateur. Le fournisseur se trouvant dans une situation de force, il peut facturer très cher la modification de programme demandée. Pour l’opérateur, ces coûts sont multipliés par le nombre de fabricants fournissant des commutateurs pour son réseau. Une fois les programmes nécessaires disponibles, il est nécessaire de les introduire dans les commutateurs du réseau si l’on veut que le service soit disponible partout. Un réseau pouvant se composer de plusieurs centaines de commutateurs, cette opération peut s’avérer longue coûteuse. On estime habituellement qu’il faut entre trois (3) et cinq (5) ans entre le moment où la décision d’introduire un nouveau service est prise et la mise en œuvre effective de ce service dans le réseau. Ces délais ne permettent pas à un opérateur de réagir rapidement à la demande d’un client pour un service particulier. Aujourd’hui on estime que six (6) mois est un délai maximum. D’autre part, certains services nécessitent que le commutateur traite des informations qui ne sont pas locales, mais communes à l’ensemble des commutateurs du réseau. Par exemple, l’application numéro vert qui permet à un appelant de faire un appel gratuit, repose sur la traduction d’un numéro logique à préfixe spécifique (0800 en France) en un numéro de destination réelle. La table de traduction est une donnée globale à tous les commutateurs. Dupliquer une telle table dans tous les commutateurs du réseau implique une gestion très difficile pour garantir sa cohérence. Par
15
contre, disposer d’un nœud central stockant cette table et étant accessible par l’ensemble des commutateurs est une solution simple à mettre en œuvre et peu coûteuse.
C’est ainsi que le numéro vert fut introduit aux Etats Unis. Un nœud appelé point de commande de service (SCP, service control point) est dédié au traitement de la traduction du numéro. Ainsi le réseau est enrichi d’une fonctionnalité nouvelle et du fait de sa capacité à traiter des informations et à offrir un service plus évolué que l’appel de base, il est qualifié « d’intelligent ».
4.1.1 Model conceptuel du réseau intelligent En vue de décrire les différents éléments du réseau intelligent, l’ITU-T a introduit un modèle conceptuel qui doit servir de cadre de spécification et la description de cette architecture. La figure ci-dessous décrit les quatre plans du modèle conceptuel du réseau intelligent (INCM, Intelligent Network Conceptual Model).
Figure 6 : Model conceptuel du réseau intelligent
15
Chacun de ces plans correspond à une abstraction différente du réseau. Ce modèle ne doit pas être considéré en soi comme une architecture il s’agit plutôt d’un guide de référence conceptuel pour concepteurs.
Le Plan service. Le plan service (SP, service plane) décrit une vue qui ne prend en compte que les services.
Un service est une offre commerciale mise à disposition par un fournisseur de service (qui peut être un operateur) pour les abonnés pour satisfaire un besoin de télécommunication. Le plan service est pris en charge par le « marketeur » de service chez un operateur de réseau ou de service. Il ne contient aucune information concernant l’implantation des services dans le réseau. Le service est décrit en langage naturel. Un service étant la plus petite unité utilisée à ce niveau. Un élément de service est un composant de service correspondant à une partie du service ou au service lui-même. Cela signifie qu’un élément de service peut lui-même être un service, c’est-à-dire correspondre à une offre commerciale. Généralement, un élément de service est indépendant d’un service donné. Cela est le cas par exemple des éléments de services pour « authentification » ou « mise en file d’attente » qui peuvent être réutilisés pour la création de nombreux services RI.
Le plan fonctionnel global Le Plan fonctionnel global (GFP, Global Functional Plan) modélise un réseau intelligent
comme une seule entité. Cette entité est capable d’effectuer un certain nombre de fonctions représentées par des blocs de construction indépendants des services (SIB, Service Independent Building Block). Un SIB particulier représente la fonctionnalité du traitement d’appel (BCP, Basic Call Process). C’est à partir de ce SIB que le service est généralement initié. Un service correspond dans le GFP à un chainage de SIB. Ce chainage comme à un endroit précis dans le traitement d’appel. Ce point de départ est appelé point d’initiation (POI, Point Of Initiation). Dans l’exemple du service numéro vert, POI correspond à la détection du préfixe « 0800 ». Après exécution de la séquence de SIB, le contrôle est à nouveau passé au BCP. Le point dans le traitement d’appel où celui-ci reprend le contrôle est appel point de retour (POR, Point of Return). Une chaine de SIB pour un service donné, associée aux points d’initiation et de retour, constitue une logique globale de service (GSL, Global Service Logic). En termes de programme, une logique 15
globale de service est assimilable à un script. LE GFP est pris en charge par le concepteur de service.)
Le plan fonctionnel réparti Le plan fonctionnel réparti (DFP, Distributed Functional Plane) modélise le réseau
intelligent comme un ensemble d’entités fonctionnelles réparties qui exécutent des actions (FEA, Functional Entity Action). Une entité fonctionnelle (FE, Functional Entity) peut être assimilée à un objet de traitement. Un SIB est matérialisé dans le DFP par une séquence d’actions FEA exécutés dans les FE. Certaines de ces actions FEA peuvent induire des flux d’information (IF, Information Flow) entre FE.Le DFP est pris en charge par le concepteur de réseau.
Le plan physique Le plan physique (PP, Physical Plane) modélise les aspects physiques du réseau intelligent.
Il identifie les différentes entités physiques (PE, Physical Entity) et protocoles qui existent dans le réseau intelligent réel. Il spécifie par ailleurs les entités fonctionnelles implantées dans les différentes entités physiques. Cette implantation doit respecter la règle qu’une entité fonctionnelle ne peut être répartie sur plusieurs entités physiques. Elle peut par contre être dupliquée dans différentes entités physiques. Les flux d’information (IF) du DFP correspondent habituellement à des protocoles d’application. Dans le plan physique, on leur assigne la pile de protocole sur laquelle ils vont fonctionner. Le plan physique est pris charge par les équipementiers et les opérateurs de réseau. Relation entre les plans Les éléments de services (SF) définis dans le plan service (SP) sont traduits en logique globale de service (GSL) dans le plan fonctionnel global (GFP). Une GSL est un regroupement d’un POI, d’un chainage de SIB et d’un POR.
15
Un SIB du GFP est réalisé dans le plan fonctionnel réparti (DFP) par une séquence d’actions d’entités fonctionnelles (FEA) exécutées dans les entités fonctionnelles (FE). Les FE sont traduits en entités physiques (PE) dans le plan physique. Des regroupements de FE peuvent s’opérer avant translation vers un PE donné.
4.1.2 Architecture et fonctionnement d’un réseau intelligent Pour mieux comprendre le fonctionnement d’un réseau intelligent il convient de se poser la question suivante : Comment sont valorisés les services mis à la disposition des clients ou abonnés d’un opérateur. En effet le réseau intelligent a pour rôle principal de valoriser c’est-à-dire d’associer les tarifs à tous les services de bases et services à valeur ajoutée (SVA) fournis par son opérateur. Le réseau intelligent comprend en gros trois grands modules à savoir le Service Control Point SCP le Service Management Point SMP, et le Service Data point SDP. Cette composition est mise en illustration à travers la figure ci –dessous.
Figure 7 : Architecture modulaire du réseau intelligent
15
Le Service Control Point est le cerveau du réseau intelligent il contient les programme qui exécutant la logique de service il est connecté au réseau GSM par le protocole INAP et constitue la porte d’entrée du réseau intelligent. Le SCP est le serveur responsable du traitement des services de réseau intelligent.
Le Service Data Point est le module contenant la base de données des services et le compte du client. Il constitue l’entrepôt de données pour le réseau intelligent. Il gère et stocke les données utilisées par le SCP pour fournir les services. Le service Management Point sert d’interface de gestion, de statistiques et d’alarme du service. Le SMP est responsable de la gestion de service et des SCP associés. Les fonctions réalisées par le SMP sont par exemple, la gestion de base de données, la surveillance et le test de réseau.
4.2 Architecture nouvelle du réseau intelligent Réseau Intelligent IN ZTE étant la plateforme cible de notre projet de migration nous allons à présent faire un zoom sur son architecture et en donner une brève description. Comme tout Réseau intelligent l’IN ZTE se compose de trois modules essentiels notamment le SMP (Service Management Point) pour la gestion, le SCP (Service Control Point) pour assurer la logique de service et le SDP (Service Data Point) pour le stockage des données. Pour une question de d’importance de rôle l’architecture de l’IN ZTE que nous présentons fait ressortir les modules SCP et SDP.
15
Figure 8: Architecture fonctionnelle du réseau intelligent IN ZTE
La convergence réseau fixe et mobile se voit à travers la prise en compte du flux GSM (téléphonie mobile) venant du MSC par protocole CAP et le flux PSTN (téléphonie fixe) venant de l’OCB par protocole INAP. Ces deux protocoles représentent de la signalisation SS7.
15
Le premier équipement qui constitue l’entrée principale du Réseau Intelligent est le SIU. Le SIU a pour rôle essentiel de transformer la signalisation en donnée IP. Les donnés IP sont ensuite traitées par le CP qui est la partie en charge de la logique de service c'est-à-dire de faire la répartition la distinction de données selon que celles-ci soient de la voix ou de USSD (Exemple #122#).
L’OPI est la partie du SCP qui récupère par protocole DCC les données jugées de voix par le CP tandis que l’IMP se charge des données USSD et IVR venant du CP par le protocole MML (Multi Media Language). Toutes ces données sont ensuite transmises au SDP qui contient les comptes des différents clients. Egalement à ce niveau une distinction est faite en entrée. Les données venant OPI sont reçues par l’interface OLC et celle venant de IMP sont transmises aux UIP. Quant aux systèmes externes comme ZEBRA, GEMALTO ils s’adressent directement à l’IN via les UIP par protocole SOAP sans passer par le SCP.
15
CHAPITRE V : ANALYSE DES ELEMENTS A MIGRER Toute migration fait allusion aux éléments faisant objet de migration, dans le cadre de notre projet de migration les éléments concernés par la migration sont les abonnés et les services utilisés par ceux-ci. La présentation de ces éléments est explosée dans les prochaines lignes.
5.1 Présentation des abonnés Orange CI
On distingue deux grandes catégories d’abonnés chez Orange CI à savoir les abonnés « Prepaid » et les abonnés « Postpaid ». Ces deux catégories diffèrent de par les services disponibles et également de par la méthode de valorisation de ces services. Les abonnés « Prepaid » payent les services avant d’en bénéficier c’est-à-dire pour utilisation d’un service quelconque le système de taxation vérifie à priori l’état du compte de l’abonné. Si celui-ci dispose de suffisamment de crédit le service lui est accordé sinon il lui est refusé. Pour alimenter son compte l’abonné « Prepaid » fait des opérations de rechargement électronique (e-recharge) ou par carte de recharge physique. Quand à un abonné « Postpaid », l’utilisation des services lui est accordée et le règlement se fera à la fin du mois où une facture lui sera adressée. La convergence en Télécom est la technologie permet aujourd’hui à l'opérateur de gérer tous ses abonnés et ses multiples produits et services sur une seule plateforme. Elle permet de gérer un catalogue de produits et services flexibles, totalement personnalisables grâce a
15
un moteur de valorisation et un moteur de facturation convergents (prépayé-»Postpaid») performants adaptés aux offres multiservices pour la téléphonie. Que le client ait un numéro prépayé ou «Postpaid», la migration d’un statut à un autre est facilitée par le fait que le système de gestion des deux types de clients est unique. L’abonné «Postpaid» jouit des mêmes avantages que n’importe quel autre abonné Prépayé en plus des avantages liés a sa formule d’abonnement.
5.2 Présentation des abonnés à migrer Dans le cadre de notre projet, la migration concerne essentiellement les abonnés de type « Postpaid » précédemment pris en charge par le Réseau Intelligent IN Alcatel. Ils existent deux types d’abonnés « Postpaid » à savoir :
les abonnés «Postpaid »
les abonnés « Mixte » ou « Hybrid »
Un abonné« Mixte » ou « Hybrid» dispose d’un forfait mensuel qui lui est accordé en totalité en TTC toute taxe confondue) quelque soit le jour de sa création (souscription) .Il a également la possibilité de faire du rechargement au même titre qu’un abonné « Prepaid » lorsqu’il épuise son forfait mensuel d’où la dénomination mixte. Contrairement « Hybrid » les abonnés «Postpaid» dispose d’un forfait mensuel HT (hors taxe) qui est fonction de son jour de souscription. Il ne dispose d’aucune possibilité d’alimentation de son compte par rechargement électronique ou physique. Il existe deux sous catégories d’abonnés «Postpaid » : les abonnés « Postpaid Purs » et les abonnés «Postpaid Contrôlés ». La différence entre ces deux sous catégories se situe au niveau de l’épuisement du forfait. Un abonné «Postpaid Pur » est autorisé au dépassement de forfait sans limite et le surplus sera mentionné dans sa facture tandis que l’abonné «Postpaid Contrôlé » se limite soit à son forfait soit à un montant bien défini au delà de son forfait. 15
Exemple : Un abonné « Postpaid Pur » disposant de forfait mensuel de 100 000 FCFA peut toujours effectuer des appels même s’il parvient à épuiser ces 100 000 FCFA et la fin du mois le montant de sa facture sera de 100 000 FCFA plus le surplus. Un abonné « Postpaid Contrôlé » disposant de forfait mensuel de 100 000 FCFA peut également continuer à émettre des appels jusqu’à un montant de 50 000 FCFA et au delà de ces 50 000Fcfa il n’est plus autoriser à effectuer un appel ou un autre service. Après analyse de l’extraction réalisée sur l’existant (IN Alcatel) il ressort que le nombre total d’abonnés «Postpaid» et « Hybrid » est de 355 689.
Flux de valorisation des abonnés « Postpaid » La valorisation des abonnés «Postpaid » se faisant en offline c’est-à-dire après utilisation de service, elle est basée sur l’analyse des fichiers générés après chaque trafic. Ces fichiers nommés CDR (Call DétailRecord) contiennent les informations sur l’appelant, l’appelé, la durée du trafic, la date du trafic, et le type de trafic. Dans le schéma ci-dessous nous présentons le flux de valorisation des abonnés «Postpaid»
15
Figure 9 le flux de valorisation des abonnés Postpaid Avant l’analyse de la figure 9 nous présentons et donnons le rôle des différents blocs qui la constituent.
Le MSC : MOBILE SWITCHING et la partie du réseau GSM qui génère les CDR des abonnés trafiquant en local. Platine : Représente la machine qui a pour rôle essentiel de collecter les CDR produits par les abonnés. C’est une plateforme de médiation. 15
MACH : c’est la plateforme qui est charge de transférer tous les CDR du trafic roaming. On parle de roaming lorsqu’un abonné se trouvant dans un pays autre que celui ou se trouve son compte effectue des appels. ZTE OCS : Représente le réseau intelligent ZTE, il sert de plateforme de valorisation des CDR BSCS : c’est la plateforme qui a pour rôle l’édition de facture des clients «Postpaid» après valorisation des services. Les scénarii suivants décrivent au mieux l’architecture présentée par la figure 9.
Platine collecte tous les CDR voix, SMS en local fournis par le MSC également les CDR roaming fournis par MACH de tous les abonnés. Il filtre ces CDR et envoie uniquement les CDR des abonnés «Postpaid» à IN ZTE.
les CDR locaux (voix et SMS) sont en format ASN1 tandis que les CDR roaming (voix et SMS) se trouvent en format TAP3.10
L’IN ZTE se charge de valoriser ces fichiers CDR
Après valorisation de ces CDR l’IN renvoie les PRE_UDR à BSCS
BSCS se charge alors d’éditer la facture
5.3 Les services à migrer
Etant donnés que la migration concerne les abonnés de type «Postpaid» nous allons donc présenter les services exclusivement réservés aux abonnés «Postpaid». Il s’agit des services Alerte Conso, Limit Conso, CUG, Share balance et le PricePlan. Ces services existent également sur la plateforme BSCS cependant les terminologies et la philosophie d’implémentation n’ étant pas les mêmes sur l’IN ZTE nous procéderons dans les lignes qui
15
suivent, à l’établissement d’une correspondance entre les deux plateformes à travers des schémas illustratifs. 5.4.1 Le PricePlan
Le PricePlan représente un ensemble de services (voix, SMS, data etc.…) ou encore un service package accompagné d’un tarif pour chaque service et du forfait mensuel accordé à un abonné. Trois types de PricePlan sont à paramétrer sur l’IN ZTE à savoir
Individual PricePlan
Default PricePlan
System PricePlan
Le Default PricePlan représente le profile de base auquel l’abonné souscrit. La règle établie est qu’un abonné doit avoir obligatoirement un seul Default PricePlan et deux abonnés ayant le même Default PricePlan sont valorisés de la même manière ces abonnés ont tous les mêmes services packages ou services. Dans le système ZTE tout Default PricePlan suit la nomenclature suivante : SP_D_XXX (SP pour service package et D pour default et XXX représente un nom). Exemple : SP_D_B_1000. Le Individual PricePlan fait référence à un PricePlan additionnel ou optionnel. La règle établie à ce niveau stipule qu’un abonné peut souscrire à zéro ou plusieurs Individual PricePlan. La nomenclature du Individual PricePlan est la suivante SP_I_YYYY (SP pour service package, I pour Individual et YYYY un nom). Exemple : SP_I_Forfait_Data_Mobile. Le système PricePlan est un PricePlan appliqué à tous les abonnés existant dans le système. Il est généralement utilisé pour un service dont la valorisation est identique quel que soit le profile ou le type d’abonné. Sur l’IN ZTE une priorisation des PricePlan est appliquée comme suite : Le service utilisé par abonné ayant les trois types de PricePlan est valorisé selon les scénarii suivants : L’IN ZTE applique le tarif correspondant à l’événement lié à ce service si celui-ci est configuré dans le Individual PricePlan de l’abonné sinon il applique le tarif correspondant à l’événement lié au service s’il
15
est configuré dans le Default PricePlan dans le cas contraire le Système PricePlan est utilisé pour la valorisation du service. Pour le projet de migration vers IN ZTE une extraction depuis BSCS révèle l’existence de 371 PricePlan dont neuf (9) Individual PricePlan et 362 Default PricePlan. Par ricocher 371 « PricePlan » sont à configurer et à paramétrer sur la plateforme cible IN ZTE. La liste exhaustive de ses PricePlan se trouve en annexe. Afin de réussir ces configurations et paramétrages nous procédons à un mappage des différents services coté IN ZTE et coté BSCS. Par exemple ce qui est PricePlan sur la plateforme l’IN ZTE est appelé service package coté BSCS, et une Offre coté ZTE est appelée «RatePlan» coté BSCS. Une offre est un ensemble de PricePlan ou de services packages. Les «RatePlan» sont également regroupés dans un paquet appelé Main Product. Dans le cadre du projet de migration un seul Main Product « CO_»POSTPAID»_MIXTE » est utilisé pour tous les PricePlan «Postpaid» et Mixte. La figure ci-après illustre le mappage entre la plateforme IN ZTE et la plateforme BSCS pour le service PricePlan.
15
Figure 10: Mapping PricePlan ZTE -BSCS
5.4.2 Service Alert Conso Le service Alert Conso est utilisé pour avertir l’abonné «Postpaid» du niveau de consommation de son forfait mensuel. Un abonné « Postpaid » ayant ce service est qualifié de « Postpaid contrôlé ». Le service Alert Conso est basé sur trois (3) attributs décrits dans le tableau ci-dessous.
15
Tableau 2 : Liste des paramètres Alert Conso
ALERT_TR1 et ALERT_TR2 sont des valeurs relatives c’est à dire un pourcentage. Un abonné ayant le paramètre ALERT_TR1 recevra un flash SMS de notification lorsqu’il aura consommé 50% de son forfait mensuel Un abonné ayant le paramètre ALERT_TR2 recevra un flash SMS de notification lorsqu’il aura consommé 75% de son forfait mensuel. Le paramètre ALERT_TR3 est par contre une valeur absolue en Francs CFA. Un abonné ayant le paramètre ALERT_TR3 recevra un flash SMS de notification lorsqu’il aura consommé la totalité de son forfait mensuel Exemple: ALERT_TR1=50 ALERT_TR2=75 ALERT_TR3=10 000 Forfait mensuel =10 000 CFA Si l’abonné bénéficie du service Alert Conso après une consommation de 5000 FCFA (50% de 10 000) un Flash SMS lui est envoyé. S’il atteint une consommation de 7500 (75% de 10000 CFA) une nouvelle notification lui est adressée et pour finir lorsqu’il épuise son forfait mensuel c'est-àdire les 10 000 FCFA, il reçoit un dernier flash SMS.
15
5.4.3 Le service Limite Conso Ce service est strictement réservé aux abonné de type «Postpaid Contrôlés », il autorise ces abonnés à consommer au delà de leur forfait mensuel jusqu’à un montant lié au paramètre du service. Un abonné « Postpaid Contrôlé » ayant le service Limit Conso est taxé en hors forfait sur sa compte principal. Les paramètres de la « Limit Conso » sont de la forme CC_montant_FCFA qui correspond à une limitation de Conso hors forfaits de valeur « montant ». Ces différents paramètres sont exposés dans la partie annexe de ce rapport. Exemple Un abonné de type « Postpaid Contrôlé » ayant le service « Limit Conso » de paramètre CC_5000_FCFA et disposant d’un forfait mensuel de 10 000 peut trafic jusqu’à atteindre une Consommation maximum de 15 000. La figure ci-après réalise la correspondance des services Alert et Limit Conso sur les plateformes IN ZTE et BSCS
15
Figure 11 : Mapping service Alerte Conso et Limit Conso ZTE-BSCS
5.4.4 Le service CUG
CUG Closed User Group ou Groupe d’Usager Fermé (GFU) est un service qui consiste à regrouper un certain nombre d’abonnés afin de leurs appliquer un tarif préférentiel lorsque les membres du groupe s’appellent entre eux. Ce service est généralement utilisé par les sociétés ou entreprises afin
15
de faciliter la communication entre ses employés. La société est considéré comme un abonné qui joue et le rôle d’administrateur du groupe ce qui lui donne droit d’effectuer les taches comme :
Définir le nombre maximum de membres du groupe, ajouter un membre au groupe ou encore retirer un membre du groupe. Egalement le mappage pour ce service entre les deux plateformes IN ZTE et BSCS est représenté par la figure 12
Figure 12 : Mapping service CUG ZTE et BSCS
15
CHAPITRE VI : IMPACT DE LA MIGRATION SUR LA PLATEFORME CIBLE Toute migration engendre un surplus de trafic ce chapitre à pour objectif l’étude de la capacité de la plateforme cible pour assurer la prise en charge des éléments de migration.
6.1 Dimensionnement actuel de la plateforme cible L’étude du dimensionnement concerne essentiellement le module SDP de notre Réseau Intelligent. Cette étude passe nécessairement par la présentation de la capacité actuelle de la plateforme cible. Dans le system ZTE, le SDP a un rôle de système de facturation en temps réel pour les abonnes prépayés et les abonnés «Postpaid». Dans le sous system SDP, nous avons les servers suivants :
serveur SDP
server de base de données
serveur OLC
serveur CSIP ou Serveurs UIP
server d’application
serveur de CDR
La figure 13 met en exergue l’architecture du sous-système SDP avec l’interconnexion des différents types de serveurs qui le composent.
15
Figure 13 : Architecture SDP de l’IN ZTE
Le serveur de base de données (DB server) héberge les données et toutes les informations du système. Le serveur OLC (OLC Server) sert principalement de passerelle entre les protocoles DIAMETRE et TCP/IP. Quant au Serveur CSIP ou serveur UIP, il sert de passerelle entre le SDP et les plateformes externes comme le SCP et ou ZEBRA. Les serveurs d’application (App Server) permettent l’administration de la plateforme SDP et la gestion des services aux utilisateurs. Les serveurs de CDR (CDR Server) stockent les CDR et servent en même temps d’interface entre le system de facturation en temps réel et le centre de facturation. Le dimensionnement du SDP concerne essentiellement les différentes portes d’entrée du SDP à savoir les serveurs OLC et les serveurs CSIP encore appelés UIP.
15
Figure 14 : Serveurs de dimensionnement
Pour le dimensionnement des serveurs deux paramètres ou indicateurs sont utilisés : CAPS (Call Attempt Per Second) et CPS (Call Per Second). Le CAPS est le nombre de tentatives d’événements que peut supporter une machine en une seconde tandis que le CPS représente le nombre d’événements que peut supporter une machine. La figure illustre la différence entre ces deux paramètres de dimensionnement de serveurs.
15
Figure 15 : Différence de capacité machine CAPS-CPS
D’après le schéma il existe deux niveaux de dimensionnement pour chaque serveur. La porte d’entrée du serveur exprimer en CAPS et le contenu du serveur exprimer en CPS Pour mieux comprendre ce type de dimensionnement nous prenons pour exemple un parking d’une capacité de dix véhicules en supposant que l’accès au parking se fait par une porte pouvant supporter le passage simultané de deux (2) véhicules. La condition d’acceptation d’un véhicule dans ce parking est la suivante : A un instant t le parking doit contenir non seulement moins de dix véhicules mais aussi moins de deux (3) véhicules en entrée. Le tableau ci-dessous résume le dimensionnement actuel de chaque type de serveurs avant la migration.
Nombre
CAPS
CPS
Etat de charge
Server CSIP ou UIP
6
230
1150
75 %
Server OLC
6
250
1250
80 %
15
Tableau 3 : Configuration actuelle des serveurs CAPS Serveur UIP= 6*230 = 1380 CPS Serveur UIP=6*1150= 6900 CAPS Server OLC= 250*6= 1500 CPS Serveur OLC= 1250*6= 7500 Cette configuration est faite sur la base de 8 Millions d’abonnés de type « Prepaid » existants sur la plateforme ZTE avant migration. La charge de ses deux serveurs étant plus grande que 80% il convient de faire un redimensionnement de ceux-ci pour toute migration engendra une charge de 5% de plus.
6.2Actions prises pour absorber le surplus Le dimensionnement est fait selon le type de services tels que VOIX, SMS, Data et autres service comme les requêtes venant des plateformes externes. Il est également basé sur le nombre d’abonnés utilisant ces services. A l’issue d’une entrevue avec l’équipe marketing et l’équipe d’exploitation de l’ancienne plateforme nous avons dressé le tableau suivant qui donne une idée générale du trafic prévisionnel des abonnés à migrer sur quatre années.
Année 1
Année 2
Année 3
Année 4
400000
600 000
800000
1 000 000
Voix (CAPS)
76
81
106
122
SMS et MMS(CAPS)
58
72
99
115
Data(CAPS)
19
29
45
50
requêtes plateformes externes(CAPS)
105
165
230
250
Nombre Abonnés
15
Tableau 4 : tableau prévisionnel du trafic abonné Postpaid A partir du tableau ci-dessus le dimensionnement des différents servers est déduit et résumé dans le tableau suivant.
Année 1
Année 2
Année 3
Année 4
Nombre Abonnés
400 000
600 000
800 000
1 000 000
Server UIP ou CSIP (Requêtes, USSD) (CAPS)
105
165
230
250
Serveur OLC (Voix, SMS, data)(CAPS)
153
182
250
287
Tableau 5 : tableau prévisionnel de capacité des serveurs La configuration matérielle est faite à base de serveurs de marque HP. Les caractéristiques de ces serveurs sont consignées dans le tableau ci-dessous.
Server HP
Caractéristiques
Capacité
HP Rx6600
(2*1.6G/8*1G/2*146G/2*FC card)
107
HP Rx6600
(4*1.6G/16*1G/2*146G/2*FC card)
315
HP Rx6600
(8*1.6G/16*2G/2146G/2*FC card)
430
HP Rx7640
(16*1.6G/12*8G/2*146G/2*FC card)
818
HP Rx8640
(32*1.6G/16*8G/2*146G/2*FC card)
1 571
Tableau 6 : Liste des machines HP disponibles NB : (2*1G/8*1G/2*146G/2*FC card) signifie : deux (2) processeurs de 1Ghz chacun, huit (8) barrettes RAM de 1Go chacune, deux (2) disques durs de capacité 146Go chacun et deux (2) cartes réseau.
15
De tous ces tableaux précédents et en tenant compte du fait que la charge maximale d’un serveur est fixée à 80%, nous préconisons l’ajout d’un serveur CSIP et d’un Serveur OLC pour assurer une prise en compte du surplus pendant une période de quatre (4) années. Marque
Marque
Capacité
Server UIP ou CSIP
HP Rx6600
(4*1.6G/16*1G/2*146G/2*FC card)
315
Serveur OLC (Voix, SMS, data)
HP Rx6600
(8*1.6G/16*2G/2146G/2*FC card)
430
Tableau 7 : Caractéristiques des serveurs additifs
Choix du fonctionnement des serveurs Deux mondes de fonctionnement sont les plus utilisés du moment à savoir le fonctionnement actif/standby et le fonctionnement répartition de charges. Le premier mode consiste à mettre en place deux machines la première reste en activité et prendre en charge toutes les opérations tandis que le second reste au repos jusqu’à ce que le premier tombe ou jusqu’à intervention d’un disfonctionnement de celui-ci Avantage : Prise en compte de toutes les taches tant qu’un serveur est en bon état. Inconvénient : Risque de surcharge d’un serveur et arrêt d’activité lorsque les deux serveurs tombent. Le second mode consiste à mettre également en place deux machines mais cette fois toutes les deux sont en activité et une répartition sont taches est faites entre les deux machines. Avantage : Risque de surcharge de serveur réduit Inconvénient : Lorsqu’un serveur tombe ses taches ne sont plus accomplies Les règles suivantes dictent les différents choix de fonctionnement des serveurs.
Quand choisir le mode actif/standby ?
15
Ici le mode actif/stand by s’impose au vu de la criticité de ses serveurs. Toutes les taches se doivent d’être prises en compte.
15
PARTIE 3 : REALISATION DE LA MIGRATION Dans cette partie sera consacrée à la configuration des différents services sur la nouvelle plateforme qui aboutira par la suite à la réalisation des tests de validation de ces services et pour finir à la mise en place d’une stratégie de migration adéquate.
15
CHAPITRE VII : MISE EN OEUVRE TECHNIQUE 7.1 Configuration des Services existants sur la nouvelle plateforme La mise en œuvre technique passe par la configuration des services Postpaid précédemment présentés sur la nouvelle plateforme. Il s’agira dans un premier temps de créer et de configurer l’ensemble des 371 PricePlan sur la plateforme cible et en fin de mettre en place des commandes SOAP qui sont de bout de code XML pour les autres services comme Limit Conso, Alert Conso, CUG et Share Balance. 7.1.1Configuration des PricePlan sur la nouvelle plateforme
Quatre étapes sont à considérer pour cette configuration à savoir la configuration des zones, la configuration des événements (appel international, appel vers autre réseau, envoi SMS), création des PricePlan et afin l’application des tarifs aux événements. La première étape de la configuration concerne les zones « zoning configuration » il consiste à regrouper un ensemble de destinations. La capture suivante donne un aperçue de cette étape
15
Figure 16 : Configuration du zoning sur l’IN ZTE
Comme le montre l’image il suffit de donner un nom significatif à la zone comme « international » ou « Orange » pour designer les événements en destination de l’international ou des abonnés Orange CI.
15
Figure 17 : configuration d’une destination sur l’IN ZTE
Ensuite il faut associer des destinations à la zone en cliquant sur le lien « zone value » et préciser les préfixes de ces destinations tels que 00221 pour le Sénégal. La seconde étape concerne les événements. Les événements dépendent des destinations on dira par exemple un appel vers MTN ou un SMS vers l’international. La capture suivante montre les détails cette configuration. 15
Figure 18 : configuration d’un événement sur l’IN ZTE
La troisième étape consiste à créer le PricePlan et d’y associer les événements l’image suivante décrit cette procédure
15
Figure 19 : configuration d’un PricePlan sur l’IN ZTE
Comme signaler dans la partie présentation des services, la capture suivante donne le choix des différents types de PricePlan : Default PricePlan, Système PricePlan ou Individual PricePlan. Une fois le choix du type de PricePlan opéré il convient de lui donner un nom comme « SP_D_XXXX » pour le Default PricePlan ou encore « SP_I_XXXX » ou le Individual PricePlan sans oublier de choisir le code du Main Product «Postpaid» qui est « CO_POSTPAID_MIXTE».
15
Après la création du PricePlan vient comme dernière étape l’association des événements précédemment configurés dans le PricePlan et l’application de tarif qui convient. Les captures ci-après représentent une illustration de cette dernière étape.
La première capture montre l’association des événements au PricePlan et la dernière l’application des tarifs aux événements.
Figure 20 : Association d’un événement à un PricePlan sur l’IN ZTE
15
Figure 20 : paramétrage de tarif sur l’IN ZTE
L’application des tarifs présente trois modules suivants :
Le premier module donne le tarif de base c’est-à-dire un tarif de la forme « appel vers une destination x est valorisé à y francs par tranche de z seconde »
Le second module donne le tarif par tranche horaire de la forme
« Un appel vers une destination x de y heure à z heures est valorisé à b Francs par tranche de c seconde » 15
Le dernier module donne le tarif par durée d’appel de la forme
« Un appel vers une destination x est valorisé à z francs de la k ième minutes à la j ième minute »
7.1.2 - Configuration des services additionnels
La configuration des services additionnels se fait principalement par des commandes SOAP. Ces commandes SOAP sont des bouts de code XML appelés WebServices. La figure ci-dessous décrit le flux d’interaction entre le Réseau Intelligent ZTE et les plateformes externes qui utilisent ces commandes.
Demande service Plateformes Externes
2
5
Interface WebServices Interface WebServices
3 IN ZTE
4 Réalisation du service Réalisation du service
IN ZTE
Figure 21 : Interaction IN ZTE et les plateformes externes
15
Description du flux : 1- Le client envoie une requête de demande de service ou de demande de changement au système externe ou plateforme externe 2- La plateforme externe ou application tierce soumet la demande de service du client ou de demande de modification à l’IN ZTE par Interface WebServices fournies de l’IN ZTE 3- Interface WebServices de l’IN ZTE prend en charge la collecte des demandes de service, et déclenche le module de réalisation de service 4- Le module de réalisation de l’IN ZTE envoie une réponse du service demandé à l’interface WebServices 5- L’interface également achemine cette réponse à la plateforme externe qui a formulé la demande du service 6- La plateforme externe fait un retour au client initial demandeur du service Ainsi pour chaque service nous présentons les différentes commandes SOAP permettant sa réalisation accompagné d’un tableau de spécification des paramètres de ces commandes. Ces commandes ont toutes la même structure générale à savoir : -
Un en-entête représenté par la balise Cette balise contient deux types de balise fils qui désigne le nom de la commande et la balise qui est un code associé à la requête ce code est incrémenté à chaque utilisation de la commande.
-
Un corps qui est représenté par la balise , c’est à l’intérieur de cette balise que se placent les différents paramètres de la commande. 15
Limite Conso et Alert Conso Pour la gestion du service Limit Conso et Alerte Conso une seule commande XML a été mise en place à savoir la commande ModSubsProfile. ModSubsProfile 0130090311 22507000961 ALERT_TR1
ALERT_TR2
ALERT_TR3 LIMITE_CONSO CC_300000_CFA
15
Nom du
Type
Taille
Description du
Paramètre
Paramètre
Paramètre
Paramètre
MSISDN
String
1~60
Le numéro bénéficiaire
AttrCode
String
1~60
Code du paramètre service à ajouter
Optionnel
AttrValue
String
1~8
Valeur du paramètre service à ajouter
Optionnel
MSISDN
Remarque
du
Obligatoire
Tableau 8 : Spécification des paramètres de commande Limit Conso et Alert Conso Le service CUG ou GFU Pour le service CUG cinq (5) commandes ont été mises en place pour la gestion à savoir la commande permettant de créer un nouveau groupe, la commande permettant d’ajouter un membre au groupe , la commande permettant de retirer un membre du groupe , la commande permettant de supprimer un groupe et enfin la commandant permettant d’interroger un groupe afin d’avoir le nom du groupe le code. Dans les lignes ci après sont présentés ces commandes et un tableau descriptif des différents paramètres à prendre en compte pour l’utilisation de ces commandes.
15
La commande AddCUG pour l’ajout d’un nouveau groupe
AddCUG
002008899100001
5535058
22547588589
C
CUG_INTRA_GFU 30
15
Nom du
Type
Taille
Description du
Paramètre
Paramètre
Paramètre
Paramètre
CUGName
String
1~60
Le nom du CUG
Obligatoire
AdminMSISDN
String
1~60
Le numéro de l’administrateur du CUG qui est également un membre du groupe
Optionnel
AdminPwd
String
1~8
Mot de pass administrateur du CUG à utiliser pour ajouter ou retirer un membre du groupe
Optionnel
CUGTypeID
String
1~3
Code du type de CUG Valeur fixe A: Appel en dehors du groupe non autorisé C: Appel en dehors du groupe autorisé
Obligatoire
CUGMemberDtoList
Array
La liste des membres du groupe
Optionnel
PricePlanCode
String
1~60
Le PricePlan associé au CUG
Optionnel
MaxMemberAmount
Long
1~6
Le nombre membres
Optionnel
Limite
Remarque
de
Tableau 9 : Spécification des paramètres de commande AddCUG
15
La commande DelCUGPour la suppression d’un groupe
DelCUG 002008899100001
5535058
Nom du
Type du
Taille du
Description du
paramètre
Paramètre
paramètre
paramètre
CUGID
Long
Remarque
1~6
Identifiant ou code du CUG obtenu à partir de la commandeQuery CUG
Obligatoire
AdminMSISDN String
1~60
Numéro MSISDN de l’administrateur du groupe.
Optionnel
AdminPwd
1~8
Le mot de pass de l’administrateur du groupe.
Optionnel
String
15
Tableau 10 : Spécification des paramètres de commande DelCUG
La commande ExitCUG Pour retirer un membre du groupe
ExitCUG
002008111700001
4973017
22547592592
Nom
Type
Taille
Description du
Remarque
Paramètre
Paramètre
Paramètre
Paramètre
CUGID
Long
1~6
Le nom du CUG .
Obligatoire
AdminMSISDN
String
1~60
Numéro MSISDN de l’administrateur du groupe.
Optionnel
AdminPwd
String
1~8
Le mot de pass de l’administrateur du groupe.
Optionnel
MSISDN
String
1~60
Numéro MSISDN du membre à retirer
Obligatoire
15
Tableau 11 : Spécification des paramètres de commande ExitCUG
La commande JoinCUG pour ajouter un nouveau membre au groupe
JoinCUG
002009031100001
5535058
22548154155
15
Nom du
Type
Taille
Description du
Remarque
Paramètre
Paramètre
Paramètre
Paramètre
CUGID
Long
1~6
Code du CUG obtenu par la commande QueryCUG
Obligatoire
AdminMSISDN
String
1~60
Numéro MSISDN de l’administrateur du CUG
Optionnel
AdminPwd
String
1~8
Mot de pass de l’administrateur du CUG.
Opitonnel
MSISDN
String
1~60
Numéro MSISDN du member à ajouter
Obligatoire
UserPwd
String
1~8
Mot de pass de l’operateur
Opitonnel
IsAllowOutgoingCall
String
1~3
Drapeau pour autoriserles appels en dehors du groupe. Y: Outgoing call allowed N: Outgoing call not allowed
Opitonnel
Tableau 12 : Spécification des paramètres de commande JoinCUG
15
La commande QueryCUG pour interroger un groupe existant
QueryCUG
00920909062500000001
0
1
CUG_311
Nom du
Type
Taille
Description du
Remarque
Parameter
Paramètre
Paramètre
Paramètre
ProviderID
Long
1~6
Toujoursmis à 0
Obligatoire
State
String
1~60
Statut du groupe 1 s’il existe des membres 0 sinon
Obligatoire
MSISDN
String
1~8
Le numéro MSISDN de l’administrateur.
Optionnel
CUGName
String
1~60
Le nom du CUG
Obligatoire
Tableau 13 : Spécification des paramètres de commande QueryCUG
15
Service de partage de balance Pour ce service également une seule commande a été mise en place pour attribuer le service à un abonné il s’agit de la commande SetBalShareRule
SetBalShareRule
016007789711
1876918
SHCRED
22547588589
2011-10-25
F
15
Nom du
Type
Taille
Description du
Remarque
Paramètre
Paramètre
Paramètre
Paramètre
AccountCode
String
1~12
Le code du compte associé à la balance
Obligatoire
AcctResCode
String
1~12
The code de la balance à partager
Obligatoire
MSISDN
String
1~23
Le numéro MSISDN du partageur.
Obligatoire
CeilLimite
String
1~12
Valeur maximum à partager
Optionnel
DailyCeilLimite
String
1~12
Valeur maximum journalier
Optionnel
EffDate
Date
10
Date effective d’application du partage
Obligatoire
ExpDate
Date
10
Date expiration du partage
Obligatoire
Priority
Long
1
Priorité des balances
Optionnel
PaymentForce
String
1
Indicateur pour signaler la possibilité d’effectuer des appels après épuisement de la balance partagée ‘N’ pour Non ‘Y’ pour Oui
Optionnel
Tableau 14 : Spécification des paramètres de commande SetBalShareRule
15
7.2 Test de validation des services Sur un plan général un projet de Migration est découpé en phases. Une première phase permet de décider du choix de la solution avec une étude de l’existant et des solutions proposées. Le nouveau Système d’Information (SI) envisagé est une cible vers laquelle il faut aller, mais qu’aucune solution d’ERP n’adresse car le Système d’Information existant est fait de plusieurs systèmes informatiques, avec un découpage métier propre et tenant tant à l’exercice du métier qu’à l’histoire même du Système d’Information. Ce projet consiste à transporter les données de l’ancien système vers le nouveau, et à vérifier au cours des différents cycles que toutes les données à reprendre l’ont été et ce correctement. La seconde phase va alors consister à tester unitairement les différents développements. Unitairement signifie que chaque livraison est testée avec lot de jeu d’essai spécifique pour remuer l’application dans tous les sens et vérifier comment elle se comporte. Suivra une phase d’intégration de l’ensemble des composants en vue de préparer la phase d’homologation. Cette troisième phase va se dérouler avec si possible des données non plus unitaires mais métier, fonctionnelles. Les tests porteront cette fois sur des ensembles de composants avec, puisque l’intégration le permet, des tests de bout en bout. Différents cycles d’homologation doivent permettre de dérouler toutes les chaines de traitement et de passer par la couverture la plus large possible du métier. Durant ces test d’homologation, il est judicieux de pouvoir utiliser les données issues du processus de reprises et ce au fur à et mesure que le projet gagne en couverture fonctionnelle. La phase d’homologation permet de vérifier que les données sont conformes avec le fonctionnement du nouvel SI, il reste cependant à tester que le projet même de migration fonctionne correctement.
15
Dans le cadre spécifique de notre projet deux phases de test sont ont été réalisées il s’agit des Test VABF et des Tests Ende to End.
7.2.1 Les Test de vérification au bon fonctionnement
Les tests de vérification au bon fonctionnement ont pour objectif principal d’assurer le bon fonctionnement de chaque service sur les différentes plateformes impliquées dans le déroulement de ces services. Le fonctionnement des services propres aux abonnés « Postpaid» impacte un ensemble de plateformes, il est question d’effectuer de façon séparée, des tests sur chaque plateforme. La figure suivante met en exergue les différentes plateformes impliquées dans cette phase de test.
Figure 23 : Architecture de provisionnement de services
15
Les plateformes concernées par ces tests sont les suivantes : KPSA, PLATINE, BSCS et IN ZTE.
KPSA est la plateforme de « Provisioning » il a pour rôle d’adresser des requêtes de provisionnement à BSCS. Le provisionnement concerne essentiellement la création de nouveaux contrats, l’ajout de services à un contrat, la résiliation de contrat, la suspension de contrat etc.… Un contrat est un numéro de téléphone associé à « PricePlan » ou un profil. KPSA adresse une requête de création de contrat à BSCS en envoyé le numéro et le PricePlan associé. BSCS la plateforme s’occupant essentiellement des clients « Postpaid » exécute cette requête et l’achemine à l’IN ZTE. BSCS également est en charge d’éditer les factures des clients après valorisation de celles-ci par l’IN ZTE. Platine quand à elle est la plateforme de médiation qui s’occupe de la collecte des CDR produits par les abonnées et les transmet à l’IN ZTE seule plateforme ayant la capacité de valorise les services abonnés. Dans le cas du test de vérification au bon fonctionnement la même opération est effectuée sur chacune des plateformes. On créera par exemple un contrat sur KPSA, un autre sur BSCS et un autre sur IN ZTE. Nous avons réalisé ces test avec la création d’un certain nombre de contrat sur l’IN ZTE pour ce qui est des autres plateforme une autre équipe a effectué les mêmes test et après confrontation des résultats obtenus, des correction ont été apportées à certaines anomalies.
7.2.2 Les test End To End Le second test appelé test End To End utilise la même architecture. Il consiste à effectuer les mêmes tests de « Provisioning » mais cette fois de bout en bout c’est-à- dire exécuter une requête depuis KPSA puis suivre cette même requête jusqu’à valorisation du CDR généré par l’abonné en question en passant par la platefome de médiation Platine. Pour réalise ce test quelques numéros de test ont été créés depuis la plateforme KPSA ensuite ces contrats ont bénéficié de services par la plateforme BSCS, des tests d’appels et d’envois de SMS s’en ont suivis pour finir une extraction de CDR a lieu afin de vérifier la cohérence dans le tarif appliqué à chaque service ajouté par BSCS.
15
7.3Mise en place de la stratégie de migration La migration étant une opération très risquée, la mise en place d’une stratégie adéquate est plus que nécessaire afin de minimiser certains risques tels que des pertes de données ou des incohérences de données. Dans le cadre de la refonte d'un système d'information complexe, la phase de migration et de déploiement est décisive car elle doit répondre à deux enjeux majeurs :
Assurer une transition cohérente entre l'ancien système et le nouveau.
Assurer dans les délais une bascule transparente pour les utilisateurs et les clients, sans remettre en cause la continuité des moyens opérationnels et des ventes
La plateforme cible étant déjà en production de minutieuses précautions sont à observer. Ainsi la migration passe par trois principales étapes et toutes ces étapes sont transparentes aux abonnés et la figure sert d’illustration pour mieux cerner ces principales étapes
15
Figure 24 : Architecture de la stratégie de migration
La migration se passera essentiellement entre les trois plateformes présentées par la figure 24.
7.3.1 La migration sur la «Test Bed» La « Test Bed » représente une copie réduite de la plateforme de Réseau Intelligent IN ZTE. Elle est utilisée pour faire les tests avant toute mise en production sur la plateforme de production. La migration sur la « Test Bed »est représentée par l’étape 1 de la figure 24 .Elle consiste à importer les fichiers contenant les clients Postpaid (Numéros de téléphone), leurs contrats (PricePlan), leurs balances (montant de crédit disponible) et leurs états (valide, suspendu ou invalide). Ces fichiers sont en format cvs ou xls extraits depuis la plateforme Alcatel. Ensuite on associe le GT de la plateforme de test (Test Bed) à ces abonnés puis on effectue des appels et on s’assure de la cohérence dans la valorisation de ces appels. On rappelle que le GT signifie Global Title et représente l’identifiant d’un Réseau Intelligent. Cette information est nécessaire pour la désignation de la plateforme IN en charge de valoriser les services utilisés par l’abonné.
15
Cette migration a été réalisée puis un fichier de consistance a été généré pour faire la comparaison avec les données de l’extraction Alcatel. Ce fichier de consistance contient le nombre total d’abonnés migrés, le nombre total de compte actifs, la somme de tous les crédits des abonnés
7.3.2 La migration à Blanc La migration à Blanc quand à elle consiste à importer ces mêmes données produites par la plateforme Alcatel mais cette fois dans la base de la plateforme de production IN ZTE. Dans ce cas de migration le GT des clients ne change pas il reste toujours celui du Réseau Intelligent Alcatel. L’objectif est de s’assurer de la cohérence et la concordance des données comme les services et le statut des abonnés. Les abonnés continuent d’être valorisés par l’ancienne plateforme puisque le GT ne change pas. Il s’agit de l’étape 2 et la figure 24
7.3.3 La migration Réelle La migration réelle est la phase finale elle représente la migration à Blanc avec changement de GT. Cette fois avec le changement du GT les abonnés sont pris en charge par l’IN ZTE de production. Généralement cette migration se déroule dans un temps très court, et de préférence à une heure ou le réseau est moins sollicité. Cette phase doit permettre à la fois d’effectuer la reprise des données avec les dernières saisies et journées comptables, de valider que la reprise est correcte en terme de quantité et de qualité, puis de décider si le GO peut-être donné. Les traitements de démarrage doivent également être lancés et vérifiés.
15
CHAPITRE VIII: ETAPES SUIVANTES ET PERSPECTIVES DU PROJET 8.1- Les étapes suivantes du projet Nous faisons un rappel sur les différentes étapes de notre projet de migration à travers le schéma cidessous.
15
Figure 25 : Etapes de la réalisation du projet de migration L’état d’avancement de notre projet de migration est tel que nous avons réalisé les tests de migration présentés dans la stratégie de migration. Il reste plus que la migration réelle. La migration réelle ne peut pas être envisagée sans une démarche d'accompagnement du changement ainsi une dernière étape s’ajoute à ce schéma à savoir Les l’analyse des risques et de l’impact. Cette étape fait allusion aux actionsà mener pour assurer un plan de continuité.
L’analyse de risque débute par une identification des menaces sur le système d’information. Les menaces peuvent être d’origine humaine (attaque délibérée ou maladresse) ou d’origine « naturelle » ; elles peuvent être internes à l’entreprise ou externes. On déduit ensuite le risque qui découle des menaces identifiées ; on mesure l’impact possible de ces risques. Enfin, on décide de mettre en œuvre des mesures d’atténuation des risques en se concentrant sur ceux qui ont un impact significatif. 15
Dans le cadre spécifique de notre projet les risques de la migration réelle sont les suivantes : - Les échecs d’appels dus au fait qu’à un moment donné de la migration aucune plateforme de valorisation IN ne prend en charge un abonné. Il s’agit du moment entre l’importation des données de l’ancienne plateforme et l’exportation de ces données dans la plateforme cible. La mesure à prendre pour atténuer voir éviter ce risque est de réaliser ces opérations d’exportation et d’importation à une heure tardive (heure de bas trafic). - La gratuité des appels qui intervient pendant la période de changement de GT des abonnés. Pour minimiser ces risques le changement de GT par un programme dont le temps d’exécution est insignifiant est préférable. -L’incohérence dans la valorisation occasionnée par l’existence de certains comptes sur l’ancienne plateforme. En effet après l’opération d’exportation de données depuis la l’ancienne plateforme lorsque de nouveau contrats sont créés sur celle-ci, ils ne sont pas pris en compte par la plateforme cible. L’analyse d’impact consiste à évaluer quel est l’impact d’un risque qui se matérialise et à déterminer à partir de quand cet impact est intolérable, généralement parce qu’il met en danger les processus essentiels (donc, la survie) de l’entreprise. Ainsi pour tous les risques précédemment cités l’impact se résume à la baisse du chiffre d’affaire de l’entreprise lorsque ces risques sont importants.
8.2-
Perspectives du projet
Pour la suite de ce projet nous suggérons à Orange CI de procéder à la migration proprement dite c’est-à-dire à la migration réelle en se basant sur la stratégie de migration proposée à la fin de notre étude. Nous rappelons le schéma à utiliser pour accomplir cette migration
15
Figure26 : stratégie de migration réelle Pour ce fait la mise en place d’un outil de migration représenté par le pont de la figure 24 est à encourager. Cet outil permettra d’exporter des données depuis la plateforme IN ZTE de test vers la plateforme IN ZTE de production. Ensuite après la migration l’organisation des séances de formation portant sur la gestion des clients Postpaid (création d’un contrat Postpaid, ajout d’un service à un contrat, suspension d’un contrat…) doit suivre. Ces formations concernent essentiellement le service exploitation de la plateforme et le et le service clients pour faire face aux plaintes clients. Pour finir nous préconisons la mise en place d’une copie de la nouvelle plateforme dans une autre localité pour assurer la relève en cas de sinistre ou autre cas de disfonctionnement pouvant mettre la nouvelle plateforme hors service.
CONCLUSION L’étude que nous avons réalisée a été faite sur demande du groupe Orange Cote d’Ivoire Telecom pour qui la maîtrise de sa politique de valorisation est un souci majeur. Ainsi notre thème 15
intitulé Etude et réalisation de la migration d’un Réseau Intelligent IN nous a permis de mettre en place une architecture flexible et performante du Réseau Intelligent. Le bilan est tel que nous avons procédé à la description du système actuel en termes de l’état de la plateforme de valorisation. Ce qui nous à permis de mieux cerner le fonctionnement du système existant, de montrer ses limites et enfin de proposer des solutions pour la mise en place d’une unification des deux plateformes initiales. Par ailleurs, nous avons procédé à la présentation des abonnés et services faisant objet de migration. Cette présentation nous a permis le paramétrage et la configuration de ses services sur la nouvelle plateforme. Nous avons en suite effectué le dimensionnement de la plateforme cible et aussi effectué des tests de vérification sur un environnement de test. La mise en place d’une stratégie de migration s’adaptant au mieux s’en est suivie. Le travail qui nous a été confié est à ce jour réalisé en partie. Il ne reste plus que la part de Orange CI qui consiste à réaliser la migration proprement dite en se basant sur la stratégie de migration que nous avons proposée. En ce qui nous concerne, nous sommes persuadés que la finalisation de ce projet aidera Orange et Cote d’Ivoire Telecom à mener une activité plus efficace afin de garantir une politique efficiente de valorisation de ses services.
REFERENCES BIBLIOGRAPHIQUES Documents 15
C. Demoulin, M. Van Droogenbroeck. Principes de base du fonctionnement du réseau GSM. Revue de l'AIM, pages 3–18, N°4, 2004. Brochure d’Information, Edition 2010 France Télécom et Orange en Afrique, au Moyen-Orient et en Asie. Mobio Chrysostome, 2010 Conception d’un outil de Reporting pour le Mobile Banking Service Orange Money« Mémoire de fin de cycle », ESI, INP-HB, Yamoussoukro.
Fadé Franck, 2010 Mise en place de méthode de résolution de défauts QoS sur réseau DATA : Cas de ORANGE Côte d’Ivoire « Mémoire de fin de cycle », E.S.I, INP-HB, Yamoussoukro, pages 410. Abdessalem MRIBAH, 2006 Etude et Dimensionnement d’un Réseau de Nouvelle Génération (NGN) Cas d’étude : Tunisie Telecom « Mémoire de fin de cycle », Sup’Com, Tunis.
Sites web Site Web d’Orange Côte d’Ivoire | Présentation de Orange Côte d’Ivoire , Site web Etude et formation en Télécommunication | Tutoriels Proposés ,
GLOSSAIRE BSC: Base Station controller BTS: Base Station Transceiver CDR: Call Details Record 15
CP: Call processor CSIP:Cloud Services Innovation Platform GSM: Global System Mobile HLR: Home Location Register HTTP: HyperText Transfert Protocol IMP: Interface Machine Processor IN: Intelligent Network IP: Intelligent Peripherical IVR: Interactive Voice Response MSC:Mobile Switching Center NAS:Network Access Server OCI: Orange Côte d’Ivoire. OCIT: Orange et Côte d’Ivoire Télécom. OCS:Online Charging System OLC: On-Line Charging OPI:Open Prepress Interface PSTN:Public Switched Telephone Network RI : Réseau Intelligent SCP : Service Control Point SDP: Service Data Point
SIU:Signaling Interface Unit SMP: Service Management Point SMS : Short Messager Service SVA : Service à Valeur Ajoutée USSD: Unstructured Supplementary Service Data 15
VLR:Visitor Location Register XML: Extensible Markup Language
15
ANNEXES
15
ANNEXE1: Architecture complète de l’IN ZTE
15
CC Terminal
SDP
Phase 2 Storage Disk Array: EMC
Backup Tap Library
SAN switch
Suse Linux, OCI provide f5
SDP2
SDP1
DB2
DB1
App1
App2 App3
App4
OAM
Proxy Charging ALU/ Logica?
CDR Server
App5
Esmertec
XML
Layer-3 switch 10/100/1000M
USSD
XML UIP2
UIP1
UIP3
UIP4
UIP5
UIP6
OLC1
Zebra E-topup
OLC2
Terminal OAM
Apache Load Balance, run UIP and webservice OLC
network
KPSA
Network Disk Array
SCP
CDR
USSD Web YZ Web
IP
E1
Foreign MSC
E1
STP
STP
CAMEL V1 Sms charging
MSC/HLR
MSC/HLR
Voucher ALU
1000M Ethernet
Fiber Channel
SMPP Noticfication
SCP
Storage Disk Array: EMC
MAP
Services: - IVR (consult, main, F&F) - SMS charging - voice (nat. & roaming) - SMS roaming (MAP GW) - USSD (consult & refill)
SCP
SIU/MAP GW
ALU MAP GW
6
YZ DB
SMP
IP OAM
1
OPI
Switch
SIU OAM
4
1 4
1 IMP
SMSC
Heart Beat
SMP1
199.8.80.141
IMP4
199.8.80.154
OLC1
E1 199.8.80.201
UIP6
199.8.80.228
YZ DB1
199.8.80.143
SMP2
199.8.80.142
OPI1
199.8.80.160
OLC2
199.8.80.202
APP1
199.8.82.231
YZ DB2
199.8.80.144
SCP1
199.8.80.134
OPI2
199.8.80.161
SDP1
199.8.80.207
APP2
199.8.82.232
YZ Web
199.8.80.173
SCP2
199.8.80.135
OPI3
199.8.80.162
SDP2
199.8.80.208
APP3
199.8.82.233
SCP3
199.8.80.136
OPI4
199.8.80.163
OCSDB1
199.8.80.215
APP4
199.8.82.234
SCP4
199.8.80.137
USSD Web1
199.8.80.171
OCSDB2
199.8.80.216
APP5
199.8.82.235
SCP5
199.8.80.138
USSD Web2
199.8.80.172
UIP1
199.8.80.221
CDR
199.8.82.240
SCP6
199.8.80.139
SIU OAM
199.8.80.129
UIP2
199.8.80.222
FC Switch1
10.1.1.254
IMP1
199.8.80.151
IP OAM
199.8.84.129
UIP3
199.8.80.225
FC Switch2
IMP2
199.8.80.152
CDR1
199.8.80.181
UIP4
199.8.80.226
EMC CX3-20
IMP3
199.8.80.153
IP OAM
199.8.80.182
UIP5
199.8.80.227
HP TAPE LIBRARY
10.1.2.254 SPA:10.1.1.11 SPB:10.1.2.11 10.1.1.21
SS7
15
ANNEXE 2: Liste de quelques PricePlan à créer sur ZTE
PROFILS BSCS B 1000 B 1000 GC B 1000 Report B 15-1000 B 15-1000 Report B 15-300 B 15-300 Report B 300 B 300 Report Forfait Data Mobile GPRS 100 M Business GPRS 30 M Business GPRS 5 M Business Forfait Data Mobile Formule 100 Formule 100 Report Formule 12.5 Formule 12.5 Report Formule 25 Formule 25 Report Formule 50 Formule 50 Report GPRS 100 M Particulier GPRS 30 M Particulier GPRS 5 M Particulier Data B1000 Orange Data Business 10 Orange Data Business 25 Orange Data Business 5 Orange Data Promo Bureau Mobile Orange Data Business 50 Classic '6 Classic '15 Classic '30 Intens '100 Intens '50
type abonné POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID POSTPAID MIXTE MIXTE MIXTE MIXTE MIXTE
Nom du PricePlan ZTE SP_D_B_1000 SP_D_B_1000_GC SP_D_B_1000_Report SP_D_B_15-1000 SP_D_B_15-1000_Report SP_D_B_15-300 SP_D_B_15-300_Report SP_D_B_300 SP_D_B_300_Report SP_I_Forfait_Data_Mobile SP_I_GPRS_100_M_Business SP_I_GPRS_30_M_Business SP_I_GPRS_5_M_Business SP_I_Forfait_Data_Mobile SP_D_Formule_100 SP_D_Formule_100_Report SP_D_Formule_12.5 SP_D_Formule_12.5_Report SP_D_Formule_25 SP_D_Formule_25_Report SP_D_Formule_50 SP_D_Formule_50_Report SP_I_GPRS_100_M_Particulier SP_I_GPRS_30_M_Particulier SP_I_GPRS_5_M_Particulier SP_D_Data_B1000 SP_D_Orange_Data_Business_10 SP_D_Orange_Data_Business_25 SP_D_Orange_Data_Business_5 SP_D_Orange_Promo_Bureau_Mobile SP_D_Orange_Data_Business_50 SP_D_Classic_6 SP_D_Classic_15 SP_D_Classic_30 SP_D_Intens_100 SP_D_Intens_50
15
ANNEXE 3: Liste des paramètres Limite Conso
Paramètres BSCS Limit_0 Limit_5000 Limit_10000 Limit_12500 Limit_15000 Limit_20000 Limit_25000 Limit_30000 Limit_35000 Limit_40000 Limit_50000 Limit_60000 Limit_70000 Limit_75000 Limit_80000 Limit_90000 Limit_100000 Limit_120000 Limit_150000 Limit_175000 Limit_200000 Limit_250000 Limit_300000 Limit_350000 Limit_400000 Limit_500000 Limit_600000 Limit_700000 Limit_800000 Limit_1000000 Limit_1500000 Limit_2000000 Limit_2500000 Limit_3000000 Limit_4000000 Limit_5000000 Limit_6000000
Paramètres IN ZTE Limit_0 Limit_5000 Limit_10000 Limit_12500 Limit_15000 Limit_20000 Limit_25000 Limit_30000 Limit_35000 Limit_40000 Limit_50000 Limit_60000 Limit_70000 Limit_75000 Limit_80000 Limit_90000 Limit_100000 Limit_120000 Limit_150000 Limit_175000 Limit_200000 Limit_250000 Limit_300000 Limit_350000 Limit_400000 Limit_500000 Limit_600000 Limit_700000 Limit_800000 Limit_1000000 Limit_1500000 Limit_2000000 Limit_2500000 Limit_3000000 Limit_4000000 Limit_5000000 Limit_6000000
Montant de la Limite Conso 0 5000 10000 12500 15000 20000 25000 30000 35000 40000 50000 60000 70000 75000 80000 90000 100000 120000 150000 175000 200000 250000 300000 350000 400000 500000 600000 700000 800000 1000000 1500000 2000000 2500000 3000000 4000000 5000000 6000000
15
ANNEXE 4: Format d’un CDR
Le fichier CDR est généré après chaque opération (événement effectué) sur le réseau ce fichier est ensuite interprété et va servir de moyen d’établissement de la facture de l’abonné Postpaid. Les informations trouvées dans un fichier CDR sont renseignées dans le tableau suivant
Nom du Champ
Description du champ
Code du Champ 1 2 3 4 7 8 9 14 19 20
CALLING_NBR CALLED_NBR START_TIME DURATION CALL_TYPE CALLING_PREFIX CALLED_PREFIX BUNDLE_ID BUNDLE_NAME EVENT_RATE
numéro appelant numéro appelé heure d'appel durée d'appel type d'événement indicatif de l'appelant indicatif de l'appelé code du compte à débiter nom du compte à débiter frais de l'événement
Tableau 15 : Description de champs d’un CDR
Comme exemple les CDR généré après trafic du numéro 07 00 02 25
15
15