Vous êtes sur la page 1sur 105

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

I
Mémoire de fin de cycle Master Génie Informatique et Réseaux
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

I
Mémoire de fin de cycle Master Génie Informatique et Réseaux
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,

I
Mémoire de fin de cycle Master Génie Informatique et Réseaux
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 ;

I
Mémoire de fin de cycle Master Génie Informatique et Réseaux
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 :

I
Mémoire de fin de cycle Master Génie Informatique et Réseaux
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

I
Mémoire de fin de cycle Master Génie Informatique et Réseaux
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

I
Mémoire de fin de cycle Master Génie Informatique et Réseaux
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

I
Mémoire de fin de cycle Master Génie Informatique et Réseaux
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.

I
Mémoire de fin de cycle Master Génie Informatique et Réseaux
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.

I
Mémoire de fin de cycle Master Génie Informatique et Réseaux
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 DMC DC DAQ

DO DED DRL

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
SERVICE RESEAU
ARCHITECTURE ET
INTERNE
DIMENSIONNEMENT

INGENIERIE RESEAU TRANSMISSION IP RESEAU STRUCTURANT


INNOVATION &
PROJETS SI D’ACCES MOBILE ET & RESEAUX ET PLATES-FORMES DE
CONTENUS
DEPLOIEMENT D’ACCES 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 DELL, HP, IBM


portables Go de RAM

Ordinateurs bureau 2,60 GHz, 1 Go de RAM, 160 Go de 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 Lexmark, HP,


Couleur17Multifonction 16 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 « <SOAP-ENV> ». 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

Nombre Abonnés

Voix (CAPS) 76 81 106 122

SMS et MMS(CAPS) 58 72 99 115

Data(CAPS) 19 29 45 50

requêtes plateformes 105 165 230 250


externes(CAPS)

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 105 165 230 250


(Requêtes, USSD) (CAPS)

Serveur OLC (Voix, SMS, 153 182 250 287


data)(CAPS)

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 4

IN ZTE
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 <header>
Cette balise contient deux types de balise fils <ACTION_ID> qui désigne le nom de la
commande et la balise <REQUEST_ID> 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 <Body>, 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.

<IN ZTE> 
   <header>
      <ACTION_ID>ModSubsProfile</ACTION_ID>
      <REQUEST_ID>0130090311</REQUEST_ID>
    </header>
  <body>
        <MSISDN>22507000961</MSISDN>
        <SubsAttrDtoList>
             <SubsAttrDto>
            <AttrCode>ALERT_TR1</AttrCode>
            <AttrValue></AttrValue>
</SubsAttrDto>
<SubsAttrDto>
            <AttrCode>ALERT_TR2</AttrCode>
            <AttrValue></AttrValue>
</SubsAttrDto>
<SubsAttrDto>
            <AttrCode>ALERT_TR3</AttrCode>
            <AttrValue></AttrValue>
            <SubsAttrDto>
                        <AttrCode>LIMITE_CONSO</AttrCode>
                        <AttrValue>CC_300000_CFA</AttrValue>
            </SubsAttrDto>
 </body>
15
 </IN ZTE>
Nom du Type Taille Description du Remarque

Paramètre Paramètre Paramètre Paramètre

MSISDN String 1~60 Le numéro MSISDN du Obligatoire


bénéficiaire
AttrCode String 1~60 Code du paramètre service à Optionnel
ajouter

AttrValue String 1~8 Valeur du paramètre service à Optionnel


ajouter

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

<IN ZTE>
   <Data>
      <header>
      <ACTION_ID>AddCUG</ACTION_ID>
      <REQUEST_ID>002008899100001</REQUEST_ID>
    </header>
    <body>
        <CUGName>5535058</ CUGName>
        <AdminMSISDN>22547588589</AdminMSISDN>
        <AdminPwd></AdminPwd>
<CUGTypeID>C</CUGTypeID>
<CUGMemberDtoList></ CUGMemberDtoList>
<PricePlanCode>CUG_INTRA_GFU</ PricePlanCode>
<MaxMemberAmount>30</ MaxMemberAmount>
</body>
  </Data>
 </IN ZTE>

