CHOUIKH Aref

Cycle de formation des ingénieurs en Télécommunications
Option :
Réseaux et Services Mobiles
Rapport de Projet de fin d’études
Thème :
Modélisation de la charge des nœuds

« cœur » de réseau GSM du Tunisie
Télécom
Réalisé par :
Aref CHOUIKH
Encadrants:
M. Sami TABBANE
M. Mohammed Hédi JALLOULI
Travail proposé et réalisé en collaboration avec
Année universitaire : 2006/2007

Dédicaces
A ma chère mère Amna
A mon cher père Béchir
A mes chères sœurs Safa et Najia
A mes cher frères Naïm et Foued
A ma toute chère famille de prés et de loin
A tous mes enseignants
A tous mes amis
A tous ceux qui m’ont aidé à réaliser ce travail
A toutes les personnes que j’aime et qui m’aiment
Je dédie ce travail, et qu’il soit un sentiment de reconnaissance

honorable et fidèle envers eux.
Fidèlement Aref
Avant propos
Le travail présenté dans ce rapport à été fait dans le cadre de mon projet de fin
d’étude pour l’obtention du diplôme d’ingénieur en télécommunication, option Réseaux et
Service Mobiles (RSM), en collaboration avec l’opérateur Tunisie Télécom et au sien du
centre de supervision qualité LAC.
Au terme de ce travail, je tiens à remercier mes encadreurs de projet de fin

d’études d’ingénieur, M. Sami TABBANE professeur à SUP’COM Tunis et M.
Mohamed-Hédi JALLOULI ingénieur en chef chez Tunisie Télécom, qui m’ont honoré
par leurs encadrements de qualité et leurs soutiens, tout au long de ce projet, pour être à la
hauteur d’un tel projet.
Aussi, j’exprime toute ma reconnaissance à l’administration de SUP’COM

pour ces efforts majeurs et continus de présenter les meilleurs conditions de réussite à ces
élèves ingénieurs.
Et toute ma gratitude envers tous les personnels de la Direction Centrale des

Réseaux Mobiles de Tunisie Télécom et plus particulièrement à monsieur Foued Ben
SLIMEN ingénieur principale au service qualité et ceux qui n’ont épargné aucun effort
pour m’aider à l’accomplissement de ce projet.
Comme je n’oublie pas à exprimé mes sincères et spéciales remerciements à

Eliza Karnatsou Chatelain formateur certifié Ericsson, qui n’a pas hésité à m’aider et
clarifié le chemin à la bonne élaboration de ce travail.
Finalement, je remercie les membres de jury pour avoir accepter d’évaluer ce

travail.
Merci infiniment
Aref
Résumé:
Les noeuds du réseau coeur (core network) sont les entités du réseau mobile
qui prennent en charge les fonctions de gestion d'abonnés, d'établissement et de
contrôle des appels, de taxation, de gestion de mobilité, de connexion avec d'autres
réseau, de gestion des ressources ... etc. La capacité d'un noeud à gérer toutes ces
fonctions dépend non seulement du volume des tâches qu'il est appelé à exécuter mais
aussi de l'état dans lequel il se situe.
L'objet de ce projet est de développer un modèle de calcul de la capacité des

noeuds du réseau coeur mobile en fonction des différents cas de trafic qui les
sollicitent. Nous avons été amenés en premier lieu d’étudier l’architecture des nœuds
cœurs utilisé chez l’opérateur Tunisie Télécom dans le but d’identifier les paramètres
dont dépend la charge.
Ensuite en se basant sur des statistiques que nous avons pu récupéré auprès de
l’OSS, nous avons utilisé la méthode Moindre Carré pour l’estimation de la charge. Et
en vue de réduire le nombre de paramètres dont dépend cette charge nous avons
utilisés la méthode de l’analyse en composante principale ACP qui a prouvé son intérêt
en terme de la simplification du travail.
Mots clé :
AXE-MSC/VLR, Charge CPU, MC: Moindre Carré, ACP : Analyse en Composante
Principale.
Sommaire
Sommaire
Table des figures
Liste des tableaux
Liste des acronymes
Introduction......................................................................................................................1
Chapitre I: Architecture de la plateforme AXE……………………………………………3
I.1 Structure d’un AXE.................................................................................................4
I.1.1 Introduction ......................................................................................................4
I.1.2 Structure de l’AXE ...........................................................................................5
I.1.3 Structure modulaire d’un AXEMSC/VLR.........................................................7
I.1.3.1 Le module système APZ ............................................................................7
I.1.3.2 Les modules applicatifs «AM: Application Module» ..................................8
I.2 Le module système XSS «Existing Source System»: .............................................12
Chapitre II: Identification des paramètres pour les différents cas de trafic………………19
II.1 Les paramètres pour la mise à jour de localisation ...............................................20
II.1.1 Mise à jour de localisation normale (Figure II.1) ...........................................21
II.1.2 Mise à jour de localisation «IMSI DETACH» (Figure II.2).............................22
II.1.3 Mise à jour de localisation «IMSI ATTACH» (Figure II.3) ...........................22
II.1.4 Mise à jour de localisation Périodique (Figure II.4) .......................................23
II.2 «Handover» .........................................................................................................24
II.2.1 Handover inter MSC (Figure II.5) .................................................................25
II.2.2. Handover intra MSC (Figure II.6).................................................................26
PFE : Modélisation de la charge

des nœuds « cœur » de réseau GSM i i
du Tunisie Télécom
Sommaire
II.3. Gestion d’appel ...................................................................................................28
II.3.1 Appels «Arriveé» (MO «Mobile Originating»)..............................................28
II.3.2 Appels à destination d’un mobile (MT «Mobile Terminating») ......................30
II.4 Gestion des messages courts SMS........................................................................33
II.4.1 Envoi d’un SMS (Figure II.9)........................................................................34
II.4.2 Réception d’un SMS (Figure 2.10) ................................................................35
II.5 Procédure des services USSD (Figure II.11).........................................................37
II.6 Accès au réseau intelligent ...................................................................................38
Chapitre III: Modélisation de la charge d'un AXEMSC/VLR…………………………42
III.1 Récupération des statistiques...............................................................................43
III.2 Etude théoriques .................................................................................................46
III.2.1 Ajustemet avec Moindre Carré.....................................................................46
III.2.2 Principe de la méthode de l’Analyse en Composantes Principales: ACP.......50
III.3 Développement de l’outil de calcul de la capacité de la charge d’un AXE
MSC/VLR. .................................................................................................................52
III.3.1 Présentation de l’environnement de développement .....................................52
III.3.2 L’outil «AXEMSC/VLR Processor Load Measurements» ............................54
III.3.2.1 Organigramme ......................................................................................54
III.3.2.2 Guide d’utilisateur de l’outil «AXEMSC/VLR Processor Load
Measurements»...................................................................................................56
Chapitre IV: Étude de cas………………………………………………………………...68
IV.1 Résultats de l’ajustement avec Moindre Carré sans ACP....................................72
IV.2 Rrésultats obtenu avec Moindre Carré en utilisant les taux par abonné................72
IV.3 Résultat obtenu avec la méthode de l’Analyse en Composante Principale ACP. 75
Conclusion Générale ......................................................................................................79
Annexe

des nœuds « cœur » de réseau GSM ii ii
Table des figures
Figure I.1 Structures d’un AXE ........................................................................................6
Figure I.2 Structure modulaire d’un AXEMSC/VLR ........................................................7
Figure I.3 Structure d’un GSS ........................................................................................11
Figure I.4 Les blocs fonctionnels du sous système TCS. .................................................12
Figure I.5 Structure matérielle du TSS............................................................................13
Figure I.6 Facturation dans un MSC/VLR ......................................................................15
Figure II.1 Mise à jour de localisation normale ...............................................................21
Figure II.2: Mise à jour de localisation avec IMSI DETACH..........................................22
Figure II.3 Mise à jour de localisation avec IMSI ATTACH...........................................22
Figure II.4 Mise à jour de localisation périodique ...........................................................23
Figure II.5 «Handover» inter MSC .................................................................................25
Figure II.6 Handover intra MSC .....................................................................................27
Figure II.7 Appels «Arriveé»..........................................................................................29
Figure II.8 Appel à destination d’un mobile...................................................................31
Figure II.9 Envoi d’un SMS ...........................................................................................34
Figure II.10 Réception d’un SMS ...................................................................................35
Figure II.11 Procédure de demande de services USSD....................................................37
Figure II.12 Appel d’un abonné prépayé.........................................................................39
Figure II.13 Appel vers un abonné prépayé.....................................................................40
Figure III.1: Chaine de récupération des statistiques .......................................................45
Figure III.2 Structure du «framwork dot Net».................................................................53
Figure III.3 Organigramme de l’outil «AXEMSC/VLR Processor Load Measurements» 55

des nœuds « cœur » de réseau GSM iii iii
Figure III.4 Lancement de l’installation..........................................................................56
Figure III.5 Choix de répertoire d’installation.................................................................57
Figure III.6 Fin de l’installation......................................................................................57
Figure III.7 Raccourci du lancement ...............................................................................58
Figure III.8 Authentification...........................................................................................58
Figure III.9 Démarrage ...................................................................................................59
Figure III.10 Choix de la méthode (Tous les paramètres)................................................60
Figure III.11 Fenêtre principale ......................................................................................61
Figure III.12 Choix de la base de donnée ........................................................................61
Figure III.13 Connexion à la base de donnée établi.........................................................62
Figure III.14 Choix de temps de la simulation ................................................................62
Figure III.15 Évolution de la charge ...............................................................................63
Figure III.16 Répartition de la charge .............................................................................63
Figure III.17 Obtention des résultats pour la première méthode ......................................64
Figure III.18 Choix de la deuxième méthode ..................................................................65
Figure III.19 Obtention des résultats pour la deuxième méthode .....................................65
Figure III.20 Choix de la méthode de l’ACP...................................................................66
Figure III.21 Obtention des résultats pour la méthode de l’ACP......................................67
Figure IV.1 Estimation de la charge avec moindre carré sans ACP .................................69
Figure IV.2 Répartition de la charge selon les différnet stypes de trafic avec Moindre
carré sans ACP ...............................................................................................................70
Figure IV.3 Ajustement de la charge avec Moindre Carré sans ACP en utilisant un
modèles générale ............................................................................................................71
Figure IV.4 Répartition de la charge avec un modèle générale sans ACP ........................72
Figure IV.5 Ajustement de la charge en utlisant les taux par abonné des différents cas de
trafic...............................................................................................................................73
Figure IV.6 Répartition de la charge en utilisant les taux des différents types de trafic....73
Figure IV.7 Ajustement de la charge en utlisant un modèle générale pour les taux des
différents cas de trafic ....................................................................................................74
Figure IV.8 Répartitin de la charge en utilisant un modèle générale pour les taux des
différents cas de trafic ....................................................................................................74

des nœuds « cœur » de réseau GSM iv iv
Figure IV.9 Ajustement de la charge aprés que nous avons utlisé la méthode de l’ACP ..75
Figure IV.10 Répartition de la charge avec Moindre Carré après ACP..........................765
Figure IV.11 Aproximation de la charge avec Moindre Carré après ACP en utilisant un
seul modèle ..................................................................................................................776
Figure IV.12 Répartition de la charge avec Moindre Carré après ACP en utilisat un seul
modèle ...........................................................................................................................77

des nœuds « cœur » de réseau GSM v v
Liste des tableaux
Tableau II.1 Les compteurs pour la mise à jour de localisation .......................................24
Tableau II.2: Les compteurs pour le Handover inter et intra MSC...................................28
Tableau II.3 Les compteurs pour les appels «Arriveé»....................................................30
Tableau II.4 Les compteurs pour les appels servis ..........................................................33
Tableau II.5 Les compteurs pour la gestion des SMS.....................................................36
Tableau II.6 Les compteurs pour les service USSD.........................................................38
Tableau II.7 Les compteurs pour l’accès au réseau intelligent .........................................41
Tableau III.1: Tableau des données.................................................................................46
Tableau IV.1 Tableau Récapitulatif des résultats obtenus ...............................................77

des nœuds « cœur » de réseau GSM vi vi
Liste des acronymes
ACA ACcounting Analyses
AM Application Modules
AMMS Automatic Meet Me Service
AUCAM Autentication Center Application Module
CA Charging Analyses
CA Charging Analysis
CC Charging Case
CHS Charging Subsystem
CLCOF CaLl supervision & Coordination Of Functions
CLR Common Language Runtime
COMS Communication Subsystem
COSS Connection Service Subsystem
CPS Central Processor Subsystem
CSE Camel Service Environment
CSI Camel Subscription Information
DA Digit Analyses
ECPOOL Echo Canceller in POOL
ESS Extended Switching Subsystem
ETC Exchange Terminal Circuits
FNRAM Flexible Number Register AM
GSS Groupe Switching Subsystem
HLRAM Home Location Register AM
IDP INITIAL DETECTIO POINT
IN Intelligent Networks
IST Intelligent network Service Trigger
IWSMS IWMSC Short Message Service Coordinator
J IT Just In Time compilation
l’ISDN Integrated Service Digital Network
l’OSS Operation and Support System
MA Mass Announcement
MABC Mobile Analysis of Bearer Capabilities

des nœuds « cœur » de réseau GSM
vii
vii
MAUTH Mobile Authentication
MBPAG Mobile GSM Paging
MCS ManMachine Communication Subsystem
MCSE Mobile Connection Service
MDS Mobile Data Subsystem
MHOC Mobile Handover Coordinator
MHOMH Mobile Handover Message Handler:
MLCAP Mobile Location Cancellation MAP
MLUAP Mobile Location Updating MAP
MML Man Machine Language
MMMLR Mobile Mobility Management Location Registration
MRNPH Mobile Roaming Number Administration
MRRM Mobile Radio Ressources Management
MSDAP Mobile Subscriber Data MAP
MSIL MicroSoft Intermediate Language»
MSMMH Mobile Short Message Service Message Handler
MSMO Mobile Short Message Service Mobile Originated
MSMT Mobile Short Message Service Mobile Terminated
MSS Mobile Switching Subsystem
MTACC Mobile Coordinator, ASubscriber, Call Control
MTBCC Mobile BSubscriber, Call Control Protocol Control
MUSSAN Mobile USSD Analyser
MUSSH Mobile USSD Handler
NE Network Elément
OICK Originating IN Category Key
OT Object Types
PLMN Public Land Mobile Network
PSTN Public Switched Telephony Network
RA Route Analyses
RE Register function block
RMP Ressources Module Platform
RPS Regional Processor Subsystem
SDM Statistical Data Mart
SHS Short Message Services Subsystem
SMIA Statistical Measurement Initiation and Administration
SSFAM Service Switchnig Function AM
SYSOMAM SYStem Operation and Maintenace AM
TCS Traffic Control Subsystem
TICK Terminated IN Category Key
TRACH Transit Call Charging
TSS Trunk and Signalling Subsystem
XSS Existing Source System:

viii
vii
Introduction
Introduction
A
ujourd’hui, les réseaux de téléphonie mobile ne cessent d’évoluer dans le but de
fournir le maximum de services, avec une qualité supérieure pour gagner de plus
en plus d’abonnés en augmentant les revenus et en minimisant les dépenses.
C’est dans ce cadre qu’intervient notre projet, qui consiste à modéliser la charge des
nœuds cœur du réseau GSM de l’opérateur Tunisie Télécom , qui sont les MSC/VLR
basés sur la plate-forme AXE d’Ericsson. Ceci afin d’optimiser le dimensionnement du
réseau dans le cadre de l’amélioration de la qualité de service (QoS) et la minimisation
des dépenses.
La plate-forme AXE est basée sur un composant matériel, qui s’appelle

«Central Processor : CP». C’est le processeur central qui exécute le programme
principal de l’AXE et contrôle en même temps le fonctionnement global de ce dernier. Le
CP de l’AXE existe en plusieurs versions, celles l’objet du présent projet est l’APZ 212
33.
Nous essayons à travers ce rapport à expliquer au mieux notre stratégie de travail.

Dans un premier chapitre, nous parlerons de l’architecture de la plate-forme AXE, afin de
mentionner les différents blocs fonctionnels, constituant ses différents sous-systèmes, qui
prennent en charge les messages échangés pour les différents cas de trafic.
Dans un deuxième chapitre, on expliquera l’intervention de ces différents blocs

fonctionnels pour le traitement de chaque message selon le type de trafic. Ceci est dans le
but d’identifier les différents compteurs mesurant le nombre d’exécutions de chaque
opération pendant une période donnée. Ces compteurs constituent nos paramètres de
travail dont dépend la charge.

