PFE SAIHI Afef

Dédicaces
A l’âme de ma chère mère...
A mon cher père,
A mon cher fiancé,
A toute ma famille et tous mes amis,
Afef "
Avant - Propos
Le travail présenté dans ce rapport a été effectué dans le cadre de notre projet de fin
d’études du cycle d’Ingénieur en Télécommunications à l’Ecole Supérieure des
Communications de Tunis (Sup’Com). Ce projet a été réalisé en collaboration avec la
société SIEMENS de Tunisie.
Au terme de ce travail, je tiens à exprimer mes remerciements à mon encadrant, à

Sup’Com, Monsieur Mounir FRIKHA, Maître assistant et Directeur du Département
Informatique et réseaux, et à mon encadrant, à SIEMENS, Monsieur Khalifa
NADDARI, Ingénieur de projets au service « IN Solutions », pour leurs idées, leurs
directives et leurs pédagogies.
Ma profonde reconnaissance s’adresse aussi à tout le personnel de SIEMENS et

spécialement à Monsieur Housseme Eddine Ben Othmen, Directeur du département
« Carrier Networks » et à Madame Barketalleh Zeineb, Ingénieur de projets au
département « Information technologies ».
Je tiens aussi à remercier tous les enseignants et les responsables de Sup’COM, ainsi
que tous les membres du jury pour l’honneur qu’ils me font en acceptant d’évaluer
mon travail.
i
Résumé
Ce projet consiste à étudier la plate-forme réseau intelligent INXpress de SIEMENS

en vue d’analyser sa performance et d’étudier l’efficacité des algorithmes de
protection contre les surcharges.
Après une analyse des principes généraux de ce type de réseau et de l’architecture de

la plate-forme, nous avons conçu un modèle à base de files d’attentes pour ce
système. Les paramètres du modèle ont été, par la suite, définis et ajustés en se basant
sur des mesures réelles à partir des fichiers de statistiques fournis par la plate-forme.
Nous avons implanté le modèle conçu et nous avons simulé des situations de
surcharge pour évaluer la robustesse de l’algorithme ACG.
La dernière étape a consisté à concevoir et implanter une application permettant le

suivi de l’évolution de la plate-forme par le biais du calcul et du stockage de ses
indicateurs de performance.
Mots Clés
Réseau intelligent, SCP, SSP, SS7, Modélisation, Simulation, Automatic Call Gap,
Indicateur de performance, Performance Monitor.
ii
Table des matières
Liste des figures ......................................................................................................................... v

Liste des abréviations ............................................................................................................... vii
Introduction générale.................................................................................................................. 1
CHAPITRE I : LE RESEAU INTELLIGENT ..................................................................... 3
I- Introduction .................................................................................................................... 3
II- Principes généraux du Réseau Intelligent ..................................................................... 3
II-1- Définition du RI.................................................................................................................. 3
II-2- Objectifs du RI ................................................................................................................... 3
III- Modèle conceptuel du réseau intelligent...................................................................... 4
III -1- Le plan de service (SP : Service Plane)........................................................................... 5
III -2- Le plan fonctionnel global : (GFP : Global Functional Plane) ...................................... 5
III -3- Le plan fonctionnel réparti .............................................................................................. 5
III -4- Le plan physique .............................................................................................................. 7
III -5- Les relations entre les plans ............................................................................................ 7
IV- Architecture du réseau intelligent : INXpress de Siemens .......................................... 8
IV-1- Environnement de Création de Services (Service Creation Environment) : SCE............. 9
IV-2- Point de Gestion de Services (Service Management Point) : SMP................................. 11
IV-3- Point de Contrôle de Services (Service Control Point) : SCP ........................................ 12
V- Présentation des services du réseau intelligent ........................................................... 12
V-1- Définition de la notion de service .................................................................................... 12
V-2- Présentation des différents services ................................................................................. 13
VI- Conclusion ................................................................................................................. 15
CHAPITRE II : MODELISATION DU RESEAU INTELLIGENT.............................. 16
I- Introduction .................................................................................................................. 16
II- Le concept d’évaluation de performance .................................................................... 16
II-1- Eléments nécessaires........................................................................................................ 16
II-2- Les techniques d’évaluation de performance................................................................... 17
III- Besoin d’étudier les performances du réseau intelligent ........................................... 18
IV- Présentation du SCP .................................................................................................. 19
IV-1- Architecture Hardware du SCP ...................................................................................... 20
IV-2- Architecture Software du SCP ........................................................................................ 20
V- Démarche pour l’étude de performance d’un réseau intelligent ................................. 21
V-1- Introduction...................................................................................................................... 21
iii
V-2- Modélisation..................................................................................................................... 21
VI- Conclusion ................................................................................................................. 24
CHAPITRE III : CARACTERISATION DU MODELE PAR DES MESURES ......... 25
I- Introduction .................................................................................................................. 25
II- Présentation des fichiers de mesures........................................................................... 25
III- Méthodologie de caractérisation du trafic.................................................................. 26
III -1- Conversion des fichiers binaires ................................................................................... 27
III -2- Filtrage des fichiers de mesures .................................................................................... 27
III -3- Représentation du trafic ................................................................................................ 28
III -4- Loi d’arrivée .................................................................................................................. 28
III -5- Trafic d’une journée ...................................................................................................... 32
III -6- Délai d’attente ............................................................................................................... 33
III -7- Méthodologie ................................................................................................................. 34
III -8- Représentation ............................................................................................................... 34
III -9- Loi de service................................................................................................................. 36
III -10- Méthodologie :............................................................................................................. 37
III -11- Représentation ............................................................................................................. 37
V- Conclusion .................................................................................................................. 39
CHAPITRE IV : CONCEPTION ET REALISATION DE L’APPLICATION ........... 40
I- Introduction .................................................................................................................. 40
II- Mécanisme de contrôle de surcharge dans le réseau intelligent.................................. 40
II-1- Description générale de la surcharge du SCP................................................................. 40
II-2- Principe de fonctionnement du Call Gapping.................................................................. 41
III - Mise en place du simulateur ..................................................................................... 42
III -1- Besoin de simuler........................................................................................................... 42
III -2- Implantation du simulateur du modèle .......................................................................... 43
III -3- Implantation du mécanisme du "Call Gap"................................................................... 44
III -4- Résultats de simulation .................................................................................................. 46
IV – Conception et implantation de l’application « Performance Monitor »................... 49
IV-1- Besoin et objectifs de l’application................................................................................. 49
IV-2- Architecture du « Performance Monitor »...................................................................... 50
IV-3- Rubriques de l’interface graphique ................................................................................ 54
V- Manuel d’utilisation du « Performance Monitor »...................................................... 57
V-1- Présentation de l’interface de « PerfMon » ..................................................................... 57
V-2- Performance par simulation............................................................................................. 57
V-3- Performance par mesures ................................................................................................ 60
VI- Conclusion ................................................................................................................. 64
Conclusion générale ................................................................................................................. 65
iv
Liste des figures
Figure I-1 Relations entre plans .............................................................................................................. 8

Figure I-2 Plate-forme INXpress de Siemens ......................................................................................... 9
Figure II-1 Architecture Hardware du SCP........................................................................................... 20
Figure II-2 Architecture Software du SCP ............................................................................................ 21
Figure II-3 Principe du déroulement d’un appel dans le RI .................................................................. 22
Figure II-4 Modèle associé au RI .......................................................................................................... 23
Figure II-5 Structure en processus au niveau du SCP ........................................................................... 24
Figure III-1 Préparation des fichiers de mesures................................................................................... 28
Figure III-2 Distribution du nombre d’appels par minute le long d’une journée .................................. 28
Figure III-3 loi d’arrivée des appels sur une journée ............................................................................ 30
Figure III-4 loi d’arrivée des appels sur une ½ heure............................................................................ 30
Figure III-5 loi de poisson obtenue par application de la méthode des moindres carrés....................... 32
Figure III-6 loi multimodale poissonienne ............................................................................................ 33
FigureIII-7 Densité de probabilité du délai d’attente en secondes ........................................................ 34
Figure III-8 Fonction de répartition du délai d’attente en secondes..................................................... 35
Figure III-9 Superposition avec la fonction de répartition Gamma....................................................... 35
Figure III-10 Superposition avec la densité de probabilité de la loi Gamma ........................................ 36
Figure III-11 Densité du Holding time.................................................................................................. 37
Figure III-12 Fonction de répartition du Holding time ......................................................................... 38
Figure III-13 Superposition des lois réelles avec la loi exponentielle................................................... 39
Figure IV-1 Organigramme de Simulation............................................................................................ 44
Figure IV-2 Procédure d’activation du mécanisme du Call Gap........................................................... 45
Figure IV-3 Fonctionnement du Call Gap............................................................................................. 46
Figure IV-4 Trafic total et trafic traité pour un taux d’arrivée λ = 80 ................................................... 47
Figure IV-7 Trafic total et trafic traité pour des taux d’arrivée variables ............................................. 49
Figure IV-8 Trafic traité au cours d’une période de surcharge ............................................................. 49
Figure IV-9 Architecture de l’application « PerfMon » ........................................................................ 50
Figure IV-10 Module de collecte des mesures ...................................................................................... 52
Figure IV-11 Cycle de vie des fichiers de mesures ............................................................................... 53
v
Figure IV-12 Algorithme de taxation .................................................................................................... 56
Figure IV-13 Ecran principal du « PerfMon » ...................................................................................... 57
Figure IV-14 Ecran du simulateur......................................................................................................... 59
Figure IV-15 Exemple d’exécution pour le simulateur ......................................................................... 59
Figure IV-16 Statistiques et représentation du trafic total..................................................................... 60
Figure IV-17 Choix de l’indicateur ....................................................................................................... 62
Figure IV-18 Appels non efficaces rejetés par tous les SSPs................................................................ 62
Figure IV-19 Présentation des indicateurs de signalisation................................................................... 63
Figure IV-20 Interface de génération de rapports ................................................................................. 63
vi
Liste des abréviations
ACG Automatic Call Gapping
ASD Advanced Service Definition
BCP Basic Call Process

CCF Call Control Function
CE Computing Element
CS Capability Set
FE Functional Entity
FPH Free Phone
GFP Global Functional Plane
GSL Global Service Logic
INAP Intelligent Network Application Part
INCM Intelligent Network Conceptual Model
ITU International Telecommunications Union
PE Physical Entities
POI Point Of Initiation
POR Point Of Return
PPC PrePaid Card
PRM Premium Rate
RI Réseau Intelligent
SC Service Customization
SCE Service Creation Environment
SCF Service Control Function
SCP Service Control Point
SDF Service Data Function
SIB Service Independent Building Block
SLP Service Logic Program
SMF Service Management Function
SMP Service Management Point
SP Service Plane
SRF Specialized Ressource Function
SSP Service Switching Point
vii
SUM Service and User Management
TCAP Transaction Capability Application Part
UAN Universal Access Number
UPT Universal Personal Telecommunication
VCC Virtual Card Calling
VOT Televoting
VPN Virtual Private Network
WebCSC Web Client Service Control
viii
Etude de Performance d’une Plate-forme Réseau Intelligent
Introduction générale
Jusqu'à un passé récent, les réseaux de télécommunications assuraient la fourniture d'un

nombre limité de services essentiels comme la téléphonie de base, le télex et la transmission
de données. Cette situation a évolué par suite de l'innovation technologique rapide et des
nouvelles conditions du marché. Dans le nouveau contexte concurrentiel, les opérateurs sont,
en effet, conduits à diversifier, dans des délais les plus courts possibles et à moindre coût,
leurs offres de services auprès de la clientèle. La structure classique des réseaux de
télécommunications avec des commutateurs indépendants, imposant des limitations dans
l'offre de services, a évolué vers une structure dans laquelle le traitement de fonctions
spécifiques est confié à des entités spécialisées commandant les commutateurs adaptés en
conséquence.
Le réseau intelligent (IN) est une technologie émergente qui permet le développement et le
déploiement des nouveaux services de télécommunications d’une manière rapide et efficace.
Actuellement, il y’a une demande croissante des nouveaux services IN, aussi bien que du
déploiement de systèmes complexes et très sophistiqués pour le support de ces services.
Toutefois, la centralisation des programmes des logiques de services, des bases de données et
d’autres fonctions de maintenance, dans le point de contrôle de service SCP, peut créer des
situations critiques et des goulots d’étranglements. C’est pourquoi, il est nécessaire d’établir
des outils capables de contrôler ces situations.
C’est dans ce cadre que se situent les travaux menés au cours de ce projet de fin d’études. En
effet, il nous a été demandé d’étudier et d’évaluer la performance de la plate-forme Réseau
Intelligent de SIEMENS et de développer des outils qui permettront à l’opérateur de procéder,
facilement et rapidement, au suivi des indicateurs de performance.
Ce présent rapport détaille le travail que nous avons réalisé. Il est composé de quatre
chapitres.
Afef SAYHI - PFE - INDP3 - 2005 1

Un premier chapitre est consacré à l’étude des réseaux intelligents. Pour cela, nous
présenterons, tout d’abord, ses principes généraux. Ensuite, nous définirons son modèle
conceptuel et les différents plans qui le composent. Et nous terminerons ce chapitre par
l’exposé de l’architecture de la plate-forme du réseau Intelligent INXpress et des différents
services offerts.
Dans le second chapitre, après avoir étudié, d’une manière générale, le principe d’évaluation
de performance, nous allons proposer un modèle à base de files d’attente pour ce système et
ceci en tenant compte de toutes les phases de déroulement d’appel.
Au cours du troisième chapitre, nous allons faire la caractérisation des paramètres du modèle
établi, dans le deuxième chapitre, et ceci en nous basant sur les mesures délivrées par le
système lui-même. Après une présentation de la structure et des différents constituants des
fichiers de mesures, nous utiliserons ces fichiers pour analyser les différents comportements
des abonnés et du système.
Le chapitre final sera consacré à la partie développement et implémentation. Au cours duquel,

nous avons commencé par l’énoncé du principe du contrôle de surcharge dans le réseau
intelligent, puis, nous avons utilisé les lois déterminées, au cours du troisième chapitre, pour
implanter un simulateur du système dans lequel nous avons implanté le mécanisme de Call
Gap en vue d’en évaluer le taux de rejet. La dernière phase était de développer un outil doté
d’interfaces graphiques qui servira aux opérateurs pour pouvoir déterminer certains
indicateurs de performance, et pour faire ceci, ils ont le choix entre le faire par simulation ou
via les mesures.