15
Nom du Type Taille Description du Remarque
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 Optionnel
l’administrateur du CUG
qui est également un
membre du groupe
AdminPwd String 1~8 Mot de pass administrateur Optionnel
du CUG à utiliser pour
ajouter ou retirer un
membre du groupe
CUGTypeID String 1~3 Code du type de CUG Obligatoire
Valeur fixe
A: Appel en dehors du
groupe non autorisé
C: Appel en dehors du
groupe autorisé
CUGMemberDtoList Array La liste des membres du Optionnel
groupe
PricePlanCode String 1~60 Le PricePlan associé au Optionnel
CUG
MaxMemberAmount Long 1~6 Le nombre Limite de Optionnel
membres

Tableau 9 : Spécification des paramètres de commande AddCUG

15
 La commande DelCUGPour la suppression d’un groupe

<IN ZTE>

<Data>
<header>
<ACTION_ID>DelCUG</ACTION_ID>
<REQUEST_ID>002008899100001</REQUEST_ID>
</header>
<body>
<CUGID>5535058</CUGID>
<AdminMSISDN></AdminMSISDN>
<AdminPwd></AdminPwd>
</body>
</Data>
</IN ZTE>

Nom du Type du Taille du Description du Remarque


paramètre Paramètre paramètre paramètre
CUGID Long 1~6 Identifiant ou code du Obligatoire
CUG obtenu à partir de la
commandeQuery CUG

AdminMSISDN String 1~60 Numéro MSISDN de Optionnel


l’administrateur du groupe.

AdminPwd String 1~8 Le mot de pass de Optionnel


l’administrateur du groupe.

15
Tableau 10 : Spécification des paramètres de commande DelCUG

 La commande ExitCUG Pour retirer un membre du groupe

 
<IN ZTE>

  <Data>
   <header>
           <ACTION_ID>ExitCUG</ACTION_ID>
           <REQUEST_ID>002008111700001</REQUEST_ID>
          </header>
        <body>
         <CUGID>4973017</CUGID>
             <AdminMSISDN>22547592592</AdminMSISDN>
              <AdminPwd></ AdminPwd>
        </body> 
</Data> 
</IN ZTE>

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 Optionnel
l’administrateur du groupe.
AdminPwd String 1~8 Le mot de pass de l’administrateur Optionnel
du groupe.
MSISDN String 1~60 Numéro MSISDN du membre à Obligatoire
retirer

15
Tableau 11 : Spécification des paramètres de commande ExitCUG

 La commande JoinCUG pour ajouter un nouveau membre au groupe

 <IN ZTE>

 <Data>

   <header>

      <ACTION_ID>JoinCUG</ACTION_ID>
      <REQUEST_ID>002009031100001</REQUEST_ID>
    </header>

     <body>

        <CUGID>5535058</CUGID>
        <AdminMSISDN></AdminMSISDN>
        <AdminPwd></AdminPwd>
        <UserPwd></UserPwd>
        <MSISDN>22548154155</MSISDN>
    </body>

  </Data>

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 Obligatoire
commande QueryCUG
AdminMSISDN String 1~60 Numéro MSISDN de Optionnel
l’administrateur du CUG
AdminPwd String 1~8 Mot de pass de l’administrateur Opitonnel
du CUG.
MSISDN String 1~60 Numéro MSISDN du member à Obligatoire
ajouter
UserPwd String 1~8 Mot de pass de l’operateur Opitonnel
IsAllowOutgoingCall String 1~3 Drapeau pour autoriserles Opitonnel
appels en dehors du groupe.
Y: Outgoing call allowed
N: Outgoing call not allowed

Tableau 12 : Spécification des paramètres de commande JoinCUG

15
La commande QueryCUG pour interroger un groupe existant 
 
<IN ZTE>
   <Data>
    <header>
       <ACTION_ID>QueryCUG</ACTION_ID>
      <REQUEST_ID>00920909062500000001</REQUEST_ID>
    </header>
   <body>
        <ProviderID>0</ProviderID>
        <State>1</State>
        <MSISDN></MSISDN>
         <CUGName>CUG_311</CUGName>
  </body>
  </Data>
 

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 Obligatoire
1 s’il existe des membres
0 sinon
MSISDN String 1~8 Le numéro MSISDN de Optionnel
l’administrateur.
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

 <IN ZTE>
  