1
Introduction
Après avoir identifié nos variables de travail, on expliquera, dans un troisième

chapitre, notre méthodologie de travail où l’on montrera l’utilité du moindre carré dans
l’approximation des phénomènes physiques réels.
En vue de réduire le nombre de variable mis en jeu dans la méthode du moindre carré,
nous utiliserons la méthode de l’ACP «Analyse en Composante Principale» qui permettra
de n’utiliser que les paramètres les plus pertinents.
Dans le dernier chapitre nous procéderons à une étude de cas, qui consiste à
appliquer la méthode à certains MSC/VLR se situant dans des régions différentes. Ceci
nous permettra de conclure que les différents MSC/VLR, bien qu’ils soient dans des
« environnements » différents, obéissent pratiquement au même modèle.

2
Chapitre I: Architecture de la plateforme AXE
Chapitre
I
A rchitecture
de la plateforme AXE
I.1 Structure d’un AXE
I.1.1 Introduction
I.1.2 Structure de l’AXE
I.1.3 Structure modulaire d’un AXE-MSC/VLR
I.2 Le module système XSS «Existing Source

System»

3
Chapitre I :
Architecture
de la plateforme AXE
Afin d’identifier les paramètres de chaque cas de trafic nous devons commencer
par une étude sur l’architecture de la plateforme AXE. L’AXE est un composant
programmable ouvert dont le fonctionnement dépend de l’application qu’on y installe.
C'est-à-dire qu’il peut jouer le rôle d’un MSC/VLR, d’un BSC, d’un HLR, d’un SCP etc.
Chaque application installée dans l’AXE est constituée d’un ensemble de blocs
fonctionnels définis par leurs interfaces grâce auxquelles ils peuvent communiquer entre
eux.
I.1 Structure d’un AXE
I.1.1 Introduction
L’AXE est introduit au marché depuis l’année 1975, c’est un produit finie et
ouvert, à utilisation multiple, pour la commutation numérique des réseaux de
télécommunication publique. Il a des capacités de traitement temps réel, de grand volume
de trafic [1].
Quand l’AXE est introduit pour la première fois au marché, l’application

majeure de télécommunication qu’il a supporté est le PSTN «Public Switched Telephony
Network». Depuis ce temps il a subi une évolution continue pour supporter aujourd’hui,
les autres applications comme l’ISDN «Integrated Service Digital Network», le PLMN
«Public Land Mobile Network» ainsi qu’au «Business Communications».
L’AXE supporte aussi, les réseaux intelligents, IN «Intelligent Networks», et les réseaux
de signalisation. Il fourni des fonctionnalités de différents niveau pour ces deux type de
réseaux.

4
I.1.2 Structure de l’AXE
Le succès de l’AXE provient de sa flexibilité et sa modularité qui lui permettent

de s’adapter aux changements des besoins des réseaux et des utilisateurs finaux. Sa
structure modulaire permet d’alléger sa manipulation et sa flexibilité lui permet de
s’adapter au monde des télécommunications [1].
L’AXE consiste en un ensemble indépendant des blocs fonctionnels. Chacun de

ces blocs effectue une tâche bien spécifique et communique avec les autres par le moyen
des signaux et interfaces bien définies. Ces blocs fonctionnels peuvent être ajoutés,
supprimés ou modifiés sans toucher les autres parties du système. Chaque ensemble de
blocs fonctionnels est regroupé dans un sous-système qui à son tour appartient à un
module système (Figure I.1). Il existe deux types de structure de l’AXE. Une qui ne suit
pas une structure modulaire (AXE 105) et qui peut être appliqué à un BSC. Et une autre
structure qui est modulaire (AXE 106) et qui peut être appliqué à un MSC/VLR. Le
niveau système 2, dans la structure non modulaire d’un AXE, est constitué uniquement
de deux modules systèmes APZ et APT. L’APT se charge généralement des fonctions de
commutation. On le nomme groupe de commutation ou GS «Groupe Switch». L’APZ
assure le contrôle et l’exploitation de l’équipement. En plus de ces deux modules système,
la structure modulaire admet les modules applicatifs AM «Application Modules» dont le
rôle dépend de l’application que l’en installe [1]. Elle admet aussi le module RMP
«Ressources Module Platform» qui permet de fournir les ressources matérielles
nécessaires pour les différents AM.

5
AXE AXE
Niveau Système 1
AM
APT APZ AM XSS RMP APZ
AM
Niveau Système 2 Modules Systèmes
Sous-systèmes
«Set of Parts»
Blocs Fonctionnels
Unités Fonctionnels
Structure Non Modulaire (AXE 105) Structure Modulaire (AXE 106)
Figure I.1 Structures d’un AXE
Si nécessaire, les ensembles de rôles ou bien «Set of Parts» sont utilisés entre le
niveau des sous-systèmes et celui des blocs fonctionnels. Ils constituent en fait un
ensemble des blocs fonctionnels dont le rôle est d’assurer les tâches relatives aux
fonctions similaires. Les tâches confiées aux différents sous-systèmes sont ainsi divisées
en blocs fonctionnels. Chacun de ces blocs constitue une unité bien définie avec ses
propres données et son signal standard d’interfonctionnement [1]. En plus un bloc
fonctionnel consiste en un ensemble d’unités fonctionnelles qui peuvent être groupés
selon trois types :
¾ Des unités matérielles.
¾ Des unités software régionales dont le rôle est de superviser la coté
hardware.
¾ Des unités software centrales qui sont responsables des fonctions
nécessaires d’analyse complexe (exemple : l’établissement d’appel).

6
I.1.3 Structure modulaire d’un AXE-MSC/VLR
La structure modulaire est un ensemble de principes bien définis pour le

développement et l’implémentation des applications software d’un AXE. Un exemple
d’un nœud qui suit cette structure est le MSC/VLR l’objet de notre projet. La structure
modulaire permet de faciliter la combinaison de plusieurs applications relatives de
télécommunication dans un même nœud. Ceci lui permet d’être capable de dialoguer avec
les autres nœuds du réseau [2]. En plus les AM sont indépendants les uns des autres et
peuvent communiquer à l’aide de protocoles et d’interfaces bien définis (Figure I.2).
XSS AM AM AM
MMS SHS
APSI
RMP
MSS TSS
COMS COSS
CP RP SP
AP Z
Figure I.2 Structure modulaire d’un AXE-MSC/VLR
I.1.3.1 Le module système APZ

Le module système APZ constitue le cœur système d’un AXE. Il se charge du
traitement des données et du contrôle des autres modules. Les interfaces entre les modules
système peuvent être soit directe où les données sont échangées, entre eux, directement
soit logique où les données sont échangées via le RMP.

7
Le module système APZ admet les sous-systèmes suivants :

CPS «Central Processor Subsystem»
Il contient du soft et du hard tout en admettant la capacité maximale d’un AXE. Il
est responsable de toutes les fonctions de haut niveau comme l’analyse des numéros
de téléphone et le traitement de l’information de taxation. Il assure aussi des tâches
administratives comme le stockage et le chargement des programmes. La procédure
d’établissement d’appel est l’une des principales tâches contrôlée par le CP. Pour des
raisons de fiabilité le CPS contient deux processeurs centraux «2 Central
Processors» travaillant en parallèle dont l’un est en exécution et l’autre en veille
qui va prendre la relève en cas de panne du CP exécutif. Les deux sont reliées par le
MAU «Maintenance Unit» afin d’assurer la synchronisation1.
RPS «Regional Processor Subsystem»

Il contient aussi du soft et du hard. La partie hard constitue un ensemble des
processeurs régionaux RP «Regional Processor», tandis que le soft est un ensemble
de programmes administratifs localisés dans les RP. Le RP est responsable du
contrôle de tout le matériel situé dans la partie commutation (XSS : C/APT et 1/APT)
et il est contrôlé par le CP. Le CP peut contrôler jusqu’à 1024 RP [1] qui sont
regroupés dan un RPH «Regional Processor Handler» (une sorte de conteneur de
RP). Le RP peut décharger le CP de simples tâches courantes et de certaines
opérations administratives.
MCS «Man-Machine Communication Subsystem»

Le sous-système MCS permet de gérer la communication entre les dispositifs
d’entrées sortie et le reste du système AXE. Ces dispositifs peuvent être des écrans
afficheurs, panneaux d’alarmes ou bien l’OSS «Operation and Support System». Le
MCS constitue l’interface homme machine avec l’AXE.
I.1.3.2 Les modules applicatifs «AM: Application Module»
Les modules applicatifs sont utilisés pour modéliser et implémenter certaines

applications fonctionnelles. On peut trouver par exemple le module applicatif, SSFAM
qui implémente la fonction d’accès au réseau intelligent. Les AM sont indépendants de la
structure interne de l’AXE.
1
Voir Annexe 1
8
Ceci rend très facile la modification, le remplacement ou la suppression des

différents modules d’application pour n’importe quel équipement se basant sur le système
AXE. Voici quelques modules applicatifs qu’on peut trouver dans un AXE :
AUCAM «Authentication Center Application Module»

Il contient les informations nécessaires pour l’authentification et le chiffrement. Il
admet une interface directe avec le RMP et des interfaces logiques avec le HLRAM,
le SYSOMAM pour les statistiques et l’APZ.
HLRAM «Home Location Register AM»

Responsable du stockage des données au niveau du HLR. Il contient en fait toutes
les informations concernant les abonnés MSISDN, IMSI, USSD etc. Il admet les
mêmes interfaces que l’AUCAM.
FNRAM «Flexible Number Register AM»

Gère la relation entre le MSISDN d’un mobile et son IMSI. Ceci va permettre à
l’opérateur d’allouer l’IMSI de son abonné d’une manière plus flexible lorsque celui-
ci change d’opérateur. Le FNR réachemine le message au réseau approprié.
SSFAM «Service Switching Function AM»

Il Assure la fonction de commutation pour les services des réseaux intelligents, et
admet les mêmes interfaces que le SCFAM «Service Control Function Application
Module» et n’admet que les protocoles CAP, INAP et TC.
SYSOMAM «SYStem Operation and Maintenance AM»

Il assure la supervision du nœud via notamment la collecte des mesures des
statistiques et les données provenant des autres modules d’application ainsi que la
coordination des demandes des collectes. Il assure entre autre les fonctions suivantes :
• Traçage du chemin d’appel.
• Lecture des informations d’état du dispositif.
• Blocage et déblocage manuel des numéros des abonnés.
• Audit sur les comptes.
• Les Statistiques et les mesures de trafic.

9
Le SYSOMAM communique avec un système d’entrée sortie pour recevoir le

mécanisme de la collecte des compteurs des donnés. Il admet en fait le sous-système STS
«Statistic and Traffic measurement Subsystem» qui se charge de la collecte, du traitement
et de la présentation des informations statistiques relatives aux différents cas de trafic.
Ceci grâce aux deux blocs fonctionnels STSORT «STs SORTing program» et
STDB «STs Data Base». En effet le bloc STSORT cherche les compteurs à partir du
CP «Central Processor» et les enregistre au niveau de STDB. Les compteurs se
réinitialisent chaque heure.
I.1.3.3 Le module Système RMP «Ressources Module Platform»
Le module système RMP, est responsable de l’allocation des ressources pour

toutes les applications. En d’autres termes il fournit toutes les ressources matérielles
demandées par les modules d’applications et fait leurs plannings via l’interface APSI
«Application Platform Service Interface». L’interface APSI est utilisée pour offrir des
services de types client serveur [3]. Ces services sont implémentés au niveau du RMP et
du XSS. En plus, ces services sont nécessaires pour mettre en coordination les ressources
communes entre les différents modules d’application. Voici les sous-systèmes qu’on peut
trouver au niveau du RMP :
GSS «Group Switching Subsystem»

Le sous-système GSS est responsable de la commutation et de la
synchronisation du réseau. Il permet aussi de gérer la sélection, la connexion et la
déconnexion des circuits de parole ainsi que les chemins que les signaux doivent
prendre à travers le groupe de commutation GS «Group Switch». Ce dernier contient
des blocs fonctionnels TSM «Time Switch Module» qui consistent en des mémoires
tampon et des blocs SPM «Space Switch Module» qui sont regroupés dans une
matrice de commutation. Chaque SPM peut gérer plusieurs TSM. Comme Le GS a
besoin de la synchronisation, le GSS admet des modules d’horloge CLM «Clock
Modules» qui déterminent la fréquence d’horloge de lecture et d’écriture chez les
mémoires de TSM. Pour des raisons de fiabilité le GSS admet trois modules
d’horloge (3CLM) et le GS entier est dupliqué en deux plans séparés qui fonctionnent
en synchronisation.

10
Group Switch (GS)

GSS
TSM 0
ETC TSM 0
SPM
SPM
TSM 1
TSM 1
T SM 3 1
T SM 3 1
Clock pulses for TSM and SPM
CLM 0 CLM 1 CLM 2

Network Synchronization NS
Figure I.3 Structure d’un GSS
COMS «Communication Subsystem»

Il implémente certains services spécifiques à l’interface APSI. Il fournit en
fait une interconnexion entre les différents modules d’application (AM) d’un même
nœud physique afin qu’ils soient interconnectés. Le sous-système COMS permet
aussi une interconnexion avec des AM externes.
COSS «Connection Service Subsystem»

Il se charge de fournir à l’utilisateur un modèle abstrait de la connexion à
travers l’équipement de commutation. Ceci le rend responsable de l’établissement de la
connexion, selon le model qu’il a fourni, ainsi qu’au contrôle d’autres équipements
comme le GS.
Maintenant il ne reste qu’à entrer dans les détails relatifs au module system
XSS. C’est ce dernier en fait qui gère la commutation et les différents cas du trafic.
Vue son importance, nous avons lui consacré la deuxième partie de ce chapitre.

11
I.2 Le module système XSS «Existing Source System»:
Le XSS constitue le système de base de la commutation et de la gestion du

trafic. Il permet de communiquer avec d’autres nœuds du réseau, comme les nœuds du
réseau téléphonique fixe ou les autres nœuds du réseau mobile. Le XSS contient plusieurs
sous-systèmes avec leurs blocs fonctionnels correspondants. Les principaux sous-
systèmes sont les suivants.
TCS «Traffic Control Subsystem»

Le sous-système de contrôle de trafic consiste en un ensemble de blocs fonctionnels
et ne contient que du soft. Ses tâches principales sont l’établissement, la supervision et la
terminaison d’appel. En plus il analyse les chiffres entrants et sélectionne les routes
sortantes. Ses blocs fonctionnels sont les suivants [1]:
¾ RE «Register function block»
Il permet de stocker les chiffres saisis et coordonne la procédure d’établissement
d’appel.
¾ CLCOF «Call supervision & Coordination Of Functions»
Quand l’appel est établit, ce bloc le supervise et se charge de le libérer.
¾ DA «Digit Analyses»
Il contient des tableaux pour l’analyse des chiffres saisis.
¾ RA «Route Analyses»
Il contient des tableaux pour la sélection des routes à suivre.
TCS TSS
Route
CLCOF RA
RC R
RE
CC TE
MSS
CHS
Figure I.4 Les blocs fonctionnels du sous système TCS.

12
Pour expliquer le fonctionnement des différent blocs fonctionnels du TCS nous

pouvons procéder comme suit : lors de l’établissement d’un appel le bloc RE enregistre le
numéro saisi sous forme de bits. Ensuite il les transmet au bloc DA afin d’être analysés
jusqu’à l’obtention des résultats suivants :
9 CC «Charging Case» : le numéro sera traité par le CA «Charging Analyses» dans
le sous-système de tarification CHS «Charging Subsystem» que l’on décrira par la
suite.
9 Les informations de l’acheminement peuvent être soit RC «Routing Case»
où elles vont pointer à une route sortante dans le TSS à travers le bloc RA; soit
TC «Terminated Call» où elles vont donner une référence à un MSS «Mobile
Switching Subsystem» pour un appel à un abonné mobile.
TSS «Trunk and Signalling Subsystem»

Le sous-système TSS comprend du soft et du hard et il est responsable de la
signalisation et de la connexion à d’autres nœuds. Il contient certains blocs fonctionnels
dont on peut trouver [1]:
¾ ETC «Exchange Terminal Circuits»
On peut trouver plusieurs ETC. C’est sont eux qui gèrent la communication avec
les autres nœuds du réseau. Ils présentent une interface physique avec le groupe de
commutation (GS).
¾ ECPOOL «Echo Canceller in POOL»
Ceci est utilisé pour annuler le maximum d’écho.
ESS
ETC Trunk line to BSC
CCD
GS
ETC Trunk line to
AST MSC/VLR or PSTN/PLMN
ECPOOL
TSS
Figure I.5 Structure matérielle du TSS.