Chapitre I
Le réseau intelligent
I- Introduction
Le Réseau Intelligent (RI) est un concept général d'architecture de commande des réseaux
destiné à permettre l'introduction rapide et à moindre coût de nouveaux services en
réorganisant de façon centralisée les fonctions élémentaires de transport de l'information.
Pour pouvoir effectuer des recherches sur ce type de réseau, il faut commencer par
comprendre ses caractéristiques. C’est l’objectif de ce chapitre dans lequel nous présenterons,
en premier lieu, le principe du réseau intelligent et ses objectifs. Ensuite, nous présenterons
globalement le modèle conceptuel du réseau intelligent ainsi que son architecture. Nous
terminerons ce chapitre par la spécification de quelques services offerts par ce réseau.
II- Principes généraux du Réseau Intelligent
II-1- Définition du RI
Le Réseau Intelligent (RI) a pour objectif de faciliter l’introduction de nouveaux services en

se basant sur plus de flexibilités et des fonctionnalités nouvelles. Le terme "service" doit être
interprété dans un sens restrictif : ce sont des services réseau (de télécommunications),
construits sur des services basiques de transport d’informations tels que le transport de la
parole, de données ou d’images vidéo.
II-2- Objectifs du RI
Le réseau intelligent est défini dans la recommandation Q1290 comme un concept

architectural pour la création et la fourniture de services de télécommunications [ITU-Q1290]

L’implantation de son architecture doit faciliter l’introduction rapide et à moindre coût de

nouveaux services basés sur une plus grande flexibilité et sur de nouvelles possibilités.
Cette architecture peut être appliquée à des types variés de réseau de télécommunications, tels
que le réseau téléphonique commuté, les réseaux de données, les réseaux mobiles.
Les objectifs du réseau intelligent peuvent alors être énoncés comme permettant :
- L’introduction de nouvelles possibilités dans les réseaux de télécommunications pour

faciliter et accélérer, de façon efficace et économique, l’implantation et la provision de
services dans un environnement multi-vendeurs ;
- L’indépendance des opérateurs vis-à-vis des constructeurs ;
- Un meilleur contrôle de l’introduction de services et du coût de fonctionnement ;
- Une adéquation entre l’offre de services et la demande des utilisateurs.
Ainsi, le but visé est d’obtenir la possibilité de programmer le réseau par la définition d’une
architecture indépendante du type de réseau et de l’implantation de services. De ces objectifs,
découle le principe du réseau intelligent, qui repose sur une séparation claire entre les
fonctions liées au réseau (les ressources) et celles qui sont intrinsèquement programmables
(les services) Les ressources regroupent toutes les fonctions qui permettent le traitement
d’appel de base (telles que le routage d’appel ou la commutation) ainsi que certaines fonctions
spécifiques qui sont liées à l’existence d’équipements spéciaux comme les serveurs
d’annonces. Les services sont constitués de logiciels qui pilotent ces ressources pour obtenir
des applications allant au-delà de l’appel de base. Ces logiciels sont constitués d’algorithmes
(logique de service) et de données qui doivent pouvoir être modifiées facilement sans remettre
en cause l’agencement du réseau.
III- Modèle 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 à la spécification et à la description de cette architecture.
Le modèle conceptuel du réseau intelligent (Intelligent Network Conceptual Model-INCM),

décrit dans la recommandation Q1201, n’est pas une architecture mais une démarche
méthodologique pour concevoir et décrire une architecture du réseau intelligent. En effet, il
est prévu de disposer d’ensembles de capacités (Capability Set) successifs, où à chaque
ensemble correspond la définition d’une architecture [7].

Le modèle est composé de quatre plans qui sont le plan service, le plan fonctionnel global, le
plan fonctionnel réparti et le plan physique.
III -1- Plan de service (SP : Service Plane)
Le plan de services 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
opérateur) pour des abonnées pour satisfaire un besoin de télécommunications. Un service
consiste en un ou plusieurs éléments de services (SF : Service Feature ), un élément de service
étant la plus petite unité utilisée à ce niveau. Un élément de service est un composant de
service correspondant à une partie de 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é.
III -2- Plan fonctionnel global : (GFP : Global Functional Plane)
Le plan fonctionnel global correspond à l’interface de programmation. Il modélise un réseau

intelligent comme une seule entité ou comme une machine virtuelle unique et globale. 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 chaînage de SIBs. Ce chaînage commence à un endroit précis dans le traitement d’appel.
Ce point de départ est appelé point d’initiation (Point Of Initiation). Dans l’exemple du
service du numéro vert, le POI correspond à la détection du préfixe « 80100 ».
Après l’exécution de la séquence de SIBs, 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 chaîne de SIBs pour un service donné, associée aux points d’initiations et de retour,
constitue une logique globale de service (GSL : Global Service Logic).
III -3- Plan fonctionnel réparti
Le plan fonctionnel réparti modélise une vue distribuée d’un réseau intelligent en décrivant
son architecture fonctionnelle. Il est composé d’entités fonctionnelles (Functional Entity : FE)

qui exécutent des actions (Functional Entity Actions : FEA). Une entité fonctionnelle
représente un groupe de fonctions localisées à un seul endroit. Elle constitue un sous-
ensemble de l’ensemble complet des fonctions nécessaires pour fournir un service. Deux
catégories d’entités fonctionnelles sont identifiées : celles relatives à la création et à la gestion
de service et celles relatives à l’exécution de service. Dans cette catégorie, on distingue les
entités relatives au contrôle de l’appel de celles relatives au contrôle du service.
Les entités fonctionnelles de création et de gestion de service sont les suivantes :
- La fonction gestion de service (Service Management Function : SMF) qui contrôle le

déploiement et la provision de services et le support du fonctionnement courant;
- La fonction environnement de création de service (Service Création Environment
Function : SCEF) permet aux services d’être définis, développés, testés et inclus dans
l’entité SMF;
- La fonction d’accès à la gestion de service (Service Management Agent Function :
SMAF) fournit l’interface entre les gestionnaires de service et l’entité SMF.
Concernant les entités fonctionnelles d’exécution de service, on distingue les entités

fonctionnelles de contrôle d’appel et les entités fonctionnelles de contrôle de service.
Les entités fonctionnelles de contrôle d’appel sont les suivantes :
- La fonction agent de commande d’appel (Call Control Agent Function : CCAF) qui
représente l’accès utilisateur au réseau.
- La fonction commande d’appel (Call Control Function : CCF) qui traite et contrôle l’appel
et la connexion. Elle correspond à la fonction classique d’un commutateur.
- La fonction commutation de service (Service Switching Function : SSF) qui constitue
l’interface entre les entités CCF et SCF. Elle permet à l’entité CCF d’être pilotée par
l’entité SCF.
- La fonction ressources spécifiques (Specialized Ressource Function : SRF) qui donne à
d’autres entités du réseau l’accès à une catégorie de ressources.
Les entités fonctionnelles de contrôle de service sont les suivantes :
- La fonction commande de service (Service Control Function : SCF) qui contient la

logique de service du réseau intelligent et effectue les traitements nécessaires au service.

- La fonction base de données de service (Service Data Function : SDF) qui gère l’accès
aux données de service et de réseau. Elle fournit à l’entité SCF une vue logique des
données en lui masquant leur implantation.
Lorsque plusieurs entités fonctionnelles sont impliquées dans la réalisation d’un service, elles
doivent échanger des flux d’informations (Information Flow : IF).
III -4- Plan physique
Le plan physique constitue l’architecture physique du réseau intelligent. Il identifie les

différentes entités physiques (Physical Entities : PE) et les protocoles qui existent dans les
réseaux réels. Il spécifie, par ailleurs, les entités fonctionnelles implantées dans les différentes
entités physiques. Cette implémentation 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. Une entité physique, quant à elle, peut contenir plusieurs entités
fonctionnelles, sous réserve qu’elles soient de types différents.
L’architecture physique du réseau intelligent, spécialement de la plate forme INXpress, va

être explicitée par la suite.
III -5- Relations entre les plans
Les services présentés aux utilisateurs par leur description au plan service sont crées par un
concepteur via l’interface de programmation (plan fonctionnel global). Cette création consiste
en la définition d’une logique globale de service, résultant de l’association d’un chaînage de
SIBs et des points d’initiations et de retour. Chaque SIB du plan global fonctionnel est
représenté, dans le plan fonctionnel réparti, par des actions (FEAs) d’une ou plusieurs entités
fonctionnelles. A une logique globale de service, correspondent une ou plusieurs logiques
réparties de services. Cette correspondance est également établie lors du processus de création
de service. Les relations entre les entités fonctionnelles sont spécifiées par des protocoles dans
le plan physique. La logique de service peut être chargée dynamiquement dans les entités
physiques adéquates. Cette correspondance relève du processus de gestion de service.
La superposition des différents plans ainsi que les relations entre eux sont présentées par la
figure si dessous :

Figure I-1 Relations entre plans
IV- Architecture du réseau intelligent : INXpress de Siemens
Les réseaux intelligents sont composés de commutateurs, de bases de données et de serveurs

spécialisés, en plus des réseaux de transport où transitent les appels et les données des
abonnés [1].
Cette architecture est basée sur l’architecture standard du réseau intelligent définie par les
recommandations de l’ITU-T-CS1 (Capability Set 1). Dans INXpress, les unités
fonctionnelles de l’architecture standard sont implémentées dans des composants systèmes
séparés. La figure ci dessous donne un aperçu sur cette plate-forme.

Figure I-2 Plate-forme INXpress de Siemens
IV-1- Environnement de Création de Services (Service Creation Environment) : SCE
C’est l’un des plus importants composants du réseau. Il présente une interface pour les
administrateurs et les opérateurs pour contrôler toutes les phases de vie d’un service. Quatre
applications principales forment cet environnement.
IV-1-1- Advanced Service Definition : ASD
A ce niveau, on définit les nouveaux services pour le réseau intelligent. En effet, en utilisant
l’éditeur logique du service, l’opérateur combine des SIBs (Service Independent Building
Blocks), qui représentent les plus petits modules fonctionnels pour la création de services,
dans une séquence logique spéciale qui permet d’appeler et d’exécuter le service désiré. La
séquence logique des SIBs forme un graphe dont les éléments graphiques des SIBs sont les
nœuds. Cette structure permet une grande flexibilité pour s’adapter aux demandes des clients.
De plus, il y a, au niveau de l’ASD, un éditeur du modèle de données qui permet de définir la
structure de données à entrer pour l’exécution des services, et un simulateur de service pour
s’assurer qu’il fonctionne. Les tâches assurées par l’ASD sont, alors, les suivantes :

- La création des graphes de services ;

- L’affectation des droits d’accès aux utilisateurs pour modifier les données de services ;
- La vérification des graphes de services créés ;
- Le transfert des graphes de services au SMP pour sauvegarde et conversion ;
- La réalisation des tests et des simulations.
Pour appliquer un service, on doit le convertir et l’activer. La conversion des données se fait
au niveau du SMP et permet de définir :
- La logique flexible des services (FSL) : informations de contrôle, manière de

l’établissement d’un appel ;
- Les prototypes supports des données de services : structure des données nécessaires pour
un service ;
- Le gabarit du champ d’autorisation.
Quant à l’activation, elle se fait à partir du SUM (Service and User Management).
IV-1-2- Service and User Management : SUM
Le SUM assure les fonctions d’administration des services, des utilisateurs, des objets créés
lors de la conversion de services et de leur affectation aux numéros d’appels. Les tâches
assurées par le SUM peuvent être classées en deux grandes catégories :
- La gestion des utilisateurs : consiste en la création d’utilisateurs ou de groupes

d’utilisateurs et la définition de leurs droits d’accès.
- La gestion des services : assure l’établissement des numéros d’appels et des plans de
routage vers les services, la génération et la sauvegarde des objets créés lors de la
conversion, leur édition dans le serveur local et leur activation dans le SCP.
IV-1-3- Service Customization : CS
A travers ce point, l’opérateur peut répondre aux demandes spécifiques d’un client pour un
service donné. Ceci est possible en agissant sur la structure de données d’un service.
Le SC s’intègre partiellement dans le SUM et comprend les applications suivantes :
- Editeur des profils statistiques : renferme les données statistiques de chaque utilisateur ;
- Editeur des champs de données : assure la vérification et les calculs sur ces champs ;
- Editeur des champs d’autorisation : définit les droits des clients à lire ou modifier les
paramètres d’entrées d’un service ;

- Définition des valeurs par défaut des données d’un service spécifique à un utilisateur ;
- Affectation des formats spécifiques d’utilisateurs à des prototypes du SAD.
IV-1-4- Client Service Control : WebCSC
Le CSC assure la personnalisation des services. Il a une architecture client-serveur : le client

CSC communique via TCP/IP avec le serveur connecté au SMP.
La structure de l’interface utilisateur CSC est le résultat d’une conversion graphique d’un
service. Elle est adaptée à chaque service via les composants du SAD et du SC.
Deux applications sont reconnues au niveau du CSC :
- Le client CSC : assure l’administration des données nécessaires aux différents services. Le
WebCSC peut aussi accéder au SMP et par suite au SCP via le serveur WebCSC. Il
permet l’édition, le transfert et la sauvegarde des services définis.
- Le client statistique : permet la collection des données statistiques relatives à chaque appel
intelligent (durée d’appel, le numéro de l’appelant, ..etc).
IV-2- Point de Gestion de Services (Service Management Point) : SMP
Il présente les fonctionnalités de serveur pour toutes les fonctions de gestion du réseau
intelligent utilisées par les clients externes. Il permet l’administration des données spécifiques
aux services et aux utilisateurs, leur présentation et leur activation dans le SCP.
Les tâches assurées par le SMP peuvent être subdivisées en trois grandes parties :
- Les fonctions de gestion d’accès : elles permettent la surveillance des droits d’accès, la
conversion et l’administration des objets et des données, le transfert des données client au
SCP et l’administration des objets dans le SCP ;
- Les fonctions statistiques : elles assurent l’évaluation des informations contenues dans les
compteurs, la réception et la sauvegarde des données statistiques relatives à un appel
fournies par le SCP.
- Les fonctions de base : elles permettent l’administration et la gestion de toutes les

fonctions précédemment définies, le contrôle d’erreurs et d’alarmes, l’enregistrement de
toutes les tâches faites par le réseau et le transfert des informations enregistrées aux
serveurs qui les demandent.