<Data>
   <header>
      <ACTION_ID>SetBalShareRule</ACTION_ID>
      <REQUEST_ID>016007789711</REQUEST_ID>
    </header>
    <body>
        <AccountCode>1876918</AccountCode>
        <AcctResCode>SHCRED</AcctResCode>
        <MSISDN>22547588589</MSISDN>
        <CeilLimite></CeilLimite>
        <DailyCeilLimite></DailyCeilLimite>  
        <EffDate>2011-10-25</EffDate>
        <PaymentForce>F</PaymentForce>
    </body>
  </Data>

 </IN ZTE>

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é à Obligatoire
la balance
AcctResCode String 1~12 The code de la balance à Obligatoire
partager
MSISDN String 1~23 Le numéro MSISDN du Obligatoire
partageur.
CeilLimite String 1~12 Valeur maximum à partager Optionnel
DailyCeilLimite String 1~12 Valeur maximum journalier Optionnel
EffDate Date 10 Date effective d’application Obligatoire
du partage
ExpDate Date 10 Date expiration du partage Obligatoire
Priority Long 1 Priorité des balances Optionnel
PaymentForce String 1 Indicateur pour signaler la Optionnel
possibilité d’effectuer des
appels après épuisement de
la balance partagée
‘N’ pour Non
‘Y’ pour Oui

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

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

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
<http://www.orange.ci/index.php?rub=orange_ci>,

Site web Etude et formation en Télécommunication | Tutoriels Proposés


<http://www.efort.com/index.php?PageID=5&l=fr>,

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
Phase 2 SDP
Storage Backup
Disk Array: EMC Tap Library

SAN switch Suse Linux, OCI OAM


provide f5 Proxy
CDR Server Charging
ALU/
Logica?
SDP1 SDP2 DB1 DB2 App1 App2 App3 App4 App5
Esmertec
XML USSD
Layer-3 switch
10/100/1000M XML
Zebra
UIP1 UIP2 UIP3 UIP4 UIP5 UIP6 OLC1 OLC2
E-topup
Apache Load Balance, run Terminal
UIP and webservice OLC OAM
KPSA
network
Network
Disk Array
SCP

Services:
SMP
1
1

SIU OAM IP OAM - IVR (consult, main, F&F)


4
4

IMP OPI - SMS charging


- voice (nat. & roaming)
- SMS roaming (MAP GW)
USSD Web YZ Web

6
Switch - USSD (consult & refill)
1
YZ DB
CDR
SIU/MAP GW SCP
IP SMPP
Storage
Disk Array: EMC
SCP Noticfication

E1 E1

ALU MAP
MAP STP STP
CAMEL V1
GW SMSC
Sms charging

Voucher
Foreign MSC MSC/HLR MSC/HLR
ALU

Fiber Channel 1000M Ethernet Heart Beat

SS7 E1
SMP1 199.8.80.141 IMP4 199.8.80.154 OLC1 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 10.1.2.254
SPA:10.1.1.11
IMP2 199.8.80.152 CDR1 199.8.80.181 UIP4 199.8.80.226 EMC CX3-20
SPB:10.1.2.11
IMP3 199.8.80.153 IP OAM 199.8.80.182 UIP5 199.8.80.227 HP TAPE LIBRARY 10.1.1.21

15
ANNEXE 2:

Liste de quelques PricePlan à créer sur ZTE

PROFILS BSCS type abonné Nom du PricePlan ZTE