13
ESS «Extended Switching Subsystem»

Le sous-système de commutation étendu est responsable des opérations qui
nécessitent des connexions avec plus de deux communicants, pour un seul appel. Il
constitue ainsi une plateforme pour les services voix interactives ainsi que la distributions
en masse des messages. Il fournit aussi une interface de signalisation avec les ressources
voix implémentées à l’extérieur. Il comprend les blocs fonctionnels suivants :
¾ MA «Mass Announcement»
Il permet la distribution massive des messages à certains abonnés, bien définis, en
même temps. Il assure la diffusion des messages.
¾ AMMS «Automatic Meet Me Service»
Il permet aux abonnés d’établir et de participer à des conférences téléphoniques
sans l’intervention de l’opérateur. Il gère l’interconnexion des différents abonnés
en fonction du type de conférence.
CHS «Charging Subsystem»
Le sous-système de tarification assure la taxation des communications des

abonnés. Il permet aussi de collecter et d’extraire les informations concernant les appels,
les services supplémentaires et leur invocation. Le CHS contient plusieurs blocs
fonctionnels divisés en deux groupes. Il y a ceux qui se chargent de la façon de la taxation
(temps, quantité du trafic) et ceux qui se chargent de l’aboutissement d’appel, en fonction
du solde existant y compris les communications internationales. On peut trouver alors
le [1]:
¾ TRACH «Transit Call Charging»

Il s’occupe du contrôle de la taxation de tout appel de transit selon de temps de
communication, ainsi que toutes les autres informations qu’il peut avoir à partir du
RMP (sous-système COMS).
¾ CA «Charging Analysis»
Permet de savoir si la tarification est applicable à l’activité du trafic et comment
elle sera faite.
¾ ACA «Accounting Analyses»
Qui se charge de l’exécution de la tarification.

14
Toutes les informations concernant les communications y compris la date, la

durée ainsi que les frais sont enregistrés dans un enregistrement nommé CDR «Call Data
Record». Cet enregistrement peut être extrait à travers une connexion X.25 ou TCP/IP
vers un centre de facturation «Billing Center».
Figure I.6 Facturation dans un MSC/VLR
MSS «Mobile Switching Subsystem» [4]

Le sous-système de commutation des abonnés mobile MSS contient les
techniques de commutation de la téléphonie mobile. Il est responsable de l’établissement,
de contrôle et supervision des appels. Il permet de gérer aussi les services supplémentaires
et contient une interface avec le sous-système de facturation. Dans un GMSC le MSS se
charge de trouver les informations de routage à partir du HLR. Dans un MSC/VLR, le
MSS contient plusieurs blocs fonctionnels parmi eux on peut citer:
¾ MABC «Mobile Analysis of Bearer Capabilities»
Il gère la négociation de la capacité de pris en charge la connexion entre l’abonné
mobile et le MSC.
¾ MCSE «Mobile Connection Service»
Il permet de gérer le trafic requis pour l’établissement des appels, sortants et
entrants, y compris le contrôle de la tonalité et les alertes d’appels.
¾ MTACC «Mobile Coordinator, A-Subscriber, Call Control»
Il est responsable de l’établissement et la supervision d’un appel sortant, en plus
de l’administration de l’état de l’appel.
¾ MTBCC «Mobile B-Subscriber, Call Control Protocol Control»
Il assure la même fonction que MTACC mais pour les appels entrants.
¾ MUSSH «Mobile USSD Handler»
Il gère le trafic relatif aux services USSD envers les autres nœuds coeur.

15
¾ MUSSAN «Mobile USSD Analyser»

Il analyse la requête envoyée par le mobile pour les services USSD afin de
déterminer les services demandés et l’opération à initier.
MMS «Mobile Mobility and Radio Subsystem» [5]

Il se charge de la gestion de mise à jour de la localisation. Il permet de gérer aussi
les ressources radio, les BSC, le «Handover» ainsi que la signalisation. Ses blocs
fonctionnels peuvent être classés selon leurs fonctions. Il y a ceux qui se chargent des
fonctions d’analyse et d’administration, ceux qui se chargent de la gestion de la mobilité
et d’autres dont la tâche est de gérer le «Handover» :
¾ MAUTH «Mobile Authentication»

Il est responsable de la procédure de la sécurité en terme d’authentification et de
chiffrement. Quand l’authentification est établis fait avec succès, il demande de
commencer le chiffrement en spécifiant la liste des algorithmes qui peuvent être
utilisés. Si l’authentification échoue il le déclare auprès du bloc MAUTHA qui
permet d’enregistrer tout échec d’authentification.
¾ MBPAG «Mobile GSM Paging»

Il assure les avis de recherche sur l’interface A.
¾ MHO «Mobile Handover»

Il permet de gérer tout type de Handover inter et intra MSC. Il contrôle la
signalisation envers le BSC et ordonne le changement de circuit de la voix durant
le Handover.
¾ MHOC «Mobile Handover Coordinator»

Il contrôle le Handover jusqu à la fin de la communication «Call Release»
¾ MHOMH «Mobile Handover Message Handler»

Il gère les messages de signalisation du Handover sur l’interface E.
¾ MMMLR «Mobile Mobility Management Location Registration»

Il permet de mettre à jour la localisation de l’abonné et l’enregistre dans le sous-
système MDS.

16
¾ MRRM «Mobile Radio Ressources Management»

Il supervise et contrôle le lien de signalisation entre le MSC et le BSC et gère
les messages échangés. Ce bloc est aussi inclus dans certaines procédures durant le
raccordement et la réinitialisation des BSC.
MDS «Mobile Data Subsystem» [6]

Le sous-système MDS se charge du stockage de toutes les informations concernant les
abonnés mobiles provenant du HLR. Il gère en fait la mise à jour de localisation ainsi
qu’aux informations relative aux abonnés. Il contient aussi plusieurs blocs fonctionnels
dont nous pouvons trouver :
¾ MLCAP «Mobile Location Cancellation MAP»

Il met en œuvre l’annulation de la localisation lors de la réception du message
«CANCEL LOCATION».
¾ MLUAP «Mobile Location Updating MAP»

Il met à jours la zone de localisation courante du mobile.
¾ MRNPH «Mobile Roaming Number Administration»

Permet de gérer le numéro MSRN.
¾ MSDAP «Mobile Subscriber Data MAP»

Il manipule l’insertion et la suppression des donnés de l’abonné.
SHS «Short Message Services Subsystem» [7]

Le sous-système SHS se charge de toutes les procédures relatives aux servies des
messages courts. On y trouve principalement les blocs fonctionnels suivants:
¾ IWSMS «IWMSC Short Message Service Coordinator»

Il organise les messages provenant du mobile ainsi que les tâches nécessaires pour
la tarification.
¾ MSMMH «Mobile Short Message Service Message Handler»

Il assure l’encapsulation et la décapsulation des messages relatifs aux envois des
SMS.

17
¾ MSMO «Mobile Short Message Service Mobile Originated»

Il est responsable de l’aboutissement du message initié par le mobile jusqu’à
l’IWMSC.
¾ MSMT «Mobile Short Message Service Mobile Terminated»

Il se charge de l’aboutissement du message à sa destination et fournit un rapport
de délivrance. Il fournit aussi des informations de diagnostic quand le message
n’aboutit pas avec succès.
Dans cette première partie nous avons étudié l’architecture d’un AXE-
MSC/VLR dans le but de décrire les principaux blocs fonctionnels qui prennent en
charge les différents messages échangés pour chaque cas de trafic. Dans chaque bloc
fonctionnel il y a des compteurs qui mesurent le nombre d’exécutions d’une opération
donnée. Dans la partie qui suit nous allons décrire les différents cas de trafic sollicitant le
MSC et l’intervention des différents blocs fonctionnels mis en jeu.

18
Chapitre II: Identification
des Paramètres pour les différents cas du trafic
Chapitre
II
I dentification des Paramètres
pour les différents cas de trafic
I.1 Mise à jour de localisation
I.1.1 Mise à jour de localisation Normale
I.1.2 IMSI DETACH
I.1.3 IMSI ATTACH
I.1.4 Mise à jour de localisation périodique
I.2 Hondover
I.2.1 HO Inter MSC
I.2.2 HO Intra MSC
I.3 Gestion d’Appels
I.3.1 MO
I.2.2 MT
I.4 SMS
I.4.1 MO SMS
I.4.2 MT SMS
I.5 USSD
I.6 Accès au réseau Intelligent

19
Chapitre II :
Identification des Paramètres

pour les différents cas de trafic
Les paramètres correspondants à chaque cas de trafic correspondent aux

différents compteurs existant au niveau de chaque bloc fonctionnel. Ces compteurs
mesurent le nombre de traitement d’un message particulier correspondant à un cas de
trafic. Dans ce chapitre nous énumérons les différents compteurs pour chaque cas de
trafic. Chaque ensemble de compteurs est regroupé dans ce qu’on appelle un «Object
Type». Cette notion sera traitée dans le prochain chapitre. Les blocs fonctionnels ne se
mettent en marche que sous l’initiation du CP. C'est-à-dire que celui-ci les ordonne de
prendre en charge le message qui convient et il reçoit le résultat retourné par le bloc
fonctionnel.
II.1 Les paramètres pour la mise à jour de localisation
La procédure de mise à jour de localisation permet au réseau d’être informé de

l’emplacement du mobile à tout moment. Cet emplacement correspond à la zone de
localisation. Une zone de localisation consiste en un ensemble de cellules dans lesquelles
le mobile se déplace sans informer le réseau de sa position. Quand le mobile se déplace
dans deux cellules appartenant à deux zones de localisation, le réseau doit être informé via
une procédure de mise à jour de localisation. Il y a quatre types de mise à jour de
localisation [2]:
9 Mise à jour normale.
9 IMSI DETACH.
9 IMSI ATTACH
9 Mise à jour périodique.

20
II.1.1 Mise à jour de localisation normale (Figure II.1)
C’est le sous-système MMS qui se charge de toutes les procédures relatives à la

gestion de localisation ainsi qu’au Handover. En effet, lors de la réception du message
«A_LU_REQUEST» ; le bloc fonctionnel MRRMH le décapsule et renvoie le résultat au
CP. Ce dernier va se rendu compte qu’il s’agit d’une mise à jour de localisation normale.
Il avertit alors les autres blocs concernés pour qu’ils prennent en charge la procédure.
Parmi ces blocs on trouve le MAUTH qui se charge de toutes les opérations
d’authentification et de chiffrement. C’est lui qui demande au bloc MVLRP de chercher
le triplet d’authentification à partir du VLR précédent. Une fois l’authentification se fait
avec succès, le bloc fonctionnel MLUAP exécute la mise à jour de localisation au niveau
du HLR. C'est-à-dire qu’il traite les messages «MAP_UPDATE_LOCATION» et
«MAP_INSERT_SUBSCRIBER_DATA» et renvoie au HLR l’acquittement correspondant.
L’enregistrement de l’abonné au niveau de sous-système MDS est assuré par le bloc
MMMLR.
A D
MS BS MSC/VLR HLR
G D
PVLR
A_LU_REQUEST MAP_SEND_IDENTIFICATION (TMSI)
MM_AUTHENTICATION_REQUEST MAP_SEND_IDENTIFICATION ack (IMSI, RAND, SRES, KC)

MM_AUTHENTICATION_REQUEST ack MAP_UPDATE_LOCATION
MAP_CANCEL_LOCATION
MAP_CANCEL_LOCATION ack
MAP_INSERT_SUBSCRIBER_DATA
MAP_INSERT_SUBSCRIBER_DATA ack
CIPHERING_MODE_COMMAND MAP_UPDATE_LOCATION ack
CIPHERING_MODE_COMPLET
TMSI_REALLOCATION
TMSI_REALLOCATION_COMPLET
A_LU_CONFIRM
RR_RELEASE
Figure II.1 Mise à jour de localisation normale

21
Dans le MSC/VLR quitté par le mobile, c’est le bloc fonctionnel MLCAP qui
va supprimer l’abonné de la liste d’abonnés enregistrés à la suite de la réception de
message «MAP_CANCEL_LOCATION», à partir du HLR. Le MAUTH, du nouveau
MSC/VLR procède au chiffrement afin que le bloc MTMSIAN puisse allouer un
nouveau TMSI. Enfin le bloc MMMLR annonce le succès de la procédure et le bloc
MRRM libère les ressources. C’est ce dernier qui gère le lien de signalisation avec le
BSS.
II.1.2 Mise à jour de localisation «IMSI DETACH» (Figure II.2)
La procédure de mise à jour par «IMSI DETACH» est utilisée pour réduire le
nombre de procédures de «paging». À la mise hors tension le mobile demande un canal
de signalisation où il va émettre le message «IMSI_DETACH». Le MRRM reçoit ce
message, le MRRMH le décapsule et le MMMLR assigne un drapeau IMSI DETACH
au mobile pour rejeter les appels qui lui sont destinés [2] [5].
MS MSC/VLR
IMSI_DETACH
IMSI_DETACH_COMPLET
Figure II.2: Mise à jour de localisation avec IMSI DETACH

II.1.3 Mise à jour de localisation «IMSI ATTACH» (Figure II.3)
La procédure de la mise à jour de localisation «IMSI ATTACH» est

complémentaire à la procédure «IMSI DETACH» [2]. Lorsque le mobile est mis sous
tension il informe le réseau qu’il est revenu à l’état actif est capable de recevoir les appels.
Il doit être alors localisé avec la procédure «IMSI ATTACH». Après avoir reçu la
demande d’attachement au réseau, c’est le même principe qu’on a décrit ci-dessus qui se
déroule. Le MMLR marque le mobile est joignable. Si le mobile change de zone en étant
éteint, une mise à jour de localisation normale est déclanchée lors de la réception de
«IMSI_ATTACH».
MS MSC/VLR
IMSI_ATTACH_REQUEST
IMSI_ATTACH_COMPLET
Figure II.3 Mise à jour de localisation avec IMSI ATTACH

22
II.1.4 Mise à jour de localisation Périodique (Figure II.4)
La mise à jour de localisation périodique est initiée par le mobile, après une
période de temps prédéfinie par l’opérateur. Si le mobile ne lance pas la mise à jour de
localisation à l’issue de cette période il est marqué comme injoignable [2]. L’avantage de
la mise à jour périodique est d’éviter les messages de recherche inutiles et ceci
typiquement lorsque le mobile se met hors service sans effectuer une procédure «IMSI
DETACH» ou lorsqu’il perd la couverture du réseau. La longueur de la mise à jour de
localisation périodique est à déterminer par l’opérateur en facteur du compromis à trouver
entre la charge et le volume de signalisations générées par le « paging» et la charge et le
volume de signalisations générées par la mise à jour de localisation périodique. Mais son
inconvénient est qu’elle occupe beaucoup de ressources. C’est toujours le bloc
fonctionnel MMMLR qui se charge de l’exécution de cette procédure [5]. Le tableau de
la page suivante résume les différents compteurs pour les quatre types de mise à jour de
localisation [8] [9].
MS MSC/VLR
LU_REQUEST
LU_ACCEPT
Figure II.4 Mise à jour de localisation périodique

23
Bloc Type
Messages Compteurs
fonctionnel d'Objet
NLOCOLDTOT+
A_LU_REQUEST MRRMH UPDLOCAT
NLOCNRGTOT
MAP_SEND_IDENTIFICATION
MVLRP NAUTFTCTOT SECHAND
(TMSI)
MAP_SEND_IDENTIFICATION ack
MVLRP NAUTFTCSUCC SECHAND
(IMSI, RAND, SRES, KC)
MM_AUTHENTICATION_REQUEST MAUTH NAUTREQTOT SECHAND
MM_AUTHENTICATION_REQUEST
MAUTH NAUTREQSUCC SECHAND
ack
MAP_UPDATE_LOCATION MLUAP NMAPTOT HLRMAP
MAP_INSERT_SUBSCRIBER_DATA MLUAP NMAPTOT HLRMAP
LU Nnormal MAP_INSERT_SUBSCRIBER_DATA
MLUAP NMAPSUCC HLRMAP
ack
MAP_UPDATE_LOCATION ack MLUAP NMAPSUCC HLRMAP
CIPHERING_MODE_COMMAND MAUTH NCIPATTTOT SECHAND
CIPHERING_MODE_COMPLET MAUTH NCIPSETSUCC SECHAND
TMSI_REALLOCATION MTMSIAN NAUTREATOT SECHAND
TMSI_REALLOCATION_COMPLET MTMSIAN NAUTREAFLT SECHAND
NLOCOLDSUCC
A_LU_CONFIRM MMMLR UPDLOCAT
+NLOCNRGSUCC
MAP_CANCEL_LOCATION MLCAP NCANCEL VLR
MAP_CANCEL_LOCATION ack MLCAP NDELETE VLR
IMSI IMSI_DETACH MMMLR NLOCDETTOT UPDLOCAT