IV-3- Point de Contrôle de Services (Service Control Point) : SCP
La tâche la plus importante du SCP est le contrôle de l’exécution temps réel du service surtout
durant la phase d’appel aux services. Le point de contrôle ou SCP se situe entre le point de
gestion de services SMP et le point de commutation SSP, il doit alors être capable de recevoir
et de gérer les différentes commandes et données reçues de ces deux points. On peut classer
les fonctions assurées par le SCP en trois catégories :
- Les fonctions de traitement d’appels : elles permettent la réception des requêtes reçues du
SSP, l’évaluation des numéros de destination et la présentation de la réponse au SSP qui
envoie par la suite les données nécessaires à la taxation pour qu’elles soient traitées et
contrôlées.
- Les fonctions statistiques : ce sont les fonctions responsables du traitement des données
statistiques, de l’administration des compteurs du SSP, de l’évaluation de leurs mesures et
du transfert de ces informations au SMP.
- Les fonctions de base : elles assurent l’administration et la gestion des données relatives
aux services, la protection du réseau intelligent contre la surcharge, la gestion des alarmes,
la sauvegarde des données pour des raisons de sécurité, l’audit et la possibilité
d’intercepter les appels.
V- Présentation des services du réseau intelligent
V-1- Définition de la notion de service
Un service est un produit créé et administré au niveau du réseau intelligent et vendu dans le
marché. En effet, dans le réseau intelligent, il est possible de définir des processus de
télécommunications qui répondent à des besoins spécifiques pour certaines catégories
d’utilisateurs. Ces processus forment les services qui sont mis à la disposition des clients pour
une utilisation efficace.
Un service du réseau intelligent est formé par des petites unités fonctionnelles qui assurent
toutes les fonctions offertes par le réseau intelligent. Ces unités sont dites SIB (Service
Independant Building Blocks), ils représentent les plus petits modules fonctionnels permettant
la création des services. Ainsi, chaque SIB assure une fonction individuelle dans le tout du
traitement d’un appel intelligent. De cette manière, on peut effectuer plusieurs combinaisons

de SIBs pour s’adapter aux demandes des clients. Alors, pour créer un service, on doit définir
au début la fonction qu’il doit assurer, par la suite, on sélectionne les SIBs nécessaires pour la
réalisation de ce service. Cette sélection et la définition de l’ordre dans lequel les SIBs
doivent être exécutés définissent la logique du service (Service Logic : SL). Cette logique
détermine la manière par laquelle un appel sera routé dans le réseau intelligent [1].
V-2- Présentation des différents services
Deux catégories de service sont définies au niveau de la plate forme INXpress : les services
prédéfinis et les services standards. Les services prédéfinis sont dits aussi les services à
traduction de numéros, ils assurent l’affectation d’un numéro composé par les clients en un
autre numéro reconnu seulement à l’intérieur du réseau permettant de les joindre à leurs
correspondants réels. Sous cette catégorie, on trouve les services suivants : Free Phone,
Premium Rate, Televoting, Universal Access Number.
Les services standards définissent un seul numéro permettant aux utilisateurs de bénéficier de
certains services offerts au sein du réseau lui-même. On cite dans cette catégorie les services
Prepaid Card, Virtual Card Calling, Universal Personnal Telecommunications, Virtual Private
Network.
V-2-1- Service Free Phone
Ce service permet d’effectuer des communications téléphoniques à la charge de l’appelé. Tout

client, quelle que soit sa localisation, compose un numéro unique pour joindre l’abonné à ce
service.
En effet, en s’apercevant qu’il s’agit d’un numéro vert, le réseau le convertit en un numéro
physique reconnu par le commutateur pour qu’il puisse établir la communication.
La deuxième tâche du réseau intelligent consiste en l’envoi de toutes les statistiques de

taxation pour la charge de l’appelé.
Ce service est appelé aussi service du numéro vert, et il est utilisé surtout dans le domaine des
affaires. Il permet aux clients de demander des informations ou des services auprès des
fournisseurs sans payer la charge de la communication.
V-2-2- Service Premium Rate (PRM)
Ce service permet à des utilisateurs d’accéder à des informations offertes par l’abonné contre
un certain prix. De cette manière, l’information sera vendue par téléphone. La charge de la

communication est assurée par l’appelant et elle couvre la communication établie par
l’opérateur du réseau et les informations offertes par l’abonné à ce service. Pour faire un appel
vers un abonné PRM, le client doit composer un numéro différent du numéro réel de l’appelé
et c’est au niveau du réseau intelligent que la conversion aura lieu.
V-2-3- Service Televoting (VOT)
Il offre la possibilité de faire des sondages sur des sujets différents d’une manière rapide et
facile. Les appelants qui veulent voter composent le code du service du vote puis le numéro
de la réponse qu’ils proposent.
Les charges des appels à ce service peuvent être ou bien totalement assurées par les appelants
ou partagées ente l’abonné au service et les appelants. Suivant la configuration établie, le
réseau intelligent se charge du transfert des données statistiques au centre de taxation.
V-2-4- Le service Universal Access Number (UAN)
Ce service permet de mettre fin aux longues listes de numéros de téléphones faisant référence
aux différentes branches d’une société quelles que soient leurs localisations. Ainsi, les
sociétés qui bénéficient de ce service peuvent être toujours jointes par un numéro unique sans
tenir compte de son emplacement ou de celui de l’appelant.
En effet, le réseau intelligent convertit le numéro composé par les appelants en une liste
contenant tous les numéros associés à l’appelé. Puis, en tenant compte de l’origine de l’appel,
le réseau commute vers le numéro de la plus proche destination. Dans le cas où cette ligne
serait occupée, le réseau réoriente l’appel vers le numéro de la destination suivante.
Les charges de ce service peuvent être assurées en totalité par les appelants ou bien partagées
entre les appelés et les appelants.
V-2-5- Le service PrePaid Card (PPC)
Ce service permet d’effectuer des appels dont on a déjà payé les charges, il présente aussi une
garantie pour le fournisseur de service puisque tous les utilisateurs payent leurs appels en
avance.
Les abonnés, qui bénéficient de ce service, achètent des cartes prépayées portant des numéros
définis dans le réseau. Après la composition du numéro du service prépayé, les abonnés
entrent le numéro de la carte. Ainsi, après l’établissement de l’appel, les charges seront
soustraites du compte prépayé de l’abonné.

V-2-6- Service Virtual Card Calling (VCC)
Ce service permet à ses abonnés de faire des appels de n’importe quel téléphone sans charger
la ligne d’origine. En effet, toutes les charges sont portées au compte virtuel de l’abonné
possédant une carte VCC.
Après avoir composé le code d’accès de ce service, l’abonné doit entrer le numéro de sa carte
et un identificateur personnel PIN pour authentifier l’appelant. Si ces deux champs sont
corrects, l’abonné pourra alors composer le numéro du destinataire qu’il veut joindre.
V-2-7- Service Universal Personal Telecommunication (UPT)
Ce servie permet à ses abonnés d’accéder aux différents services de télécommunications à

partir de n’importe quel terminal indépendamment de leurs localisations géographiques. Il
s’adapte à la mobilité de ses abonnés. Pour pouvoir accéder au réseau, un abonné doit entrer
son identifiant personnel en plus du code du service, alors le réseau pourra déterminer
l’emplacement de l’abonné et par la suite assurera le routage des appels entrants vers le
terminal du lieu où se trouve l’abonné. Concernant les appels sortants, leurs charges seront
comptabilisées par rapport au compte de l’abonné.
V-2-8- Le service Virtual Private Network (VPN)
Ce service permet de définir des réseaux imaginaires au sein du même réseau de

télécommunication. Les bénéficiaires de ce service ont l’impression qu’ils sont directement
connectés à un réseau privé ne contenant que les clients qui y sont définis.
VI- Conclusion
Le réseau intelligent constitue une première étape dans la démarche entreprise pour élaborer
un environnement propice au développement du marché de service.
Les aspects relatifs à la création de service ont déjà fait l’objet de considérations importantes
et des constructeurs proposent des environnements opérationnels permettant de mener à bien
cette tâche. Cependant, certains problèmes sont encore traités de façon empirique et sans
méthodologie rigoureuse, tel l’intéraction de services. La complexité de ce sujet l’identifie
comme un axe de recherche autour duquel une communauté très active s’est formée.

Chapitre II
Modélisation du réseau intelligent
I- Introduction
Les exigences des systèmes de communications, en terme d’interopérabilité, de passage en

échelle, de sécurité et de performance (délai de bout en bout, utilisation des ressources, débit
nominal, ..etc), compliquent d’avantage la mise en œuvre et la maintenance de tels systèmes.
Il est alors judicieux d’étudier le comportement du système avant son déploiement sur terrain
afin de comprendre et régler les éventuels problèmes qui pourraient affecter le système.
L’évaluation de performance présente aussi un avantage autre que l’étude à priori d’un
nouveau système (dimensionnement). En fait, on pourrait procéder à une étude de
performance de différents systèmes existants pour comparer leurs comportements en fonction
de leurs paramètres d’entrée.
Nous nous intéresserons, dans la première partie de ce chapitre, à la présentation du concept

d’évaluation de performance. La deuxième partie sera consacrée à l’établissement d’un
modèle propre au réseau intelligent.
II- Le concept d’évaluation de performance
II-1- Eléments nécessaires
Pour faire de l’évaluation de performance on doit disposer de deux éléments :
- Un système : c’est l’entité dont on évalue la performance. En gros, un système est

considéré comme étant un ensemble de ressources partagées entre différentes tâches. La
caractéristique commune pour de tels systèmes est la présence de temps d’attente pour
l’accès à ces ressources partagées.

- La Charge (workload) : la charge du système représente généralement le trafic en entrée,

qui pourrait être l’ensemble de messages servis par un dispositif du réseau, le nombre de
tâches à exécuter par un processeur. Il est généralement décrit par des lois probabilistes
(Poisson, Exponentiel, ..etc).
La bonne connaissance de ces deux éléments permet l’évaluation de performance du système.

La performance dont on s’intéresse peut prendre plusieurs formes en fonction du système et
de ses paramètres. On peut s’intéresser par exemple au débit nominal si on évalue les
performances d’un réseau sans fil, au temps de réponse pour un système temps réel, ..etc.
II-2- Les techniques d’évaluation de performance
II-2-1- Méthode analytique
Il s’agit de réduire le système en un modèle mathématique et l’analyser numériquement. Le

principe de la méthode consiste à faire un modèle abstrait du système en réalisant à l’aide
d’outils mathématiques une représentation fidèle du système et de ses paramètres d’entrée.
L’approche analytique est parfois rapide à réaliser, mais présente le souci de la représentation
fidèle du système. Il est parfois très complexe voir impossible de modéliser le comportement
réel du système mathématiquement. Généralement, on se pose des hypothèses qui simplifient
l’étape de modélisation du système et rendent l’évaluation numérique faisable. Ces
hypothèses simplificatrices peuvent toucher à la fidélité de représentation du système, mais
permettent, toutefois, de traduire son comportement approché.
II-2-2- Méthode de simulation
Il s’agit d’implanter un modèle simplifié du système à l’aide d’un programme de simulation

adéquat. En fonction de la charge du système (paramètres d’entrée), le simulateur permet de
fournir en sortie les résultats de simulation permettant d’analyser et de comprendre au mieux
le comportement réaliste du système.
C’est une technique largement utilisée pour l’évaluation des performances. Elle présente
l’avantage par rapport aux méthodes analytiques de traduire d’une manière plus réaliste le
comportement du système à évaluer. On procède généralement à la simulation pour évaluer
un nouveau système ou bien pour des raisons de coûts d’évaluation par des mesures réelles.

II-2-3- Méthode des mesures
Il s’agit de faire des mesures et les analyser directement sur un système réel. Cette technique
permet de comprendre le vrai comportement du système. Mais faire des mesures sur des
systèmes réels n’est pas toujours possible car ça pourrait gêner le fonctionnement du système
ou aussi pour des problèmes de coûts [3].
III- Besoin d’étudier les performances du réseau intelligent
Dans les dernières années, le développement des réseaux de télécommunications était rapide.
Les fonctions des réseaux de télécommunications, auparavant, étaient contrôlées
principalement par les opérateurs. Le désir de partager les données et distribuer les
applications entre les éléments du réseau, le besoin d'interfaces standardisées entre eux, et les
demandes de l'utilisateur pour des services de télécommunications plus sophistiqués ont
particulièrement changé le contrôle des éléments du réseau. Les éléments des réseaux de
télécommunications, aujourd'hui, sont contrôlés par l'opérateur du réseau, le fournisseur du
service ou le client lui-même.
Avec le déploiement croissant des services du réseau intelligent, la conception et la

construction de plates-formes d'intelligence réseau pour accommoder les demandes de clients
qui sont toujours en changement et en croissance, présentent un marché riche d'opportunités et
de défis.
La performance du système impose que les temps de réponse ont besoin d'être minimisés, une
capacité redondante suffisante doit être installée en cas d'échec et un contrôle intégré pour
gérer les situations exceptionnelles qui menacent l'intégrité du réseau. Le scénario du service
mélange la demande du service, la topologie physique du réseau, le flux des messages de
signalisation, le mappage des entités fonctionnelles en composants physiques, et le routage
comme partie du processus de conception du réseau pour assurer que les exigences de la
performance sont rencontrées.
Selon l'aspect de la performance du système, les changements les plus considérables, dus au
réseau intelligent, sont la distribution de l'intelligence du réseau et les nouveaux services
rendus possibles par cette architecture distribuée.
Alors que traditionnellement, un appel est développé dans le commutateur, dans

l'environnement du réseau intelligent, un appel implique le traitement coopératif de plusieurs

éléments du réseau connectés par un réseau de signalisation. Ce changement fondamental

possède de nouveaux défis pour les experts du téletraffic pour assurer que l'IN est conçu pour
fournir des services clients avec une bonne performance.
Les multiples services qui sont implantés dans le réseau intelligent risquent inévitablement
d'interagir les uns sur les autres et de provoquer des situations indésirables pour les
utilisateurs qui les ressentiront comme des dysfonctionnements du réseau. Il est alors
nécessaire de mettre en oeuvre des techniques de détection, prévision de ces interactions avant
le déploiement des services et d'autres techniques de détection, correction une fois les services
déployés.
La performance du service devrait refléter les expectations de l'utilisateur du service avec le

respect de la disponibilité, de la promptitude et de la facilité d'usage.
De plus, la performance du service ne doit pas être seulement garantie pendant un état de
charge normale, mais aussi pendant les charges qui dépassent la capacité du réseau ou pendant
les pics de trafic.
Comme les solutions réseau intelligent courantes dépendent d'un point de contrôle de service
centralisé (SCP) pour l'exécution du service, un mécanisme de contrôle de surcharge efficace
est exigé pour assurer l'intégrité du nœud SCP pendant la surcharge.
IV- Présentation du SCP
La caractéristique principale de l'architecture du réseau intelligent est que l'intelligence ou la

logique d'exécution de services à valeur ajoutée est enlevée du commutateur et est placée dans
un ordinateur central appelé le Point du Contrôle du Service (SCP). C’est le composant du
réseau intelligent qui stocke les données client et les logiques de service, et répond aux
requêtes en provenance des SSPs.
L'activité fondamentale du SCP est le traitement d'appel du réseau intelligent (IN call
processing). L'architecture du réseau intelligent dépend d'une variété de fonctions de contrôle
de service (Service Control Functions : SCFs) fournies par le SCP.
Les programmes de la logique de service (Service Logic Programs : SLPs) sont tenus et
exécutés au niveau du nœud SCP. Ce dernier est aussi responsable de la signalisation SS7 et
des protocoles du LAN. La base de données qui stocke les SLPs est aussi maintenue par le
SCP. Il est utilisé pour fournir le traitement intelligent des appels. Par exemple, si un abonné