B 1000 POSTPAID SP_D_B_1000
B 1000 GC POSTPAID SP_D_B_1000_GC
B 1000 Report POSTPAID SP_D_B_1000_Report
B 15-1000 POSTPAID SP_D_B_15-1000
B 15-1000 Report POSTPAID SP_D_B_15-1000_Report
B 15-300 POSTPAID SP_D_B_15-300
B 15-300 Report POSTPAID SP_D_B_15-300_Report
B 300 POSTPAID SP_D_B_300
B 300 Report POSTPAID SP_D_B_300_Report
Forfait Data Mobile POSTPAID SP_I_Forfait_Data_Mobile
GPRS 100 M Business POSTPAID SP_I_GPRS_100_M_Business
GPRS 30 M Business POSTPAID SP_I_GPRS_30_M_Business
GPRS 5 M Business POSTPAID SP_I_GPRS_5_M_Business
Forfait Data Mobile POSTPAID SP_I_Forfait_Data_Mobile
Formule 100 POSTPAID SP_D_Formule_100
Formule 100 Report POSTPAID SP_D_Formule_100_Report
Formule 12.5 POSTPAID SP_D_Formule_12.5
Formule 12.5 Report POSTPAID SP_D_Formule_12.5_Report
Formule 25 POSTPAID SP_D_Formule_25
Formule 25 Report POSTPAID SP_D_Formule_25_Report
Formule 50 POSTPAID SP_D_Formule_50
Formule 50 Report POSTPAID SP_D_Formule_50_Report
GPRS 100 M Particulier POSTPAID SP_I_GPRS_100_M_Particulier
GPRS 30 M Particulier POSTPAID SP_I_GPRS_30_M_Particulier
GPRS 5 M Particulier POSTPAID SP_I_GPRS_5_M_Particulier
Data B1000 POSTPAID SP_D_Data_B1000
Orange Data Business 10 POSTPAID SP_D_Orange_Data_Business_10
Orange Data Business 25 POSTPAID SP_D_Orange_Data_Business_25
Orange Data Business 5 POSTPAID SP_D_Orange_Data_Business_5
Orange Data Promo Bureau
POSTPAID
Mobile SP_D_Orange_Promo_Bureau_Mobile
Orange Data Business 50 POSTPAID SP_D_Orange_Data_Business_50
Classic '6 MIXTE SP_D_Classic_6
Classic '15 MIXTE SP_D_Classic_15
Classic '30 MIXTE SP_D_Classic_30
Intens '100 MIXTE SP_D_Intens_100
Intens '50 MIXTE SP_D_Intens_50

15
ANNEXE 3:

Liste des paramètres Limite Conso

Paramètres BSCS Paramètres IN ZTE Montant de la Limite Conso

Limit_0 Limit_0 0
Limit_5000 Limit_5000 5000
Limit_10000 Limit_10000 10000
Limit_12500 Limit_12500 12500
Limit_15000 Limit_15000 15000
Limit_20000 Limit_20000 20000
Limit_25000 Limit_25000 25000
Limit_30000 Limit_30000 30000
Limit_35000 Limit_35000 35000
Limit_40000 Limit_40000 40000
Limit_50000 Limit_50000 50000
Limit_60000 Limit_60000 60000
Limit_70000 Limit_70000 70000
Limit_75000 Limit_75000 75000
Limit_80000 Limit_80000 80000
Limit_90000 Limit_90000 90000
Limit_100000 Limit_100000 100000
Limit_120000 Limit_120000 120000
Limit_150000 Limit_150000 150000
Limit_175000 Limit_175000 175000
Limit_200000 Limit_200000 200000
Limit_250000 Limit_250000 250000
Limit_300000 Limit_300000 300000
Limit_350000 Limit_350000 350000
Limit_400000 Limit_400000 400000
Limit_500000 Limit_500000 500000
Limit_600000 Limit_600000 600000
Limit_700000 Limit_700000 700000
Limit_800000 Limit_800000 800000
Limit_1000000 Limit_1000000 1000000
Limit_1500000 Limit_1500000 1500000
Limit_2000000 Limit_2000000 2000000
Limit_2500000 Limit_2500000 2500000
Limit_3000000 Limit_3000000 3000000
Limit_4000000 Limit_4000000 4000000
Limit_5000000 Limit_5000000 5000000
Limit_6000000 Limit_6000000 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 CALLING_NBR numéro appelant
2 CALLED_NBR numéro appelé
3 START_TIME heure d'appel
4 DURATION durée d'appel
7 CALL_TYPE type d'événement
8 CALLING_PREFIX indicatif de l'appelant
9 CALLED_PREFIX indicatif de l'appelé
14 BUNDLE_ID code du compte à débiter
19 BUNDLE_NAME nom du compte à débiter
20 EVENT_RATE 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