DETACH IMSI_DETACH_COMPLET MMMLR NLOCOLDSUCC UPDLOCAT
NLOCATTTOT
IMSI_ATTACH_REQUEST MMMLR UPDLOCAT
IMSI +NLOCNRGTOT
ATTACH NLOCOLDSUCC
IMSI_ATTACH_COMPLET MMMLR UPDLOCAT
+NLOCNRGSUCC
NLOCPERTOT
PER_LU_REQUEST MMMLR UPDLOCAT
LU +NLOCNRGTOT
Périodique NLOCOLDSUCC
PER_LU_ACCEPT MMMLR UPDLOCAT
+NLOCNRGSUCC
Tableau II.1 Les compteurs pour la mise à jour de localisation
II.2 «Handover»
En cours de communication ou pendant l’établissement d’appel, le mobile mesure

en permanence les fréquences des cellules voisines et génère un rapport de mesure. Ce
rapport sera transmis au BSC afin d’être analysé. Il comprend la qualité du signal ainsi
que son niveau de champ. Le BSC lance la procédure de «Handover» dans le cas où il
trouve une des cellules voisines correspond au meilleur niveau du champ.
24
Dans cette partie on s’intéressera uniquement au Handover inter et intra MSC

puisque la charge provoquée par le Handover intra BSC est négligeable. Il ne s’agit en fait
que d’une information renvoyée par le BSC au MSC.
II.2.1 Handover inter MSC (Figure II.5)

La procédure de Handover incluant l’initiation, le contrôle et la coordination de
Handover inter et intra MSC est prise en charge principalement par les blocs fonctionnels
suivants : MBSSD, MHO, MMM, MRRM et MRRMHO. Le Handover intra MSC
consiste à faire passer la communication en cours vers un autre canal de trafic dans le but
d’assurer la continuité du lien radio pour la station mobile servi par le même MSC. Alors
que le Handover inter MSC assure la continuité de la communication dans le cas où le
mobile se déplace vers une autre cellule contrôlées par un autre MSC [10].
À la réception de la demande de «Handover», le message

«BSSMAP_HANDOVER_REQUIRED» sera décapsulé par le bloc MRRMH qui le passera au
bloc MHO. Ce dernier, après avoir découvert la cellule cible dans la demande du
«Handover», il essaye de trouver le MSC cible dans le groupe des noeuds voisins
existants au niveau du bloc MBSSD. S’il le trouve, en recevant une confirmation du
MBSSD, il construit un message MAP pour communiquer avec cet MSC à travers le bloc
MHOMH.
MS-BSCA MSC-A/VLR-A MSC-B/VLR-B MS-BSCB
BSSMAP_HANDOVER_REQUIRED MAP_PREFORM_HANDOVER BSSMAP_HANDOVER_REQUEST
BSSMAP_HANDOVER_REQUEST ack
MAP_PREFORM_HANDOVER ack
BSSMAP_HANDOVER_COMMAND
SWITCHING CALL TO NEW CHANNEL

BSSMAP_HANDOVER_DETECTED
MAP_PROCESS_ACCESS_SIGNALLING
BSSMAP_CLEAR_COMMAND MAP_SEND_END_SIGNAL BSSMAP_HANDOVER_COMPLET

BSSMAP_CLEAR_COMPLET
ENF_OF_CALL
MAP_SEND_END_SIGNAL ack
Figure II.5 «Handover» inter MSC

25
Au niveau du second MSC/VLR (MSC/VLR-B) le bloc fonctionnel MRRMHO

se charge de traitement des messages BSSMAP avec le BSC cible, et la communication
entre les deux MSC sera contrôlée par le bloc fonctionnel MHOC.
Après avoir reçut l’accord du MSC cible, toujours à travers le bloc MHOMH, le
MHO passe à l’exécution du Handover en envoyant la commande au BSC source par le
message «BSSMAP_HANDOVER_COMMAND». Lorsque le bloc MHO reçoit la réponse du MSC
cible, il commute la communication vers le nouveau canal TCH et attend la fin de la
procédure. Au niveau du MSC cible, le bloc fonctionnel MHOC se charge du traitement
du message «BSSMAP_HANDOVER_DETECTED» qui renseigne sur la détection du mobile
dans la nouvelle station de base, et la procédure du «Handover» se termine à la réception
du message «BSSMAP_HANDOVER_COMPLETE». Dans ce cas, le MHO reçoit le message
«MAP_SEND_END_SIGNAL» qui signifie que le «Handover» a été bien effectué et peut
demander la libération des ressources avec l’ancien BSC. En plus le MHOC contrôle le
Handover jusqu’à la fin de la communication. Une fois la communication est terminée, le
MHO libère toutes les ressources avec le MSC voisin via le bloc MRRM.
II.2.2. Handover intra MSC (Figure II.6)
Le Handover intra MSC se produit lorsqu’en cours de communication ou

pendant l’établissement d’appel, le mobile se déplace vers une cellule desservie par le
même MSC mais par deux BSC différents. Lorsque le BSC courant décide d’effectuer un
«Handover», il envoie au MSC le message «BSSMAP_HANDOVER_REQUIRED» comportant
la liste des cellules vers lesquelles le mobile peut être transféré. Le message
«BSSMAP_HANDOVER_REQUIRED» est reçu au niveau du MSC par le bloc MRRM. À la
réception de ce message le bloc MRRM y enregistre les identifiants des cellules et envoi
au bloc fonctionnel MHO le signal «SEIZEHOVERLI4». [10].

26
A A
BSC-A MSC BSC-B
BSSMAP_HANDOVER_REQUIRED SCCP_CONNECTION_REQUEST
BSSMAP_HANDOVER_COMMAND SCCP_CONNECTION_CONFIRM
BSSMAP_HANDOVER_DETECT
SWITCHING_CALL_TO_NEW_CHANNEL
BSSMAP_CLEAR_COMMAND BSSMAP_HANDOVER_COMPLET
BSSMAP_CLEAR_COMPLET
Figure II.6 Handover intra MSC
Ensuite le lien avec le MHO est établi. Ce dernier va répondre au MRRM par
«HOVERLINKED» dans le but d’obtenir la destination de l’appel. Lorsque la demande passe
avec succès au BSC cible, le passe la commande au BSC source et reçoit par la suite le
message de détection de Handover, à partir du BSC destinataire. Ceci l’oblige à basculer
la communication vers le nouveau canal sans même attendre la fin de la procédure. Quand
le MRRM reçoit le message «BSSMAP_HANDOVER_COMPLET», il informe le MHO
par le signal «HOVERCOMPLETE». Ce dernier passe alors à la libération de la connexion
avec l’ancien BSC toujours par le bloc MRRM.
Le tableau ci après résume les compteurs relatifs aux deux types de «Handover»
décrit ci-dessus [8] [9].

27
Messages Bloc fonctionnel Compteurs Type d'Objet

BSSMAP_HANDOVER_REQUIRED MRRM NHNDRQDTOT HNDOVER
MAP_PREFORM_HANDOVER MHOMH NNBRHBANTOT NBRMSCLST
BSSMAP_HANDOVER_REQUEST MRRMHO NHNDREQTOT HNDOVER
BSSMAP_HANDOVER_REQUEST ack MRRMHO NHNDREQSUCC HNDOVER
HO Inter-MSC
MAP_PREFORM_HANDOVER ack MHOMH NNBRHBANSUCC NBRMSCLST

BSSMAP_HANDOVER_COMMAND MRRMHO NHNDCMDTOT HNDOVER
BSSMAP_HANDOVER_DETECTED MHO NHNDDGSSUCC HNDOVER
BSSMAP_HANDOVER_COMPLET MHO NHNDCGSSUCC HNDOVER
MAP_SEND_END_SIGNAL MHO NHNDCGSSUCC HNDOVER
BSSMAP_CLEAR_COMMAND MRRM FLASRO IS41HOFF1
BSSMAP_CLEAR_COMPLET MRRM FACLRI IS41HOFF1
BSSMAP_HANDOVER_REQUIRED MRRM NHNDRQDTOT HNDOVER
SCCP_CONNECTION_REQUEST MRRMHO NHNDREQTOT HNDOVER
HO Intra-MSC
SCCP_CONNECTION_CONFIRM MRRMHO NHNDREQSUCC HNDOVER

BSSMAP_HANDOVER_COMMAND MHO NHNDCMDTOT HNDOVER
BSSMAP_HANDOVER_DETECT MHO NHNDDGSSUCC HNDOVER
BSSMAP_HANDOVER_COMPLET MHO NHNDCGSSUCC HNDOVER
BSSMAP_CLEAR_COMMAND MRRM FACLRO IS41HOFF1
BSSMAP_CLEAR_COMPLET MRRM FACLRI IS41HOFF1
Tableau II.2: Les compteurs pour le Handover inter et intra MSC
II.3. Gestion d’appel

Le but de la procédure de gestion des appels est d’établir et d’acheminer les
appels entre les abonnées. Les abonnés appelants et appelés peuvent se trouver soit dans
le même réseau soit dans des réseaux différents. Ils peuvent aussi se trouver dans des pays
différents générant ainsi des appels internationaux [11].
II.3.1 Appels «Arriveé» (MO «Mobile Originating»)

Après que l’abonné ait composé le numéro de son correspondant, il valide
l’appel et envoie une demande de ressource radio sur laquelle il va échanger les messages
de signalisation. Avant l’intervention du sous-système TCS, le bloc fonctionnel MABC
essaye de vérifier si l’appel peut être pris en charge ou non. Il vérifie aussi la disponibilité
du service demandé et l’inscription de l’abonné à ce service.

28
Puis le MAUTH se charge de l’authentification et du chiffrement. C’est lui qui

effectue ces tâches quelque soit le cas de trafic. Le sous-système TCS analyse ensuite le
numéro de destination à partir du message «CC_SETUP» grâce au bloc fonctionnel DA.
Celui-ci évoque le RA dans le cas où l’appel doit être acheminé vers un autre nœud. Il va
aussi déterminer le cas de taxation à communiquer au bloc de l’analyse de taxation dans le
sous-système CHS. À ce moment là, le bloc fonctionnel MRRMASG du sous-système
MMS demande au BSC d’allouer un canal de trafic sur lequel la communication se
dérouler. Cette demande est mentionnée par les deux compteurs NCHAFRMTOT et
NCHAFRMSUCC donnant respectivement le nombre d’allocations de canal et le nombre
d’opérations d’allocation de canal qui ont été fait avec succès (Tableau II.3).
MS-BSC MSC/VLR NE
CM_SERVICE_REQUEST
AUTHENTICATION_REQUEST
AUTHENTICATION_RESPONSE
CIPHRING_COMMAND
CIPHRING_COMPLET
CC_SETUP
CC_CALL_PROCEEDING
BSSMAP_ASSIGNEMENT_REQUEST
BSSMAP_ASSIGNEMENT_COMPLET IAM
CC_ALERTING_MESSAGE ACM
CC_CONNECT B_ANSWER
CC_CONNECT ack
CONVERSATION
CALL_REALEASE
CC_DISCONNECT CALL_RELEASE
CC_RELEASE CALL_RELEASE_COMPLET
CC_RELEASE_COMPLET
CLEAR_COMMAND
CLEAR_COMPLET
Figure II.7 Appels «Arriveé»

29
Ensuite le lien avec l’autre nœud du réseau est établit par l’un des blocs ETC du
sous-système TSS soit vers un réseau téléphonique, soit vers un centre de transit national
ou international dont le bloc fonctionnel UPHMS va envoyer le message IAM
«Initial Address Message». Les deux messages ACM «Address Complet
Message» et la réponse «B_ANSWER» seront traités par le bloc UPHMR. Le MCSE
s’occupe de la tonalité vers l’abonné appelant ainsi que de la connexion lorsque le
destinataire décroche et l’appel sera basculé à l’état actif. Le bloc MCSE se charge aussi
de la libération du lien, lorsque l’abonné raccroche. Finalement le MRRM demande au
BSC de libérer les ressources radio [4] [11].
N’importe quel élément du réseau «Network Element» lié au MSC, un

centre de transit international, national, un autre MSC ou un réseau téléphonique fixe,
constitue un objet de type TRUNKROUTE. Ce ci nous mène à trouver les mêmes
compteurs dans tous les objets. L’activation de TRUNKROUTE permet aux compteurs
de se mettre à jour automatiquement pour tous les objets. Lors du prélèvement des
statistiques au niveau de l’OSS, nous devons identifier les valeurs des différents
compteurs pour chaque objet.
CM_SERVICE_REQUEST MABC NCALLSI TRUNKROUTE
AUTHENTICATION_REQUEST MAUTH NAUTREQTOT SECHAND
AUTHENTICATION_RESPONSE MAUTH NAUTREQSUCC SECHAND
CIPHRING_COMMAND MAUTH NCIPATTTOT SECHAND
CIPHRING_COMPLET MAUTH NCIPSETSUCC SECHAND
CC_SETUP MABC NIRNFRMTOT IRNEG
CC_CALL_PROCEEDING MABC NIRNFRMSUCC IRNEG
BSSMAP_ASSIGNEMENT_REQUEST MRRMASG NCHAFRMTOT CHASSIGNT
Appel Arrivés
BSSMAP_ASSIGNEMENT_COMPLET MRRMASG NCHAFRMSUCC CHASSIGNT

IAM UPHMS NCALLSO TRUNKROUTE
ACM UPHMR THROUGHRTECNT TRUNKROUTE
CC_ALERTING_MESSAGE MCSE DIALTONEONCOUNT NETWRK
B_ANSWER UPHMR NANSWERSI TRUNKROUTE
CC_CONNECT MABC NANSWERSO TRUNKROUTE
CC_CONNECT ack MABC NTHCON BSUBTYPE
CC_DISCONNECT MCSE NCTDDISC DISCCALL
CALL_RELEASE MCSE RSEIZO IS41VMSC2
CALL_RELEASE_COMPLET MCSE RSEIZI IS41VMSC2
CC_RELEASE MCSE RSEIZO IS41VMSC2
CC_RELEASE_COMPLET MCSE RSEIZI IS41VMSC2
Tableau II.3 Les compteurs pour les appels «Arriveé»

30
II.3.2 Appels à destination d’un mobile (MT «Mobile Terminating»)

Les appels à destination d’un mobile se produisent lorsque un usager venant
d’un réseau mobile ou un réseau fixe désire entrer en communication avec un abonné
mobile. Ceci ne peut se faire qu’à condition que ce dernier soit dans une zone couverte et
que son terminal soit sous tension. Après que l’usager demande l’établissement d’une
communication, l’élément du réseau au quel il est rattaché et qu’on a marqué sur le
schéma NE «Network Elément» (Figure II.8) utilise le numéro MSISDN pour
localiser le G-MSC vers lequel il doit router l’appel [4] [11].
NE G-MSC HLR MSC/VLR BSC-MS
CM_REQUEST MAP_SEND_ROOTING_INFO MAP_PROVIDE_ROAMING_NUMBER
MAP_SEND_ROOTING_INFO ack MAP_PROVIDE_ROAMING_NUMBER ack
ISUP_INITIAL_ADDRESS_MESSAGE BSSMAP_PAGING
BSSMAP_PAGING ack
AUTHENT_REQUEST
AUTHENT_RESPONSE
CIPHER_COMMAND
CIPHER_COMPLET
CALL_SETUP
CALL_CONFIRM
BSSMAP_ASSIGNEMENT_REQUEST
BSSMAP_ASSIGNEMENT_REQUEST ack
ISUP_ADDRESS_COMPLET_MESSAGE CALL_ALERTING
CALL_CONNECT
ISUP_ANSWER
CALL_CONNECT ack
CONVERSATION
CALL_RELEASE
CALL_RLEASE CC_DISCONNECT
CALL_RLEASE_COMPLET CC_RELEASE
CC_RELEASE_COMPLET
Figure II.8 Appel à destination d’un mobile

31
Comme nous avons expliqué précédemment, le NE peut être un réseau PSTN un