compose un numéro vert (free phone), un trigger, qui sert la région de cet abonné, sera activé
au niveau du SSP. Un message de requête TCAP (Transaction Capability Application Part)
est envoyé vers le SCP via le réseau de signalisation SS7. Le SCP exécute alors le SLP
correspondant, détermine le numéro physique correspondant au numéro vert composé et
renvoie toute l'information exigée au SSP dans le but d'initier le "call setup" [1].
IV-1- Architecture Hardware du SCP
La haute disponibilité de l'IN doit être garantie à tout moment. La haute disponibilité du nœud
SCP est réalisée en se basant sur le concept du hardware distribué fortifié par une couche
software spéciale.
Tous les composants hardware du nœud SCP (CPU, disque durs, mémoires, contrôleurs) sont,
au moins, dupliqués et opèrent en parallèle tout en restant indépendants les uns des autres en
fonctionnement normal. Dans le cas d'une panne d'un composant hardware, le composant du
même type assurera la fonctionnalité du composant défectueux. La duplication est même au
niveau des liens de signalisation avec les SSPs.
La figure suivante donne un aperçu sur la structure hardware du nœud SCP, formé par deux
CEs.
Figure II-1 Architecture Hardware du SCP
IV-2- Architecture Software du SCP
La partie software du serveur SCP est divisée en trois couches. La couche 0 est assurée par le
système d'exploitation Reliant Unix et le software OMNI. La plate-forme IN et le système de
gestion et de sauvegarde des données constituent la couche du milieu. Quant à la dernière

couche, elle est formée principalement par l'application de gestion des services RI et par la
partie de l'administration du nœud SCP.
La figure suivante donne un aperçu sur la structure software du nœud SCP.
Figure II-2 Architecture Software du SCP
Le software OMNI consiste en une combinaison d'appels de fonctions, de processus et de

séquences de modules. Ce dernier est lié avec le noyau UNIX pour des raisons d'optimisation
de la performance des durées des travaux. En conséquence, le nombre de changements de
processus dans l'environnement de l'utilisateur UNIX est minimisé.
V- Démarche pour l’étude de performance d’un réseau intelligent
V-1- Introduction
Le formalisme le plus utilisé en modélisation des réseaux est celui des files d'attentes. D’une
manière générale, une file d'attente est constituée d'un ou de plusieurs «serveurs» à qui on
demande un service, de clients qui demandent ce service, et d'un lieu où les clients attendent
quand aucun serveur n'est disponible. L'aléatoire réside dans la variabilité des services et
l'imprévisibilité des arrivées de clients. Dans cette étude, nous allons donner un modèle à base
de files d’attentes pour le réseau intelligent et nous essayerons, par la suite, de simplifier ce
modèle.
V-2- Modélisation
V-2-1- Déroulement d’un appel
Il est important d’étudier le déroulement d’un appel pour bien cerner le problème de l’étude
de performance qu’on va mener. Observons la figure suivante [6]:

Figure II-3 Principe du déroulement d’un appel dans le RI
Comme le montre la figure, le réseau intelligent consiste en un "Service Switching Point"

(SSP) qui accommode des terminaux, le "Service Control Point" (SCP) qui stocke les bases de
données (DB) et exécute un contrôle avancé du service, et le réseau de signalisation (SS7) qui
transfère des messages entre SCPs et SSPs via les points de transfert sémaphores (STP).
Un service du réseau intelligent implique typiquement des interactions entre les SSPs et les
autres nœuds de l'IN pour exécuter le contrôle des appels et des connexions, interagir avec
l'utilisateur, et contrôler les événements sur les interfaces de signalisation.
Après la numérotation de la destination (1), le SSP détecte que c’est un appel IN et initie
directement une requête vers le réseau intelligent qui passe via le réseau de signalisation (2)
pour atteindre le SCP. Ce dernier suit la FSL du service sollicité et pour cela il est nécessaire
de lui fournir des paramètres sur la connectivité de l’appel (solde de l’appelant, destination
physique de l’appelé, …etc.), et par conséquent il interrogera la base de données sur ces
paramètres (3). Dès que le SSP reçoit l’ordre du SCP de connecter l’appel (4), il l’exécute et
connecte appelant et appelé (5 et 6). Le scénario d’appel qu’on vient de citer est presque le
plus fréquemment rencontré mais d’autres cas de figures peuvent se poser comme par
exemple dans le cas de la téléphonie prépayée mobile (SMS, WAP, ROAMING, ..etc) où
plusieurs autres périphériques interagissent avec l’IN.
V-2-2- Modèle associé : Réseau fermé de files d’attentes
Tout en se référant à la configuration de l’architecture du réseau intelligent, et après avoir fait

une étude de son principe de fonctionnement, on peut le présenter comme un réseau de files

d’attentes où le nombre total de clients est fixe. Les réseaux de files d’attentes de ce type sont
dits fermés.
Figure II-4 Modèle associé au RI
V-2-3- Simplification du modèle
Le nœud SCP est le point de concentration de l’intelligence du réseau intelligent, c’est le

point qui contient la base de données en ligne et contient aussi l’implantation de la logique du
service. Ceci fait de lui le nœud le plus important de tout le réseau. Dans ce qui suit, on va
essayer de se focaliser sur le SCP en vue de décrypter un peu la complexité de ce nœud.
Comme tout système informatique, la performance du SCP dépend d’une part de sa structure
hardware et aussi de sa structure software. Le traitement d’une requête de service en
provenance du SSP nécessite la réservation de ce qu’on appelle contexte d’appel qui est
l’ensemble des variables utilisées par le système pour garantir le déroulement de la logique du
service. Une structure très complexe de processus assure ce fonctionnement au niveau du
SCP. Vu la complexité de ces processus, nous allons nous intéresser aux processus qui entrent
en jeu lors de l’exécution d’un service. Observons la figure ci dessous qui présente de manière
grossière ces processus : Le "semain" est le processus principal responsable du traitement des
informations échangées entre le SCP et les SSPs. Ce processus traduit les FSLs en une suite
d’instructions et de requêtes pour assurer l’exécution du service, formuler et envoyer les
réponses vers les nœuds SSPs. Le "semain" est en relation très étroite avec d’autres processus
citons par exemple le "overload process" responsable de la surveillance du déroulement des
autres processus au-dessous de leurs seuils de surcharge [1].

IN X p ress C om m an d er
SM P
C lie n t
G a te w a y G a te w a y
r tc o n u lv a r e x tic k e t a d m in
m c lie n t
s ta tis tic a u d it
bk
D a ta S e m a in
B ases
o v e r lo a d
ir c
cm
c o n te x t
I N a p p lic a tio n s SSD L og
O M N I P la tfo r m S S 7 S ta c k
Figure II-5 Structure en processus au niveau du SCP
Chacun de ces processus (surtout le processus « semain ») gère des files d’attente à travers
lesquelles il communique avec les autres processus.
De plus, d’autres files sont gérées au niveau des disques et CPU du SCP.
Alors si on va tenir compte, dans ce modèle, de toutes les files d’attente qui existent dans le
système, on ne va pas s’en sortir et on va obtenir un système très complexe d’attente. La
caractérisation des paramètres de ce dernier sera, alors, très difficile.
On se propose alors de faire des simplifications en considérant tout le réseau intelligent

comme une seule file d’attente dont le taux d’arrivée est λ et le taux de service est µ.
VI- Conclusion
A travers ce chapitre, on a pu mettre l’accent sur l’importance du principe d’évaluation de

performance d’un système. Ce principe ne peut être abordé sans avoir recours à concevoir un
modèle pour ce système. Après avoir proposé un modèle pour le réseau intelligent, la
prochaine étape consiste à le caractériser et identifier ses paramètres, ce qui fera l’objectif du
prochain chapitre.

Chapitre III
Caractérisation du modèle par des mesures
I- Introduction
Chaque appel au réseau intelligent déclenche plusieurs actions au niveau du SCP. Cela inclut
l'enregistrement des données de l'appel correspondant. Les données sont filtrées et transférées
au serveur SMP où les données statistiques des numéros IN sont triées et stockées.
Les statistiques sont utilisées pour rassembler de l'information sur le comportement de l'appel
dans le réseau intelligent. Cette caractéristique fournit à l'opérateur du réseau, le fournisseur
du service ainsi que l'abonné de nombreuses opportunités pour obtenir et évaluer les données,
par exemple concernant la séquence d'appel, les tentatives de fraude et la disponibilité des
services. Les données statistiques sont rassemblées au niveau du SCP et sauvegardées dans
des enregistrements "records" appelés aussi "tickets".
Dans ce chapitre, on se propose d’utiliser ces fichiers de mesures afin de caractériser le

modèle déjà conçu, et en déduire le comportement de l’abonné et le comportement du système
réseau intelligent.
II- Présentation des fichiers de mesures
Les données statistiques sont enregistrées au niveau du SCP selon la présélection faite par les
profils de statistiques au niveau du SC. Ces données sont transférées du SCP au SMP où elles
seront stockées dans des fichiers.
Selon leurs types, les données individuelles sont sauvegardées dans des fichiers différents.
Ces fichiers ont une structure binaire. Pour les enregistrements d'appel et les enregistrements
de fraude, la longueur du fichier est définie par la sélection faite dans le profil de statistique.

Les enregistrements d'appel contiennent toutes les données associées à un appel spécifique
telles que le plan de numérotage de l’appelant, le plan de numérotage de l’appelé, la durée de
l'appel en secondes, la durée de la conversation en secondes.
Ces données sont sauvegardées dans un format de données prédéfini. De plus,

l'enregistrement d'appel peut inclure un champ de données transparentes. A travers ce champ,
l'information spécifique au service et à l'abonné au service peut être évaluée d'après les
critères définis par le concepteur du service.
Les enregistrements de fraude contiennent les données sur les événements de fraude pendant
un appel telles que "le numéro du compte est incorrect", "le numéro PNP est non autorisé", "le
PIN est incorrect".
Après plusieurs tentatives échouées à entrer le PIN, par exemple, un enregistrement pour cet
événement est écrit et contient le numéro de l'appelant et le nombre de tentatives.
Les enregistrements d'appel de recharge fournissent les données sur les appels de recharge en
ligne au niveau du SCP.
Les enregistrements de confirmation sont écrits pour les actions exécutées par le SCP.
Les enregistrements incluent toujours une entête qui fournit des données telles que la version
du format de l'enregistrement respectif, le type de données brutes, le temps pendant lequel le
SCP a écrit cet enregistrement et le numéro IN associé. Les entrées, dans tous les champs
restants, peuvent toujours être écrites au SCP indépendamment des SIBs utilisés dans le
service [2].
III- Méthodologie de caractérisation du trafic
Dans notre démarche de caractérisation du trafic, nous avons passé par une étape
d’observation dans laquelle nous avons essayé de voir de près le comportement du trafic. Le
but de cette étape est de faire les approximations nécessaires en vue de caractériser le trafic
par des lois mathématiques.
Nous nous sommes basés sur les fichiers de statistiques. Les fichiers de mesures dont nous
disposons sont des fichiers en format binaire. Il faut passer par plusieurs étapes pour rendre
ces fichiers exploitables. La première étape est la conversion en format ASCII du fichier, la
deuxième étape est le filtrage de ce fichier pour ne prendre que les enregistrements d’appels

qui nous seront utiles pour notre analyse. L’étape suivante est le filtrage des enregistrements
d’appels pour ne prendre que les instants d’appels.
III -1- Conversion des fichiers binaires
La conversion des fichiers de mesures en format ASCII nécessite la bonne connaissance du

format d’écriture de ces fichiers en binaire, c'est-à-dire connaître les différents champs et leurs
longueurs respectives. Les enregistrements des fichiers de statistiques sont connus sous le
nom de tickets de statistiques, chaque ticket est caractérisé par des champs dont les plus
importants sont :
- Champ d’entête : qui contient des informations sur les délimiteurs et le type du ticket.
- Champ de données : qui contient des informations obligatoires à être affichées.
- Champ de données variables : champs de données spécifiques à l’opérateur.
III -2- Filtrage des fichiers de mesures
Le filtrage des mesures s’applique sur le fichier ASCII généré après l’étape de conversion.
Les tickets de types « call record » sont les plus importants pour notre étude puisqu’ils
contiennent les enregistrements des appels. L’information la plus importante que nous allons
extraire de ces enregistrements est l’instant de l’appel, puisque chacun est considéré comme
une tentative d’appel.
Les fichiers de mesures que nous possédons sont d’une taille énorme et contiennent une très
grande quantité d’information. Ainsi, pour pouvoir les traiter et déterminer à partir d’eux les
informations dont nous avons besoin, on doit préparer des programmes spécifiques. Pour ce
fait, nous avons opté pour le langage "Perl" parce qu’il est orienté vers le traitement des
fichiers.
L’organigramme suivant présente les différentes étapes par lesquelles nous sommes passés
pour préparer les fichiers de mesures :

Conversion des fichiers bruts
Séparation des types de tickets
Filtrage des fichiers d'enregistrements d'appels
Extraction des instants d'appels
Ordre des instants d'appels
Figure III-1 Préparation des fichiers de mesures
III -3- Représentation du trafic
La courbe suivante est la représentation du nombre d’appels par minute reçus le long d’une
journée :
N o m b r e d 'a p p e ls p a r m in u t e
2500
2000
Nombre d'appels
1500
1000
500
Error!
0
23:20
23:58
0:36
1:14
1:52
2:30
3:08
3:46
4:24
5:02
5:40
6:18
6:56
7:34
8:12
8:50
9:28
10:06
10:44
11:22
12:00
12:38
13:16
13:54
14:32
15:10
15:48
16:26
17:04
17:42
18:20
18:58
19:36
20:14
20:52
21:30
22:08
22:46
H e u re
Figure III-2 Distribution du nombre d’appels par minute le long d’une journée
III -4- Loi d’arrivée
Problématique : Avoir N tentatives d’appels par seconde est une variable aléatoire. Il est très
important de caractériser cette variable et de la représenter mathématiquement. Etant donnés
les différents instants d’appels, comment va-t-on calculer la probabilité d’avoir N appels?
Solution : Voici l’algorithme que nous avons proposé et que nous avons implanté, nous allons
appeler cet algorithme AT1 :

- Extraire les instants d’appels dans un tableau TAB1;
- Ordonner le tableau TAB1;
- Parcourir le tableau TAB1 et compter le nombre d’instants égaux et les enregistrer dans
un tableau TAB2 ;
Î Le tableau TAB2 va se prolonger de l’instant début jusqu’à l’instant de fin et contiendra le

nombre d’appels à chaque instant.
- Noter le max et le min du tableau TAB2 : min est le nombre de tentatives d’appels
minimal et max est le nombre maximal ;
- En allant de min à max, compter le nombre d’apparitions de chaque nombre de tentatives

et ainsi on aura la probabilité d’avoir x tentatives d’appels qui s’écrit :
Nombre _ d ' apparition _ de _ x _ dans _ TAB 2

P( N = x) = (1)
longueur _ de _ TAB 2
En implantant l’algorithme ci-dessus et en l’appliquant aux mesures d’une journée, nous

avons obtenu la courbe ci-dessous :
d e n s i t é d e p r o b a b ilit é
0 .1 2
0 .1
0 .0 8
Probbilité
0 .0 6
0 .0 4
0 .0 2
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73
N o m b r e d e t e n t a t i v e s d 'a p p e l s p a r s e c o n d e

F o n ctio n d e rép artitio n
1.2
0.8
0.6
0.4
0.2
0
23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81
1 3 5 7 9 11 13 15 17 19 21
N o mb re d e ten tatives d 'ap p els p ar seco n d e
Figure III-3 loi d’arrivée des appels sur une journée
Problème : Cette représentation de probabilité n’est pas proche d’une loi connue. C’est une
représentation de toute une journée et nous savons que, pendant une journée, le comportement
des clients change. Pendant les heures de la nuit, il est très rare d’avoir des appels, et pendant
les heures de travail, le comportement change, et ceci on peut le voir d’après la courbe qui
représente le trafic quotidien.
Solution : L’idée est de diviser le trafic d’une journée en des périodes de courtes durées tel
que par exemple une demi-heure et observer les changements de distribution. Voici la courbe
qui représente la densité de probabilité pendant une demi-heure :
Densité de probabilité (1/2 heure)
0.09
0.08
0.07
0.06
Probabilité
0.05
0.04
0.03
0.02
0.01
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45
Tentativ es/seconde
Figure III-4 loi d’arrivée des appels sur une ½ heure

Approximations : dans le cas d’un réseau intelligent, nous pouvons faire les hypothèses
suivantes :
- Le nombre de clients est très grand (infini) ;
- Le fait d’avoir N tentatives d’appels par seconde à un instant t ne renseigne en rien sur le
nombre de tentatives qui sera à l’instant t+∆(t) Î processus sans mémoire ;
- Les clients sont indépendants les uns des autres.
Ces hypothèses nous rappèlent celles de la loi de poisson, la courbe représentée confirme
aussi cette hypothèse. Des courbes tracées sur des périodes de temps différentes indiquent la
même allure mais la seule différence c’est le pic de probabilité. De plus, nous nous sommes
aidés de quelques articles sur la modélisation du trafic téléphonique qui assument toujours des
lois d’arrivées approximées par des lois de poissons [6].
Problème : Comment va t-on déterminer le paramètre λ de la loi de poisson?
Solution : Nous avons utilisé la méthode des moindres carrés pour minimiser l’écart entre la
courbe réelle et des lois de poissons théoriques en faisant varier le paramètre de la loi à
chaque fois. Voici l’algorithme qu’on a utilisé pour déterminer les lois théoriques pour chaque
période, on va l’appeler AT2 : Etant donnée la courbe réelle qui représente Pr(N=x) :
- Appliquer l’algorithme AT1 pour la période en question ;
- Déterminer le max des tentatives d’appels de cette période ;
- Résoudre l’équation à inconnu λ suivante :
⎡i = max e − λi x λi 2 ⎤
min λλ == 0max ⎢ ∑ ( Pr(N = x ) - ) ⎥ (2)
⎣ i = 0 x ! ⎦
En appliquant l’algorithme ci-dessus, nous avons obtenu un poisson de paramètre 24. La

représentation de la superposition des 2 courbes est représentée par la figure suivante :

A ppr ox imation par une loi de pois s on de paramètre 24
0.09
0.08
0.07
Pois s on(24)
0.06
Probabilité par mes ures
0.05
Pro b ab ilit é
0.04
0.03
0.02
0.01
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45
Ten t a t iv e s / s e c on d e
Figure III-5 loi de poisson obtenue par application de la méthode des moindres carrés
III -5- Trafic d’une journée
La répartition des tentatives d’appels au cours d’une période d’une ½ heure est bien
approximée par une loi de poisson, le paramètre de ce poisson est déterminé par l’algorithme
AT2.
Une journée peut être considérée comme une population composée par des échantillons de ½
heures, soit 1/48 de la population totale [9].
En conclusion, la distribution de la probabilité du trafic quotidien suit une loi multimodale

poissonienne, d’où l’équation de la distribution de probabilité quotidienne :
1 i = 48
e _ λ i λ ik
P(N = k) =
48
∑
i=0 k!
(3)
La représentation graphique de cette équation est donnée par la figure suivante. Cette figure
est presque superposable à la figure de probabilité calculée à partir des fichiers de mesures.

Dis tribu tio n de prob abilité
0.12
0.1
0.08
Pro b ab ilit é
0.06
0.04
0.02
0
1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97 101 105 109 113 117
Ten t a t iv e s d 'a pp e ls p a r s e c o n d e
Figure III-6 loi multimodale poissonienne
III -6- Délai d’attente
Le délai d’attente est le temps qu’un client attende avant d’être servi par le serveur. La
connaissance de ce paramètre est très utile dans l’étude de performance du réseau intelligent.
En effet, la connaissance de ce paramètre est très souhaitée par les opérateurs pour pouvoir
intervenir s’ils observent que cette valeur dépasse certaines valeurs seuils.
On se propose, dans cette partie, de représenter la probabilité qu’un client attende un certain
nombre de secondes avant que son appel ne soit servi. Le fichier de mesures dont on dispose,
contient toutes les tentatives d’appels : réussis et échoués. Le deuxième type (appels échoués
pour une raison ou une autre) ne renseigne pas sur le délai d’attente car par exemple une
grande partie contient des tentatives où la partie appelée ne répond pas, le délai sera alors très
grand et va fausser les mesures qui renseignent sur le comportement du système réseau
intelligent.
Par conséquent, il faut filtrer le fichier de mesures pour ne laisser que les appels aboutissants.
En fait, même pour les appels aboutissants, le délai d’attente contient en partie le
comportement de l’abonné, car le délai de la connexion d’appel contient en partie le délai que
consomme la partie appelée pour décrocher son appareil. Mais, vu le nombre très grand
d’appels, l’effet de ce cette attente tend vers une moyenne. En effet, il y a des destinations
dont les réponses sont rapides et d’autre dont les réponses sont lentes et ces deux types
existent en nombres très grands, donc le fait de les considérer tous c’est comme-ci nous les
moyennons automatiquement.

III -7- Méthodologie d’étude du délai d’attente
Pour représenter la probabilité qu’un client attende x secondes, nous avons implanté
l’algorithme suivant que nous avons appelé AD1 : Voici les étapes que nous avons
implémentées dans un programme informatique pour représenter le délai d’attente :
- Filtrer le fichier de mesures Î garder les appels aboutissants ;
- Chercher le max des délais d’attentes ;
- Chercher le nombre d’occurrences de chaque délai, ainsi on aura la probabilité que le

client attende x secondes avant d’avoir son appel connecté s’écrit :
Nombre _ d ' occurance _ de _ x

P( N = x) = (4)
Nombre _ total _ d ' appels
III -8- Représentation du délai d’attente
La figure suivante représente les densités de probabilité pour les délais d’attente, pour deux
journées différentes. On voit bien que les deux courbes aient la même allure.
Dens ité de probabilité du délai d'attente (2 mes ures )
0.07
0.06
0.05
0.04
Probabilité
0.03
0.02
0.01
0
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97
Délai en s ec onde
FigureIII-7 Densité de probabilité du délai d’attente en secondes

Fo n c tio n d e r é p a r titio n
1.2
0.8
0.6
0.4
0.2
0
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97
Dé la i e n s e c o n d e
Figure III-8 Fonction de répartition du délai d’attente en secondes
En faisant quelques superpositions avec des fonctions de probabilités usuelles, nous avons
trouvé que cette fonction est plus vraisemblable avec la distribution GAMMA de paramètres
α=3.8 et β=3.7. Les figures suivantes montrent les superpositions respectives des deux
distributions et des deux densités de probabilités :
Superpos ition av ec la dis tribution de la loi GA MMA
1 .2
Dis tribution d'une loi GA MMA

1
Dis tribution mes urée

0 .8
0 .6
0 .4
0 .2
0
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97
Délai en s ec onde
Figure III-9 Superposition avec la fonction de répartition Gamma
La superposition des densités de probabilités des délais calculés depuis les fichiers de mesures
(délais réels) et de la densité de la loi GAMMA de paramètres α=3.8 et β=3.7 donne la figure
suivante :

S u p e r p o s itio n a v e c la d e n s ité d e p r o b a b ilité d e la lo i G A M M A

0 .0 7
0 .0 6
D e n s ité d 'u n e lo i G A M M A
0 .0 5
P r o b ab ilit é
0 .0 4
0 .0 3
D e n s ité m e s u r é e
0 .0 2
0 .0 1
0
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97
D é la i e n s e c o n d e s
Figure III-10 Superposition avec la densité de probabilité de la loi Gamma
Ces hypothèses ont été confirmées par plusieurs autres mesures, nous pouvons conclure que le
délai d’attente des clients, avant d’être servis par le réseau intelligent, obéit à une loi
GAMMA de paramètre α=3.8 et β=3.7 qui s’écrit comme suit :
x
1 −
Fα , β ( x ) = α x α −1 e β (5)
β .Γ (α )
Où Г est la fonction Gamma qui s’écrit :
∞
Γ (α ) = ∫ 0
t α −1 .e − t .dt (6)
III -9- Loi de service
Après un certain temps d’attente, un client sera servi, et le temps qu’il passe dans le système
est appelé temps de service. Autrement dit, c’est la durée de temps pendant laquelle le client
consomme les ressources de la plateforme réseau intelligent. Dans l’étude de performance de
la plateforme, la connaissance de cette variable est très utile car elle indique le temps de
séjour d’un client dans le système et à partir de la quelle et des autres lois (arrivée et délai
d’attente et capacité du système), on pourra déduire d’autres indicateurs de performance très
importants tels que la probabilité que le système se sature ou que la file soit vide… Ces
indicateurs seront développés plutard. Dans ce qui suit, on se propose de déterminer la loi qui
régit la variable aléatoire : temps de service ou Holding time.

C’est évident que le temps de service ne concerne que les appels aboutissants, pour cela il faut
filtrer le fichier de mesures.
III -10- Méthodologie d’étude de la loi de service
Pour représenter la probabilité qu’un client séjourne pendant x secondes, nous avons implanté
l’algorithme suivant que nous avons appelé AS1 :
- Filtrer le fichier de mesures Î garder les appels aboutissants ;
- Chercher le max des durées d’appels ;
- Pour toutes les durées de 0 à durée max : chercher le nombre d’occurrences de chaque
durée, et ainsi on aura la probabilité de séjour ou de service. Finalement, nous écrivons la
probabilité pour qu’un client demeure x secondes sur le système comme suit :
Nombre _ d ' occurance _ de _ x

P( N = x) = (7)
Nombre _ total _ d ' appels
III -11- Représentation du holding time
La figure suivante représente la densité de probabilité pour les temps de service, sachant que
ces mesures ont été répétées sur plusieurs périodes et nous avons obtenu toujours la même
allure.
D is tr ib u tio n d e p r o b a b ilité d u te m p s d e s e r v ic e
0 .0 2 5
0 .0 2
P r ob ab i li té
0 .0 1 5
0 .0 1
0 .0 0 5
0
1 26 51 76 101 126 151 176 201 226 251 276 301 326 351 376 401 426 451 476 501 526 551 576 601 626 651 676 701 726 751 776
Du r é e e n s e c o n d e
Figure III-11 Densité du Holding time
La courbe tracée nous laisse penser aux distributions exponentielles. Traçons la courbe de
répartition :

F o n c tio n d e r é p a r titio n d u te m p s d e s e r v ic e
1 .2
0 .8
0 .6
0 .4
0 .2
0
1 49 97 145 193 241 289 337 385 433 481 529 577 625 673 721 769 817 865 913 961 1009 1057 1105 1153
Du ré e e n s e c o n d e
Figure III-12 Fonction de répartition du Holding time
Plusieurs recherches estiment que le temps de service (holding time) suit une loi exponentielle
[6]. La courbe que nous avons représentée confirme aussi cette hypothèse. En conclusion,
nous allons prendre la loi exponentielle comme loi de service, reste à chercher le meilleur
paramètre de la loi qui minimise l’écart entre les deux courbes. Pour cela nous avons
développé l’algorithme que nous avons appelé AS2 semblable à l’algorithme AT2, nous
avons trouvé que la loi la plus représentative de la distribution de probabilité du temps de
service est une loi exponentielle de paramètre λ=0.0101. Les deux courbes suivantes
confirment notre hypothèse. En effet, on observe presque la superposition des deux courbes
mesurée et théorique.
Fonc tions de répartitions mes urée et de la loi ex ponentielle (0.0101)

1 .2
Répartition mes urée

1
0 .8
0 .6
Répartition de la loi ex ponentielle
0 .4
0 .2
0
1 31 61 91 121 151 181 211 241 271 301 331 361 391 421 451 481 511 541 571 601 631 661 691 721 751 781 811 841 871 901 931
Durée en s ec onde

De n s ité d e p r o b a b ilité m e s u r é e e t d e la lo i e x p o n e n tie lle ( 0 .0 1 0 1 )

0 .0 2 5
0 .0 2
P r obabilité
0 .0 1 5
0 .0 1
De n s ité me s u r é e
0 .0 0 5
De n s ité d e la lo i e x p o n e n tie lle
0
1 27 53 79 105 131 157 183 209 235 261 287 313 339 365 391 417 443 469 495 521 547 573 599 625 651 677 703 729 755 781
Du r é e e n s e c o n d e
Figure III-13 Superposition des lois réelles avec la loi exponentielle
En conclusion, la loi de service est une loi exponentielle de paramètre λ=0.0101. D’où la
probabilité qu’un client séjourne x secondes sur le système s’écrit comme suit :
P ( N = x ) = λ .e − λx Avec λ=0.0101 (8)

Dans les observations et les études que nous avons faites, nous avons pu déterminer la loi
d’arrivée, la loi d’attente et la loi de service. Ces lois nous renseignent sur le comportement
du système et des clients dans ce système. Plusieurs indicateurs de performance en peuvent
être automatiquement déduis, ce qui fera l’objectif de la prochaine partie.
V- Conclusion
Au cours de ce chapitre, nous avons pu caractériser les différents paramètres du modèle en se