autre MSC ou un centre de transit. En suite le G-MSC demande les informations de
routage du destinataire à partir du HLR. Celui-ci utilise le numéro MSISDN pour trouver
par quel MSC/VLR l’abonné est servi afin de lui demander un numéro MSRN et le faire
transférer au G-MSC. Le G-MSC utilise le MSRN pour l’acheminent de l’appel et le bloc
fonctionnel MRNPH se charge de l’opération concernant le MSRN.
Une fois l’appel parvenu au MSC/VLR, ce dernier utilise le MSRN pour

retrouver l’IMSI du mobile et sa zone de localisation. En plus, la différence majeure entre
MO et MT c’est que l’emplacement exact de l’abonné destinataire n’est pas connue. Il
doit être alors localisé grâce à l’avis de recherche «PAGING» avant l’établissement de la
connexion. Le canal SDCCH est utilisé pour toute la procédure de l’établissement de
l’appel y compris l’authentification et le chiffrement. Ensuite le MSC ordonne le BSC
d’allouer un canal TCH au mobile afin que celui-ci puisse entrer en communication.
Lorsque la connexion est établie le mobile est marqué occupé et la connexion

s’établit. Le bloc MCSE se charge de la tonalité ainsi que de la connexion et de la
déconnexion. Le MRRM se charge toujours de la libération des ressources radio.
Le tableau suivant contient les compteurs correspondant à la gestion des appels

à destination d’un mobile.

32

CM_REQUEST G-MSC: MABC
MAP_SEND_ROOTING_INFO G-MSC: GRI
MAP_PROVIDE_ROAMING_NUMBER MRNPH NMAPTOT HLRMAP
MAP_PROVIDE_ROAMING_NUMBER
MRNPH NMAPSUCC HLRMAP
ack
MAP_SEND_ROOTING_INFO ack G-MSC: GRI
MAP_INITIAL_ADDRESS_MESSAGE IUBSIC NCALLSI TRUNKROUTE
BSSMAP_PAGING MBPAG NPAG1LOTOT PAGING
BSSMAP_PAGING ack MBPAG NPAG1RESUCC PAGING
AUTHENT_REQU MAUTH NAUTREQTOT SECHAND
AUTHENT_RESP MAUTH NAUTREQSUCC SECHAND
Appel Entrant
CIPHER_COMMAND MAUTH NCIPATTTOT SECHAND

CIPHER_COMPLET MAUTH NCIPSETSUCC SECHAND
CALL_SETUP MTBCC NIRNTOTOT IRNEG
CALL_CONFIRM MTBCC NIRNTOSUCC IRNEG
BSSMAP_ASSIGNEMENT_REQUEST MRRMASG NCHATOMTOT CHASSIGNT
BSSMAP_ASSIGNEMENT_COMPLET MRRMASG NCHATOMSUCC CHASSIGNT
CALL_ALERTING MCSE DIALTONEONCOUNT NETWRK
CM_RESPONCE MCSE NANSWERSO TRUNKROUTE
CALL_CONNECT MABC NANSWERSI TRUNKROUTE
CALL_CONNECT ack MABC NTHCON BSUBTYPE
CC_DISCONNECT MCSE NCTDDISC DISCCALL
CALL_RLEASE MCSE RSEIZO IS41VMSC2
CALL_RLEASE_COMPLET MCSE RSEIZI IS41VMSC2
CC_RELEASE MCSE RSEIZO IS41VMSC2
CC_RELEASE_COMPLET MCSE RSEIZI IS41VMSC2
Tableau II.4 Les compteurs pour les appels servis
II.4 Gestion des messages courts SMS
Le SMS consiste en l’envoi de texte alphanumérique jusqu'à 160 caractères. Les

messages courts peuvent être transférés à partir d’un centre de messagerie (SMSC) ou à
partir des mobiles. Les messages courts sont transférés ainsi sur le réseau de signalisation
et ne nécessite pas de canaux de trafic [2].

33
II.4.1 Envoi d’un SMS (Figure II.9)
La procédure de transmission d’un SMS est très similaire à celle d’établissement

d’appel sauf que celle-ci ne nécessite pas la réservation d’un circuit de parole. Quand le
mobile veut envoyer un message court, il demande l’allocation d’un canal de signalisation
sur lequel il va envoyer son SMS au sous-système MMS. Ce dernier informe le sous-
système SHS qu’il s’agit d’un envoie d’un SMS. Le bloc MSMMH existant au niveau du
SHS décapsule le message de la demande «SMS_CP_DATA» pour récupérer les
informations nécessaires à sa délivrance, c'est-à-dire le numéro du serveur SMSC et
l’adresse de IWMSC. Sous l’initiation de MSMMH, Le bloc MSMO va se rendre
compte de cette procédure et incrémente son compteur correspondant [7]. Ensuite Il
demande au bloc MSMOAP de transférer le message au nœud IWMSC mais pas avant
que la procédure d’authentification ne soit réalisée par le bloc MAUTH.
MS MSC/VLR IWMSC SMSC
ACCESS_AND_ALLOCATION
AUTHENTICATION_REQUEST
AUTHENTICATION_RESPONCE
CIPHRING_COMMAND
CPHRING_COMPLET
SMS_CP_DATA
SMS_CP ack MAP_FORWARD_SHORT_MESSAGE Short Message
STOCKING_SMS_AND_ADDRESS
SMS_CP_DATA ack MAP_FORWARD_SHORT_MESSAGE ack Short Message ack
SMS_CP ack
RESSOURCE_RELEASE
RESSOURCE_RELEASE ack
Figure II.9 Envoi d’un SMS

34
Une fois le message est transmis avec succès vers le IWMSC le MSMOAP
prend en charge le message «MAP_FORWARD_SHORT_MESSAGE ack» et le compteur sera
toujours incrémenté au niveau du MSMO. C’est ce dernier qui va envoyer par la suite le
rapport de délivrance au mobile. Une fois ceci est fait, les ressources seront libérées. Le
centre SMSC transmet le message lorsqu’il le peut. C'est-à-dire qu’il le garde pour un
certain temps, si ce temps expire il efface le SMS de sa mémoire.
II.4.2 Réception d’un SMS (Figure 2.10)

Pour faire parvenir un message court à sa destination, le serveur envoie le
message et la date de sa réception au GMSC pour que celui-ci demande la localisation du
mobile auprès du HLR «SEND_ROUTING_INFORMATION_FOR_SM». Le HLR lui donne
alors l’adresse globale du MSC/VLR contrairement à l’appel qui nécessite un MSRN. Au
niveau du MSC on trouve le bloc MSMT qui se charge de l’SMS pour le faire parvenir à
sa destination. En plus le bloc MSMTAP responsable de la réception du message
provenant d’un SMS-GMSC. La procédure d’authentification est toujours effectuée par le
MAUTH mais après que l’on a effectué un avis de recherche du destinataire.
HLR MSC/VLR MS
SMSC SMS-GMSC
FORWARD_SMS
SEND_ROUTING_INFORMATION_FOR_SM
SEND_ROUTING_INFORMATION_FOR_SM ack PAGING_AND_RESPONSE
MAP_FORWARD_SM
AUTHENTICATION_AND_CIPHERING
SMS_CP_DATA
MAP_FORWARD_SM ack SMS_CP_DATA ack
MAP_REPORT_DELIVERY
RESSOURCE_RELEASE
TRANSMISSION_REPORT MAP_REPORT_DELIVERY ack
Figure II.10 Réception d’un SMS

35
Si le destinataire n’est pas dans une zone de couverture, à la réception d’un

acquittement négatif, le GMSC informe le HLR qu’un message n’a pas été envoyé. Le
HLR positionne alors un indicateur et garde aussi l’adresse du serveur concerné. Les
informations sont sauvegardées au niveau du VLR mais seul le serveur contient le
message. Dès que le mobile se manifeste, le MSC/VLR avertit le HLR qui à son tour
avertit le SMSC pour qu’il envoie le message mis en attente. Voici les compteurs
correspondant à la gestion des messages courts (Tableau II.5) [8] [9].
Bloc
Messages Compteurs Type d'Objet
fonctionnel
ACCESS_AND_ALLOCATION MSMMH/MSMO
AUTHENTICATION_REQUEST MAUTH NAUTREQTOT SECHAND
AUTHENTICATION_RESPONSE MAUTH NAUTREQSUCC SECHAND
CIPHRING_COMMAND MAUTH NCIPATTTOT SECHAND
CIPHRING_COMPLET MAUTH NCIPSETSUCC SECHAND
SMS Sortant
SMS_CP_DATA MSMO NSMSRDOTOT SHMSGSERV

SMS_CP ack MSMO
MAP_FORWARD_SHORT_MESSAGE MSMO NSMSCDOTOT SHMSGSERV
MAP_FORWARD_SHORT_MESSAGE ack MSMMH NSMSCAOSUCC SHMSGSERV
SMS_CP_DATA ack MSMO NSMSRAOSUCC SHMSGSERV
SMS_CP ack MSMO NSMSCMRSUCC SHMSGSERV
RESSOURCE_RELEASE MRRM RSEIZO IS41VMSC1
RESSOURCE_RELEASE ack MRRM RSEIZI IS41VMSC1
MAP_FORWARD_SM MSMTAP NSMSSMRLTOT SHMSGSERV
PAGING_REQUEST MBPAG NPAGSMSTOT SHMSGSERV
PAGING_ANSWER MBPAG NPAGSMSRES SHMSGSERV
SMS Entrant
AUTHENTICATION_REQUEST MAUTH NAUTREQTOT SHMSGSERV

AUTHENTICATION_RESPONSE MAUTH NAUTREQSUCC SHMSGSERV
CIPHRING_COMMAND MAUTH NCIPATTTOT SHMSGSERV
CIPHRING_COMPLET MAUTH NCIPSETSUCC SHMSGSERV
SMS_CP_DATA MSMT NSMSCMTOT SHMSGSERV
SMS_CP_DATA ack MSMT NSMSCMRSUCC SHMSGSERV
MAP_FORWARD_SM ack MSMT NSMSSRSUCC SHMSGSERV
Tableau II.5 Les compteurs pour la gestion des SMS

36
II.5 Procédure des services USSD (Figure II.11)

L’idée principale des services USSD est de fournir aux opérateurs un mécanisme
de conception de leurs propres services sans recourt à la normalisation. Et ceci dans le but
de faire bénéficier les abonnés des services supplémentaires déjà existants dans les
réseaux PLMN [2]. Quand un mobile veut accéder à un service USSD, il demande un
canal de signalisation et évoque un changement de ses informations au sein du HLR. La
demande contient en fait le code du service demandé qui est délimité généralement par les
caractères «*» et «#». Un tel changement est nécessaire car le mobile peut changer de
zone de localisation qui est contrôlé par un autre MSC/VLR et mise à jour à partir du
HLR. C’est le MSC qui décide si la demande peut être transmise au HLR ou non. En cas
d’erreur (comme la non validité du service demandé ou lorsque l’abonné n’est pas inscrit
dans le réseau) un message d’erreur est retourné au MSC.
gsmSCF
MS-BSC MSC/VLR HLR USSDC
USSD_REQUEST MAP_PROCESS_UNSTRUCTURED_SS_REQUEST
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST
MAP_UNSTRUCTURED_SS_REQUEST
USSD_ INFO_REQUEST MAP_UNSTRUCTURED_SS_REQUEST
USSD_ INFO_REQUEST ack MAP_UNSTRUCTURED_SS_REQUEST ack
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST ack
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST ack
USSD_ RESPONSE MAP_PROCESS_UNSTRUCTURED_SS_REQUEST ack
Figure II.11 Procédure de demande de services USSD

37
La demande de service USSD peut se traduire comme une transaction avec le

réseau en envoyant une requête, contenant toute les informations nécessaires pour cette
opération, au MSC. Cette requête sera analysée par le bloc MUSSAN qui va déterminer le
service USSD demandé et vérifier si la demande peut être prise en charge. Si s’est le cas,
il demande au MUSSH de transférer la demande au HLR avec le message
«MAP_PROCESS_UNSTRUCTURED_SS_REQUEST». Le MSC/VLR sera par la suite
transparent pour n’importe quelle requête ou demande entre le HLR et le mobile. Parfois
on trouve que le réseau demande au mobile de saisir les champs de son compte «Login
& Password». C’est le bloc MUATAI qui se charge de toute information concernant
les comptes des abonnés. Voici les compteurs correspondant (Tableau II.6) [8] [9].
Bloc
fonctionnel
USSD_ REQUEST MUSSAN NPURGEMS VLR
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST MUSSH NUSSDNTS VLR
MAP_UNSTRUCTURED_SS_REQUEST MUSSH NPUSSRQR VLR
USSD_ INFO_REQUEST MUATAI NUSSDRQS VLR
USSD_ INFO_REQUEST ack MUATAI NPUSSDAR VLR
MAP_UNSTRUCTURED_SS_REQUEST ack MUSSH NPRSINFO VLR
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST ack MUSSH
USSD_ RESPONSE MUSSAN
Tableau II.6 Les compteurs pour les service USSD
II.6 Accès au réseau intelligent
Le concept de réseau intelligent a été introduit dans le monde des

télécommunications dans le but de faciliter et de rendre plus flexible la fourniture des
services aux usagers des réseaux. Une des applications des réseaux intelligents est le
service de prépaiement qui constitue aujourd’hui le service le plus utilisé.
Le module applicatif SSFAM au sein du MSC/VLR constitue un élément du

communication avec les autres nœuds du réseau intelligent. Le SSFAM évoque le SCF
pour l’exécution de certains services demandés [12].

38
La seule différence avec la procédure d’établissement d’appel normale réside

dans les messages de signalisation pure entre le SSF et le SCF. En effet lorsque le
MSC/VLR reçoit la demande d’établissement d’un appel par un abonné prépayé, il vérifie
son profil contenant le OICK «Originating IN Category Key». L’OICK permet de
déterminer si pour l’appel en question un service prépayé est à invoqué et renseigne sur le
nœuds à contacter pour invoquer ce service. Le TCS analyse son numéro ainsi que le
numéro du destinataire (DA) et vérifie dans sa table de routage (RA) pour déterminer la
route à utiliser. Une route interne avec le SSFAM sera identifiée pour que le TCS puisse
lui envoyer un message de type IST «Intelligent network Service Trigger». Le SSF
l’analyse et identifie ce qu’on appelle une «Trigger Table» particulière qui est associée au
service demandé. Dans cette table on trouve les informations nécessaires identifiant le
SCF à évoquer ainsi que les informations à envoyer [1].
Ensuite le SSF commence à envoyer les messages au SCF lui indiquant les
opérations à exécuter. Le bloc fonctionnel SHBCA est responsable de toute information
envoyée ou reçu vers ou à partir les autres parties comme le TCS. Ensuite le SHCM va se
rendre compte qu’il s’agit d’un établissement d’appel lorsqu’il reçoit le message IST. Le
SHRDO va chercher la route qui convient «Trigger Table» et le SHTTM déterminer les
informations nécessaires à l’invocation de SCF, c’est lui qui transmet le message IDP
«INITIAL_DETECTION_ POINT».
MSC/VLR MIN
MS
SSF SCF SDF
PPC REQUEST IST INITIAL DETECTION POINT

CALL INFORMATION REQUEST
CALL INFORMATION REPORT
CONNECT_TO_RESSOURCE
CONNECTION REPORT
CALL ST UP
CONVERSATION & ACCOUNT_MANAGEMENT
EVENT REPORT BCSM
CONTINUE
CALL_RELEASE
RELEASE CALL
Figure II.12 Appel d’un abonné prépayé

39
Avant l’exécution du service, le SCF demande les informations relatives à son

exécution comme par exemple le type de taxation pour l’établissement de l’appel. Les
informations relatives à la taxation sont déterminées par les blocs SHCA, pour déterminer
le cas de taxation, et SHCHM pour déterminer quel paramètre à envoyer vers les autres
nœuds. Le SCF demande aussi les autres informations concernant la suffisance du crédit
et la validité du compte auprès du SDF qui est contrôlée par le SDP. Le SHCC se charge
de la demande et de l’envoi des informations relatives à l’établissement d’appel avec le
SCF (les messages «CALL_INFORMATION_REQUEST» et «CALL_INFORMATION_REPORT»).
Dans le cas où le compte de l’abonné est valide le SCF ordonne le SSF de se