référant à des mesures extraites à partir d’une plate-forme chez un opérateur de réseau.
Dans le prochain chapitre, on se propose d’implanter un simulateur du modèle en question

pour pouvoir identifier certains comportements et en déduire des paramètres de performance.
Finalement, on va mettre en place l’outil graphique « Performance Monitor ».

Chapitre IV
Conception et réalisation de l’application
I- Introduction
Une application destinée à l’opérateur doit avoir une interface simple et facile à utiliser et ceci
pour éviter à ce dernier de toucher aux codes sources de l’application ou de manipuler des
fichiers de grandes tailles.
Après une présentation du principe du simulateur proposé, nous exposerons les différents
algorithmes sur lesquels il repose. Finalement, nous montrerons les détails de la conception de
l’application finale et, après réalisation, nous allons donner les résultats obtenus.
II- Mécanisme de contrôle de surcharge dans le réseau intelligent
II-1- Description générale de la surcharge du SCP
Le SCP, dans le réseau intelligent, est capable de manipuler la charge qui change avec le
temps. Si la charge maximale que le système est capable de supporter est dépassée, le système
est en état de surcharge. Par conséquent, il ne sera pas capable de travailler dans son état
normal. Pour prévenir cette situation, une procédure de contrôle de surcharge est implémentée
dans le logiciel du SCP. Cette procédure a la tâche de garder la charge du SCP en dessous de
la charge maximale que le système est capable de supporter. Cette procédure assure que le
SCP fonctionnera dans un état sécurisé.
Les objectifs principaux du contrôle d’overload sont de protéger efficacement les ressources
des problèmes de surcharge, de maintenir un « throughput » élevé et d’assurer une
distribution équitable de la capacité des ressources entre les services.
Le SCP du système réseau intelligent peut être dans une situation de surcharge à cause de
différentes raisons [4].

II-1-1- Raisons externes
La situation de surcharge peut être causée par un nombre élevé de tentatives d'appels. Cela se
passe quand la limite de l'IN est atteinte. Par conséquent, le SCP ne peut pas manipuler tous
les appels. La limite de la capacité maximale que le système devrait manier est appelée la
valeur du maxbhca. Si ce seuil est dépassé, le mécanisme du "Automatic Call Gapping"
automatique (ACG) réduira la charge dans le SCP, et par conséquent prévient une situation de
surcharge. Avec "call gapping" (CG), il est aussi possible de limiter le nombre d'appels en
dessous de la capacité maximale du système. Ce "call gapping" est alors causé par une raison
externe.
II-1-2- Raisons internes
L'autre raison de la situation de surcharge est que les ressources internes sont trop lentes ou
trop usagées. Pour cette raison, les charges des CPU et les longueurs des files augmenteront.
Pour prévenir la chute subite du système, le mécanisme du "call gapping" automatique
prendra partout. Il va aussi, dans cette situation, réduire le nombre d'appels connectés au SCP
et par conséquent libérer quelques ressources du système. La charge du CPU et la longueur de
la file devraient alors descendre. Donc ce "call gapping" est initié par des problèmes internes.
II-2- Principe de fonctionnement du Call Gapping
Quand le SCP reconnaît une situation de surcharge, un message de "call gapping" est envoyé
au SSP via le protocole (INAP). Ce message inclut deux paramètres importants : "gap
duration", et "gap time" [5].
II-2-1- gap duration
Le "gap duration" est le temps pour lequel ce message de "call gapping" est valide. Le "call
gapping" commencera après avoir reçu ce message et s'arrêtera après la durée de l'intervalle,
si aucun autre message de "call gapping" n'est reçu par le SSP. La valeur du "gap duration"
pour la surcharge du système peut être fixée dans le fichier de configuration du SCP en
utilisant le paramètre "gapsysd" ou par le logiciel d'administration du SCP. La gamme du
paramètre du gapsysd est de 0 à 2047 secondes. Mais dans les systèmes pratiques, les valeurs
entre 60 et 300 secondes sont communes.

II-2-2- gap time
Le "gap time" est le paramètre qui définit le montant par lequel le trafic sera réduit. Il est aussi
connu sous le nom de "gap interval". Le "call gapping" limite le nombre d'appels transmis au
SCP en laissant passer seulement un appel au SCP dans un certain temps (le "gap time"). Si
plus qu'un appel arrive au SSP dans ce temps, tous ces appels (sauf le premier) seront rejetés
en jouant une annonce à l'appelant.
Donc quand le "call gapping" commence, le premier appel qui arrive au SSP ne détectera pas
toute différence, cela signifie qu'il sera traité comme en état normal. Les appels suivants qui
arrivent au SSP ne seront pas traités comme le premier, mais terminés par le SSP ce qui ne
cause aucune charge supplémentaire au SCP. Si le temps exigé est passé (un gaptime), la
procédure recommence du début. Le premier appel va atteindre le SCP et les appels suivants
seront rejetés.
L'utilisateur ne peut pas configurer le "gap time" directement comme le "gap duration" parce
qu'il sera calculé par le système qui réagit en situation de surcharge. Beaucoup de paramètres
aussi bien que quelques mesures du système influencent le calcul du "gap time".
III - Mise en place du simulateur
III -1- Besoin de simuler
Généralement, la détermination d’un modèle pour un système est suivie, souvent, de son
implantation dans un simulateur qui traduit un comportement simulé pour ce modèle, ce qui
aidera par la suite lors de la phase de dimensionnement.
Certains pensent que cette phase de simulation deviendrait inutile lorsqu’on dispose d’un
système réel, mais la question qui se pose est que faire lorsqu’il s’agit d’une plate-forme
fonctionnelle placée chez un opérateur ? Bien évidement, on n’est pas permis de faire toutes
les manipulations et les observations qu’on voudrait faire pour ne pas gêner le
fonctionnement normal du système. On voudrait par exemple appliquer au système des flux
de différents taux d’arrivées et observer le résultat obtenu. Et si nous allons attendre que le
système réel nous donne telle ou telle mesure, il nous faut peut être quelques mois ou plus.

De plus, la simulation d’un tel modèle nous permettra de faire la prédiction du trafic, dans
certains cas comme celui de la congestion, pour pouvoir agir dans l’occasion correspondante,
et de déterminer des paramètres de performance par simulation.
III -2- Implantation du simulateur du modèle
Le modèle est caractérisé par trois variables aléatoires : la loi d’arrivée (loi poissonienne de
paramètre λ) Î donc les interarrivées suivent la loi exponentielle de paramètre 1/ λ, la loi
d’attente (loi Gamma de paramètres α =3.8 et β =3.7), et la loi de service (loi exponentielle de
paramètre µ = 0.0101). Il faut, alors, commencer par la génération de ces séquences aléatoires
en commençant par la génération des interarrivées puis des durées d’attentes et enfin des
durées de services. On obtient finalement trois tableaux : Tab1, Tab2 et Tab3.
- Tab1 contient les instants d’arrivées, et ces derniers sont calculés en cumulant les
interarrivées.
- Tab2 contient les instants de services, ces instants sont calculés de la manière suivante :
Instant_service = Instant_arrivée + durée d’attente.
- Tab3 contient les instants de sortie, ces instants sont calculés de la manière suivante :
Instant_sortie = Instant_service + durée de service.
Après avoir préparé, de façon aléatoire, les instants d’arrivées, les instants de services et les
instants de sorties, on va passer à l’étape de simulation en choisissant l’échantillon sur lequel
on va simuler.
Pour pouvoir simuler le comportement temps réel du système et mettre en correspondance les
différentes arrivées, services et sorties, on a mis en place un certain nombre de variables
comme le nombre de clients original, en attente, en service, rejetés, déjà servis, ..etc. Puis, au
cours de l’exécution du programme, on va suivre l’évolution de ces différentes variables. Le
programme de simulation est présenté par l’organigramme ci dessous :

Fixer instant actuel (i_act)
non i_act est un

i_act est un i_act est un
instant non instant de non instant de
d’arrivée ? service ? sortie ?
oui oui oui
non nbr_clien non nbr_clien

t_en_atte t_en_ser
nte >0 ? vice >0 ?
oui oui
1- Incrémenter 1- Incrémenter
Incrémenter nbr_client_en_service nbr_client_déjà_servis
nbr_client_en_attente 2- Décrémenter 2- Décrémenter
nbr client en attente nbr client en service
Incrémenter i_actuel
Figure IV-1 Organigramme de Simulation
III -3- Implantation du mécanisme du "Call Gap"
Le déclenchement du mécanisme du Call Gap, dans le simulateur, va dépendre de la valeur du

maxbhca allouée au système. On va se reposer sur le principe de prédiction du trafic : on va
observer le nombre de nouveaux venus sur une période de mesure de ‘load’ et on va, par la
suite, prédire la valeur atteinte par ce nombre après une heure d’observation. Si cette valeur

prédite va dépasser la valeur du maxbhca, le mécanisme du Call Gap sera déclenché. La

procédure d’activation de ce mécanisme est explicitée dans l’organigramme ci dessous :
i_act est un
oui instant de non
mesure ?
Incrémenter le nombre de nouveaux

venus sur le système au cours de la
(1 heure / periode_mesure)x
oui non période de mesure
nbr_nouveaux_venus >
maxbhca (1+10%) ?
Activer le ACG Initialiser le nombre

de nouveaux venus
Incrémenter i_actuel
Figure IV-2 Procédure d’activation du mécanisme du Call Gap
L’introduction du mécanisme de Call Gap va influer sur le fonctionnement du simulateur et

va, par conséquent, affecter toutes les variables de simulation (nombre de clients en attente,
nombre de clients en service, nombre de clients rejetés, ..etc).
Les paramètres ″gap duration″ et ″gap interval″ ont été ajustés de telle sorte qu’on obtienne, à
partir de mesures extraites durant un jour d’overload, les mêmes résultats.
On va introduire des modifications sur l’organigramme correspondant au fonctionnement du

simulateur, plus précisément, au niveau des instants de services, ceci est représenté par
l’organigramme ci dessous :

oui i_act est un non

instant de
service ?
non ACG oui

actif ?
Un appel est
non pris dans le gap oui
interval
correspondant à
i act ?
non nbr_client_e oui

nbr_client_e n_attente >0
oui ?
n_attente >0
?
non 1- nbr_client_en_service + 1 1- nbr_client_rejetés + 1
2- nbr_client_en_attente + 1 2- nbr_client _attente + 1
Inrémenter i_act
non i_act > oui

Gap end time?
Désactiver ACG
Figure IV-3 Fonctionnement du Call Gap
III -4- Résultats de simulation
Après la mise en place du simulateur, on lui a appliqué différents flux d’arrivées et on a

essayé d’observer le trafic total arrivant et le trafic traité par le système et ceci en vue de
déterminer le trafic rejeté et d’en déduire le taux de rejet du système.

Avec un taux d’arrivée λ = 80 (c’est à dire 80 appels par seconde), on a obtenu, après
simulation sur un échantillon de longueur 1 heure, les courbes suivantes représentatives du
trafic total et du trafic réellement réalisé. Si on suppose que le taux d’arrivée est 80 appels par
seconde, le nombre moyen d’arrivées sur une heure sera de (3600 * 80) soit 288000 appels
par heure dépassant le maxbhca du système, ce qui explique l’apparition d’appels rejetés
comme le montre la figure suivante :
trafic total et trafic traité
6000
trafic total
5000
nombre d'appels
4000
3000
2000 trafic traité
1000
0
1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61
minute
Figure IV-4 Trafic total et trafic traité pour un taux d’arrivée λ = 80
Avec un taux d’arrivée moins que le premier (soit 60 appels par seconde), on remarque,
comme c’est montré par la figure ci dessous, que le taux de rejet est plus petit.
trafic total
4000
3500
nombre d'appels
3000
2500
Series1
2000
trafic traité Series2
1500
1000
500
0
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61
minute

4000 trafic
3500
3000
nombre d'appels 2500
Series1
2000
trafic traité Series2
1500
1000
500
0
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61
minute
- Pour λ = 80, le taux_rejet = 0,204 soit 20,4%.
- Pour λ = 60, le taux_rejet = 0,131 soit 13.1%.
- Pour λ = 58, le taux_rejet = 0,043 soit 4.3%.
Au cours du chapitre précédent, on a montré que la loi d’arrivée est une loi poissonienne
multimodale (des taux d’arrivées différents). L’idée qui en découle est d’essayer de
représenter les courbes de trafic avec des taux d’arrivées variables et d’observer la variation
des taux de rejet.
On va diviser l’échantillon d’observation (3600 secondes) en considérant qu’on a un taux

d’arrivée de 50 appels par seconde pendant 10 minutes (600 secondes), un taux d’arrivée de
55 appels par seconde pendant 1000 secondes, un taux d’arrivée de 60 appels par seconde
pendant 1000 secondes et un taux d’arrivée de 70 appels par seconde pendant 1000 secondes.
La représentation du trafic total et du trafic traité pour des taux d’arrivées variables est
illustrée par la figure ci dessous.

4000 trafic total

3500
3000
2500 trafic traité
Series1
2000 λ = 70
Series2
1500
λ = 60
1000 λ = 55
500 λ = 50
0
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61
Figure IV-7 Trafic total et trafic traité pour des taux d’arrivée variables
III -5- Résultats par mesures
Des mesures réelles, qui correspondent à un jour de fête (jour de surcharge), ont donné le
résultat présenté par la figure ci dessous :
n o m b re d 'a p p e ls p a r m in u te s (z o n e d u c a ll g a p )
4500
4000
3500
3000
nombre d'appels
2500
2000
1500
1000
500
0
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
0
0
:0
:0
:0
:0
:0
0:
2:
4:
6:
8:
0:
2:
4:
6:
8:
0:
2:
4:
6:
8:
0:
2:
4:
6:
8:
0:
2:
4:
6:
8:
0:
50
52
54
56
58
:0
:0
:0
:0
:0
:1
:1
:1
:1
:1
:2
:2
:2
:2
:2
:3
:3
:3
:3
:3
:4
:4
:4
:4
:4
:5
9:
9:
9:
9:
9:
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
h e u re
Figure IV-8 Trafic traité au cours d’une période de surcharge
Les résultats obtenus par mesures valident bien le fonctionnement du simulateur, puisque, en
comparant les deux courbes (d’overload) obtenues par mesures et par simulation (voir Figure
IV-4), on trouve qu’elles sont très proches.
IV – Conception et implantation de l’application « Performance Monitor »
IV-1- Besoin et objectifs de l’application
Les fichiers de mesures sont très grands et difficiles à traiter. L’opérateur a besoin de
quelques informations précises, et pour les obtenir, il doit passer par une longue phase de

recherche et de traitement des mesures Î d’où le besoin du « PerfMon » qui sera un outil
adapté à l’opérateur pour lui automatiser la tâche de traitement des fichiers et le stockage des
informations utiles dans une base de données adéquate, ainsi que l’affichage harmonieux des
courbes et des résultats.
IV-2- Architecture du « Performance Monitor »
Le « Performance Monitor » est un outil informatique basé sur le traitement des fichiers de
mesures. L’apport de cet outil est qu’il repose sur une base de données dans laquelle on
stocke les données utiles à la compréhension et à l’analyse de la performance du réseau
intelligent. Cet outil est doté d’une interface graphique qui répond aux besoins de l’opérateur
du Réseau Intelligent en terme de visualisation et d’analyse des données.
L’architecture de l’application est résumée dans la figure ci-dessous :
Réseau Intelligent
Flux des données Traitement des

Collecte des fichiers
fichiers de mesures
de mesures
Base de
données
Interface graphique
Figure IV-9 Architecture de l’application « PerfMon »
L’analyse de la performance du réseau intelligent est basée sur les mesures générées par ce
dernier. Les mesures sont sous forme de fichiers de très grandes tailles.
Les modules les plus importants dans l’architecture du « PerfMon » sont les modules de
collecte et de traitement de ces fichiers. En effet, ils doivent assurer une très grande capacité
de traitement vue la quantité importante des flux de mesures générées par la plate-forme RI.

La base de données est la base de connaissance du « PerfMon », elle doit être adaptée pour
stocker les informations utiles à l’analyse de performance et à la surveillance de l’évolution
de la plate-forme.
L’output du « PerfMon » est assuré par une interface graphique et un outil de génération de
rapports. Ce dernier servira à générer des fichiers « performance reports » qui seront utilisés
par l’opérateur pour un besoin ou un autre.
IV-2-1- Les fichiers de mesures
Les fichiers de mesures sont les sorties de la plate-forme Réseau Intelligent plus précisément
du nœud SCP. Nous les avons classés en 2 types : les fichiers Call Record et les fichiers de
mesures de signalisation N°7.
Les fichiers Call Record (voir chapitre 3) sont les enregistrements de toutes les tentatives
d’appels traitées par le SCP. Ces tentatives sont enregistrées dans des tickets de statistiques
bruts. En effet, le SCP est le nœud responsable du traitement des logiques des services en
communiquant ces décisions vers les différents SSPs qui l’interrogent. Pour cela, il faut qu’il
dédie le maximum de ses ressources à cette tâche principale. Alors, il ne fait qu’enregistrer le
ticket de l’appel d’une manière grossière puis il le passe directement vers le serveur SMP. Ce
dernier a tout le temps pour collecter, trier et stocker les enregistrements des appels. Pour
cette raison, les Call Record sont écrits dans des fichiers binaires sur le serveur SMP. Ces
fichiers ne sont jamais écrasés, le mode d’écriture est toujours « append ». L’une des tâches
principales de l’opérateur est de déplacer ces fichiers pour libérer de l’espace disque et de les
sauvegarder périodiquement.
Quant aux fichiers de mesures de signalisation, on les trouve sur le serveur SCP avec un
format bien défini. Ces mesures obéissent à la norme ITU-Q.752 qui propose les types de
compteurs de signalisation qu’il faut mesurer et superviser. Les fichiers de mesures de
signalisation contiennent des mesures sur toute la pile SS7 (on trouve des mesures pour la
couche TCAP et des mesures pour les couches MTP).
IV-2-2- Module de collecte des fichiers de mesures
Le « PerfMon » est un outil d’aide à la décision, c’est pourquoi les mesures qu’il présente
doivent être exactes et surtout complètes. D’où l’importance du module de collecte des
mesures. Ce dernier, étant placé sur le serveur « PerfMon », doit de façon périodique pouvoir

accéder aux serveurs SCP et SMP pour voir s’il y a de nouvelles mesures disponibles et les
amener vers ce serveur.
Ce module doit stocker l’information à propos des dernières mesures collectées sur la base de
données. Ainsi, il n’y a pas risque de collecter les mesures plusieurs fois. Pour cette raison,
nous avons créé une table dans la base de données qui contient le nom des derniers (mesures)
fichiers collectés.
Nous avons choisi comme protocole de transfert le protocole FTP (file transfert Protocol),
d’où la nécessité d’avoir un compte qui a suffisamment de droits pour pouvoir copier les
fichiers de mesures à partir de leurs emplacements vus que la plateforme IN est basée sur
UNIX comme OS. Ce module sera lancé périodiquement, pour cela nous allons nous aider du
programme « cron » sous linux qui est un gestionnaire de tâches très performant.
Voici l’organigramme du module de collecte des fichiers de mesures :
Le module sera lancé par le gestionnaire de tâches
Consulter la base de données pour connaître le nom et la

date des dernières mesures collectées
Accéder via FTP au noeud SMP pour voir s’il y a un

nouveau fichier Call Record
Accéder via FTP au noeud SCP pour voir s’il y a de

nouvelles mesures de la pile SS7
Télécharger les nouvelles mesures
Mettre à jours la base de données avec les dates et les

noms des dernières mesures collectées
Figure IV-10 Module de collecte des mesures
IV-2-3- Module de traitement et de filtrage des fichiers
Rappelons que le module de collecte des mesures est lancé périodiquement par le gestionnaire
de tâches. Une fois téléchargées, les mesures vont être stockées dans un répertoire que nous

avons appelé raw_repository. Le module de traitement des fichiers de mesures a pour

tâches :
- La conversion des fichiers de mesures en un format lisible ;
- Le filtrage des mesures ;
- Le Chargement dans la base de données ;
- Le Sauvegarde des fichiers de mesures.
Ce module est aussi lancé par le gestionnaire de tâches, il doit être synchronisé avec le
module de collecte de données.
Pour récapituler, voici le cycle de vie des fichiers de mesures au cours du processus de leur
traitement par le « Performance Monitor » :
SCP PerfMon Server

/folder_x/ss7_meas/ /raw_respository/SS7
/raw_respository/call_records
SMP DB
/folder_y/call_records/ /backup_respository/SS7
/backup_respository/call_recodrs
Figure IV-11 Cycle de vie des fichiers de mesures
1. Les fichiers sont collectés par le module de collecte, ils seront stockés dans deux
répertoires ; /raw_repository/SS7 pour les mesures de signalisation et
/raw_repository/call_records pour les fichiers call record.
2. Le module de traitement est ensuite lancé pour convertir les fichiers de mesures brutes et
charger l’information utile dans la base de données.
3. Les fichiers obtenus sont ensuite déplacés respectivement vers des répertoires
/backup_respository/SS7 et /backup_respository/call_recodrs pour y être compressés
et archivés dans le but d’une future utilisation éventuelle.

IV-3- Rubriques de l’interface graphique
Le « Performance Monitor » doit être muni d’une interface graphique qui met en relief, de
manière simple et rapide, les importants indicateurs de performance. Ceci en s’aidant des
graphes telles que des courbes et des histogrammes.
IV-3-1- Performance avec simulation
Après avoir analysé les fichiers de mesures, nous avons pu déterminer les lois probabilistes
qui régissent le système (attente, service). Nous avons aussi pu déterminer le comportement
des abonnés (arrivée). Ces lois ainsi que leurs paramètres ont été implantés sous la rubrique
« performance by simulation ».
Le but de cette rubrique est de donner à l’opérateur la possibilité d’étudier le comportement

du système sous différents scénarios, et ceci en lui donnant la main à modifier les paramètres
d’entrée du système telle que par exemple le taux d’arrivée des appels.
Parmi les objectifs de cette rubrique, se place l’étude des scénarios de surcharge. En effet,
l’opérateur pourrait programmer le simulateur avec des lois d’arrivées qui correspondent à des
surcharges de durées bien déterminées. En l’exécutant, l’opérateur aura une bonne estimation
sur le taux de rejet des appels suite au déclenchement du mécanisme du Call Gapping.
IV-3-2- Performance par mesures
Le calcul des vrais indicateurs de performances se fait avec la rubrique « Performance par
mesures ». Cette dernière servira à afficher le résultat des calculs basés sur les mesures
traitées au paravent par le module de traitement des fichiers de mesures, et stockées dans la
base de données. L’opérateur pourra, en utilisant cette rubrique, afficher les valeurs des
indicateurs de performance souhaités en faisant simplement quelques clicks de souris.
Les indicateurs de performance doivent donner une idée claire sur le comportement du
système. Plusieurs conditions doivent être satisfaites :
- La présentation des compteurs doit être sous forme graphique (courbe, histogramme…) ;
- Etre capable de comparer les taux de réussite et de rejet des appels ;
- Etre capable de déceler les causes de rejet et les classer ;
- Etre capable de présenter les compteurs pour chaque composant du réseau de

signalisation : SSP, IP, lien de signalisation…

IV-3-3- Vérificateur de taxation
Nous l’avons appelé le taxomètre. Le service le plus commercialisé dans le monde des
réseaux intelligents est le service de prépaiement. D’ailleurs, les fichiers de mesures dont
nous disposons concernent ce service. L’idée du taxomètre découle du fait que l’un des soucis
majeurs d’un client est d’avoir un solde bien entretenu par le SCP, sa décrémentation doit être
très précise. Notons que la taxation d’une ligne prépayée se fait en mode « Online » à l’aide
de messages INAP entre le SSP et le SCP. A la fin d’une communication, le SSP envoie au
SCP un message INAP appelé CIR (Call Information Report) qui contient le résultat du
déroulement de l’appel telle que le début de l’appel et la durée totale de l’appel. Dans certains
cas, ce message arrive erroné au SCP suite à une erreur de signalisation ce qui induit une
incohérence entre la durée et le coût de l’appel. Ce module a pour tâche principale de repérer
de telles erreurs et de les reporter dans un fichier que l’opérateur analysera, et pourra
éventuellement prendre certaines mesures pour remédier à de telles fautes. L’algorithme
qu’on a suivi est similaire à celui du calcul du coût de l’impulsion d’un appel dans le service
PPS [10] qui dépend de l’emplacement géographique de la partie appelante et appelée, du
temps et de la durée de l’appel. Nous avons implanté une sorte de matrice de taxation qui
comprend trois tables : origine, destination et temps de l’appel. En combinant ces trois
variables, nous obtenons dans une autre table la durée d’une impulsion que nous multiplions
par le nombre d’impulsions de l’appel pour trouver le montant. Comme dernière étape, nous
comparerons celui-ci avec le coût calculé par le système, et en cas de différence l’erreur sera
reportée. Voici une représentation de cet algorithme :

Origine Destination
1 Préfix1 1 Préfix1
2 Préfix2 Préfix22 2 Préfix2
Matrice des zones Intervalle

1 2 3 4 temporel
1
2 21
3
Matrice de Taxation
… … Time4 ..
…
21 170
22
23
24
Figure IV-12 Algorithme de taxation
Dans cet exemple, l’appelant A, dont le numéro commence par les chiffres dans Préfix1, a
appelé le numéro B qui commence par le Préfix3. La combinaison des deux préfix nous donne
une idée sur la géographie de cet appel, qui, en la combinant avec l’heure de l’appel, nous
obtenons la durée d’une impulsion qui est de 170 s. A la fin, supposons que l’appel a duré 500
secondes et que son montant est M1. Nous calculons M2 = (Coût d’une impulsion)x(3
impulsions) et nous comparons M1 et M2. En cas de différence, il faut reporter cet
enregistrement à l’opérateur.
IV-3-4- Le générateur de rapports
Le générateur de rapports est une rubrique très importante du « Performance Monitor ». En

effet, sa tâche principale est l’enregistrement périodique des mesures de performance dans des
rapports lisibles et facilement exportables vers d’autres types d’applications. Via l’interface
graphique, l’opérateur pourra programmer quelles sont les mesures qu’il veut reporter ainsi
que le format du rapport (excel, csv…) et aussi la fréquence de génération de ces mesures.
Les rapports seront générés automatiquement à la période mentionnée et archivés dans un
emplacement bien défini.

V- Manuel d’utilisation du « Performance Monitor »
L’interface graphique du « PerfMon » est conviviale et facile à utiliser. Nous l’avons conçu
pour répondre aux besoins de l’opérateur en terme de calcul et de visualisation rapides et
exactes des compteurs et d’indicateurs de performance. Dans ce qui suit nous allons essayer
de parcourir les fonctionnalités de cet outil en élaborant une sorte de manuel d’utilisation.
V-1- Présentation de l’interface de « PerfMon »
L’interface graphique de l’application « PerfMon » est composée de deux fenêtres principales.

La fenêtre de gauche sert au choix de la rubrique à exécuter, on distingue :
- Performance By simulation : Rubrique sous laquelle nous avons implémenté le

simulateur.
- Performance by Measurement : Rubrique sous laquelle nous avons implémenté les

modules de calcul des indicateurs de performances à partir des mesures.
La fenêtre de droite est l’écran où seront affichés les résultats. La figure suivante est l’écran
principal du « PerfMon » :
Figure IV-13 Ecran principal du « PerfMon »
V-2- Performance par simulation
Le simulateur peut être utilisé pour étudier le comportement du système sous différents types
de scénarios et en utilisant différents paramètres.

V-2-1- Paramètres de simulation
Pour utiliser le simulateur, l’opérateur doit le paramétrer. Voici la liste des paramètres de ce
simulateur :
- Arrival rate : c’est le taux moyen d’arrivée des appels par seconde. Cette constante sera
utilisée lors de la génération d’une séquence aléatoire qui obéit à une loi de Poisson
centrée en ce paramètre.
- Service Rate : c’est le paramètre caractéristique de la loi de service que nous avons
approximée, auparavant, par une loi exponentielle. Il sera utilisé pour la génération d’une
séquence aléatoire décrivant les délais des séjours des clients en communication.
- Alpha et Beta : Paramètres caractérisant la loi d’attente que nous avons approximée par
une loi Gamma. Grâce à ces paramètres, le simulateur va générer les séquences aléatoires
qui décrivent les délais d’attente des clients avant d’être servis.
- MaxBHCA (Maximum Busy Hour Call Attempt) : Ce paramètre caractérise la capacité

maximale du système en terme de traitement d’appels. Il donne le maximum nombre
d’appels que le système peut gérer pendant une heure.
- Simulation Duration : c’est la durée de la séquence aléatoire à simuler. Par exemple, en

entrant 1 heure comme durée de simulation, le simulateur générera des séquences
aléatoires qui décriront 1 heure de trafic.
- Load Measurment Period (ms) : Pour prédire si le système risquera de dépasser le seuil de
fonctionnement normal (MaxBHCA), nous avons implanté un mécanisme de contrôle de
congestion qui se base sur la mesure du trafic périodiquement à des intervalles espacés de
ce paramètre. Nous avons fixé ce paramètre à 30000 ms parce que, avec cette valeur, nous
avons obtenu des résultats très vraisemblables avec le comportement d’un système réel.
- Gap Duration : c’est la durée, pendant laquelle, le mécanisme de contrôle de congestion