connecter au réseau menant l’appel à sa destination «CONNECT_TO_RESSOURCE». Durant la
conversation le SSF, à l’aide de SHEC, peut informer le SCF des événements qui
peuvent être provoqués par l’abonné appelant comme la déconnexion par exemple. S’il
n’y a pas de déconnexion, le SCF demande au SSF de poursuivre sa supervision
(CONTINUE) ; dans le cas contraire il l’ordonne de libérer le lien [1].
Pour un appel venant d’un abonné prépayé les messages de signalisation entre le
SSF et le SCF restent les mêmes. Ce sont les mêmes compteurs qui vont s’incrémenter
que ce soit pour une invocation de SCF ou pour une demande d’instruction. La différence
est que le SSF va demander le profile de l’abonné contenant le TICK «Terminated IN
Category Key» auprès du HLR (CSI «Camel Subscription Information», CSE «Camel
Service Environment») non seulement pour se rendre compte qu’il est obligé de consulter
un nœud du réseau intelligent mais aussi pour savoir quel SCF à invoquer. Ensuite le SSF
demande les instructions nécessaires à exécuter (ARI «AssistRequestInstruction»).
NE MSC/VLR MIN
HLR
SSF SCF SDF
IAM CSI
CSE
ARI
COMMANDS
Figure II.13 Appel vers un abonné prépayé

40
Dans le tableau ci-dessous on trouve les différents compteurs correspondants à

l’accès au réseau intelligent [8] [9].
Bloc
fonctionnel
IST SHTTM ISTSEL SSFICCI
INITIAL_DETECTIO_ POINT SHTTM OPSINI SSFOHDCI
Appel d'un abonné
CALL_INFORMATION_REQUEST SHCC OPREQDM SSFOHDCT

CALL_INFORMATION_REPORT SHCC OPREQCH SSFOHDCT
prépayé
CONNECT_TO_RESSOURCE SHOPSRF SRFATT SHAM

CONNECTION_REPORT SHOPSRF TIMESRF SHAM
CALL_ST_UP SHCC OPRECAL SHIST
EVENT_REPORT_BCSM SHEC OPSSUB SHIST
CONTINUE SHCC OPRECAL SHIST
RELEASE_CALL SHCM OPRECAL SHIST
IAM SHTTM IAMBATT SSFICCT
abonné prépayé
Appel vers un
CSI SHTTM NSERVFEAT SERVFEAT

CSE SHTTM NSERVFEATINV SERVFEAT
ARI SHTTM OPSINI SHIST
Command SHCC OPRECAL SHIST
Tableau II.7 Les compteurs pour l’accès au réseau intelligent
Nous avons décrit dans ce chapitre l’intervention des blocs fonctionnels pour le
traitement des différents messages correspondants aux différents cas du trafic. Ceci est
dans le but d’identifier les paramètres qui sont les compteurs existant au niveau des blocs
fonctionnels. Dans la partie qui suit on expliquera notre méthodologie de travail pour la
modélisation de la charge.

41
Chapitre III : Modélisation
de la charge d’un AXE-MSC/VLR
Chapitre
III
M odélisation de la
charge d’un AXE-MSC/VLR
III.1 Récupération des statistiques
III.2 Etude théoriques
III.2.1 Ajustement avec Moindre Carré
III.2.2 Principe de la méthode de l’Analyse en Composante
Principale: ACP.
III.3 Développement de l’outil de calcul de la capacité

de la charge d’un AXE-MSC/VLR.
III.3.1 Présentation de l’environnement de développement

III.3.2 L’outil «AXE-MSC/VLR Processor Load
Measurement»
III.3.2.1 Organigramme
III.3.2.2 Guide d’utilisateur de l’outil
«AXE-MSC/VLR Processor Load Measurement»

42
du nœud cœurs du réseau GSM
Chapitre III :
Modélisation de la
charge d’un AXE-MSC/VLR
Après avoir identifié nos paramètres d’entrée, nous devons prendre des
observations de leur évolution au cours du temps (des statistiques). Nous devons suivre
aussi l’évolution de la charge CPU du noeud; c’est notre variable à ajuster. Dans ce
chapitre nous allons décrire la chaine de la récupération des statistiques (statistiques
pour tout une semaine) et nous passerons par la suite à la modélisation pour finir avec
une description de l’outil dévéloppé.
III.1 Récupération des statistiques
Pour pouvoir récupérer les statistiques il faut préparer les fichiers nécessaires.
Dans le chapitre précédent on a mentionné les types d’objets «Object Type» des
différents compteurs. Au sein du noeud il faut les activer pour que les compteurs
correspondants se mettent à jour automatiquement. Mais il faut désactiver toutes les
statistiques sur le noeud en premier lieu. Ceci est dans le but de préparer le noeud pour
recevoir les nouveaux changements. À l’aide des commandes MML 2 «Man Machine
Language» nous avons pu communiqué directement avec le noeud (plus précismeent avec
le sous-système STS) et activer ces «Object Type».
2
Voir Annexe 2
43
Ces commandes sont entrées à partir de client OSS «Operation and Support
System» relié par une liaison spécialisé (LS de 2 Mb/s) avec le serveur OSS situé dans le
centre O&M. C’est à travers ce serveur que la communication directe avec les noeuds du
réseau se fait. Bien évidemment c’est lui qui contrôle tous les noeuds du réseau selon le
concept du réseau GSM.
Les statistiques sont envoyés à l’OSS dans un fichier de format «iso» que l’on
doit créer d’avance. Dans ce fichier on met les «Object Types» déjà activés pour obtenir
les statistiques volues. L’outil qui permet la création de ce fichier s’appelle SMIA
«Statistical Measurement Initiation and Administration». A la réception de ce fichier, le
SDM «Statistical Data Mart», existant au niveau du serveur OSS, le traite pour bien
organiser les statistiques dans la base de donnée CSDDB (Figure III.1). La base de
donnée BSDDB contient aussi les mêmes statistiques et les rapports déjà prédéfinis.
Ensuite, à partir de notre client OSS et avec l’outil BO «Business Object» on

doit créer l’univers contenant les commandes SQL. Cet univers nous permettra de
consulter facilement la base de donnée (sans entrer les commandes SQL) en précisant le
temps de début et de la fin de l’observation. On peut même choisir le nœud à partir du
quel nous voulons récupérer les données. Enfin il ne reste qu’extraire les rapports et les
enregistrés dans des formats exploitable (comme par exemple le format html ou txt) pour
faire notre étude.

44
Réseau GSM
B
LS 2 Mb /s
OSS Client LAC
1 4
OSS Serveur Hached
MML 3
Liaison X.25
2
SMIA BO
4
C
AXE-MSC/VLR
SDM
CSDDB
5 STDB
BSDDB STSORT
1: Activation des «Object Type» au sein du noeud à l’aide de commandes MML.

A-B: La communiction avec le noeud se fait à travers le serveur OSS.
2: Création du fichier que le noeud va envoyer à Serveur OSS.
C: Le fichier réçu sera traité par SDM et les statistiques seront bien organisées au
niveau de la base de données.
3: Création de l’univers qui correspend aux statistiques volues.
4: Consultation de la base de données (CSDDB) pour la récupération des statistiques.
5: Edition des rapports.
6: Utilisation de l’Excel pour manipuler les données facilement
Figure III.1: Chaine de récupération des statistiques

45
III.2 Etude théoriques

Aprés avoir récupérer les statstiques, nous procédons à leur organisation dans le
but d’obtenir un tableau où chaque ligne correspond à une période d’observation. Dans
chaque ligne on a la charge réelle du CPU et les valeurs des différents compteurs. Nous
avons procéder différement pour l’ajustement de la charge CP tout en utilisant le principe
de l’ajustement avec Moindre Carré.
Période Charge Opération 1 .............. Opération p
t1 y1 C11 .............. C1p
. . . .............. .
. . . .............. .
. . . .............. .
. . . .............. .
. . . .............. .
. . . .............. .
. . . .............. .
tN yN CN1 .............. CNp
Tableau III.1: Tableau des données
III.2.1 Ajustemet avec Moindre Carré

Comme nous n’avons aucune idée sur l’évolution de la charge CPU ni sur
l’évolution des différents paramètres dont elle dépend, la meilleurs façon de faire est de
minimiser l’erreur entre la charge réel et la charge approximée. Donc c’est un ajustemet
avec moindre carré. En plus ces paramètres sont indépendants les uns des autres; il forme
alors une famille génératrice. Ceci nous permet de projeter la charge sur la base constitué
par ces différents compteurs; c’est à dire qu’elle sera égale à la somme des ces compteurs
multipliés chacun par un coéificient à déterminer (équoition III.1). Ce que nous permet de
conclure qu’il s’agit d’un ajustment avec moindre carré et avec la dépendance la plus
simple qui est la dépendence linéaire.
En effet, pour chaque période d’observation la charge peut s’écrire comme suit:
j= p
y i = ∑j= 1
αj∗C ij Pour 1≤i ≤ N Equation III.1

46
de la charge d’un AXEMSC/VLR
Nous aurons donc un vecteur Y qui est égal au produit d’une matrice C,
constitueé par les valeurs des différents compteurs, et un vecteur de coeifficients α à
déterminer.
æ y 1 ö æ α 1 ö æ C 11 . . . C 1p ö

ç ÷ ç ÷ ç ÷
ç . ÷ ç . ÷
ç . . . . . ÷
ç . ÷ ç ÷
. ÷ et C = ç . . . . . ÷
Y = C * α Avec Y = ç ÷ ; α = ç
ç . ÷ ç . ÷ ç ÷
ç ÷ ç . . . . . ÷
ç ÷ ç . ÷
ç . ÷ ç ÷
ç y ÷ ç α ÷
è N ø
è C N1 . . . C NP ø
è N ø
Le critère de moindre carré à minimiser est le suivant:
ˆ (α ) - Y) T M(( Y

J MC Δ ( Y ˆ (α ) - Y) Eqaution III.2
ˆ (α ) est le vecteur charge approximé ( Y

Où Y ˆ (α ) = C ´ α ), Y est le vecteur des
échantillions de la cahrge réelle et α constitue le vecteur des coeifficiente à déerminer.

¶ J MC
Minimiser J MC Þ = 0
¶ α
Rappel sur les dérivés :
Soit les deux vecteurs a, b et la matrice M
T T
¶ b a ¶a Ma
= b ; = 2Ma
a a
¶ J MC
= 0 =
[
¶ (C α - Y ) M (C α - Y )
T
] Eqaution III.3
¶ α ¶ α

47
de la charge d’un AXEMSC/VLR
¶ J MC
=
[
¶ α T C T MC α - α T C T MY - Y T MC α + Y T MY ]
¶ α ¶ α
= 2C T MC α - 2Y T MC = 0
= 2C T MC α - 2Y T MC = 2C T MC α - 2C T MY = 0
α = (C T MC) -1 C T MY Eqaution III.4
Au cours du développement mathématique nous pouvons aboutir au résultat de

T
ce type C M (C a - Y ) = 0 . Mais on ne peut pas simplifier directmet par l’inverse de
C T M car il s’agit d’une matrice rectangulaire pxN. C T est une matrice Nxp et M est une
matrice symétrique définie postivie à définir. En effet la matrice M est une matrice de
pondération. Elle permet de négliger les données abhérents peu fiable et au contraire de
donner de l’importance aux données qui sont fiables. Dans notre études nous n’avons pas
eu ce probleme des points abhérents. La matrice M sera égale à la matrice identité et le
problème se ramène à un ajustmeet avec moindre carré ordinaire. Le vecteurs des
coeifficients sra alors
α = (C T C) -1 C T Y Eqaution III.5
En suite la charge approximée sera égale au produit scalaire entre le vecteur α et
la matrice C constituée par les valeurs des différents compteurs. Les cœfficients de
vecteur α traduisent en fait la contribution de chaque opération dans la charge.
Pour répartir la charge selon les différents types de trafic, on doit sommer les
compteurs correspondant multiplié chacun par son cœfficient correspondant. C'estàdire
pour une période donnée (qui correspond à une ligne dans le tableau des mesures) la
charge provoquée par l’un des types des trafics peu s’écrire comme suit :
l = h
Ch_TC = å C _TC ´ a l _ TC
l = 1
l
Eqaution III.6

48
Ch_TC : C’est la charge provoquée par le cas de trafic considérée (TC pour
dire «Trafic Case».
Cl_TC : Les différents compteurs correspondant au cas de trafic considéré
( 1 ≤ l ≤ h avec h < p) .
αl_TC : Les coefficients correspondant aux différents compteurs d’un cas de

trafic.
Nous pouvons également ajuster la charge CPU de notre MSC selon les taux par
abonné de chaque cas de trafic. Pour cela, il faut diviser chaque compteur correspondant
par le nombre total d’abonnés enregistrés. Ce dernier varie au cours de temps ; ce qui
nous permettons de le retenir en plus des taux déjà calculés. En plus il faut tenir compte
uniquement des messages échangés avec les BSC. Par exemple pour les appels arrivés
(compteur NCALLSI) il ne faut pas tenir compte du nombre d’appel venant des autres
nœuds autre que les BSC. Soit par exemple NCALSSI_BSC le nombre d’appels venant
uniquement des BSC et pas de tous les nœuds qui sont liés à notre MSC. Le tau d’appel
arrivé par abonner sera alors:
NCALSSI_BS C
Tau_MO = Eqaution III.7
Nbr d' Abonné Enregistré
Travailler avec les taux de chaque type de trafic par abonné, rend notre outil à
dévélopper plus pratique au cours de la phase de dimensionnemet du réseau. Surtout que
les compteurs ne sont pas connus par tout le monde et leurs identification n’était pas si
facil. Nous pouvons également proceder autrement, en réduisant le nombre des compteurs
utilisé. La réduction de nombre des parmaètres est l’objet de la discipline de l’analyse
factorielle de données dont la méthode de l’ACP fait partie. Dans la partie qui suit on en
expliquera le principe.

49
III.2.2 Principe de la méthode de l’Analyse en Composantes Principales:
ACP.
Le but principal de l’ACP est de réduire le nombre des variables mises en jeu et
donc de construire une base particulière à partir des variables d’origine. Cette base est
constituée des vecteurs z1….zr (r<p), appelées variables artificielles, choisies de telle
sorte que les sommes des distances des variables d’origines à chacun des sous-espaces
[z1], [z1, z2], … [z1…zr] soient minimales [13].
Les axes engendrés par les variables artificielles sont appelées axes principaux.
Les variables artificielles étant choisi pour former une base orthonormée. Elles sont
orthogonales entre elles et normées, de ce fait elle sont linéairement indépendantes, non
corrélées et appartenant au cercle unité. Ce passage entre les deux bases permet d’obtenir
une représentation de l’espace des variables la plus simples possible (en diminuant si
possible le nombre de générateurs) et la plus fidèle possible (la distance entre les variables
initiales et les variables artificielles est la plus faible possible en moyenne).
La base des axes principaux (z1…zr) est engendrée par les vecteurs propres
relatifs aux valeurs propres non nulles de la matrice symétrique calculée à partir des
produits scalaires deux à deux des variables d’origines. Généralement les deux premiers
axes drainent la majorité de l’information contenue dans le tableau initiale des données.
Ces deux premiers axes correspondent aux valeurs propres les plus élevées. Si nous
tenons comptes de toutes les axes nous conservons l’ensemble de cette information.
(z 1 .....z r ) = χU ;
U = {Vecteurs propres} de la matrice CTC. C éant la matrice des données d' origine
Il est préférable de travailler avec les variables réduites centrées lorsque leurs
écarts types sont très différents. Ceci est dans le but de ne pas privilégier l’effet de taille et
tout réduire à la même échelle (on retranche la moyenne et on divise par la variance).
(C − C )
χ = ij j
ij Var(C )
j

50
Ensuite, il faut calculer les corrélations entre la charge Y et ces différents axes
pour trouver quels sont les axes par lesquels la charge est portée le plus. De même avec
les variables d’origine, afin de déterminer par quelle composante chaque variable est
portée. Ceci est dans le but d’identifier nos variables d’origines. Après les avoir identifié,
nous devons revenir à la méthode de moindre carré mais avec beaucoup moins de
variables. La corrélation entre les variables d’origine et les axes obtenus nous permet
d’obtenir un tableau de ce type :
variable z1 zr
C1 corr(C1,z1) ... corr(C1,zr)
. .
. .
. .
. .
Cp corr(Cp,z1) ... corr(Cp,zr)
Ensuite nous obtiendrons notre tableau d’origine mais avec k colonnes où k<<p
Période Charge Opération 1 . . . . . . . . . . . . . . Opération k

t1 y1 C11 .............. C1k
. . . .............. .
. . . .............. .
. . . .............. .
. . . .............. .
. . . .............. .
. . . .............. .
. . . .............. .
tN yN CN1 .............. CNk
Et notre nouvelle matrice C de donnée sera
⎛ C11 . . . C1k ⎞
⎜ ⎟
⎜ . . . . . ⎟
C=⎜ . . . . . ⎟
⎜ ⎟
⎜ . . . . . ⎟
⎜C . . . C Nk ⎟⎠
⎝ N1

51
III.3 Développement de l’outil de calcul de la capacité de la charge

d’un AXE-MSC/VLR.
Nous décrivons brièvement l’outil et l’environnement utilisé pour le

développement de l’application objet de ce travail. La deuxième partie sera consacrée à la
description de cette application
III.3.1 Présentation de l’environnement de développement
L’environnement utilisé est «Visuel Studio dot Net 2005 de Microsoft». En

raison des différentes fonctionnalités qu’il offre, nous l’avons retenu pour le
développement de notre application. En effet «Visuel Studio dot Net 2005 de Microsoft»
constitue une famille des outils de développement permettant d’être plus productif tout en
améliorant la performance de l’application. Grâce à cet environnement, nous pouvons
également concevoir nos applications d’une façon plus modulaire. En plus, ces
applications ne sont pas limitées uniquement à la machine où elles fonctionnent, elles
peuvent être exécutées sur n’importe quel autre machine admettant le «framwork dot
Net». Ce dernier contient touts les éléments nécessaires pour l’exécution et le
développement des applications Windows, des applications Web ainsi que les services
correspondants [14].
L’avantage majeur de l’environnement «dot Net» c’est qu’il est indépendant du

langage grâce aux différents compilateurs qu’il contient. C'est-à-dire que nous pouvons
également développer des applications avec des codes différents et qui correspondent aux
langage (C++/CLI, C#, J#, JScript .NET, et Visual Basic .NET) fournis par Microsoft
(Figure III.2). L’interopérabilité de ces différents codes est assuré par le module MSIL
«MicroSoft Intermediate Language» situé dans le «framework dot Net». Ce ci veut dire
que tous les codes vont être traduits en un seul code.

52
Code Source Code Source Code Source Code Source

C++ C# Visuel JScript.NET
Basic : VB
Compilateur Compilateur Compilateur Compilateur

C++ C# VB JScript.Net
MSIL & Métas données
CLR
Système d’exploitation
Figure III.2 Structure du «framework dot Net»
L’autre avantage de l’environnement «dot Net» réside dans la portabilité des

applications développées en utilisant ses codes. Grâce au compilateur JIT «Just In Time
compilation» existant au niveau de CLR «Common Language Runtime», le code MSIL
sera compilé pour obtenir un code adapté à l’architecture matérielle de la machine. Ceci
est réalisé grâce aux métas donnés trouvés au sein de l’exécutable obtenu après la
compilation.
Le langage utilisé pour le développement de l’application objet de notre travail

est le Visual C++ vue de sa simplicité.

53
III.3.2 L’outil «AXE-MSC/VLR Processor Load Measurement»

III.3.2.1 Organigramme
La structure de notre programme se présente comme suite. Après l’installation

l’utilisateur doit être authentifié. Il ne doit pas dépasser trois essais, si non le programme
se ferme et l’utilisateur sera obligé de redémarrer l’application. Dans le cas où il est
authentifié avec succès une séquence démarrage aura lieu et durera 5secondes. Après le
démarrage l’utilisateur doit choisir la méthode avec laquelle il veut travailler (c’est
toujours l’ajustement avec moindre carré, mais les paramètres qui sont utilisés diffèrent).
En suite il faut se connecter à une base donnée de type «Access», à l’aide d’une classe
appelée «data», pour importer les données (les statistiques des mesures récupérées à partir
de l’OSS) (figure III.3).
Nous devons par la suite tout transférer vers une classe MATLAB (Bibliothèque
contenant toute les fonctionnalités MATLAB à intégrer dans notre code programme) en
spécifiant le temps de début et de fin de la simulation. Dans cette classe MATLAB se
produira tout le calcul matriciel et le traçage de courbes ainsi que le renvoie des résultats
au programme principal. Enfin aura lieu la mise à jour de la base de données afin de créer
des historiques qui pourraient être utiles à l’avenir pour l’évolution de l’outil.

54
Installation
Fermer
Non
Succès
Sortir du Programme
Oui
Authentification
Non & essai >3 Non & essai ≤ 3

Valide
Sortir du Programme
Oui
Démarrage
Temps <5 secondes

Temps
Temps =5 secondes
Méthode
Touts les Taux par abonné ACP

paramètres
Programme Temps
Data Principale
Transfère de données
Connexion avec précision de temps
Mise à jour de la base de
données Retour des résultats
MATLAB
Base de Données
Access
Figure III.3 Organigramme de l’outil «AXE-MSC/VLR Processor Load Measurement»

55
III.3.2.2 Guide d’utilisateur de l’outil «AXE-MSC/VLR Processor Load Measurement»

Nous avons prévu avec cette application un installateur qui peut s’installer sur
une machine Windows. Cet installateur est créé au cours du développement de l’outil au
sien de l’environnement. Ceci peut se faire en ajoutant simplement un «Project» dont le
type est « Set Up Project» à notre application. Après la compilons de projet «Set Up», le
« framework dot Net» sera ajouté automatiquement à l’installateur et nous obtenons à la
fin un fichier de format «msi» dont l’exécution produira l’installation de l’outil. Nous
pouvons également ajouter des options au projet «Set Up», comme par exemple l’ajout
d’une icône sur le bureau ou bien dans le menu «Tous les programmes» du menu
«démarrer». L’exécution du fichier «AXE CPU Set UP.msi» nous affichera sa boîte de
dialogue de guide d’installation «Install Shield».
Figure III.4 Lancement de l’installation

56
En suite on nous demande l’emplacement de l’installation. Nous avons choisi le

répertoire d’installation «C:\Program Files» suivi du nom constructeur «SupCom &
Tunisie Telecom» en suite le répertoire où l’application sera placée.
Figure III.5 Choix de répertoire d’installation
Figure III.6 Fin de l’installation

57
Après l’installation, une icône sera créée sur le bureau. Cette icône constitue un
raccourci pour notre application d’où nous pouvons la lancer. Au cours du lancement une
boite de dialogue s’ouvre pour la saisie du compte (Authentification Login : supcom ;
Password : supcom). Une erreur se produira si l’authentification est échouée.
Lancement à partir d’une Lancement à partir de

icône sur le bureau menu programme du
menu démarrer
Figure III.7 Raccourci du lancement
Figure III.8 Authentification

58
Lorsque le bouton «Proceed>>>» est activé, la boite de dialogue de démarrage,

s’ouvrira. Cette boite de dialogue dure 5 secondes et s’accompagnera d’une animation
audio.
Figure III.9 Démarrage
Après le démarrage une boite de dialogue donne le chois entre les trois méthodes
de travail. La première option (Tous les paramètres) permet de tenir compte de touts les
paramètres (touts les compteurs) dans la méthode de l’ajustement avec moindre carré. La
deuxième (Taux par abonné) utilisera les taux par abonné de chaque type de trafic, qui
seront calculé à partir des données d’origines. La dernière (ACP) permet de tenir compte
uniquement des variables les plus pertinents. La validation d’un chois est assuré par un
simple click. Nous allons expliquer par la suite l’utilisation de chaque méthode.

59
Figure III.10 Choix de la méthode (Tous les paramètres)
Après la validation du premier choix nous obtiendrons ainsi la fenêtre principale

de la première méthode. Les boutons à gauche constituent les boutons des données qui
vont nous renseigner sur les valeurs des différents compteurs pour un instant donné (après
la simulation). Les boutons à droite constituent les boutons de contrôle de la fenêtre avec
lesquels nous pouvons par exemple importer les données, les visionner, simuler pour le
traçage de la charge réelle et celle ajustée en plus du changement de la méthode. Cette
dernière est dans le but de faire une comparaison entre les méthodes.
Au début les trois boutons «Visionner les données» (qui permet de visionner les
données importées à tout moment) et «Simuler» (qui permet de passer à la simulation) ne
sont pas activés. Ces boutons ne le seront qu’après l’import des données. En plus le
bouton «Enregistrer les résultats» ne sera activé qu’après la simulation. Il permet
de mètre à jour la base donnée avec les résultats obtenus (la colonne Charge CPU
Ajustée»). Le bouton «Changer le méthode» est toujours activé afin de permettre le
changement de la méthodologie de travail à tout moment.
60
Figure III.11 Fenêtre principale
Avec un simple click sur le bouton «Importer les données», une boite de
dialogue d’ouverture de fichier s’ouvrira afin de choisir à quel base de donné se connecter
(sur la figure ci-dessous nous avons la base de donnée «Access» «Statistiques.mdb»).
Figure III.12 Choix de la base de donnée

61
Ensuite nous aurons notre base de donnée qui s’affichera sur l’écran où nous
voyons très bien la colonne «Charge CPU Ajustée est vide. Cette colonne sera remplie
après la simulation par des valeurs ajustées.
Figure III.13 Connexion à la base de donnée établi
Pour passer à la simulation (click sur le bouton «Simuler» qui est devenu activé)
il faut spécifier le temps de début et de fin ; c'est-à-dire qu’il faut spécifier la durée de la
simulation. Dans une autre boîte de dialogue nous choisissons ces deux instants.
Figure III.14 Choix de temps de la simulation

62
En activant le bouton «Proceed Simulation» il ne reste que voir les résultats sont
affichés. En effet, nous avons deux boites de dialogues MATLAB qui vont s’ouvrir, l’une
pour l’évolution de la charge au cours du temps et l’autre la répartition en moyenne de la
charge selon les types de trafic. Les interprétations des résultats font l’objet du chapitre
suivant.
Figure III.15 Évolution de la charge
Figure III.16 Répartition de la charge

63
Nous pouvons visionner les résultats et certaines valeurs des différents

compteurs après la simulation. Nous pouvons ainsi voir la charge réelle, celle qui est
approximé et l’erreur de précision.
Figure III.17 Obtention des résultats par la première méthode
Nous pouvons également changer la méthode de l’approximation de la charge en

appuyant sur le bouton «changer la méthode». Ceci nous permet de revenir à la page des
chois de la méthode. En suite le principe de la simulation reste le même que nous avons
décrit ci dessus.

64
Figure III.18 Choix de la deuxième méthode
Figure III.19 Obtention des résultats par la deuxième méthode

65
De même pour la méthode de l’ACP, où nous avons uniquement les paramètres

les plus pertinents. C’est à dire qu’on estime la charge avec moins de paramètres.
Figure III.20 Choix de la méthode de l’ACP

66
Figure III.21 Obtention des résultats par la méthode de l’ACP
Nous avons décrit dans ce chapitre l’application, le principe de l’estimation de

la charge avec Moindre Carré ainsi que la méthode de l’ACP. Nous allons également
décrit dans le chapitre suivant les résultats obtenus

67
Chapitre IV : Étude de cas
Chapitre
IV
É tude de cas
IV.1 Résultats de l’ajustement avec Moindre Carré

sans ACP
IV.2 Rrésultats obtenu avec Moindre Carré en utilisant les

taux par abonné
IV.3 Rrésultats obtenu avec Moindre Carré après ACP
68
68
Chapitre IV:
Étude de cas
À l’aide de la métode du moindre carré, nous avons pu estimé la charge de
certains MSC/VLR dans des régions différentes avec une bonne précision.
IV.1 Résultats de l’ajustement avec Moindre Carré sans ACP
La figure suivante montre pour chaque MSC étudié, la charge réelle (en bleu) et
la charge estimé (en rouge). Nous avons eu une forte corrélation (0,9) ainsi que l’erreur
est autour de 4% en moyenne.
Figure IV.1 Estimation de la charge avec moindre carré sans ACP
69
69
Au niveau du chapitre précedent nous avons montré comment la charge se

répartit selon les différents cas de trafic (Chapitre III Equaution III.6). En effet la gestion
d’appels possede l’impact majeur sur la charge. Elle peut atteindre les 70% de la charge
globale. Ensuite la mise à jour de localisation intervien en deuxièmme degré pour se situer
autour de 25%; le Handover peut atteindre les 5% de la charge. Les SMS 3% et les
services USSD ayant l’impact le moin faible environ 1% (Figure IV. 2).
Figure IV.2 Répartition de la charge selon les différnet stypes de trafic avec Moindre carré sans
ACP
La charge des différents MSC/VLR évolue et se répariti, selon les différnets

types de trafic, de la même manière. Ceci nous permet de prédire que les MSC/VLR
obeissent au même modèle. Pour déterminer ce modèle nous pouvons prendre la moyenne
des modèles particulièrs . C’est à dire qu’à partir des vecteurs des coeifficients α, que
nous avons déterminé avec la méthode de la moindre carrés pour les quatre MSC/VLR,
nous allons déterminer un autre vecteur qui sera la moyenne de ces quatres vecteurs et qui
sera aussi valable pour les quatres MSC/VLR.
1
α _ Moy = (α _ BJ 2 + α _ GAF + α _ KAI + α _ OU )
4
70
70
Figure IV.3 Ajustement de la charge avec Moindre Carré sans ACP en utilisant un modèles
générale
Nous pouvons remarquer que les résultats obtenus sont moin précis que ceux
trouvés avec des modèles particulièrs. Mais nous voyons très bien que la charge estimée
fluctue toujours autour de la charge réelle. L’erreure n’a jamais dépassé les 5% en
moyenne et la corrélation entre la charge réel et celle estimée est de l’ordre 0,8 en
moyenne pour les qutre MSC. De même pour la répartion de la charge, nous avons pas eu
des grandes erreurs de précision(Figure IV.4).
Figure IV.4 Répartition de la charge avec un modèle générale ACP

71
71
De ce que préced nous pouvons conclure que les MSC/VLR choisis obeissent
au même modèle. Les écarts constatés sont visiblement dûs à la non uniformité du profil
d’abonné dans les différents régions (nos avons considéré des compteurs horaires qui
donnent des valeurs moyenne heur par heur et non des compteurs instantanées). En plus
nous n’avons pas tenus compte de certaine fonction supplémentaire au sein des
MSC/VLR comme la fonction de transit et la gestion d’équipement ainsi que la différence
entre les fichiers de configuration.
IV.2 Rrésultats obtenu avec Moindre Carré en utilisant les taux par
abonné.
Nous avons pu également travaillé avec les différents taux de chaque types de
trafic par abonné et nous avons obtenu pratiaquemet les mêmes résultats soit pour
l’ajustmeent de la charge soit pour sa répartition. Il s’agit siplement d’un ajustement avec
moindre carré mais au lieu d’utilser tous les compteurs on en calcule les taux
correspendants au différents cas de trafic. L’erreurs était toujours de l’ordre de 3%.
Figure IV.5 Ajustement de la charge en utlisant les taux par abonné des différents cas de trafic
72
72
Figure IV.6 Répartition de la charge en utilisant les taux des différents types de trafic
Les résultats sont aussi valables lorsque nous avons utilisé un modèle générale.
L’erreur est pratiquement la même (3% environ).
Figure IV.7 Ajustement de la charge en utlisant un modèle générale pour les taux des différents cas
de trafic
73
73
Taux HO INTER MSC Taux HO INTRAMSC

Taux HO INTRAMSC Taux MO SMS
Taux MO SMS 3%4%
2% Taux HO INTER MSC
Taux LU PER
Taux LU PER Taux MT SMS 2%3% 2%
Taux MT SMS 2% 7% 3%Taux LU IMSI ATT
2% 6% 4% Taux LU IMSI ATT Taux USSD 1%
Taux USSD 1% 3% Taux IMSI DET Taux MIN1%
2% Taux IMSI DET
Taux MIN 1% 7% 7%Taux LU NORM
Taux LU NORM
38%
Taux MO
38%
Taux MO
29% 30%
Taux MT
Taux MT
MSC GAF2
MSC BJ2
Taux HO INTRAMSC Taux HO INTER MSC Taux HO INTRAMSC

Taux MO SMS
2% 3% Taux LU PER 2%
Taux MO SMS Taux MT SMS 2%2% 3% Taux HO INTER MSC
Taux MT SMS 2% 7% Taux LU PER
2% 3% Taux LU IMSI ATT Taux USSD 1% 7% Taux LU IMSI ATT
Taux USSD 1% 3% Taux IMSI DET 3%3%
1% Taux IMSI DET
1% Taux MIN
Taux MIN 7%Taux LU NORM 7%
Taux LU NORM
Taux MO 39% 40%

Taux MO
30% 29%
Taux MT Taux MT
MSC KAI MSC OU
Figure IV.8 Répartitin de la charge en utilisant un modèle générale pour les taux des différents cas
de trafic
IV.3 Résultat obtenu avec la méthode de l’Analyse en Composante

Principale ACP.
Les axes obtenus aprés avoir éffectué la méthode de l’ACP sont généralement
les deux premiers axes corrspendant aux valeurs propres les plus elevés. Ces deux axes
contient ainsi la majorité de l’information. Pour les quatre MSC/VLR nous avons trouveé
les mêmes variables d’origines (les compteurs). En suite nous avons essayé d’appliquer la
méthodes de la moindre carré avec uniqument ces variables. Nous avons trouvé ainsi
pratiquement les mêmes résultats sauf qu’il y a des petites erreurs de précision. Mais
l’erreurs en moyenne n’a pas dépassé 5%.
74
74
Figure IV.9 Ajustement de la charge aprés que nous avons utlisé la méthode de l’ACP
Aprés que nous avons identifié les variables d’origine; nous avons trouvé qu’ils
correspondent uniquement aux cas de trafic suivant: Gestion d’appels, Mise à jour de
localisation, Handover et les SMS. Nous pouvons donc négliger la charge provoqué par
les services USSD ainsi que l’accés aux réseau intelligent pour l’estimation de la charge
d’un AXE-MSC/VLR. En effet la charge provoqué par ces deux types de trafic etait
toujours négligeable par rapport aux autres; elle elle n’a jamais dépassé 1% (parfois 0,9 et
0,5 %).
Figure IV.10 Répartition de la charge avec Moindre Carré après ACP

75
75
Nous avons essayé aussi de trouver un autre modèle générale aprés l’utilisation
de l’ACP afin d’estimer la charge pour n’importe quel MSC/VLR avec le minum de
paramètres. C’est vrai que la charge approximé n’était pas toujours confondue avec celle
réelle, mais cette méthode prouve une simplification consiérable du travail qui ne coute
tout de même que prés de 3% par rapport à l’utilisation des modèles particulieèrs par
MSC en tenant compte de tout les parmaêtres. De même pour la répartition de la charge.
Figure IV.11 Aproximation de la charge avec Moindre Carré après ACP en utilisant un seul modèle
Figure IV.12 Répartition de la charge avec Moindre Carré après ACP en utilisat un seul modèle
76
76
Le tableau ci dessous présente les résultats obtenus avec l’approximation de la

charge en utilisant le moindre carré diférément.
Tableau IV.1 Tableau récapitulatif des résultats obtenus
Nous avons présenté dans ce chapitre les résultéts obtenus avec la méthode de
Moindre Carré pour l’éstimation de la charge des MSC. Nous avons également montré
l’interré de l’utilisation de la méthode de l’ACP pour la simplification du modèles utilisé.
77
77
Conclusion générale
Conclusion Générale
L e but principal du présent projet fin d’études est de modéliser la charge des nœuds
cœur du réseau GSM. Pour ceci nous avons commencé par une étude de l’architecture de
ces nœuds.
Après avoir identifié ces paramètres, nous avons utilisé la méthode de moindre
carré pour l’estimation de la charge déferrement. En effet, nous avons tenu compte, en
premier lieu de tout, de tous les paramètres, que nous avons récupéré. En suite nous avons
travaillé avec les taux des différents types de trafic afin de rendre l’outil à développer plus
pratique au cours de sont utilisation pendant la phase de dimensionnement. Ceci nous a
permit d’aboutir à conclure que les MSC/VLR malgré qu’ils sont situés dans des
environnements différents ils obéissent au même modèle.
En plus nous avons montré l’intérêt de la méthode de l’ACP dans l’ajustement

de la charge CP des nœuds tout en diminuant les paramètres dont elle dépend. Cette
méthode nous permit de conclure, qu’uniquement la Gestion des appels, la Mise à jour de
localisation, le Handover ainsi et les SMS sollicitent la charge de manière significative.
La charge provoquée par les services USSD et l’accès au réseau intelligent était toujours
négligeable.

78
Du nœud cœurs du réseau GSM
de Tunisie Télécom
Annexe
Annexe 1
Description de diagramme de bloc APZ 212 33
APZ 212 33 Logical Block Diagram RP
CP-A Central processor, A-side *RPB-31B

CP-B Central processor, B-side *RPB-31A
AMB Automatic maintenance bus
CLKB Clock bus RP
CPUM Central processor unit magazine
CTB CPU test bus *RPB-0B
DSU Data store unit *RPB-0A
IPU Instruction processor unit
MAB Maintenance bus *Parallel or serial
**Optional
MAI Maintenance unit interface
MAU Maintenance unit
PRS Program and reference store
PTB Processor test bus
RP Regional processor
RPB Regional processor bus
RPBSX Regional processor bus serial cross connect
RPH Regional processor handler
RPHM Regional processor handler magazine
SPU Signal processor unit
UMB-I Update and match bus instruction processor
UMB-S Update and match bus signal processor
CP-A RPB 0 1 2 3 28 29 30 31
CP-B
RPH
RPBSX
RPIO RPBH RPBH RPBH RPBH
POU-R
RPBI-P RPBI-P RPBI-S
RPHB
SPU MAI
MASTER SLAVE
CDU
OPA/BB-M OPA/BB-S
POWC
IPI JBMU RPHI FAN

FAN MAU
MKU SKU PSIC MAB
ALU ALU POU-C
AMU AMB
RESB-M RESB-S
MAB, AMB
STIM SMUM SMUS STIS MIC CTB
CTB
TPU
CLKB PTB
UMB-S
IPU
OPBB1
OPAB1
OPBB0
OPAB0
IQC
JAMU LMU IMAI RMU SPI ATU PRSU DSH UMU
ALU0 ALU1
DEDB0
DEDB1
UMB-l
JAM TRIU CM PRS UBC
DSU-D/S
IPI
DSC
7
0
RP
RP
CP-A CP-B IOG20** APG30/

APG40**
RPBSX
RPH RPH RPV STOC
RPHM RPHM
CPUM CPUM
SP AP
UMB-S
SPU SPU
CLKB
MAI MAI
IPU IPU
PRS PRS
AT AD
MAB, AMB, CTB
MAU
DSU UMB-I DSU DL DL
PTB PTB
IOG20 SP based input/output system MIC Maintenance interface circuit

AT Alphanumeric terminal POWC Power control unit
DL Data link PSIC Power and serial interface controller
IOG Input/output group POU-C Power unit Central processor unit
RPV Regional processor connected to VME
SP Support processor MAU Maintenance unit
VME Versa module Europe AMU Automatic maintenance unit
TPU Test and processor unit
APG30/ AP based input/output system
APG40 IPU Instruction processor unit
AD Alphanumeric device ALU Arithmetic logic unit
AP Adjunct processor ATU Assembler to micro code translator unit
APG Adjunct processor group CM Control memory
DL Data link DEDB Destination data bus
STOC Signaling terminal for open communication DSH Data store handler
IMAI Instruction processor unit Maintenance
RPH Regional processor handler interface
POU-R Power unit Regional processor handler IQC Instruction queue controller
RPBH Regional processor bus handler JAM Jump address memory
RPBI-P Regional processor bus interface parallel JAMU Jump address memory unit
RPBI-S Regional processor bus interface serial LMU Load and measurement unit
RPHB Regional processor handler bus OPAB Operand A bus
RPIO Regional processor input/output OPBB Operand B bus
PRS Program and reference store
SPU Signal processor unit PRSU Program and reference store unit
ALU Arithmetic logic unit RMU Register memory unit
IPI Instruction processor interface SPI Signal processor interface
JBMU Job buffer memory unit TRIU Trigger unit
MKU Master kernel unit UBC Update buffer and match circuit
OPA/BB-M Operand A/B bus master UMU Update and match unit
OPA/BB-S Operand A/B bus slave
RESB-M Result bus master DSU-D/S Data store unit – DRAM/SRAM
RESB-S Result bus slave DRAM Dynamic random access memory
RPHI Regional processor handler interface DSC Data store memory control circuits
SKU Slave kernel unit SRAM Static random access memory
SMUM Signal processor unit maintenance unit master
SMUS Signal processor unit maintenance unit slave
STIM Signal processor unit test interface master
STIS Signal processor unit test interface slave The equipment practice for APZ 212 33 is BYB 501.
MAI Maintenance unit interface Ericsson assumes no legal responsibility for any error
CDU Control processor display unit or damage resulting from the use of this guide.
Annexe 2
Commandes MML
Commandes MML
1-Dialoguer avec le sous-système STS
>IMLCT:SPG=0;
2- On arrête les statistiques
:SDDCE;
3- Initiation au nouveau changement
:SDDOI;
4- Activation d’un “Object Type”
: SDDOC:OBJTYPE=CHASSIGNT,INCL=YES,BRP=15;
5- Exécution des instructions
:SDDOE:EXEC;
6- Collecte des données
:SDDCI;
7- Mise à jours des tables
:SDDTI;
8- Fin des instructions
:END;
Bibliographie
[1] GMS SYSTEM SURVEY; Ericsson Radio Systems AB 1998
[2] GSM DATA TRANSCRIPT; Ericsson Radio Systems AB 1998
[3] SYSTEM DESCRIPTION OF APZ PLATFORM, GSM900/1800+WCDMA;
Ericsson 2002
[4] SUBSYSTEM MSS, MOBILE SWITCHING SUBSYSTEM; Ericsson,
Bibliothèque ALEX.
[5] SUBSYSTEM MMS MOBILE MOBILITY AND RADIO SUBSYSTEM;
Ericsson, Bibliothèque ALEX.
[6] SUBSYSTEM MDS (GSM and WCDMA), MOBILE DATA SUBSYSTEM;
Ericsson, Bibliothèque ALEX.
[7] SUBSYSTEM SHS SHORT MESSAGE SERVICE; Ericsson, Bibliothèque
ALEX.
[8] Object Types in STS; Ericsson, Bibliothèque ALEX.
[9] DIDs in STS; Ericsson, Bibliothèque ALEX.
[10] BLOCK MHO MOBILE TELEPHONY HANDOVER; Ericsson, Bibliothèque
ALEX.
[11] Xavier Lagrange, Philippe Godlewski, Sami Tabbane “Réseaux GSM-DCS”
Édition Hermes, Imprimé par FLOCH À MAYANNE en May 1999.
[11] USER GUIDE FOR TRAFFIC SET-UP OF IN/CAMEL TRANSACTIONS

IN GSM/WCDMA MOBILE SYSTEMS, MSC R10.
[12] GSM PPS/PPLE Service Overview; Ericsson, Bibliothèque ALEX.
[13] Ruben Rodriguez, Herrera Danielle Salles-Le Gac “INITIATION À
L’ANALYSE FACTORIEL DE DONNÉES» Edition Ellipses Imprimé par
MAME en May 2002
[14] Stephen R. G. Fraser “Pro Visual C++/CLI and the .NET 2.0 Platform” Library
of Congress Cataloging-in-Publication USA 2006
Résumé:
Les noeuds du réseau coeur (core network) sont les entités du réseau mobile
qui prennent en charge les fonctions de gestion d'abonnés, d'établissement et de
contrôle des appels, de taxation, de gestion de mobilité, de connexion avec d'autres
réseau, de gestion des ressources ... etc. La capacité d'un noeud à gérer toutes ces
fonctions dépend non seulement du volume des tâches qu'il est appelé à exécuter mais
aussi de l'état dans lequel il se situe.
L'objet de ce projet est de développer un modèle de calcul de la capacité des

noeuds du réseau coeur mobile en fonction des différents cas de trafic qui les
sollicitent. Nous avons été amenés en premier lieu d’étudier l’architecture des nœuds
cœurs utilisé chez l’opérateur Tunisie Télécom dans le but d’identifier les paramètres
dont dépend la charge.
Ensuite en se basant sur des statistiques que nous avons pu récupéré auprès de
l’OSS, nous avons utilisé la méthode Moindre Carré pour l’estimation de la charge. Et
en vue de réduire le nombre de paramètres dont dépend cette charge nous avons
utilisés la méthode de l’analyse en composante principale ACP qui a prouvé son intérêt
en terme de la simplification du travail.
Mots clé :
AXE-MSC/VLR, Charge CPU, MC: Moindre Carré, ACP : Analyse en Composante
Principale.

CHOUIKH Aref

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CHOUIKH Aref

Încărcat de

Drepturi de autor:

Formate disponibile

Cycle de formation des ingénieurs en Télécommunications

Rapport de Projet de fin d’études

Modélisation de la charge des nœuds

Travail proposé et réalisé en collaboration avec

Année universitaire : 2006/2007

Je dédie ce travail, et qu’il soit un sentiment de reconnaissance

Au terme de ce travail, je tiens à remercier mes encadreurs de projet de fin

Aussi, j’exprime toute ma reconnaissance à l’administration de SUP’COM

Et toute ma gratitude envers tous les personnels de la Direction Centrale des

Comme je n’oublie pas à exprimé mes sincères et spéciales remerciements à

Finalement, je remercie les membres de jury pour avoir accepter d’évaluer ce

L'objet de ce projet est de développer un modèle de calcul de la capacité des

PFE : Modélisation de la charge

PFE : Modélisation de la charge

PFE : Modélisation de la charge

PFE : Modélisation de la charge

PFE : Modélisation de la charge

PFE : Modélisation de la charge

PFE : Modélisation de la charge

PFE : Modélisation de la charge

La plate-forme AXE est basée sur un composant matériel, qui s’appelle

Nous essayons à travers ce rapport à expliquer au mieux notre stratégie de travail.

Dans un deuxième chapitre, on expliquera l’intervention de ces différents blocs

PFE : Modélisation de la charge

Après avoir identifié nos variables de travail, on expliquera, dans un troisième

PFE : Modélisation de la charge

I.1 Structure d’un AXE

I.2 Le module système XSS «Existing Source

PFE : Modélisation de la charge

I.1 Structure d’un AXE

Quand l’AXE est introduit pour la première fois au marché, l’application

PFE : Modélisation de la charge

I.1.2 Structure de l’AXE

Le succès de l’AXE provient de sa flexibilité et sa modularité qui lui permettent

L’AXE consiste en un ensemble indépendant des blocs fonctionnels. Chacun de

PFE : Modélisation de la charge

Structure Non Modulaire (AXE 105) Structure Modulaire (AXE 106)

Figure I.1 Structures d’un AXE

PFE : Modélisation de la charge

I.1.3 Structure modulaire d’un AXE-MSC/VLR

La structure modulaire est un ensemble de principes bien définis pour le

Figure I.2 Structure modulaire d’un AXE-MSC/VLR

I.1.3.1 Le module système APZ

PFE : Modélisation de la charge

Le module système APZ admet les sous-systèmes suivants :

 RPS «Regional Processor Subsystem»

 MCS «Man-Machine Communication Subsystem»

I.1.3.2 Les modules applicatifs «AM: Application Module»

Les modules applicatifs sont utilisés pour modéliser et implémenter certaines

Ceci rend très facile la modification, le remplacement ou la suppression des

 AUCAM «Authentication Center Application Module»

 HLRAM «Home Location Register AM»

 FNRAM «Flexible Number Register AM»

 SSFAM «Service Switching Function AM»

 SYSOMAM «SYStem Operation and Maintenance AM»

PFE : Modélisation de la charge

Le SYSOMAM communique avec un système d’entrée sortie pour recevoir le

I.1.3.3 Le module Système RMP «Ressources Module Platform»

Le module système RMP, est responsable de l’allocation des ressources pour

 GSS «Group Switching Subsystem»

PFE : Modélisation de la charge

Group Switch (GS)

Clock pulses for TSM and SPM

RPS «Regional Processor Subsystem»

MCS «Man-Machine Communication Subsystem»

AUCAM «Authentication Center Application Module»

HLRAM «Home Location Register AM»

FNRAM «Flexible Number Register AM»

SSFAM «Service Switching Function AM»

SYSOMAM «SYStem Operation and Maintenance AM»

GSS «Group Switching Subsystem»

COMS «Communication Subsystem»

COSS «Connection Service Subsystem»

TCS «Traffic Control Subsystem»

TSS «Trunk and Signalling Subsystem»

ESS «Extended Switching Subsystem»

CHS «Charging Subsystem»

MSS «Mobile Switching Subsystem» [4]

MMS «Mobile Mobility and Radio Subsystem» [5]

MDS «Mobile Data Subsystem» [6]

SHS «Short Message Services Subsystem» [7]