est activé, afin d’essayer de limiter le trafic.
- Gap Time : Nous l’avons fixé à 11ms.
- Output Period : c’est la période d’affichage des résultats, nous l’avons fixé à 1 minute. Ce
qui veut dire que le simulateur affiche le résultat à chaque minute de trafic.

Le simulateur pourra être stoppé à n’importe quel moment à l’aide du bouton STOP. Une
barre d’état, en bas de l’écran, sert à nous renseigner sur l’état du simulateur, par exemple s’il
y a ou non une congestion.
La figure suivante donne une idée sur l’écran du simulateur.
Figure IV-14 Ecran du simulateur
V-2-2- Résultats de simulation
Les résultats sont affichés, au fur et à mesure que la simulation s’exécute, sous forme d’un
graphe qui trace le trafic en nombre d’appels par minute et qui sépare le trafic total du trafic
traité par le système. On trouve aussi l’histogramme qui met en évidence le nombre d’appels
ayant été rejetés suite au déclenchement du mécanisme de contrôle de congestion et le
compare au nombre d’appels réussis. La figure suivante présente un exemple d’exécution du
simulateur :
Figure IV-15 Exemple d’exécution pour le simulateur

V-3- Performance par mesures
L’étude de la performance par mesures se base sur les mesures déjà traitées par le module de
filtrage des fichiers de la plateforme. Plusieurs modules ont été inclus sous cette rubrique.
V-3-1- Statistiques et représentation du trafic total
Grâce à ce module, nous pouvons suivre le comportement du trafic quotidien. A la fin de

l’exécution de ce module, nous allons obtenir trois courbes et un histogramme.
Dans le concept des réseaux intelligents, les IPs (Intelligent Peripherals) sont des composants
qui contiennent des ressources spéciales utilisées par le service. Ils servent, en majeure partie,
à enregistrer les annonces qui sont des phrases audibles utilisées pour dialoguer avec
l’utilisateur (par exemple : l’annonce du solde d’un compte prépayé).
Il est important, pour l’opérateur, de savoir le nombre d’accès à ces composants et ceci pour
étudier le comportement des abonnés et éventuellement planifier des dimensionnements.
Un autre indicateur de performance important à connaître est la distribution des appels par
SSP, ceci est calculé et représenté sous forme d’un histogramme en cercle.
Voici une capture d’écran d’exécution d’un tel calcul.
Figure IV-16 Statistiques et représentation du trafic total

V-3-2- Exemple d’interprétation
La courbe tracée du trafic est celle du 31/12/2004, nous observons bien qu’entre 23h:00 et
00h:00, il y a eu un pic d’appels qui a atteint presque les 2600 appels par minute, donc une
décision que l’opérateur pourra entreprendre est de réserver une équipe de supervision dans
un tel cas.
L’histogramme de distribution des appels montre bien que le SSP1 est le plus sollicité avec
32% des appels, donc il est préférable de le libérer un peu en routant des appels vers les autres
SSP moins chargés.
L’accès aux IPs est presque constant entre 10h:00 et 20h:00 avec une valeur de presque 300
appels par minute.
V-3-3- Qualité du trafic
Le module « traffic Quality Engine » est une sorte de moteur de recherche qui a pour but
l’analyse de la qualité du trafic. La recherche se fait selon un indicateur que l’opérateur
choisira sur une interface dédiée.
Nous avons implémenté les indicateurs suivants :
- Calcul et représentation des appels efficaces pour un SSP donnée ou pour tous les SSPs :
Un appel est dit efficace si le montant consommé par l’abonné au cours de cet appel est
strictement supérieur à zéro.
- Calcul des appels non efficaces pour un SSP donnée ou pour tous les SSPs : C’est
l’ensemble des appels non-aboutissants pour une raison ou une autre. Il est important
d’étudier ces appels parce qu’ils consomment des ressources sans générer des revenus.
- Calcul et représentation des appels non efficaces rejetés par le SCP pour un SSP donnée
ou pour tous les SSPs.
- Calcul et représentation des appels non efficaces rejetés par les SSPs pour un SSP donnée
ou pour tous les SSPs.
- La distribution de ces types d’appels cités par SSP.
- La comparaison du nombre de ces types d’appels avec le nombre d’appels total.
Voici l’interface via laquelle on choisit l’indicateur qu’on veut représenter :

Figure IV-17 Choix de l’indicateur
Voici l’exécution d’une requête de calcul sur les appels non efficaces rejetés par tous les
SSPs :
Figure IV-18 Appels non efficaces rejetés par tous les SSPs
Plusieurs décisions peuvent être tirées juste en observant le format de la courbe et les
histogrammes. En effet, le nombre d’appels rejetés est énorme, l’opérateur doit
impérativement approfondir les analyses pour connaître la cause de ces rejets. Il peut
représenter d’autres indicateurs comme par exemple les rejets causés par le SCP et les rejets
par SSP… Par cette démarche, il peut cerner le problème et améliorer sa qualité de service.
V-3-4- Mesures de signalisation N°7
Ce module a pour objectif de générer les calculs de performances relatives à la signalisation

N° 7. Nous avons choisi de représenter pour la couche TCAP les données suivantes :
- Nombre de « Begin Message » envoyés et reçus.
- Nombre de « End Message » envoyés et reçus.
- Nombre de « Abort » envoyés et reçus.

- Nombre de « Continue » envoyés et reçus.
Concernant la couche MTP, nous avons choisi de représenter l’utilisation des liens de
signalisation. Cette information est très importante, elle renseigne sur le taux d’utilisation des
liens de signalisation en Erlang. L’analyse de telles mesures pourra initier un
redimensionnement de quelques liens.
Voici comment sont présentés ces indicateurs dans notre interface graphique :
Figure IV-19 Présentation des indicateurs de signalisation
V-3-5- Le générateur de rapports
Avec ce module, l’opérateur pourra, à tout instant, générer des rapports de performance.
L’output généré sera sous la forme d’un fichier exportable facilement vers d’autres
applications. Ainsi, il sera facile pour l’opérateur de les archiver et de personnaliser plus les
indicateurs de performance qu’il cherche à calculer.
Dans l’application que nous avons conçue et réalisée nous avons implémenté l’interface
suivante pour dire à l’opérateur quel rapport il veut générer :
Figure IV-20 Interface de génération de rapports

V-3-6- Le taxomètre
Nous avons implémenté ce module qui utilise deux fichiers de configuration : dest_tab et
orig_tab. Ces fichiers de configuration sont respectivement des clones des tables des
destinations et des origines.
Le « taxometer » détecte toutes les erreurs de taxation des appels dont la durée et la taxation
sont incompatibles. Il générera un fichier qui contient tous les enregistrements de ce type.
L'opérateur analysera ensuite ces fichiers pour conclure sur les mesures à prendre.
VI- Conclusion
L’objectif de ce chapitre a été de concevoir des outils qui aident l’opérateur à analyser les
performances du système réseau intelligent d’une manière claire, efficace et rapide.
Pour atteindre notre objectif, nous avons commencé par maîtriser un langage de
développement (Perl) pour implanter un simulateur du système. Puis, nous avons utilisé la
version graphique de ce langage pour développer une application graphique « Performance
Monitor » permettant d’analyser la performance du système en utilisant le simulateur ou en
utilisant des mesures.

Conclusion générale
Nous venons de présenter, dans ce travail, les étapes d’étude, de conception, et d’implantation
que nous avons menées afin de proposer des solutions adéquates au cahier de charge proposé.
Nous avons commencé par une étude complète des réseaux intelligents et de leurs services.
Cette étude nous a permis de bien connaître les principes fondamentaux de fonctionnement de
ces types de systèmes ainsi que les contraintes susceptibles de nous rencontrer lors de la
réalisation de notre application et nous a poussés par la suite à la recherche de solutions.
Ensuite, nous avons exposé nos solutions en proposant, en premier lieu, un modèle à base de
files d’attentes pour le système réseau intelligent et en adoptant une démarche bien définie
pour caractériser ce modèle et déterminer ses différents paramètres, et ceci en se basant sur
des mesures réelles.
Nous avons complété notre travail par la réalisation d’un simulateur du modèle afin de tester
le comportement du système sous différents scénarios. Ainsi, après la description du
mécanisme de contrôle de surcharge sur lequel se base ce système, nous avons intégré son
algorithme correspondant dans celui du simulateur en vue d’analyser son fonctionnement.
Enfin, une interface utilisateur, dédiée à l’opérateur, s’est avérée essentielle pour finaliser le
travail et augmenter la facilité et la souplesse d’utilisation de l’application. Cette application
permettra à l’opérateur d’analyser la performance et la qualité de services offertes par le
système réseau intelligent.
L’application traitée au cours de ce projet reste ouverte, car les indicateurs qui permettent de
donner des idées sur la performance sont très nombreux. De plus, les codes sources, sont
toujours à optimiser, à affiner et à compléter dans le but d’atteindre un produit complet prêt à
la commercialisation.
Enfin, pour clore ce rapport, nous espérons que les résultats obtenus trouveront un bon écho et
formeront un petit noyau de recherche pour tout intéressé par les applications d’étude de
performance.

Bibliographie
[1] INXpress System Description, System Information ,SIEMENS INXpress 5.2 A512-
A3-B130-1-7618
[2] Statistics and Reports, UMN : Statistics, SIEMENS-INXpress 5.2, A50012-A3-
C57-5-7619
[3] Bruno Baynat, Théorie des files d'attentes des chaînes de Markov aux réseaux à
forme produit
[4] Bruce S. Northcote et Donald E. Smith, Service Control Point Overload Rules to
Protect Intelligent Network Services, IEEE/ACM Trans. on Networkin, Vol. 6, No.
1, February 1998.
[5] Donald E. Smith, Ensuring Robust Call Throughput and Fairness for SCP
Overload Controls, IEEE/ACM Trans. on Networking, Vol. 3. No. 5. October
1995.
[6] Natalia Kryvinska et Harmen R.van As, Queuing System Models for Performance
Analysis of Intelligent Networks, Institute of Communication Networks, Vienna
University of Technology, Vienna, Austria.
[7] Simon ZNATY, Le réseau intelligent : Principes, Services et Architecture,
http:www.efort.com.
[8] Modules Perl, http://www.cpan.org/
[9] Loi normale, article de wikipédia, fr.wikipedia.org/wiki/loi_normale.htm
[10] Operation : Service Parameters Entry – UMN : Prepaid Service, SIEMENS-

INXpress 5.2, A50012-A3-B496-1-7619
[11] L. Kleinrock, and R. Gail, Solution Manual for Queueing Systems. Volume II:
Computer Applications, ISBN 0-942948-01-7, Technology Transfer Institute,
1986.

PFE SAIHI Afef

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PFE SAIHI Afef

Uploaded by

Copyright:

Available Formats

Dédicaces

A l’âme de ma chère mère...

A mon cher père,

A mon cher fiancé,

A toute ma famille et tous mes amis,

Au terme de ce travail, je tiens à exprimer mes remerciements à mon encadrant, à

Ma profonde reconnaissance s’adresse aussi à tout le personnel de SIEMENS et

Ce projet consiste à étudier la plate-forme réseau intelligent INXpress de SIEMENS

Après une analyse des principes généraux de ce type de réseau et de l’architecture de

La dernière étape a consisté à concevoir et implanter une application permettant le

Liste des figures ......................................................................................................................... v

Figure I-1 Relations entre plans .............................................................................................................. 8

ACG Automatic Call Gapping

ASD Advanced Service Definition

BCP Basic Call Process

Jusqu'à un passé récent, les réseaux de télécommunications assuraient la fourniture d'un

Afef SAYHI - PFE - INDP3 - 2005 1

Le chapitre final sera consacré à la partie développement et implémentation. Au cours duquel,

Afef SAYHI - PFE - INDP3 - 2005 2

II- Principes généraux du Réseau Intelligent

Le Réseau Intelligent (RI) a pour objectif de faciliter l’introduction de nouveaux services en

Le réseau intelligent est défini dans la recommandation Q1290 comme un concept

Afef SAYHI - PFE - INDP3 - 2005 3

L’implantation de son architecture doit faciliter l’introduction rapide et à moindre coût de

- L’introduction de nouvelles possibilités dans les réseaux de télécommunications pour

III- Modèle conceptuel du réseau intelligent

Le modèle conceptuel du réseau intelligent (Intelligent Network Conceptual Model-INCM),

Afef SAYHI - PFE - INDP3 - 2005 4

III -1- Plan de service (SP : Service Plane)

III -2- Plan fonctionnel global : (GFP : Global Functional Plane)

Le plan fonctionnel global correspond à l’interface de programmation. Il modélise un réseau

III -3- Plan fonctionnel réparti

Afef SAYHI - PFE - INDP3 - 2005 5

Les entités fonctionnelles de création et de gestion de service sont les suivantes :

- La fonction gestion de service (Service Management Function : SMF) qui contrôle le

Concernant les entités fonctionnelles d’exécution de service, on distingue les entités

Les entités fonctionnelles de contrôle d’appel sont les suivantes :

Les entités fonctionnelles de contrôle de service sont les suivantes :

- La fonction commande de service (Service Control Function : SCF) qui contient la

Afef SAYHI - PFE - INDP3 - 2005 6

III -4- Plan physique

Le plan physique constitue l’architecture physique du réseau intelligent. Il identifie les

L’architecture physique du réseau intelligent, spécialement de la plate forme INXpress, va

III -5- Relations entre les plans

Afef SAYHI - PFE - INDP3 - 2005 7

Figure I-1 Relations entre plans

IV- Architecture du réseau intelligent : INXpress de Siemens

Les réseaux intelligents sont composés de commutateurs, de bases de données et de serveurs

Afef SAYHI - PFE - INDP3 - 2005 8

Figure I-2 Plate-forme INXpress de Siemens

IV-1- Environnement de Création de Services (Service Creation Environment) : SCE

IV-1-1- Advanced Service Definition : ASD

Afef SAYHI - PFE - INDP3 - 2005 9

- La création des graphes de services ;

- La logique flexible des services (FSL) : informations de contrôle, manière de

IV-1-2- Service and User Management : SUM

- La gestion des utilisateurs : consiste en la création d’utilisateurs ou de groupes

IV-1-3- Service Customization : CS

Le SC s’intègre partiellement dans le SUM et comprend les applications suivantes :

Afef SAYHI - PFE - INDP3 - 2005 10

IV-1-4- Client Service Control : WebCSC

Le CSC assure la personnalisation des services. Il a une architecture client-serveur : le client

Deux applications sont reconnues au niveau du CSC :