Embed Size (px)
Citation preview
N° d‟ordre : 13/STIM/TCO Année Universitaire : 2011 / 2012
UNIVERSITE D’ANTANANARIVO
-----------------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-----------------------------
DEPARTEMENT TELECOMMUNICATION
MEMOIRE DE FIN D‟ETUDES
en vue de l‟obtention
du DIPLÔME D‟INGENIEUR
Spécialité : Télécommunication
Option : Services de Télécommunication, de l‟Informatique et du Multimédia (STIM)
Par : RANDRIAMANANJARA Mandamahefa
ANALYSE DE PERFORMANCE ET DE QUALITE
DE SERVICE D’UN RESEAU UMTS
Soutenu le 12 Aout 2013 devant la Commission d‟Examen composée de :
Président :
M. ANDRIAMIASY Zidora
Examinateurs :
M. RATSIMBAZAFY Andriamanga
M. RAKOTONDRAINA Tahina Ezéchiel
M. RASOLOMANANA Fanomezantsoa
Directeur de mémoire :
M. RAKOTOMALALA Mamy Alain
i
REMERCIEMENTS
Je rends grâce à Dieu pour sa bonté, de m‟avoir donné la force et la santé durant la
réalisation de ce mémoire.
Je remercie chaleureusement, tout d‟abord, Monsieur ANDRIANARY Philippe
Antoine, Professeur Titulaire, Directeur de l‟Ecole Supérieure Polytechnique d‟Antananarivo,
de m‟avoir accueilli au sein de son établissement.
Je tiens également à adresser mes vifs remerciements aux personnes suivantes sans qui
ce travail n‟aurait pas pu être réalisé :
- Monsieur ANDRIAMIASY Zidora, Maître de Conférences, Enseignant au sein du
Département Télécommunication, qui me fait l‟honneur de présider le jury de ce
mémoire
- Messieurs les membres du jury:
- M. RATSIMBAZAFY Andriamanga, Maître de Conférences, Enseignant au
sein du Département Télécommunication.
- M. RAKOTONDRAINA Tahina Ezéchiel, Docteur, Enseignant au sein du
Département Télécommunication.
- M. RASOLOMANANA Fanomezantsoa, Doctorant, Enseignant au sein du
Département Télécommunication.
- Mes vifs remerciements s‟adressent à Monsieur RAKOTOMALALA Mamy
Alain,Maître de Conférences, Enseignant au sein du Département Télécommunication, Chef
du Département, Directeur de ce mémoire, pour ses précieux conseils et surtout de m‟avoir su
m‟orienté.
- Tous les enseignants et tout le personnel de l‟Ecole Supérieure Polytechnique
d‟Antananarivo, en particulier ceux du département Télécommunications ;
- Je n‟oublierai pas ma famille pour leurs soutiens bienveillants et leurs
encouragements, pour ce mémoire, comme en toutes circonstances. Plus particulièrement, à
mes parents pour leurs sacrifices durant ces longues années afin que je puisse arriver à ce
niveau et pour tous ceux qui ont contribué de près ou de loin à l‟élaboration de ce mémoire. Je
remercie également mon oncle pour son incontestable contribution à l‟accomplissement de ce
mémoire.
ii
TABLE DES MATIERES
REMERCIEMENTS .............................................................................................................................. i
TABLE DES MATIERES .................................................................................................................... ii
LISTE DES NOTATIONS ET ABREVIATIONS ............................................................................. v
INTRODUCTION GENERALE .......................................................................................................... 1
CHAPITRE 1: LE RESEAU D’ACCES DE L’UMTS ...................................................................... 4
1.1 Introduction ..................................................................................................................................... 4
1.2 Concept de base de l’UMTS ........................................................................................................... 5
1.2.1. Réseau cœur et réseau d’accès ................................................................................................................ 5
1.2.2 Découpage en strates : NAS, AS .............................................................................................................. 5
1.2.3. Notion de RAB ......................................................................................................................................... 7
1.3 Architecture de l’UMTS ................................................................................................................. 8
1.3.1 Le réseau cœur .......................................................................................................................................... 8
1.3.2 Le Réseau d’accès UTRAN .................................................................................................................... 10
1.4 Interface radio de l’UTRAN ......................................................................................................... 12
1.4.1 Interface radio......................................................................................................................................... 12
1.4.2 Les canaux .............................................................................................................................................. 13
1.4.3. Couches physiques de l’UTRAN ........................................................................................................... 18
1.5 Conclusion ...................................................................................................................................... 18
CHAPITRE 2: LA QUALITE DE SERVICE ET LA PERFORMANCE D’UN RESEAU
MOBILE .............................................................................................................................................. 19
2.1 Introduction ................................................................................................................................... 19
2.2 Notion de Qualité de Service et de Performance du réseau ....................................................... 19
2.3 Critères d’évaluation de la NP et de la QoS :.............................................................................. 20
2.4 Mécanismes de supervision de la QoS et de la NP : ................................................................... 21
2.4.1 Les plaintes des abonnés ......................................................................................................................... 22
2.4.2 Les mesures terrains : ............................................................................................................................. 22
2.4.3 L’Analyse des KPIs via l’OMC ............................................................................................................... 23
2.5 Connaissance du réseau : base de l’analyse des KPIs ................................................................ 24
2.5.1. Classes de services : ............................................................................................................................... 24
2.5.2 Protocoles de l’UTRAN .......................................................................................................................... 25
2.5.3 Catégories des KPI .................................................................................................................................. 32
2.6 Conclusion ...................................................................................................................................... 34
CHAPITRE 3: GESTION DE LA QoS DU RESEAU PAR L’ANALYSE DES INDICATEURS
CLES DE PERFORMANCE (KPI) ................................................................................................... 35
iii
3.1 L'organisation des données statistiques à analyser .................................................................... 35
3.1.1 Période granulaire .................................................................................................................................. 35
3.1.2 Période d’observation : ........................................................................................................................... 36
3.1.3 Niveaux d’observation : .......................................................................................................................... 36
3.1.4 Les compteurs OMC ............................................................................................................................... 37
3 1.5 Les indicateurs clés de performance ...................................................................................................... 37
3.2 L’analyse des KPI de la Co-OP relatifs à l’UTRAN d’un réseau UMTS ................................. 38
3.2.1 Définitions des compteurs OMC : .......................................................................................................... 39
3.2.2 Définitions des Indicateurs Clés de Performance UMTS : Co – OP KPI relatifs à l’UTRAN............. 52
3.3 Conclusion ...................................................................................................................................... 60
CHAPITRE 4: LES PRINCIPALES SOLUTIONS D’AMELIORATION DE PERFORMANCE
............................................................................................................................................................... 61
4.1 Introduction ................................................................................................................................... 61
4.2 Amélioration de performance d’un réseau mobile ..................................................................... 61
4.3 Principales solutions d’amélioration de la performance de l’UTRAN suite à l’analyse de
compteurs OMC : ................................................................................................................................ 62
4.3.1 Accessibilité ............................................................................................................................................. 62
4.3.2 Continuabilité.......................................................................................................................................... 65
4.3.3 Mobilité ................................................................................................................................................... 68
4.4 Quelques exemples de modèles d’amélioration de performance d’un réseau mobile ............. 70
4.4.1 Amélioration du taux d’établissement d’appels par l’ajout de nouveaux serveurs .............................. 70
4.4.2 Amélioration du taux de coupure d’appels par la réduction de la charge du lien montant d’une cellule
.......................................................................................................................................................................... 71
4.5 Conclusion ...................................................................................................................................... 74
CHAPITRE 5: SIMULATION SOUS MATLAB DE L’ANALYSE DES KPI RELATIFS A
L’UTRAN DEFINIS PAR LA Co-OP EN VUE D’UNE AMELIORATION ............................... 75
5.1 Introduction ................................................................................................................................... 75
5.2 Description de la simulation ......................................................................................................... 75
5.2.1 Paramètres de la simulation ................................................................................................................... 75
5.2.2 Résultats de la simulation ....................................................................................................................... 79
5.3 Analyse et amélioration de performance ..................................................................................... 85
5.3.1 Cellule n°1 ............................................................................................................................................... 85
5.3.2 Cellule n°2 ............................................................................................................................................... 86
5.3.3 Cellule n°3 ............................................................................................................................................... 87
5.3.4 Cellule n°4 ............................................................................................................................................... 88
5.3.5 Cellule n°5 ............................................................................................................................................... 89
5.4 Solutions d’amélioration de performance proposée pour les cellules n°3 et n°4 ..................... 90
iv
5.4.1 Réduction de la charge du lien montant de la cellule n°3 ..................................................................... 90
5.4.2 Augmentation du nombre de ressources radio de la cellule n°4 ........................................................... 92
5.5 Conclusion ...................................................................................................................................... 93
CONCLUSION GENERALE............................................................................................................. 94
ANNEXES ............................................................................................................................................ 96
LISTE DES COMPTEURS RELATIFS A L’UTRAN SPECIFIES PAR LE 3GPP TS 32.403....... 96
L’INTERFACE GRAPHIQUE DE LA SIMULATION ................................................................... 105
BIBLIOGRAPHIE ............................................................................................................................ 110
PAGE DE RENSEIGNEMENTS ..................................................................................................... 115
RESUME ............................................................................................................................................ 116
ABSTRACT ....................................................................................................................................... 116
v
LISTE DES NOTATIONS ET ABREVIATIONS
kpbs kilobits par seconde
mW milliWatt
ms milliseconde
BR Blocking Rate
Bgrd Background
Conv Conversational
CallDR Call drop rate
CSSR Call Setup success sate
HHOSR Hard Handover outgoing success rate
IRATHOSR Inter Radio Access Technology Handover outgoing success rate
IuConnDR Iu Connection Drop Rate
Intact Interactive
Mbps Megabits par seconde
RabEstabSR RAB establishment success rate
RrcEstabSR RRC connection establishment success rate
RLAddSR Radio Link Addition success rate
Strm Streaming
AICH Acquisition Indicator CHannel
vi
ALCAP Access Link Control Application Protocol
AM Acknowledged Mode
AP Application Protocol
AS Access Stratum
ATM Asynchronous Transfer Mode
AuC Authentication Center
BCCH Broadcast Control CHannel
BCH Broadcast CHannel
BMC Broadcast/Multicast Control
BSIC Base Station Identification Code
BTS Base Transceiver Station
CC Call Control
CCCH Common Control CHannel
CCTrCH Coded Composite Transport CHannel
CN Core Network
Co-OP Cooperative – Operating sub-system Project
CPCH Common Packet CHannel
CPICH Common Pilot CHannel
CS Circuit Switched
CTCH Common Traffic CHannel
DC Dedicated Control
vii
DCCH Dedicated Control CHannel
DCH Dedicated CHannel
DL DownLink
DPCCH Dedicated Physical Control CHannel
DPDCH Dedicated Physical Data CHannel
DSCH Downlink Shared Channel
DTCH Dedicated Traffic CHannel
ETSI European Telecommunications Standards institute
FACH Forward Access CHannel
GC General Control
GGSN Gateway GPRS Support Node
GMM GPRS Mobility Management
GMSC Gateway Mobile-services Switching Center
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile communications
IMS IP Multimedia Subsystem
Inter-RAT inter Radio Access Technology
IP Internet Protocol
Iu Interface entre RNC et CN
Iub Interface entre Node B et RNC
viii
Iur Interface entre RNCs
KPI Key Performance Indicators
MAC Medium Access Control
MM Mobility Management
MSC Mobile Switching Center
NAS Non Access Stratum
NBAP Node B Application Part
NP Network Performance
Nt Notification
OMC Operation and Maintenance Center
OSI Open System Interconnection
OSS Operating Sub-System
PCCH Paging Control CHannel
PCCPCH Primary Common Control Physical CHannel
PCH Paging CHannel
PCPCH Physical Common Packet CHannel
PDCP Packet Data Convergence Protocol
PDSCH Physical Downlink Shared Channel
PDU Protocol Data Unit
PH Peak Hour
PLMN Public Land Mobile Network
ix
PRACH Physical Random Access CHannel
PS Packet Switched
QoS Quality Of Service
RAB Radio Bearer Service
RACH Random Access CHannel
RAN Radio Access Network
RANAP Radio Access Network Application Part
RLC Radio Link Control
RNC Radio Network Controller
RNL Radio Network Layer
RNS Radio Network Subsystem
RNSAP Radio Network Subsystem Application Part
RRC Radio Resource Control
RRM Radio Ressource Management
RTCP Réseau Téléphonique Commuté Public
SAP Service Access Point
SCCPCH Secondary Common Control Physical CHannel
SCH Synchronisation CHannel
SDU Service Data Unit
SGSN Serving GPRS Support Node
SM Session Management
x
SMS Short Message Service
SRNC Serving RNC
TB Transport Bloc
TBS Transport Bloc Set
TFS Transport Format Set
TM Transparent Mode
TS Technical Specification
TTI Transmission Time Interval
UE User Equipment
UIT – T Union Internationnale des Télécommunications - Télécommunications
UL UpLink
UM Unknowledged Mode
UMTS Universal Mobile Telecommunications System
UTRAN Universal Terrestrial Radio Access Network
Uu Interface air
2G 2nd Generation
3G 3rd Generation
3GPP 3rd Generation Partnership Project
1
INTRODUCTION GENERALE
Les évolutions technologiques dans le monde ne cessent de s‟accentuer à haute
cadence, notamment pour les systèmes de télécommunications mobiles. Durant ces dernières
années, les réseaux radio mobiles ont eu une expansion sans précédent surtout en termes de
nombre d‟abonnés. Les réseaux mobiles de troisième génération représentent un des succès
industriels les plus marquants de ces dernières années.
Face à la concurrence omniprésente entre les opérateurs mais aussi entre les grands
constructeurs, la nécessité d‟améliorer le service rendu s‟est largement manifestée. Offrir une
qualité de service satisfaisante aux utilisateurs est devenue une priorité plus qu‟un objectif
pour les opérateurs mobiles. Du point de vue d‟un utilisateur, obtenir un service n‟importe
quand et n‟importe où, et maintenir ledit service jusqu‟à ce qu‟ils décident de le terminer,
signifie obtenir une qualité de service satisfaisante. Du point de vue de l‟opérateur, maintenir
un haut niveau de performance de son réseau permet d‟achever cet objectif. Ainsi, il est obligé
de surveiller en permanence la performance du réseau. Cette tâche n‟est nullement facile car
l‟opérateur mobile doit faire face à des trafics et des conditions très variés, mais aussi
permettre aux utilisateurs de se déplacer n‟importe où. Les opérateurs des réseaux UMTS
(Universal Mobile Telecommunications System) utilisent différentes techniques pour
superviser la qualité de service offerte aux utilisateurs.
C'est dans ce contexte que porte notre étude sur l‟ « Analyse de la performance et de la
qualité de service d‟un réseau UMTS » dans lequel nous tenons à étudier la supervision de la
performance du réseau UMTS par l‟analyse des clés indicateurs de performance du réseau
d‟accès en vue d‟une amélioration.
Cela a nécessité des informations recueillies sur le réseau d‟accès UTRAN (Universal
Terrestrial Radio Access Network), qui constitue l'élément fondamental pour laquelle la
qualité de service sera évaluée, à l'aide des indicateurs de performances KPI (Key
Performance Indicators) qui seront calculés à partir des compteurs OMC (Operation and
Maintenance Center).
L‟analyse des fichiers de mesure permet d‟apporter d‟énormes informations quant au
fonctionnement du réseau et ses performances. Les compteurs OMC implémentés dans
différents éléments du réseau sont incrémentés à chaque message protocolaire échangé entre
les différentes entités pour des évènements correspondants. Ces informations sont inutiles à
moins de les transformer en des informations concrètes : les indicateurs de performance.
2
Aussi, les indicateurs de performance présentent une gamme d‟indicateurs qui couvrent
différents aspects de performance du réseau en matière d‟accessibilité, de continuabilité, de
mobilité, etc... L‟analyse des indicateurs de performance à partir des données recueillies par
ces compteurs représente une aide importante à la décision dans les opérations journalières de
maintenance et de supervision de la qualité du réseau. En effet, elle permet efficacement de
repérer au plus vite les problèmes du réseau, et de trouver les solutions d‟amélioration de
performance adéquates à appliquer sur la configuration physique et logique des différents
équipements. Toutefois, les indicateurs de performance, et les mesures terrains sont
complémentaires pour évaluer la qualité de service du réseau permettant entre autres une
analyse détaillée, variée et causale des principaux phénomènes et problèmes rencontrés dans
le réseau UMTS.
Dans le présent document, nous nous sommes particulièrement intéressés à donner au
premier chapitre un aperçu sur le réseau d‟accès de l‟UMTS. En fait, nous allons présenter le
concept de base de l‟UMTS. Et ensuite nous porterons plus d‟intérêt au réseau d‟accès, et à
ses interfaces. De plus, nous allons exposer certaines caractéristiques du sous-système radio.
Dans le deuxième chapitre, nous tenons à étudier la qualité de service et la
performance d‟un réseau UMTS. Cette notion a été illustrée par l‟exposition des critères
d‟évaluation de la performance du réseau et les mécanismes de la supervision de la qualité de
service. Nous terminerons ce chapitre par quelques connaissances utiles pour la supervision
de la qualité de service et de la performance d‟un UTRAN.
Dans le troisième chapitre, nous décrirons la gestion de la qualité de service par
l‟analyse des KPIs. En fait, nous allons étudier en premier lieu l‟organisation des données
statistiques à analyser dans laquelle nous ferons la description des compteurs OMC et des
indicateurs clés de performance ; et en second lieu, nous passerons à l‟analyse des indicateurs
clés de performance relatifs au réseau d‟accès de l‟UMTS, spécifiés par la Co-OP
(Cooperative – Operating sub-system Project).
Dans le quatrième chapitre, nous nous proposerons d‟étudier les principales solutions
d‟amélioration d‟un réseau d‟accès UMTS. Nous verrons d‟abord le processus d‟amélioration
de performance du réseau d‟accès en général, pour ensuite décrire les principales solutions, et
nous terminerons par l‟étude de quelques exemples de ces solutions.
Et finalement, nous allons passer à la simulation sous Matlab d‟une analyse des
indicateurs de performance définis dans le chapitre 3. Dans ce dernier chapitre, nous décrirons
la simulation ainsi que l‟interprétation des résultats et les recommandations appropriées. Et en
3
dernier lieu, nous allons appliquer sur quelques cellules les exemples de solutions
d‟amélioration de performance vus dans le chapitre 4.
4
CHAPITRE 1
LE RESEAU D’ACCES DE L’UMTS
1.1 Introduction
Les limites des systèmes de seconde génération incitent les opérateurs de
télécommunications à définir une norme commune, d‟où l‟idée d‟un système de
radiocommunication de troisième génération. Le réseau UMTS fait partie des réseaux mobiles
de troisième génération.
L‟idée fondatrice de l‟UMTS est d‟intégrer tous les réseaux en un seul et de lui
adjoindre des capacités multimédia (haut débit pour les données), comme l‟indique
l‟acronyme UMTS, pour Universal Mobile Telecommunications System. [1]
Pour aboutir à ces objectifs, un certain nombre de notions assez nouvelles par rapport à la
norme UMTS et aux normes de 2G (2nd
Generation) sont introduites dans la norme UMTS.
Deux éléments fondamentaux permettent d‟expliquer cette approche :
- Les services supportés : du fait que les champs d‟applications des normes 2G
étaient assez limités : téléphonie, données bas débit, service de messages courts,
les réseaux 3G (3rd Generation) ont des ambitions beaucoup plus larges, liées à
l‟évolution des services sur les réseaux fixes.
- L‟indépendance de la couche d‟accès radio : lorsque l‟on considère le réseau 2G,
on se rend compte que la couche d‟accès radio a été définie de manière rigide,
offrant peu de flexibilité au réseau d‟accès.
La norme UMTS propose donc une architecture et un découpage fonctionnel plus
ouvert, en séparant les fonctions liées à la technologie d‟accès de celles qui ne dépendent pas
du mode d‟accès. Ce concept de séparation de la couche d‟accès au reste du réseau accroît
l‟évolutivité de la norme UMTS car il permettra de faire évoluer l‟interface d‟accès radio en
minimisant les impacts sur les équipements. [1][2][3][4]
5
1.2 Concept de base de l’UMTS
1.2.1. Réseau cœur et réseau d’accès
Comme le réseau GSM (Global System for Mobile communications), un réseau
UMTS est composé d‟un réseau cœur CN (Core Network) et d‟un réseau d‟accès RAN (Radio
Access Network).
L‟interface entre ces deux réseaux est appelée « Iu ». Cette interface a été définie
d‟une manière aussi générique que possible afin d‟être capable de connecter, en plus de
l‟UTRAN qui est considéré comme la technologie d‟accès grand public de l‟UMTS, des
réseaux d‟accès de technologies différentes au réseau cœur de l‟UMTS entre autres le SRAN
(Satellite Radio Access Network), le BRAN (Broadband Radio Access Network) ou le
WLAN (Wireless Local Area Network). [2][5][6]
Afin d‟assurer l‟indépendance de l‟interface Iu par rapport à la technologie d‟accès, cette
interface intègre la notion de RAB (Radio Bearer Service), qui permet de décrire de manière
générique le canal de communication utilisé dans le réseau d‟accès. [1][2][5]
1.2.2 Découpage en strates : NAS, AS
La modélisation du réseau UMTS peut se faire par un découpage en strates (ou
niveaux) selon les spécifications du 3GPP (3rd Generation Partnership Project). Ce
découpage est conforme à celui du modèle OSI (Open System Interconnection), permettant de
séparer les niveaux de services indépendants. [1][5]
Il y a deux grandes strates dans le réseau UMTS: Strate d‟accès AS (Access Stratum) et Strate
de non accès NAS (Non Access Stratum).
Figure 1.01 : Découpage en strates du réseau
6
1.2.2.1. Strate d‟accès AS
La strate d‟accès regroupe les fonctions propres au réseau d‟accès, c‟est-à-dire à
l‟UTRAN. Elle comprend les protocoles qui gèrent les services supports. Ces derniers
convoient l‟information entre l‟équipement usager et l‟infrastructure, sachant que cette tâche
est effectuée en deux étapes par le biais des interfaces «Uu» et «Iu». [1][5][6]
1.2.2.2. Strate de non accès NAS
On appelle strate de non-accès un ensemble de protocoles qui permet l‟échange d‟information
entre l‟équipement usager et le réseau cœur indépendamment du réseau d‟accès radio utilisé.
Elle a alors les fonctions comme :
Les fonctions d‟établissement d‟appel, correspondant aux couches de protocole CC
(Call Control) pour les appels circuits et SM (Session Management) pour les appels
paquets ;
Les fonctions de gestion de la mobilité des mobiles en mode veille, correspondant aux
couches de protocole MM (Mobility Management) pour les appels circuits et GMM
(GPRS Mobility Management) pour les appels paquets. [5][6]
1.2.2.3. Les SAP
L‟AS agit en fait comme un fournisseur de service vis-à-vis du NAS. Par exemple,
lors de l‟établissement d‟une communication, l‟AS est chargé, sur demande du NAS, d‟établir
les connexions de signalisation et les canaux de transmission dans le réseau d‟accès, en
fonction du type d‟appel et des attributs de la qualité de services négociés au niveau NAS
entre le mobile et le réseau. [5][6]
Un certain nombre de liens, les SAP (Service Access Point) ont été définis entre les
AS et NAS, dans le terminal et dans le réseau cœur. Ces SAP permettent de classer les
interactions entre le NAS et l‟AS, suivant la nature du service offert ou demandé. Ces points
d‟accès sont :
GC (General Control), utilisé par le NAS pour demander à l‟AS de diffuser un
message d‟informations d‟intérêt général sur l‟interface d‟accès
Nt (Notification), utilisé, par exemple, pour diffuser les messages de paging, ou encore
les notifications d‟établissement d‟appel de groupe.
DC (Dedicated Control), ce SAP est utilisé pour établir ou libérer des connexions de
signalisation et pour échanger des informations sur les connexions. [2][4][5]
7
1.2.3. Notion de RAB
Lors de l‟établissement d‟une communication, le type de services et les
caractéristiques des ressources qui serviront de support à la communication sont négociés
entre l‟usager et le réseau au niveau NAS. Par la suite, l‟AS sera chargé par le NAS d‟établir
le chemin de communication dans le réseau d‟accès. [1][5][6]
La seule vision qu‟a le NAS du canal de communication utilisé est le RAB. Dans l‟AS, le
RAB est décomposé en deux parties :
Le radio bearer, correspondant au segment « interface radio » du RAB
L‟Iu bearer, correspondant au segment « interface Iu» du RAB.
Figure 1.02 : Service support d’accès radio RAB
En raison du principe d‟indépendance des niveaux de l‟UMTS, le NAS ne connaît pas
les caractéristiques précises du RAB, c‟est-à-dire la manière dont il sera mis en œuvre dans
l‟AS. Par exemple, le type de canal radio utilisé, les protocoles employés et leur mode de
fonctionnement ne sont connus que par le réseau d‟accès. Le RAB n‟est en fait caractérisé que
par des attributs négociés entre l‟usager et le réseau cœur. [2][5]
En fonction de la valeur de ces différents attributs, l‟UTRAN doit être en mesure
d‟effectuer les opérations suivantes :
Le choix d‟un codage de canal, c‟est-à-dire de la protection apportée aux données
utilisateur échangées sur l‟interface radio. Ce choix est fait en fonction des différents
taux d‟erreurs requis pour le RAB.
Le dimensionnement des ressources radio associées au RAB. En fonction des
paramètres de débit garanti, débit maximal, classe de service et codage de canal,
l‟UTRAN détermine le débit de la ressource à utiliser sur l‟interface radio.
L‟allocation du radio bearer, de l‟Iu bearer. En cas de congestion du trafic, les attributs
de préemption et de priorité du RAB permettent à l‟UTRAN de préempter une
ressource existante, ou de placer la demande de ressource en file d‟attente. [1][3] [5]
8
1.3 Architecture de l’UMTS
Le diagramme suivant illustre l‟architecture d‟un réseau UMTS.
Figure 1.03 : Architecture d’un réseau UMTS
L‟architecture de l‟UMTS comprend :
- Les terminaux UE (User Equipment) ;
- Les réseaux d‟accès dit UTRAN;
- Le réseau cœur CN (Core Network) ;
Les différents éléments du réseau sont interconnectés à travers des interfaces :
Uu : reliant les terminaux mobiles aux Node B
Iub : reliant les Node B à un RNC (Radio Network Controller)
Iur : reliant deux RNC
Iu-CS : reliant les RNC au réseau cœur, dans le domaine circuit
Iu-PS : reliant les RNC au réseau cœur, dans le domaine paquet [1][2][3][5][6]
1.3.1 Le réseau cœur
Dans les spécifications 3GPP, la version R3 (Release3) de l‟UMTS a défini deux domaines :
- Le CS (Circuit Switched) domain, pour la commutation de circuits ;
9
- Le PS (Packet Switched) domain pour la commutation de paquets.
Ces deux domaines permettent aux équipements usagers de pouvoir gérer
simultanément une communication paquets et circuits. Ces domaines peuvent être considérés
comme des domaines de service. Ce type d‟architecture permet de pouvoir créer
ultérieurement d‟autres domaines de service. [2][4][5]
Par conséquent, les éléments du réseau cœur sont répartis en trois groupes :
- Les éléments du CS domain, tels que le MSC (Mobile Switching Center), le
GMSC (Gateway Mobile-services Switching Center), le VLR (Visitor Location
Register) ;
- Les éléments du PS domain, tels que le GGSN (Gateway GPRS Support Node), le
SGSN (Serving GPRS Support Node);
- Les éléments communs de ces deux domaines, tels que le HLR (Home Location
Register), l‟AuC (Authentication Center), l‟EIR (Equipment Identity Register).
Figure 1.04 : Eléments du réseau cœur
Les différents éléments du réseau cœur UMTS ont les mêmes fonctions qu‟en réseau
cœur GSM.
L‟évolution du réseau cœur de l‟UMTS introduit l‟IMS (Internet protocol Multimedia
Subsystem) dont le but principal est de proposer une architecture réseau unifiée, basée sur les
protocoles de type Internet pour le support de services de communications convergents.
[2][3][5][6]
10
L‟architecture IMS présente un double intérêt pour les opérateurs de réseau :
- Une plateforme unifiée : à terme, l‟IMS est amené à supporter l‟ensemble des
services usager, du domaine PS comme du domaine CS. La gestion du réseau s‟en
trouve simplifier dans la mesure où il n‟existe plus de différenciation entre les
services de ces deux domaines ;
- Le support des services Internet : l‟IMS fournit la possibilité aux opérateurs
cellulaires de créer, ou proposer à leurs abonnés tout un ensemble de services à
valeur ajoutée et de tirer parti de la migration des services vers le monde IP.
Afin d‟assurer la compatibilité avec les services de la téléphonie fixe, l‟architecture
IMS joue également le rôle de passerelle vers le RTCP (Réseau Téléphonique Commuté
Public). [2][5]
1.3.2 Le Réseau d’accès UTRAN
Le réseau d‟accès UTRAN est la partie radio du réseau qui assure l‟interfaçage entre le
réseau cœur et le terminal mobile. Il regroupe alors plusieurs RNC et des Node B.
L‟ensemble constitué d‟un seul RNC et de plusieurs NodeB est nommé RNS (Radio Network
Subsystem). [2]
1.3.2.1. Le Node B
Le Node B correspond à un BTS (Base Transceiver Station) dans le système GSM. Il
contient les fonctions de transmission radio (modulation, démodulation, codage, etc.), il est
responsable de la configuration des cellules radio (gestion des fréquences porteuses, les codes
des cellules, la configuration des canaux, etc.), de la gestion des canaux de transport communs
et dédiés, de la synchronisation, de la gestion de la signalisation de l‟interface Iub ainsi que du
maintien des liens et du partage de la charge.
Un Node B doit être capable de gérer jusqu‟à quatre fréquences porteuses.
Théoriquement, chaque porteuse fournit un débit de 2Mbps par cellule radio. Ils existent
plusieurs types de cellules radio selon l‟environnement.
- Une pico-cellule permet des débits de l‟ordre de 2 Mbps lors d‟un déplacement de
l‟ordre de 10 km/h (marche à pied, déplacement en intérieur, etc.).
- Une micro-cellule permet des débits de l‟ordre de 384 kbps lors d‟un déplacement
de l‟ordre de 120 km/h (véhicule, transports en commun, etc.).
11
- Une macro-cellule permet des débits de l‟ordre de 144 kbps lors d‟un déplacement
de l‟ordre de 500 km/h (Train à Grande Vitesse, etc.).
1.3.2.2 Le RNC
Le rôle principal du RNC est le routage des communications entre le Node B et le
réseau cœur. Lorsqu‟un mobile est en communication, une connexion RRC (Radio Resource
Control) est établie entre le mobile et un RNC de l‟UTRAN. Le RNC en charge de cette
connexion est appelé SRNC (Serving RNC). Lorsque l‟usager se déplace dans le réseau, il
peut être conduit à changer de cellule (handover) en cours de communication, et peut même
se retrouver dans une cellule faisant partie d‟un Node B ne dépendant plus de son SRNC. On
appelle alors controlling RNC le RNC en charge de ces cellules distantes. D‟un point de vue
RRC, le RNC distant est appelé drift RNC. Les données échangées entre le serving RNC et le
mobile transitent par les interfaces Iur et Iub. Le drift RNC joue donc le rôle de simple routeur
vis-à-vis de ces données.
Figure 1.05 : Les Rôles du RNC
Le RNC est le responsable de la gestion et du contrôle des canaux radio
(établissement/ maintien/libération des connexions radio). Il est aussi responsable de la
gestion du handover quand un terminal mobile se déplace d‟une cellule radio à une autre. Il
gère les mécanismes de contrôle de puissance dans les deux directions montante et
descendante.
12
1.4 Interface radio de l’UTRAN
1.4.1 Interface radio
L‟interface radio de l‟UTRAN se trouve entre la station mobile et le Node B.
1.4.1.1 Architecture en couches
Figure 1.06 : Architecture en couche de l’interface radio
Dans un réseau UMTS, l‟architecture en couches de l‟interface radio correspond aux
trois premières couches du modèle OSI.
Le premier niveau représente la couche physique de l‟interface radio. Cette couche
réalise entre autres les fonctions de codage canal, d‟entrelacement et de modulation.
Le deuxième niveau comprend les couches de protocoles MAC (Medium Access Control),
RLC (Radio Link Control), BMC (Broadcast/Multicast Control), PDCP (Packet Data
Convergence Protocol). C‟est le niveau qui assure :
- Le multiplexage de différents flux de données (couche MAC),
- Le transport fiable des données (couche RLC),
- La diffusion de messages sur l‟interface radio (couche BMC),
- L‟indépendance des protocoles radio de l‟UTRAN par rapport aux couches de
transport réseau et le support d‟algorithmes de compression de données (couche
PDCP).
13
Ces différentes couches de protocoles de l‟interface radio sont présentées en détails
dans le chapitre suivant.
Le troisième niveau de l‟interface radio contient la couche RRC qui a la fonction
générale de gérer l‟échange de signalisation établie entre l‟UTRAN et le mobile.
1.4.1.2. Plan de contrôle et plan usager
La norme du réseau 3G, l‟UMTS sépare en deux plans le flux de données qui
transitent sur l‟interface radio :
- Le plan de contrôle
- Le plan usager
Le plan usager regroupe l‟ensemble des données qui sont échangées au niveau de NAS
du réseau. On trouve donc dans le plan usager des datagrammes IP, la voix, les messages
courts ou SMS (Short Message Service) ou encore les informations diffusées par la partie
NAS du réseau.
Le plan de contrôle est quant à lui utiliser pour véhiculer l‟ensemble de la signalisation
entre le mobile et le réseau, au travers le protocole RRC.
On peut distinguer deux sous-ensembles de signalisation dans ce plan de contrôle :
- La signalisation au niveau du NAS qui correspond essentiellement aux couches de
protocoles MM, GMM et SM, assurant les fonctions d‟établissement et de gestion
d‟appel. Elle est véhiculée de manière transparente par la couche RRC.
- La signalisation au niveau de l‟AS échangée entre l‟UTRAN et le terminal. Cette
signalisation correspond par exemple aux fonctions de l‟UTRAN d‟établissement
de connexion RRC ou d‟établissement et de libération de ressources radio.
1.4.2 Les canaux
Les spécifications de l‟UTRAN contiennent une grande variété de canaux de
communication, répartis en trois grandes classes :
Les canaux logiques
Les canaux de transport
Les canaux physiques
Pour mieux garantir l‟indépendance entre les différents niveaux fonctionnels de
l‟interface radio, ces différentes classes de canaux ont été créées. La définition de canaux
14
propres à chaque niveau donne une grande flexibilité à l‟UTRAN en lui permettant de
s‟adapter à la multitude d‟applications envisagées pour les réseaux de 3G.
1.4.2.1. Canaux logiques
Les canaux logiques correspondent aux différents types d‟informations véhiculées par
les protocoles radio de l‟UTRAN.
La notion de canal logique permet de découpler le canal de transmission de
l‟utilisation qui en est faite. Ainsi, on peut imaginer qu‟un type de canal de transmission peut
convenir à deux utilisations différentes, c‟est-à-dire supporter deux types de canaux logiques
différents, ou encore qu‟il est possible de multiplexer deux canaux logiques sur un même
canal de transmission.
Les canaux logiques de l‟UTRAN sont répartis en deux groupes :
- Les canaux logiques de trafic, qui servent à transférer les informations du plan
usager ;
- Les canaux logiques de contrôle, utilisés pour transférer les informations du plan
de contrôle.
Les canaux logiques de l‟UTRAN sont récapitulés dans le tableau 1.01 :
Type Nom Rôle
Trafic
DTCH (Dedicated Traffic CHannel) Transfert de données dédiées à un
utilisateur, bidirectionnel
CTCH (Common Traffic CHannel)
Canal point multipoint pour le transfert de
données à un groupe d‟utilisateurs ; DL
(DownLink) uniquement
Contrôle
BCCH (Broadcast Control CHannel) Diffusion d‟informations de contrôle du
système ; DL uniquement
PCCH (Paging Control CHannel) pour le paging ; DL uniquement
DCCH (Dedicated Control CHannel)
Transfert d‟informations de contrôle
(établissement d‟appel, handovers, etc.)
dédiée à un utilisateur ; bidirectionnel
CCCH (Common Control CHannel)
Transfert d‟informations de contrôle
partagées par les utilisateurs (accès initial,
réponse à l‟accès initial) ; bidirectionnel
Tableau 1.01 : Canaux logiques
15
1.4.2.2 Canaux de transport
En fonction des contraintes de qualité de service liées aux applications supérieures
supportées par les réseaux, il est nécessaire de mettre en œuvre un certain nombre de
mécanismes destinés à fiabiliser les échanges de données, de les protéger sur l‟interface radio.
La notion de canal de transport correspond à ces différents mécanismes.
Par définition, les canaux de transport de l‟UTRAN représentent le format et, plus
généralement, la manière dont les informations sont transmises sur l‟interface radio. Le canal
de transport est donc représentatif de la qualité de service fournie par le réseau sur la partie
RAB, également appelée radio bearer.
Ainsi, à chaque canal de transport, l‟UTRAN associe une liste d‟attributs appelée TFS
(Transport Format Set), destinée à représenter le format et la manière dont les données sont
transmises sur l‟interface radio.
Les différents types de canaux de transport connus dans l‟UTRAN sont récapitulés
dans le tableau 1.02 :
Type Nom Rôle
Dédié DCH (Dedicated CHannel)
Transport des informations de
l‟utilisateur et des informations de
contrôle des couches supérieures
relatives à cet utilisateur
Communs
BCH (Broadcast CHannel) Diffusion d‟informations système
propres à une cellule ; sens descendant
FACH (Forward Access CHannel)
Après une demande d‟accès initial par
le canal RACH, le réseau répond au
mobile dans ce canal ; sens descendant
PCH (Paging CHannel)
Canal permettant au réseau d‟appeler
un mobile dans la zone de localisation
; sens descendant
DSCH ( Downlink Shared Channel)
Canal transportant des données dédiées
à un utilisateur spécifique ; sens
descendant (variante de FACH)
RACH (Random Access CHannel) Canal dans lequel un mobile effectue
en requêtes de demande de connexion ;
16
sens montant
CPCH (Common Packet CHannel)
Canal partagé qui étend les
fonctionnalités du RACH. Les mobiles
peuvent y envoyer des paquets de
données sans nécessairement avoir une
connexion ouverte ; sens montant
Tableau 1.02 : Les canaux de transport
1.4.2.3 Canaux physiques
Le canal physique est l‟association d‟une fréquence porteuse, d‟une paire de codes
(embrouillage et étalement) et d‟une durée temporelle exprimée en multiple de chips.
Il existe plusieurs types de canaux physiques. Le tableau 1.03 résume les différents
types de canaux physiques.
Type Nom Rôle
Dédiés
DPDCH (Dedicated Physical Data
CHannel)
Transport de données dédiées à un
utilisateur; bidirectionnel
DPCCH (Dedicated Physical Control
CHannel) Contrôle le DPDCH; bidirectionnel
Communs
(visibles par
les couches
supérieures)
PRACH (Physical Random Access
CHannel)
Pour accès initial des mobiles dans le
réseau; UL (UpLink) uniquement
PCPCH (Physical Common Packet
CHannel)
Canal partagé montant ; UL
uniquement
PDSCH (Physical Downlink Shared
Channel)
Canal partagé pour les transmissions
descendantes sporadiques ; DL
uniquement
PCCPCH(Primary Common Control
Physical CHannel)
SCCPCH(Secondary Common
Control Physical CHannel)
Diffusion d‟informations système
(primary); paging et réponse des
couches hautes aux accès (secondary);
DL uniquement
Communs
(uniquement
AICH (Acquisition Indicator
CHannel)
Pour une réponse de la couche
physique aux accès initiaux ; DL
17
couche
physique)
uniquement
SCH (Synchronisation CHannel) Permet au mobile de se synchroniser
au réseau ; DL uniquement
CPICH (Common Pilot CHannel)
Permet au mobile de se synchroniser
sur la cellule et d‟estimer sa puissance
reçue (mesure à l‟origine des
handovers) ; DL uniquement
Tableau 1.03 : Canaux physiques
Il est possible qu‟un canal physique supporte différents canaux de transport ou qu‟un
canal de transport soit supporté par deux canaux physiques distincts.
Le CCTrCH (Coded Composite Transport CHannel) est l‟intermédiaire entre le canal
de transport et le canal physique. Ce CCTrCH est le résultat du multiplexage de différents
canaux de transport, il peut ensuite être supporté par un ou plusieurs canaux physiques sur
l‟interface physique.
Figure 1.07 : Canaux physiques et canaux de transports
1.4.2.4. Correspondances entre canaux
La correspondance entre les canaux logiques et les canaux de transport est assurée par
la couche MAC de l‟UTRAN.
La correspondance entre les canaux de transport et les canaux physiques est quant à
elle réalisée par la couche physique de l‟UTRAN. La couche physique ne dispose d‟aucune
flexibilité dans cette correspondance, dans la mesure où chaque canal de transport ne peut être
supporté que par un type de canal physique donné.
18
Figure 1.08 : Correspondances entre les types de canaux
1.4.3. Couches physiques de l’UTRAN
Elles couvrent et regroupent toutes les fonctions de traitement à partir des blocs de
transport jusqu‟au signal radio émis à l‟antenne, à savoir:
Détection et correction d‟erreurs dans les canaux de transport ;
Multiplexage des canaux de transport sur des canaux physiques ;
Etalement et désétalement de spectre des canaux physiques ;
Prélèvement des mesures radio (envoyées aux couches supérieures) ;
Contrôle de puissance ;
Modulation et démodulation Radio Fréquence.
1.5 Conclusion
Après avoir passé en revue le concept de base du réseau UMTS, on a regardé de près
l‟UTRAN, ces interfaces ainsi que les différentes couches existantes.
Nous allons passer au chapitre suivant qui concerne la notion de Qualité de Service et
de la Performance d‟un réseau.
19
CHAPITRE 2
LA QUALITE DE SERVICE ET LA PERFORMANCE D’UN RESEAU MOBILE
2.1 Introduction
La nécessité d‟améliorer le service rendu au niveau des réseaux mobiles s‟est
largement manifestée, dans le secteur privé comme dans le secteur public. La notion de
qualité de service (QoS : Quality Of Service) est un indicateur qui nous est de plus en plus
familier, mais qui la plupart du temps reste flou dans les esprits car le terme service recouvre
des réalités variées. [7]
2.2 Notion de Qualité de Service et de Performance du réseau
Ce terme a une signification spécifique dans le monde des télécommunications. Il se
rapporte à la rentabilité et à la fiabilité d‟un réseau et de ses services. Le domaine actuel de la
QoS est extrêmement vaste puisque les opérateurs et les fournisseurs de service utilisent des
technologies différentes et s‟adressent à une clientèle très variée [8].
Pour limiter ce domaine et pour faciliter la compréhension et la mise en place d‟une
approche simple concernant la QoS, nous nous appuyons sur les principes suivants :
- La qualité de service ne concerne que l‟ensemble des propriétés, des
caractéristiques et des paramètres qui peuvent être choisis, mesurés et comparés à des
valeurs limites.
- L‟évaluation de la qualité de service peut être réduite à quelques
caractéristiques essentielles de qualité. Il n‟est pas nécessaire de définir et mesurer
chaque propriété des dispositifs du service.
- Il est important de définir un ensemble commun d‟outils pour fournir des
résultats comparables non seulement pour faire face à la concurrence, mais aussi pour
fidéliser les utilisateurs finaux [7].
La Qualité de Service (QoS – Quality of Service) d‟un réseau est définie dans la
Recommandation E.800 de l‟UIT-T (Union Internationale des Télécommunications -
Télécommunication) comme l‟effet global produit par la qualité de fonctionnement de ses
services qui détermine le degré de satisfaction de l‟utilisateur de services. [9]. Elle doit être
distinguée de la Performance du Réseau ou NP (Network Performance), qui, toujours selon
E.800, est l‟aptitude d'un réseau ou d'un élément du réseau à assurer les fonctions liées aux
20
communications entre usagers. Du point de vue des opérateurs, la qualité technique du réseau
c‟est-à-dire la performance du réseau est un concept qui traduit la manière dont les
caractéristiques du réseau sont établies, mesurées et contrôlées pour atteindre un niveau
satisfaisant de QoS [10].
Figure 2.01 : Relation entre la QoS et la qualité technique du réseau
Cependant, dans d‟autres documents de l‟UIT-T et d‟autres organisations, le terme
« Qualité de service » se limite à la qualité déterminée par la NP [11]. L‟ETSI (European
Telecommunications Standards Institute), par exemple, définit les «Mesures de la Qualité de
Service » comme les mesures de performance d‟un système de Télécommunications. [12]
2.3 Critères d’évaluation de la NP et de la QoS :
L‟objectif principal de l‟évaluation de la NP et de la QoS dans les réseaux mobiles se
résume à satisfaire les utilisateurs en leur offrant la meilleure QoS possible tout en maintenant
une balance Qualité-Coût équilibrée. Pour pouvoir atteindre la meilleure performance
possible, il faut contrôler, surveiller et améliorer la performance du réseau en permanence.
Les critères qui rentrent dans l'estimation de la qualité d'un réseau peuvent
globalement être classés en deux grandes catégories selon le point de vue adopté : opérateur
ou utilisateur.
Ces critères sont directement en rapport avec les attentes des abonnés et affectent
profondément leur degré de satisfaction [13]. Dans les réseaux mobiles, ces attentes sont
principalement liées à :
Qualité de service
Qualité de fonctionnement du
réseau
Aspects de qualité de
fonctionnement non liés au réseau
21
La disponibilité et d‟accessibilité du réseau (probabilité d'obtention d'un nouvel
appel),
Au maintien des communications (la probabilité de coupure d'une communication),
Une bonne qualité de la communication (puissance du signal, brouillage…).
Du côté utilisateur, les critères les plus courants pour lesquels un utilisateur peut juger la QoS
sont :
- Couverture du réseau (puissance du signal reçu en tout point de la couverture…),
- Etablissement d‟appel (taux de congestion ou taux de blocage…),
- Qualité des communications ou qualité vocale (taux d‟erreurs binaires, microcoupures,
interférences…),
- Interruption de communications ou coupure d‟appel (perte totale de communication en
cours, taux de coupure).
Du point de vue opérateur, il cherche à minimiser ses coûts tout en garantissant une bonne
qualité de services QoS qui est évaluée par les moyens déclarés dans le tableau 2.01.
Indicateurs de performance Mode d’évaluation
Couverture Mesures radio et plaintes des abonnés
Taux d‟appels réussis Mesures système
Qualité de la communication pendant l‟appel Mesures radio, mesure système et analyseurs
de qualité vocale
Taux de coupure d‟appels Mesures système
Tableau 2.01 : Les principaux indicateurs de qualité de service dans les réseaux mobiles
2.4 Mécanismes de supervision de la QoS et de la NP :
La supervision de la QoS et de la NP actuelle combine trois mécanismes [13] [14] [15]:
- Plaintes des abonnés,
- Mesures terrains : mesures Drive Tests, et analyse des fichiers Trace de signalisation
sur les interfaces du réseau (Uu, Iub, Iu…),
- Analyse des Indicateurs clés de performance KPI (Key Performance Indicators) via
l‟OMC.
22
Figure 2 .02: Les mécanismes d’analyse de la NP
2.4.1 Les plaintes des abonnés
Les plaintes des abonnés informent sur le niveau de performance du réseau
directement perçu par les utilisateurs. Cependant, elles sont assez subjectives, vagues, et
souvent trop tardives pour que l‟opérateur puisse réagir.
2.4.2 Les mesures terrains (drive tests) :
Pour les mesures terrains, on mesure la QoS grâce à des sorties terrains et des
simulations en différents scénarios possibles dans lesquels on teste l‟établissement de l‟appel
(absence d‟échec), le maintien de la communication pendant un certain temps seuil (absence
de coupure) et la qualité de la communication, etc…, tout en tenant compte de la mobilité de
l‟usager. Le rapport de mesure ainsi obtenu reflète de façon objective la qualité de service des
prestations des opérateurs. Elles constituent pour cela le meilleur moyen de vérifier les
performances du réseau et de les ajuster aux attentes des abonnés, car elles décrivent l‟état de
la qualité des ressources radio du réseau telle qu‟elle est perçue par les abonnés, ainsi que la
qualité auditive de la communication [13].
Pour réaliser ces mesures, un comité se déplace, dans une voiture, muni d‟une chaîne
de mesure numérique de type drive test qui comporte essentiellement :
- Un mobile (s) à trace
Un mobile à trace dit aussi mobile de test est équipé d‟un logiciel spécial et est utilisé pour les
mesures radio (mesures numériques). A l'aide de l'Hyper Terminal et d'un câble série, il est
possible de taper des commandes qui permettent d'éteindre le mobile ou encore d'appeler
quelqu'un, mais sa véritable utilité réside dans le fait qu‟il peut calculer tous les paramètres
Mesures
Terrain
Analyse des
compteurs OMC
Réclamation des
abonnés
Analyse et
détection du
problème
23
radios (niveau du signal, la qualité du signal…etc.) et les communiquer au PC suites à la
réception de commandes (commandes AT) sur son modem. En général, un mobile à trace
permet de faire tous les scénarios possibles pour chaque région mesurée.
- Un équipement GPS
Un GPS (Global Positioning System) est utile pour la localisation exacte de la position
géographique de chaque point de mesure, notamment pour repérer les points de
l‟environnement où il y a des problèmes radios.
- Un ordinateur portable doté d‟un outil (software) spécial
Permettant l‟acquisition, le traitement et l‟enregistrement des mesures récupérées du mobile à
trace (paramètres radios) et du récepteur GPS (coordonnées géographiques) dans des fichiers
spéciaux. En visualisant sur l‟écran de l‟ordinateur les différentes mesures réalisées, il permet
à l‟ingénieur de constater l‟état du réseau sur place.
Les mesures terrains sont souvent utilisées pour référence, pour vérifier la véracité des
plaintes des utilisateurs et les problèmes et/ou les solutions identifiées par l‟analyse statistique
des indicateurs KPI. Cependant, elles nécessitent de terminaux spécifiques. De plus, elles
n‟assurent pas une supervision permanente de la NP et de la QoS du réseau.
2.4.3 L’Analyse des KPIs via l’OMC
L‟Analyse des Indicateurs clés de performance KPI consiste à faire l‟analyse
statistique des données enregistrées dans les compteurs OMC qui sont implémentés dans les
différents éléments du réseau. Les données enregistrées dans ces compteurs sont accessibles
au sous-système d‟exploitation ou OSS (Operating Sub-System). Ceci permet la supervision
presque à temps réel de la NP. Les compteurs étant situés dans les différents éléments du
réseau, on peut faire une analyse de région spécifique, d‟une partie du réseau ou le réseau tout
entier [14]. En ces termes, l‟analyse statistique des KPI se trouve être le meilleur moyen de
supervision de la QoS d‟un réseau mobile.
Cette analyse requiert cependant de l‟ingénieur une bonne connaissance du réseau, une
compétence analytique, et beaucoup d‟expériences en termes de NP. En outre, quelquefois,
elle identifie les problèmes et non les causes ou les solutions [11] [14][15].
Néanmoins, l‟exploitation de l‟analyse statistique des KPI peut améliorer la QoS de
façon significative. D‟autres parts, c‟est un processus automatisable.
24
Dans ce qui suivra, on va s‟intéresser à ce mécanisme.
2.5 Connaissance du réseau : base de l’analyse des KPIs
Pour pouvoir superviser la performance du réseau par l‟analyse des KPIs, l‟ingénieur
doit connaître en détail le fonctionnement du réseau. Dans notre étude, nous nous sommes
focalisés sur le réseau d‟accès UTRAN.
L‟UMTS, par rapport aux réseaux 2G, offre aux utilisateurs des services très variés
dans la transmission de voix, mais surtout dans la transmission de données. Les applications
sont classées dans quatre catégories. Le paragraphe 2.5.1 décrit en détail ces différentes
classes de service.
Sachant que les compteurs OMC sont incrémentés ou décrémentés à chaque réception
ou transmission de messages protocolaires échangés dans les différentes entités du réseau, il
est important d‟avoir une bonne connaissance sur les protocoles radio et réseau de l‟UTRAN.
Le paragraphe 2.5.2 nous en propose une vue globale.
Du point de vue d‟un opérateur, pour garantir une bonne qualité de service, un réseau
mobile est performant s‟il peut être accessible à tout moment, et qu‟aucune communication
n‟est coupée pour des raisons ne dépendant pas de l‟utilisateur mais de la configuration du
réseau. Dans la supervision de la performance du réseau, il faut donc que l‟ingénieur choisisse
les KPIs qui reflètent la NP et la QoS offerte aux utilisateurs. Ainsi, le paragraphe 2.5.3 classe
les KPIs les plus supervisés par les opérateurs et les plus considérés par les constructeurs en
fonction des principaux critères de performance du point de vue de l‟opérateur.
2.5.1. Classes de services :
La spécification de 3GPP sur la qualité de service propose de classer les applications
suivant quatre catégories :
2.5.1.1 Classe A : Conversationnelle (Conversational)
Les applications de cette classe impliquent deux utilisateurs humains ou plus qui
échangent des informations voix et/ou vidéo en temps réel. Les exigences sur le délai de
transfert sont strictes, ces derniers doivent être suffisamment faibles pour ne pas dégrader la
perception humaine du signal (visuelle et auditive).
25
2.5.1.2 Classe B: Diffusion en flux tendu (Streaming)
Les applications de cette classe impliquent un utilisateur humain et un serveur de
données. Le transfert d‟information se fait depuis le réseau vers l‟utilisateur mobile et la
connexion est à temps réel et asymétrique. La sensibilité au délai est moins stricte pour cette
classe que pour la classe Conversationnelle car il n‟y a pas d‟interactivité entre les deux
entités.
2.5.1.3 Classe C : Interactive (Interactive)
Les applications de cette classe impliquent un utilisateur humain et un serveur de
données ou d‟applications. La connexion est, dans ce cas, basée sur le principe du requête-
transfert. La requête se fait depuis le terminal mobile vers le serveur et le transfert depuis le
serveur vers le terminal mobile. L‟utilisateur attend certes une réponse rapidement mais les
délais restent bien plus importants que pour les classes Conversationnelle et Diffusion. La
priorité est mise sur la fiabilité car les données transférées ne doivent pas être altérées. Il est
donc possible de traiter ces applications comme non temps réel sans dégrader leur qualité de
service
2.5.1.4 Classe D: Tâche de fond (Background)
Les applications de cette classe impliquent un utilisateur, le plus souvent un équipement
terminal, qui envoie ou reçoit des données en tâches de fond. L‟utilisateur à l‟origine de la
requête n‟attend pas de réponse dans une limite de temps fixée. En revanche, l‟intégralité des
données est primordiale. [2][5][6]
2.5.2 Protocoles de l’UTRAN
2.5.2.1 Couches de protocole radio
2.5.2.1.1. Couche RRC
La couche RRC a pour rôle de gérer la signalisation des connexions radio entre le
mobile en mode connecté et l‟UTRAN : établissement, libération, et reconfiguration de la
communication.
Elle est responsable des fonctions du contrôle d‟admission, de la gestion des
ressources radio, du contrôle de puissance et la gestion de mobilité.
26
Une seule connexion RRC est établie pour chaque mobile quel que soit le nombre de
sessions effectivement établies et le mode (PS ou CS). Cette couche interagit avec les couches
RLC et MAC pour déterminer la taille des RLC-PDU (RLC- Protocol Data Unit) au niveau de
la couche RLC ainsi que le nombre de TB (Transport Bloc) qui pourront être envoyés dans un
même TTI (Transmission Time Interval) au niveau de la couche MAC.
Figure 2.03 : Etat de la connexion RRC
Afin de permettre à l‟UTRAN de s‟adapter au mieux à l‟ensemble des classes de
services qui devront être supportées, quatre états différents de la connexion RRC ont été
définis.
L‟état CELL_DCH : c‟est en général l‟état qui sera choisi pour le support des
applications à contrainte temps réel, comme la téléphonie ou la diffusion vidéo. La
mobilité du terminal est contrôlée par le réseau, en fonction des mesures effectuées par
le mobile ou le réseau.
L‟état CELL_PCH : le comportement du mobile dans cet état est en fait assez proche
du mode veille (ou idle). Le mobile se contente en effet de lire les informations
transmises par le réseau sur les canaux BCH et PCH. Le mobile contrôle lui-même sa
mobilité dans le réseau d‟accès au moyen des mêmes mécanismes et critères que ceux
employés en mode veille.
L‟état URA_PCH : cet état est fonctionnellement assez identique au CELL_PCH
précédent.
L‟état CELL_FACH : c‟est en fait un état hybride tenant à la fois des états
CELL_DCH et CELL_PCH. Dans l‟état CELL_FACH, aucun canal physique dédié
n‟est alloué au mobile. Le mobile (ou le réseau) a cependant la possibilité de
27
transmettre des données usager sur le canal de transport RACH (ou FACH pour le
réseau).
2.5.2.1.2. Couche RLC
La couche RLC (Radio Link Control) de l‟UTRAN assure les fonctions du niveau 2,
c‟est-à-dire le transfert fiable des données en provenance du plan usager ou du plan contrôle
sur l‟interface radio.
La couche RLC propose trois modes de fonctionnement : mode transparent, mode non
acquitté, mode acquitté.
Le mode transparent TM (Transparent Mode) : dans ce mode, le RLC n‟effectue aucun
contrôle, aucune détection de RLC-PDU manquante. Le format du paquet RLC-PDU est donc
extrêmement simple, puisqu‟il ne dispose d‟aucun en-tête et qu‟il n‟est composé que de
champ de données.
Cependant, la couche RLC réalise uniquement les opérations de segmentation et
réassemblage des RLC-SDU (RLC- Service Data Unit) venant de le couche RRC.
Le mode non acquitté UM (Unknowledged Mode) offre les mécanismes des
segmentations et réassemblages ainsi que des mécanismes de concaténation de plusieurs
paquets RLC-SDU (paquets reçus par la couche RLC des couches supérieures) dans un seul
RLC-PDU.
Le mode UM assure la détection d‟erreurs et de pertes mais aucun mécanisme de
retransmission n‟est mis en place.
A la différence du mode TM, le mode UM nécessite la présence d‟un en-tête pour lui
assurer les fonctions décrites.
Le mode acquitté AM (Acknowledged Mode) : dans ce mode fonctionnement, la
couche RLC assure les mêmes fonctions du mode UM mais en plus, elle assure les fonctions
de retransmission des paquets perdus ou erronés.
Le récepteur a la possibilité de demander la retransmission de certains RLC-PDU qui
n‟ont pas été correctement reçus. L‟entité réceptrice peut alors demander à l‟émetteur de
retransmettre les PDU manquants au moyen de l‟envoi du PDU de contrôle STATUS.
Son rôle est de fiabiliser les transmissions sur l‟interface radio, tout en réalisant un contrôle de
flux.
28
2.5.2.1.3. Couche MAC
La couche MAC effectue l‟association des canaux logiques (visibles par la couche
RLC) et des canaux de transport offerts par la couche physique. Elle gère les priorités entre
les flux d‟un même utilisateur et entre différents utilisateurs, et collecte de mesures sur le
volume de trafic puis les transmet au RRC.
La fonction de la couche MAC est réalisée au travers des deux sous fonctions suivantes :
Le multiplexage des données sur les canaux de transport ;
Le choix du canal de transport et du format des données transportées.
En raison de la grande flexibilité du fonctionnement de l‟UTRAN, la couche MAC réalise
différents types de multiplexage.
Lorsqu‟un canal de transport commun est utilisé, la couche MAC effectue le
multiplexage des flux de données de différents usagers du canal.
Par ailleurs, la couche MAC peut effectuer le multiplexage des différents canaux
logiques d‟un même usager sur un unique canal de transport dédié de type DCH.
Au niveau de la couche MAC, on définit les notions suivantes :
- TB qui correspond à un MAC-PDU qui encapsule un RLC-PDU. La taille du TB
est un paramètre dynamique.
- TBS (Transport Bloc Set) : c‟est un ensemble de TB transmis par la couche MAC
vers la couche physique dans un intervalle de temps TTI. Le nombre de TB dans
un TBS est un paramètre dynamique qui dépend de la bande passante radio
disponible et des exigences des services supportés.
- TTI : qui représente la durée d‟émission d‟un groupe de blocs de transport. C‟est
un paramètre qui peut avoir des valeurs multiples de 10ms.
Ses valeurs typiques sont 10, 20, 40 et 80 ms.
- TFS : c‟est un ensemble de TF dont chacun définit une taille de TB et une taille de
TBS.
La couche MAC interagit avec la couche RRC qui lui communique la taille d‟un TB,
la taille d‟un TBS et la valeur du TTI, afin de choisir le format de transport des données
effectué sur chaque période TTI.
2.5.2.1.4 Couche PDCP
Dans la spécification de l‟UTRAN, la couche PDCP a pour fonction de comprimer les
en-têtes de protocole TCP/IP.
29
Les paquets de contrôle de la connexion TCP (Transmission Control Protocol) de taille 40
octets sont composés de 20 octets d‟en-tête IP et 20 octets d‟en-tête TCP. Ils ne contiennent
donc aucune information usager.
On voit donc tout l‟intérêt pour le réseau cellulaire d‟un mécanisme qui permettrait de
comprimer efficacement les en-têtes des datagrammes IP transmis sur l‟interface radio.
2.5.2.1.5. Couche BMC
La couche BMC permet de diffuser sur la cellule des informations destinées à
l‟ensemble des utilisateurs ou à un groupe restreint d‟abonnés. On peut être comparée au
service de diffusion SMS du GSM. Cette couche assure également la répétition de
l‟information sur l‟interface radio lorsque l‟on doit être diffusée plusieurs fois.
2.5.2.2 Protocoles réseau de l‟UTRAN
L‟UTRAN ne se limite pas à l‟interface radio. En raison des nombreux nœuds réseau
définis dans l‟UTRAN (Node B et RNC), un ensemble de protocoles et d‟interfaces
appartenant à la partie de l‟UTRAN a été défini par le 3GPP pour permettre à ces différents
nœuds d‟échanger des signalisations et des données usager.
L‟architecture générique des interfaces logiques de l‟UTRAN est représentée dans la
figure 2.03. Afin d‟éviter certain inconvénient, une approche a été abordée pour les interfaces
réseau de l‟UTRAN, garantissant une meilleure évolutivité de la norme UMTS face aux
évolutions des technologies de transport, la structure de la pile protocolaire se divise alors
horizontalement et verticalement en deux couches pour que certaine modification dans la
partie transport de l‟interface n‟a aucun impact sur les couches AP (Application Protocol).
Figure 2.04 : Modèle en couches des interfaces réseau de l’UTRAN
30
2.5.2.1.1 Couche réseau radio RNL
La couche RNL compose la découpe verticale: le plan de contrôle et le plan usager.
Ces deux plans ont leurs propres protocoles.
a- Protocoles de signalisation de la couche RNL
Le plan de contrôle de la couche RNL a les trois protocoles de signalisation suivants:
RANAP (Radio Access Network Application Part), NBAP (Node B Application Part),
RNSAP (Radio Network Subsystem Application Part).
Le protocole RANAP est utilisé pour les échanges de signalisation entre le réseau
cœur et le RNC.
On peut classer les procédures et les messages supportés par le protocole RANAP en deux
catégories :
Les messages destinés à une connexion particulière servent à réaliser les fonctions
suivantes :
- La gestion de RAB, l‟allocation, la libération et la modification des RAB,
- La relocalisation du SRNC,
- Les fonctions de sécurité, la demande de passage en mode chiffré,
- Le transfert de la signalisation des couches supérieures. La signalisation provenant
des couches du NAS, fonctionnellement transparente à l‟UTRAN, transite au
travers du protocole RANAP.
Les messages destinés au RNC permettent d‟assurer les fonctions suivantes :
- La réinitialisation du RNC ou du MSC. Cette fonction est par exemple utilisée en
cas de panne logicielle grave,
- Le paging d‟un mobile (demande d‟appel d‟un mobile en provenance du réseau).
Le protocole NBAP est utilisé pour les échanges de signalisation entre le RNC et le Node B.
Comme le RANAP, il y a deux catégories d‟échanges: ceux destinés à un usager particulier,
identifiés au niveau du protocole NBAP et ceux destinés au Node B.
Les messages de la première catégorie assurent les fonctions suivantes :
- La gestion des liens radio, c‟est-à-dire la création ou la suppression ou encore la
reconfiguration d‟un lien,
31
- La gestion des mesures radio sur les canaux dédiés, c‟est-à-dire la configuration
des mesures effectuées par le Node B pour un mobile particulier et la remontée de
ces mesures du Node B vers le RNC,
- Le contrôle de puissance qui permet au RNC d‟ajuster le niveau de puissance du
Node B sur les canaux descendants.
Les messages de la seconde catégorie permettent d‟assurer les fonctions suivantes :
- La gestion des canaux de transport communs de la ou des cellules du Node B,
- La configuration de la ou des cellules supportées par le Node B,
- La configuration des informations système diffusées par les cellules du Node B,
- La gestion des mesures radio sur les canaux communs de la cellule.
Le protocole RNSAP est utilisé pour les échanges de signalisation entre deux RNC de
l‟UTRAN. Par conséquent, il comprend l‟ensemble des fonctions du protocole NBAP
associées aux liens en mode dédié:
La gestion des liens radio,
La gestion de mesures radio sur les canaux dédiés,
Le contrôle de puissance.
Les fonctions relatives au Node B (configuration ou gestion des canaux communs)
n‟ont plus lieu d‟être dans le protocole RNSAP, car elles sont assurées par le RNC contrôlant
directement le Node B (le controlling RNC) au travers de l‟interface Iub.
b- Protocoles Frame Protocol
Les protocoles applicatifs du plan usager du RNL sont appelés FP (Frame Protocol).
Ces protocoles sont plus simples que les protocoles réseau du plan de contrôle, car leur
fonction principale se limite au transport des paquets de données du plan usager. Les
protocoles FP se situent dans le Node B et les RNC pour les transferts des données sur les
interfaces Iu, Iub et Iur.
2.5.2.2.2. Couche réseau de transport TNL
La technique de transmission ATM (Asynchronous Transfer Mode) est employée dans
la plupart des interfaces réseau de l‟UTRAN. D‟une manière très simplifiée, l‟ATM est une
technique de transmission mixte qui combine à la fois les avantages de la commutation en
mode circuit (permettant d‟offrir un débit et un délai de transmission garantis) et ceux de la
commutation en mode paquet (la possibilité de gains statistiques liés au multiplexage de
différents usagers ayant des profils de trafic différents).
32
En règle générale, les échanges de signalisations des plans de contrôle utilisent un
transport ATM/AAL5 sur l‟ensemble des interfaces de l‟UTRAN (Iu, Iub et Iur).
Les données du plan usager sont quant à elles transportées par l‟ATM/AAL5 s‟il s‟agit de
données liées au domaine PS et par l‟ATM/AAL2 s‟il s‟agit de données liées au domaine CS.
La couche ALCAP (Access Link Control Application Protocol) est utilisée par la couche de
transport pour établir les chemins de transmission du plan usager. Lorsque le plan usager
utilise un transport de type ATM/AAL5, les circuits virtuels sont préétablis. Dans ce cas, la
couche ALCAP et le plan de contrôle du réseau de transport sont inexistants. Mais si le plan
usager emploie un transport ATM/AAL2, les circuits virtuels sont établis au travers de
l‟ALCAP, qui est dans ce cas le protocole de signalisation AAL2.
2.5.3 Catégories des KPI
Une bonne qualité de service nécessite de choisir les KPI qui reflètent le plus l‟objectif
de l‟opérateur en termes de performance de réseau. Les KPI les plus souvent considérés par
les constructeurs et supervisés en permanence par les opérateurs sont catégorisées dans le
tableau 3.01 [9] [20] [21]
Catégories
KPI
Domaine Circuit (CS) Domaine Paquet ( PS)
Accessibilité RAB Establishment Success Rate
CS
RAB Establishment. Success Rate
PS
RRC Connection Establishment Success Rate
Call Setup Success Rate
Continuabilité Connection Drop Rate CS Connection Drop Rate PS
Call Drop Rate CS Call Drop Rate PS
Mobilité Outgoing Hard Handover success rate
Outgoing Inter System Handover
success rate CS
Outgoing Inter System Handover
success rate PS
Soft Handover Success Rate
33
Capacité Throughput Measurements CS Throughput Measurements PS
Tableau 2.02 : Catégories de KPI de l’UTRAN
L‟accessibilité est définie comme étant l‟aptitude du réseau à offrir une ressource à un
utilisateur après une demande (accessibilité de connexion, accessibilité de service, et
accessibilité de service). Elle dépend de la performance de propagation (propagation
performance), de la capacité d‟écoulement du trafic (trafficability performance), et de la
disponibilité du réseau (availability performance). [9]
La continuabilité est définie comme l‟aptitude d‟un réseau à maintenir une connexion
ou une ressource après qu‟elle ait été établie (continuabilité d‟un service, continuabilité d‟une
connexion établie). Elle dépend de la performance de propagation (propagation performance),
de la capacité d‟écoulement du trafic (tafficability performance), et de la disponibilité du
réseau (availability performance) et de la fiabilité (reliability performance). [9]
La mobilité est définie comme l‟aptitude du réseau à gérer le déplacement d‟un
utilisateur dans tout le réseau sans qu‟il y ait une rupture de connexion. Elle dépend
principalement de la performance d‟handover (handover performance). [9] [26]
La capacité est définie comme l‟aptitude d‟un réseau à servir un certain nombre
d‟utilisateurs et de services correspondants. Les débits mesurés sur une entité du réseau
(throughput measurements) permettent de déterminer le trafic à écouler sur ladite entité. [20]
La supervision permanente de ces KPI permet d‟améliorer efficacement la QoS du
réseau.
Le Call Setup Success Rate et le Handover Success Rate permettent d‟évaluer l‟impact de la
congestion pendant les deux plus grandes procédures de tentatives des appels, en regardant du
point de vue de l„utilisateur. [14]
Les taux de coupure (Drop Rate) permettent d‟évaluer le taux de maintien des
communications.
Finalement, le RAB Establishment Success Rate et le RRC Connection Establishment
Success Rate permettent de comprendre où exactement les congestions apparaissent causant
ainsi un taux de succès d‟établissement d‟appel (Call Setup Success Rate) très bas. [14] [20]
[26].
34
2.6 Conclusion
Dans ce chapitre, on a défini la notion de Qualité de Service et de Performance d‟un
réseau mobile. Ensuite, on a détaillé les critères d‟évaluation de la performance et de la
Qualité de Service. Puis, on a décrit les différents mécanismes de supervision de la QoS et de
la NP. Dans la dernière section, on s‟est concentrée sur les connaissances fondamentales que
doit avoir l‟ingénieur pour pouvoir superviser la performance d‟un réseau, notamment le
réseau d‟accès, par les KPIs, qui est le principal objectif de notre étude.
Ainsi, le chapitre suivant va détailler l‟analyse des indicateurs clés de performance.
35
CHAPITRE 3
GESTION DE LA QoS DU RESEAU PAR L’ANALYSE DES INDICATEURS CLES
DE PERFORMANCE (KPI)
3.1 Introduction
Dans ce chapitre, nous allons nous focaliser sur l‟un des mécanismes de gestion de la
qualité de service d‟un réseau. Le but de toute activité de la Gestion de la Performance est de
rassembler des données qui peuvent être utilisées pour vérifier la configuration physique et
logique du réseau et localiser des problèmes potentiels le plus tôt possible.
3.1 L'organisation des données statistiques à analyser
Les données concernant la performance du réseau sont rassemblées dans les éléments
du réseau (équipements du réseau qui peuvent contenir des compteurs OMC) et
habituellement envoyées dans une base de données. Cette base de données est subdivisée en
« types d'objet » qui correspondent aux différents équipements ou blocs du système. Chaque
« type d‟objet » contient plusieurs compteurs d‟évènements [16] [17].
A la fin de chaque période granulaire les éléments du réseau téléchargent les données
enregistrées dans les différents compteurs vers la base de données statistiques de l‟OMC. Ces
données sont encore de données brutes, ou « Raw data » [15] [17].
Des spécifications plus détaillées concernant les méthodes de collecte, de stockage, de
transfert des données de mesures et le format des fichiers des données sont décrites dans les
spécifications techniques du 3GPP TS 32.401 et TS 32.404.
3.1.1 Période granulaire
La période granulaire est définie par le TS 52.402 du 3GPP comme le laps de temps
qui s‟écoule entre deux commencements consécutifs de collecte de données. En effet, à la fin
de chaque période granulaire, les différents compteurs envoient les données enregistrées à la
base de données de l‟OMC. Les valeurs normalisées de cette période sont de 5 minutes, 15
minutes, 30 minutes ou 1 heure. La période granulaire minimum est de 5 minutes dans la
plupart des cas, mais pour quelques mesures, elle peut être juste le temps de nécessaire pour
rassembler des données utiles. La période granulaire sera synchronisée sur une heure pleine
[16].
36
3.1.2 Période d’observation :
Il est important de définir les délais d‟observation pendant lesquels les données seront
assemblées et développées puis analysées, c'est-à-dire que les données enregistrées à la fin de
chaque période granulaire ne sont analysées qu‟à la fin de la période d‟observation. Les
périodes d‟observation sont donc des multiples de la période granulaire, synchronisées à des
heures pleines. On peut choisir parmi les périodes d‟observation suivantes:
Les heures: Les statistiques de toutes les heures donnent une image détaillée de
performance du réseau. Elles sont utiles pour identifier les tendances du réseau et
résoudre les problèmes temporaires.
L‟Heure de pointe ou PH (Peak Hour): Les statistiques à cette heure sont les plus
significatives parce qu'elles correspondent au moment où le réseau est le plus
chargé, donc c‟est le cas le plus défavorable qui sera étudié. Dans le chapitre
suivant, c‟est cette période d‟observation qui sera choisie.
Les Jours: Les statistiques journalières sont utiles pour évaluer les variations des
mesures pendant une journée. Elles sont bonnes pour faire l‟objet de référence.
Online: Les statistiques « online » permettent la surveillance presque à temps réel
du réseau. Les statistiques peuvent être obtenues directement aux nœuds du réseau
où les compteurs fournissent les données à chaque fin de période granulaire. [16]
[17]
3.1.3 Niveaux d’observation :
L'analyse statistique du réseau peut être faite à différents niveaux :
- Le réseau entier: permet d‟avoir une vue globale de la performance du réseau.
- Par région géographique: permet l‟analyse de toutes les cellules qui appartiennent à
une région géographique donnée.
- Par ville: permet l‟analyse de toutes les cellules appartenant à une ville.
- Par RNC: permet l‟analyse de toutes les cellules qui appartiennent à un RNC.
- Par Node B : permet l‟analyse de toutes les cellules qui appartiennent à un Node B
37
- Par Cellule: permet l‟analyse de performance de chaque cellule [15] [18]
3.1.4 Les compteurs OMC
Ces compteurs sont gérés par l‟OMC : activation, stockage, reporting etc…Ils sont
déclenchés par des évènements. Un évènement décrémente ou incrémente la valeur d‟un
compteur. En effet, c‟est par le comptage de message « pertinents » que les compteurs OMC
sur les interfaces Iub/Iu/Uu, font leurs mises à jour [16] [19] [20] [21].
Dans le but de superviser la NP, les constructeurs ont implémenté des logiciels ou des
applications spécifiques appelés « Performance Management » qui sont intégrés avec l‟OMC
et traduisent les données brutes des compteurs OMC en informations lisibles et facile à
comprendre [18] [19].
Chaque constructeur a ces propres compteurs et son propre « Performance
Management » ce qui rend difficile la comparaison entre équipements provenant de différents
constructeurs.
3 1.5 Les indicateurs clés de performance
Généralement, les KPIs sont des indicateurs mesurables d‟aide décisionnelle dont le
but est de représenter un aperçu d'évolution des facteurs clés de succès des processus de
l'entreprise afin d'évaluer sa performance globale en fonction des objectifs à atteindre [20]
[21] [22].
Pour les réseaux PLMN (Public Land Mobile Network), les KPIs peuvent être
considérés comme un outil de mesure de la performance. Les opérations de maintenance
journalière et les planifications d‟un réseau PLMN exigent des données sur quoi baser des
décisions [13]. Mais les données enregistrées par les compteurs OMC sont sous forme de
données brutes qui ne représentent aucunes informations utiles avant qu‟elles ne soient
interprétées en utilisant des formules KPI. Un KPI peut être calculée à partir d‟un ou plusieurs
compteurs [17] [20].
Il est plus facile de comprendre ce qu'un KPI représente plutôt que ce que représentent
les compteurs avec lesquels le KPI est calculé. En revanche, quelques informations sont
toujours perdues parce qu‟une valeur de KPI contient les informations de plusieurs compteurs
[8].
38
3.2 L’analyse des KPI de la Co-OP relatifs à l’UTRAN d’un réseau UMTS
Dans un réseau où le matériel provient de différents constructeurs, c'est important de
savoir que les données du résultat de la mesure produites par le matériel d'un fournisseur est
équivalent aux données du résultat de la mesure qui sont produites par le matériel équivalent
d'un autre fournisseur. C'est particulièrement important quand il faut analyser les données à
travers le réseau entier.
Jusqu‟à présent, les KPI n‟ont pas encore fait l‟objet de standardisation à travers les
constructeurs d‟équipement. C‟est pourquoi c‟est encore très difficile pour les Opérateurs
utilisant des équipements de constructeurs différents de pouvoir calculer facilement les
principaux KPI.
Typiquement, les opérateurs et les constructeurs ont combiné de façon subjective
quelques-uns des indicateurs clés pour calculer les KPI. Les principaux KPIs tels que le taux
de succès des Handovers (Handovers Success Rate), le taux de coupure d‟appels ou CallDR
(Call Drop Rate), le taux de succès d‟établissements d‟appels ou CSSR (Call Setup Success
Rate) doivent être continuellement contrôlés et surveillés pour pouvoir améliorer la
performance du réseau.
Les mesures de performance utilisées pour calculer les KPI sont rassemblées par des
compteurs partout dans le réseau et l‟organisme de standardisation 3GPP a défini des
centaines de compteurs standardisés dans les spécifications 52.402 et 32.403. La liste de ces
compteurs est fournie en annexe.
Le rapport technique 32.814 version 7.0.0 du 3GPP en Mars 2007, détaille un projet
qui a pour but de créer des KPI pour l‟UTRAN et le GERAN d‟un réseau en utilisant les
compteurs standardisés dans les spécifications 52.402 et 32.403 du 3GPP. Ce projet est le fruit
de la coopération de 8 grands constructeurs à travers le monde : Alcatel-Lucent, Ericsson,
Huawei, Motorola, NEC, Nokia Siemens Networks, Nortel, Samsung. Ces constructeurs se
sont regroupés sous le nom de CO-OP. [20]
Ainsi, les calculs des KPI qui suivent ne seront pas soumis au problème
d‟hétérogénéité des équipements (énoncé plus haut) si les équipements du réseau proviennent
de ces 8 constructeurs.
39
3.2.1 Définitions des compteurs OMC :
Dans cette section, nous n‟allons pas définir tous les compteurs standardisés par le
3GPP, mais juste ceux nécessaires aux calculs des Co-OP KPI pour l‟UTRAN d‟un réseau
UMTS [17] [20]
3.2.1.1 Notation :
Pour ce qui suit, on adopte les notations suivantes pour décrire les différents compteurs.
Description:
- Une explication courte de la mesure.
Méthode de collection:
- La forme dans laquelle ces données sont obtenues:
- Compteur Cumulatif ;
- Jauge (variable dynamique), utilisée quand les données mesurées peuvent
augmenter ou diminuer pendant la période granulaire;
- Enregistrement d‟évènement discret (DER - Discret Event Registration), quand
les données en rapport avec un événement particulier sont capturées et seul le n-
ième événement est enregistré, où n peut être 1 ou plus;
- Inspection d‟état SI (Status Inspection).
Condition:
- La condition pour que les compteurs soient mises à jours. Si ce n'est pas possible de
donner une condition précise, alors ce sont les circonstances qui mènent aux mises à
jour qui sont mentionnées.
(Tous les éléments du réseau se communiquent par le biais des signalisations. Ce
sont les messages qu‟ils s‟envoient qui renseignent sur l‟opération effectuée à un
moment donné.)
Nom abrégé:
- Le Nom abrégé du compteur pour pouvoir faciliter son identification.
40
Résultat de la mesure (valeur mesurée, Unité):
- Une description courte de la valeur enregistrée par le compteur (par exemple. un
nombre entier).
3.2.1.2 Définition des compteurs
a. Tentatives d’établissement de RAB dans le domaine circuit (ou paquet) (Attempted
RAB establishments for CS (or PS) domain)
Définition 3.01 :
Ce compteur fournit le nombre de requêtes d‟établissement de RAB dans le domaine
circuit (ou paquet), il représente la somme des sous-compteurs qui fournissent le nombre de
tentatives d‟établissement de RAB par classe de service : Conversationnelle, diffusion en flux
tendu ou Streaming, Interactive et tâche de fond (Background).
Méthode de collection : Compteur cumulatif
Condition : Réception du RNC de message de "RANAP DEMANDE
d‟ASSIGNATION de RAB" dans le domaine circuit (ou paquet) pour les différentes
classes de service (cf 3GPP TS 25.413 et TS 23.107). L‟incrémentation est effectuée
sous la condition que le RAB n‟ait pas été établi avec succès ou modifié
précédemment lors d‟une demande d‟assignation, ou une demande de relocalisation.
Nom abrégé :
Domaine circuit :
RAB.AttEstabCS.Conv. ; RAB.AttEstabCS.Strm ; RAB.AttEstabCS.Intact ;
RAB.AttEstabCS.Bgrd
Domaine paquet :
RAB.AttEstabPS.Conv. ; RAB.AttEstabPS.Strm ; RAB.AttEstabPS.Intact ;
RAB.AttEstabPS.Bgrd
Résultats de la mesure : Un nombre entier.
41
b. Nombre de procédures d’établissement de RAB réussies sans attente dans le domaine
circuit (ou paquet) (Successful RAB establishments without queuing for CS (or PS)
domain)
Définition 3.02:
Ce compteur fournit le nombre de procédures d‟établissement de RAB réussies sans
qu‟une procédure de file d‟attente n‟ait été effectuée, dans le domaine circuit (ou paquet).
Méthode de collection : Compteur cumulatif
Condition : Réception du RNC de message de "RANAP REPONSE
d‟ASSIGNATION de RAB" dans le domaine circuit pour les différentes classes de
service (cf 3GPP TS 25.413 et TS 23.107). L‟incrémentation est effectuée sous la
condition que le RAB n‟ait pas été établi avec succès avec attente ou modifié
précédemment lors d‟une réponse d‟assignation, ou une demande de relocalisation.
Nom abrégé :
Domaine circuit :
RAB.SuccEstabCSNoQueuing.Conv ; RAB.SuccEstabCSNoQueuing.Strm ;
RAB.SuccEstabCSNoQueuing. Intact ; RAB.SuccEstabCSNoQueuing.Bgrd.
Domaine paquet :
RAB.SuccEstabPSNoQueuing.Conv ; RAB.SuccEstabPSNoQueuing.Strm ;
RAB.SuccEstabPSNoQueuing. Intact ; RAB.SuccEstabPSNoQueuing.Bgrd.
Résultats de la mesure : Un nombre entier.
c. Nombre de procédures d’établissement de RAB réussies avec attente dans le domaine
circuit (ou paquet) (Successful RAB establishments with queuing for CS domain)
Définition 3.03:
Ce compteur fournit le nombre de procédures d‟établissement de RAB réussies avec
une procédure de file d‟attente dans le domaine circuit (ou paquet).
Méthode de collection : Compteur cumulatif.
Condition : Réception du RNC de message de "RANAP REPONSE
d‟ASSIGNATION de RAB" dans le domaine circuit pour les différentes classes de
service (cf 3GPP TS 25.413 et TS 23.107). L‟incrémentation est effectuée sous la
42
condition que le RAB n‟ait pas été établi avec succès sans attente ou modifié
précédemment lors d‟une réponse d‟assignation, ou une demande de relocalisation.
Nom abrégé :
Domaine circuit :
RAB.SuccEstabCSQueuing.Conv ; RAB.SuccEstabCSQueuing.Strm ;
RAB.SuccEstabCSQueuing. Intact ; RAB.SuccEstabCSQueuing.Bgrd.
Domaine paquet :
RAB.SuccEstabPSQueuing.Conv ; RAB.SuccEstabPSQueuing.Strm ;
RAB.SuccEstabPSQueuing. Intact ; RAB.SuccEstabPSQueuing.Bgrd.
Résultat de la mesure : Un nombre entier.
d. Tentatives d’établissement de connexion RRC (Attempted RRC connection
establishments)
Définition 3.04
Ce compteur fournit le nombre de tentatives d‟établissement de connexion RRC pour
chaque cause et pour les différentes classes de service.
Méthode de collection : Compteur cumulatif.
Condition : Réception du message "DEMANDE de CONNEXION RRC" provenant
de l‟équipement utilisateur pour chaque cause et pour les différentes classes de service
(cf 3GPP TS 25.331).
Nom abrégé :
RRC.AttConnEstab.OriginatingConversationalCall;
RRC.AttConnEstab.OriginatingStreamingCall;
RRC.AttConnEstab.OriginatingInteractiveCall;
RRC.AttConnEstab.OriginatingBackgroundCall;
RRC.AttConnEstab.TerminatingConversationalCall;
RRC.AttConnEstab.TerminatingStreamingCall;
RRC.AttConnEstab.TerminatingInteractiveCall;
Résultat de la mesure : Un nombre entier.
43
e. Nombre de procédures d’établissement de connexion RRC réussies (Successful RRC
connection establishments)
Définition 3.05
Ce compteur fournit le nombre de procédures d‟établissement de connexion RRC
réussies pour chaque cause et pour les différentes classes de service.
Méthode de collection : Compteur cumulatif.
Condition : Réception du message "CONNEXION RRC ETABLIE" provenant de
l‟équipement utilisateur pour chaque cause et pour les différentes classes de service (cf
3GPP TS 25.331).
Nom abrégé :
RRC.SuccConnEstab.OriginatingConversationalCall;
RRC.SuccConnEstab.OriginatingStreamingCall;
RRC.SuccConnEstab.OriginatingInteractiveCall;
RRC.SuccConnEstab.OriginatingBackgroundCall;
RRC.SuccConnEstab.TerminatingConversationalCall;
RRC.SuccConnEstab.TerminatingStreamingCall;
RRC.SuccConnEstab.TerminatingInteractiveCall;
RRC.SuccConnEstab.TerminatingBackgroundCall;
Résultat de la mesure : Un nombre entier.
f. Tentatives de demande de libération de connexion Iu par l’UTRAN dans le domaine
circuit (ou paquet) (Attempted Iu connection release request by UTRAN for CS (or PS)
domain)
Définition 3.06 :
Ce compteur fournit le nombre de tentatives de demande de l‟UTRAN de libérer une
connexion Iu entre le RNC et un réseau cœur (CS CN, ou PS CN).
Méthode de collection : Compteur cumulatif.
Condition : Transmission de message "RANAP DEMANDE DE LIBERATION IU"
par le RNC au CS CN (ou PS CN) pour des libérations anormales. (cf 3GPP TS
25.413).
44
Nom abrégé :
IU.AttConnRelReqUTRANCS. (domaine circuit) ;
IU.AttConnRelReqUTRANPS. (domaine paquet) ;
Résultat de la mesure : Un nombre entier.
g. Tentatives de libération de connexion Iu par le CN dans le domaine circuit (ou dans le
domaine paquet) (Attempted Iu connection release by CN for CS domain (or PS
domain)
Définition 3.07 :
Ce compteur fournit le nombre de tentatives de libération de connexion Iu par le CS
CN (ou PS CN) entre le RNC et le CS CN (ou PS CN).
Méthode de collection : Compteur cumulatif.
Condition : Réception par le RNC d‟un message “RANAP COMMANDE DE
LIBERATION DE CONNEXION IU” provenant du CS CN (ou PS CN).
Nom abrégé :
IU.AttConnRelCNCS (domaine circuit)
IU.AttConnRelCNPS (domaine paquet).
Résultat de la mesure : Un nombre entier.
h. Nombre de demandes de libération de RAB par l’UTRAN dans le domaine circuit (ou
dans le domaine paquet) (RAB release requests by UTRAN for CS domain (or PS
domain))
Définition 3.08 :
Ce compteur fournit le nombre de RAB que l‟UTRAN a demandé à être libérés dans
le domaine circuit (ou dans le domaine paquet).
Méthode de collection : Compteur cumulatif.
Condition : Transmission par le RNC d‟un message "RANAP DEMANDE DE
LIBERATION DE RAB" dans le domaine circuit (ou dans le domaine paquet).
Résultat de la mesure : Un nombre entier.
45
i. Le nombre de RAB correspondant aux demandes de libération de connexion Iu (The
number of RAB related to the Iu release request for CS domain)
Définition 3.09 :
Ce compteur fournit le nombre de RAB correspondant aux demandes de libération de
connexion Iu.
Méthode de collection : Compteur Cumulatif.
Condition : Transmission par le RNC du message “RANAP DEMANDE DE
LIBERATION DE CONNEXION IU” dans le domaine circuit (ou paquet) vers le CS
CN (ou PS CN).
Nom abrégé : RAB.RelReqCS.
Résultat de la mesure : Un nombre entier.
j. Nombre de procédures d’addition de lien radio au lien actif établies avec succès (côté
équipement utilisateur) (Successful radio link additions to active link set (UE side))
Définition 3.10 :
Ce compteur fournit le nombre de liens radio ajoutés avec succès pendant la procédure
de mise à jour du lien radio actif (côté utilisateur) pour chaque cellule.
Méthode de collection : Compteur Cumulatif.
Condition : Réception du message "ACTIVE SET UPDATE COMPLETE" (RRC)
envoyé par le terminal vers le SRNC en réponse au message “ACTIVE SET
UPDATE”.
Nom abrégé : SHO.SuccRLAddUESide.
Résultat de la mesure : Un nombre entier.
k. Tentatives d’ajout de liens radio au lien actif (côté terminal) (Attempted radio link
additions to active link set (UE side))
Définition 3.11 :
Ce compteur fournit le nombre de tentatives d‟ajout de liens radio pendant la
procédure de mise à jour du lien radio actif (côté utilisateur) pour chaque cellule.
Méthode de collection : Compteur Cumulatif.
46
Condition : Transmission par le SRNC du message “ACTIVE SET UPDATE” (RRC)
au terminal mobile.
Nom abrégé : SHO.AttRLAddUESide.
Résultat de la mesure : Un nombre entier.
l. Tentatives de hard handovers sortants intra-Node B (Attempted outgoing intra-Node B
hard handovers)
Définition 3.12 :
Ce compteur fournit le nombre de tentatives de hard handovers sortant intra-Node B.
Méthode de collection : Compteur Cumulatif.
Condition : Transmission d‟un message RRC “RECONFIGURATION DE CANAL
PHYSIQUE‟‟, „‟RADIO BEARER SETUP‟‟, „‟RECONFIGURATION DE RADIO
BEARER‟‟, „‟LIBERATION DE RADIO BEARER‟‟, ou ‟‟RECONFIGURATION
DE CANAL DE TRANSPORT‟‟ par le RNC source vers le terminal mobile indiquant
la tentative de hard handover sortant intra- Node B.
Nom abrégé : HHO.AttOutIntraNodeB.
Résultat de la mesure : Un nombre entier.
m. Nombre de hard handovers sortants intra-Node B réalisés avec succès (Successful
outgoing intra-NodeB hard handovers)
Définition 3.13 :
Ce compteur fournit le nombre de hard handovers sortants intra-Node B réalisés avec
succès.
Méthode de collection : Compteur Cumulatif.
Condition : Réception d‟un message RRC “RECONFIGURATION DE CANAL
PHYSIQUE ACHEVEE‟‟, „‟RADIO BEARER SETUP COMPLETE‟‟,
„‟RECONFIGURATION DE RADIO BEARER ACHEVEE‟‟, „‟LIBERATION DE
RADIO BEARER ACHEVEE‟‟, ou ‟‟RECONFIGURATION DE CANAL DE
TRANSPORT ACHEVEE‟‟ par le RNC source provenant du terminal mobile
indiquant un succès de hard handover sortant intra- Node B.
Nom abrégé : HHO.SuccOutIntraNodeB
Résultat de la mesure : Un nombre entier.
47
n. Tentatives de hard handovers sortants inter-Node B, intra-RNC (Attempted outgoing
inter-NodeB, intra-RNC hard handovers)
Définition 3.14 :
Ce compteur fournit le nombre de tentatives de hard handovers sortants inter-Node B,
intra-RNC.
Méthode de collection : Compteur Cumulatif.
Condition : Transmission d‟un message RRC “RECONFIGURATION DE CANAL
PHYSIQUE‟‟, „‟RADIO BEARER SETUP‟‟, „‟RECONFIGURATION DE RADIO
BEARER‟‟, „‟LIBERATION DE RADIO BEARER‟‟, ou ‟‟RECONFIGURATION
DE CANAL DE TRANSPORT‟‟ par le RNC source vers le terminal mobile indiquant
la tentative de hard handover sortant inter-Node B, intra-RNC.
Nom abrégé : HHO.AttOutInterNodeBIntraRNC.
Résultat de la mesure : Un nombre entier.
o. Nombre de hard handovers sortants inter-Node B intra-RNC réalisés avec succès
(Successful outgoing inter-Node B, intra-RNC hard handovers)
Définition 3.15 :
Ce compteur fournit le nombre de hard handovers sortants inter-Node B, intra-RNC
réalisés avec succès.
Méthode de collection : Compteur Cumulatif.
Condition : Réception d‟un message RRC “RECONFIGURATION DE CANAL
PHYSIQUE ACHEVEE‟‟, „‟RADIO BEARER SETUP COMPLETE‟‟,
„‟RECONFIGURATION DE RADIO BEARER ACHEVEE‟‟, „‟LIBERATION DE
RADIO BEARER ACHEVEE‟‟, ou ‟‟RECONFIGURATION DE CANAL DE
TRANSPORT ACHEVEE‟‟ par le RNC source provenant du terminal mobile
indiquant un succès de hard handover sortant inter- Node B, intra-RNC.
Nom abrégé : HHO.SuccOutInterNodeBIntraRNC.
Résultat de la mesure : Un nombre entier.
48
p. Tentatives de hard handovers sortants inter-RNC via Iur (Attempted outgoing inter-
RNC hard handovers via Iur)
Définition 3.16 :
Ce compteur fournit le nombre de tentatives de hard handovers sortants inter-RNC via Iur.
Méthode de collection : Compteur Cumulatif.
Condition : Transmission d‟un message RRC “RECONFIGURATION DE CANAL
PHYSIQUE‟‟, „‟RADIO BEARER SETUP‟‟, „‟RECONFIGURATION DE RADIO
BEARER‟‟, „‟LIBERATION DE RADIO BEARER‟‟, ou ‟‟RECONFIGURATION
DE CANAL DE TRANSPORT‟‟ par le RNC source vers le terminal mobile indiquant
la tentative de hard handover sortant inter-RNC via Iur.
Nom abrégé : HHO.AttOutInterRNCIur
Résultat de la mesure : Un nombre entier.
q. Nombre de hard handovers sortants inter-RNC réalisés avec succès via Iur (Successful
outgoing inter-RNC hard handovers via Iur)
Définition 3.17 :
Ce compteur fournit le nombre de hard handovers sortants inter-RNC réalisés avec
succès via Iur.
Méthode de collection : Compteur Cumulatif.
Condition : Réception d‟un message RRC “RECONFIGURATION DE CANAL
PHYSIQUE ACHEVEE‟‟, „‟RADIO BEARER SETUP COMPLETE‟‟,
„‟RECONFIGURATION DE RADIO BEARER ACHEVEE‟‟, „‟LIBERATION DE
RADIO BEARER ACHEVEE‟‟, ou ‟‟RECONFIGURATION DE CANAL DE
TRANSPORT ACHEVEE‟‟ par le RNC source provenant du terminal mobile
indiquant un succès de hard handover sortant inter-RNC via Iur.
Nom abrégé : HHO.SuccOutInterRNCIur.
Résultat de la mesure : Un nombre entier.
49
r. Tentatives de hard handovers sortants inter-RNC commutés dans le CN (Attempted
outgoing inter-RNC hard handovers switching in the CN)
Définition 3.18 :
Ce compteur fournit le nombre de tentatives de hard handovers sortants inter-RNC
commutés dans le CN.
Méthode de collection : Compteur Cumulatif.
Condition : Transmission d‟un message RRC “RECONFIGURATION DE CANAL
PHYSIQUE‟‟, „‟RADIO BEARER SETUP‟‟, „‟RECONFIGURATION DE RADIO
BEARER‟‟, „‟LIBERATION DE RADIO BEARER‟‟, ou ‟‟RECONFIGURATION
DE CANAL DE TRANSPORT‟‟ par le RNC source vers le terminal mobile indiquant
la tentative de hard handover sortant inter-RNC commuté vers le CN (cf. 3GPP TS
25.331).
Nom abrégé : HHO.AttOutInterRNCCN.
Résultat de la mesure : Un nombre entier.
s. Nombre de hard handovers sortants inter-RNC réalisés avec succès commutés vers le
CN correspondant à l’UE (Successful outgoing inter-RNC hard handovers switching in
the CN related to UE)
Définition 3.19 :
Ce compteur fournit le nombre de hard handovers sortants inter-RNC réalisés avec
succès commutés dans le CN.
Méthode de collection : Compteur Cumulatif.
Condition : Réception d‟un message RRC “RECONFIGURATION DE CANAL
PHYSIQUE ACHEVEE‟‟, „‟RADIO BEARER SETUP COMPLETE‟‟,
„‟RECONFIGURATION DE RADIO BEARER ACHEVEE‟‟, „‟LIBERATION
DE RADIO BEARER ACHEVEE‟‟, ou ‟‟RECONFIGURATION DE CANAL DE
TRANSPORT ACHEVEE‟‟ par le RNC source provenant du terminal mobile
indiquant un succès de hard handover sortant inter-RNC commuté dans le CN.
Nom abrégé : HHO.SuccOutInterRNCCN.
Résultat de la mesure : Un nombre entier.
50
t. Tentatives de préparation de relocalisation pour les inter-RAT handovers sortants dans
le domaine circuit (Attempted relocation preparation for outgoing circuit switched
inter-RAT handovers)
Définition 3.20 :
Ce compteur fournit le nombre de tentatives de préparation de relocalisation pour les
inter-RAT handovers sortants dans le domaine circuit.
Méthode de collection : Compteur Cumulatif.
Condition : Transmission d‟un message „‟RANAP RELOCATION RECQUIRED‟‟
par le SRNC vers le CN indiquant une tentative de préparation de relocalisation pour
un inter-RAT handover sortant (cf. 3GPP TS 25.331).
Nom abrégé : IRATHO.AttRelocPrepOutCS
Résultat de la mesure : Un nombre entier.
u. Nombre d’inter-RAT handovers sortants réussis dans le domaine circuit (Successful
outgoing circuit switched inter-RAT handovers)
Définition 3.21 :
Ce compteur fournit le Nombre d‟inter-RAT handovers sortants réussis dans le
domaine circuit.
Méthode de collection : Compteur Cumulatif.
Condition : Réception d‟un message „‟RANAP COMMANDE DE LIBERATION
DE CONNEXION IU‟‟ par le SRNC provenant du CN indiquant un inter-RAT
handover sortant réussi (cf. 3GPP TS 25.331).
Nom abrégé : IRATHO.SuccOutCS.
Résultat de la mesure : Un nombre entier.
v. Tentatives d’inter-RAT handovers sortant contrôlés par l’UTRAN dans le domaine
paquet (Attempted outgoing packet switched inter-RAT handovers, UTRAN controlled)
Définition 3.22 :
Ce compteur fournit le nombre de tentatives d‟inter-RAT handovers sortants contrôlés
par l‟UTRAN dans le domaine paquet.
Méthode de collection : Compteur Cumulatif.
51
Condition : Transmission d‟un message RRC „‟ CELL CHANGE ORDER FROM
UTRAN‟‟ par le SRNC vers l‟UE indiquant une tentative d‟inter-RAT handover
sortant dans le domaine paquet (cf. 3GPP TS 25.331).
Nom abrégé : IRATHO.AttOutPSUTRAN
Résultat de la mesure : Un nombre entier.
w. Nombre d’inter-RAT handovers sortant contrôlés par l’UTRAN réussis dans le
domaine paquet (Successful outgoing packet switched inter-RAT handovers, UTRAN
controlled)
Définition 3.23 :
Ce compteur fournit le nombre d‟inter-RAT handovers sortants contrôlés par
l‟UTRAN dans le domaine paquet réussis.
Méthode de collection : Compteur Cumulatif.
Condition : Réception d‟un message „‟RANAP COMMANDE DE LIBERATION DE
CONNEXION IU‟‟ envoyé par PS CN vers le RNC source, indiquant un inter-RAT
handover sortant réussi dans le domaine paquet (cf. 3GPP TS 25.331).
Nom abrégé : IRATHO.SuccOutPSUTRAN
Résultat de la mesure : Un nombre entier.
x. Débit de données utilisateur (User Data Throughput)
Définition 3.24 :
Ce compteur fournit le débit de données par utilisateur en octets par seconde sur les
interfaces Iu/Iub, au sens montant ou descendant, dans le domaine circuit ou paquet. Il
compte le nombre d‟octets de données qui passent par l‟interface et le divise par le nombre
d‟utilisateur du secteur.
Aucune standardisation n‟a été effectuée pour ce compteur. (cf. 3GPP TS 32.814)
Méthode de collection : Compteur Cumulatif.
Condition : Réception/Transmission de données en octets.
Nom abrégé :
Domaine circuit :
Iub.UserThroughput.UlCS; Iub.UserThroughput.DlCS;
IuCS.UserThroughput.Ul; IuCS.UserThroughput.Dl;
Domaine paquet :
52
Iub.UserThroughput.UlPS; Iub.UserThroughput.DlPS;
IuPS.UserThroughput.Ul; IuPS.UserThroughput.Dl;
Résultat de la mesure : Un nombre entier.
3.2.2 Définitions des Indicateurs Clés de Performance UMTS : Co – OP KPI relatifs à
l’UTRAN
3.2.2.1 Notations :
Pour ce qui suit, on adopte les notations suivantes pour décrire les différents KPI de ce
paragraphe. [20] [26]
a. Abréviation
b. Description:
-Une explication courte de la mesure.
c. Formule:
d. Unité:
.-Unité de la valeur du KPI calculée.
e. Type:
Le type de KPIs auquel il appartient. Il existe en existe 3 types:
-Type PROPORTION : Ce type de KPI renvoie un pourcentage d‟un cas
spécifique d'un événement par rapport à tous les cas.
-Type MOYENNE : Ce type de KPI renvoie une valeur moyenne des mesures
basées sur plusieurs échantillons.
-Type CUMULATIF : Ce type de KPI renvoie une mesure cumulative qui
augmente toujours.
f. Seuil :
- Valeur seuil du KPI. Il faut noter qu‟aucune standardisation n‟a été
explicitement spécifiée mais la valeur seuil d‟un KPI dépend principalement de l‟objectif du
fournisseur de service. Dans la présente littérature, les valeurs seuil ont été considérées en
53
tenant compte les recommandations de Nokia Siemens Network et de Huawei Technology
[24] [27]
3.2.2.2 Définitions des KPI relatifs à l‟UTRAN spécifiés par la Co-OP
Le paragraphe suivant donne une définition de chaque KPI associée à une formule qui
indique comment le KPI est calculé à partir d‟indicateurs fournis par les compteurs énoncés
précédemment [20] [22] [24] [26]
a. Taux d’établissements réussis de RAB (RAB establishment success rate)
Abréviations :
RabEstabSR.CS (domaine CS)
RabEstabSR.PS (domaine PS)
RabEstabSR
Définition 3.25 :
Ce KPI décrit la proportion d‟établissements de RAB réussis par rapport au nombre total de
tentatives d‟établissement.
Formule
100].[.
].[.
].[.
.
type
type
typeAttEstabCSRAB
typeSQueuingSuccEstabCRAB
typeSNoQueuingSuccEstabCRAB
CSRabEstabSR
(3.01)
100].[.
].[.
].[.
.
type
type
typeAttEstabPSRAB
typeSQueuingSuccEstabPRAB
typeSNoQueuingSuccEstabPRAB
PSRabEstabSR
(3.02)
100].[.].[.
].[.
].[.
].[.
].[.
type
type
typeAttEstabPSRABtypeAttEstabCSRAB
typeSQueuingSuccEstabPRAB
typeSNoQueuingSuccEstabPRAB
typeSQueuingSuccEstabCRAB
typeSNoQueuingSuccEstabCRAB
RabEstabSR
(3.03)
type = Є {Conv, Strm, Intact, Bgrd}
54
Unité : Pour cent
Type : PROPORTION
Seuil :> 95 %
b. Taux de succès d’établissement de connexion RRC (RRC connection establishment
success rate)
Abréviations :
RrcEstabSR
Définition 3.26 :
Ce KPI décrit la proportion de succès d‟établissements de connexion RRC par rapport au
nombre total de tentatives d‟établissement.
Formule
100*].[.
].[.
cause
cause
causeabAttConnEstRRC
causetabSuccConnEsRRC
RrcEstabSR
(3.04)
causes: - Originating[type]
- Terminating[type]
type = Є {Conv, Strm, Intact, Bgrd}
Unité : Pour cent
Type : PROPORTION
Seuil :> 96 %
c. Taux de succès d’établissement d’appels (Call Setup Success Rate)
Abréviations :
CSSR
55
Définition 3.27 :
Ce KPI décrit la proportion de succès d‟établissements d‟appels basé sur le taux de succès
d‟établissement de connexion RRC et le taux de succès d‟établissement de RAB
Formule
].[.
].[.*
causeabAttConnEstRRC
causetabSuccConnEsRRCRabEstabSRCSSR
(3.05)
causes: - Originating[type]
- Terminating[type]
type = Є {Conv, Strm, Intact, Bgrd}
Unité : Pour cent
Type : PROPORTION
Seuil :> 97 %
d. Taux de libérations anormales de connexion Iu initiées par l’UTRAN (Iu Connection
Drop Rate)
Abréviations :
IuConnDR.CS
IuConnDR.PS
IuConnDR
Définition 3.27 :
Ce KPI décrit la proportion de libérations anormales de connexion Iu initiée par l‟UTRAN par
rapport au nombre total de libération Iu initiée par le CN.
Formule
100*.
.
RelCNCSIU.AttConn
NCSRelReqUTRAIU.AttConnCSIuConnDR
(3.06)
56
100*.
..
RelCNPSIU.AttConn
NPSRelReqUTRAIU.AttConnPSIuConnDR
(3.07)
100*
.
.
.
.
RelCNPSIU.AttConn
RelCNCSIU.AttConn
NPSRelReqUTRAIU.AttConn
NCSRelReqUTRAIU.AttConn
IuConnDR
(3.08)
Unité : Pour cent
Type : PROPORTION
Seuil :< 3 %
e. Taux de coupures d’appel (Call Drop Rate)
Abréviations :
CallDR.CS
CallDR.PS
CallDR
Définition 3.28 :
Ce KPI décrit la proportion de demande de libération de RAB par rapport au nombre
d‟établissement de RAB réussi (par domaine CS/PS). Les coupures sont dérivées des
messages envoyés par l‟UTRAN vers le CN
Formule
100*
].[.
].[.
ReRe.ReRe..
type typeSQueuingSuccEstabCRAB
typeSNoQueuingSuccEstabCRAB
qCSlNbrIuRABqCSlRABCSCallDR
(3.09)
100*
].[.
].[.
ReRe.ReRe..
type typeSQueuingSuccEstabPRAB
typeSNoQueuingSuccEstabPRAB
qPSlNbrIuRABqPSlRABPSCallDR
(3.10)
57
100*
].[.
].[.
].[.
].[.
ReRe.ReRe.
ReRe.ReRe.
type
typeSQueuingSuccEstabPRAB
typeSNoQueuingSuccEstabPRAB
typeSQueuingSuccEstabCRAB
typeSNoQueuingSuccEstabCRAB
qPSlNbrIuRABqPSlRAB
qCSlNbrIuRABqCSlRAB
CallDR
(3.11)
Unité : Pour cent
Type : PROPORTION
Seuil :< 2 %
f. Taux de Soft handovers réussis (Soft Handover Success Rate)
Abréviations :
RLAddSR
Définition 3.29 :
Ce KPI décrit la proportion de Soft handovers réussis par rapport au nombre de tentatives.
Formule
100*.
.
SideAttRLAddUESHO
ESideSuccRLAddUSHORLAddSR
(3.12)
Unité : Pour cent
Type : PROPORTION
Seuil :> 90 %
g. Taux de hard handovers sortants réussis (Outgoing Hard Handover success rate)
Abréviations :
HHOSR.IntraNB
HHOSR.IntraRNC
HHOSR.InterRNCviaIur
HHOSR.InterRNCCN
HHOSR
58
Définition 3.30 :
Ce KPI décrit la proportion entre les hard handovers sortants réussis et les tentatives.
Formule
100*.
._
aNodeBAttOutIntrHHO
raNodeBSuccOutIntHHOIntraNBHHOSR
(3.13)
100*.
._
aRNCrNodeBIntrAttOutInteHHO
raRNCerNodeBIntSuccOutIntHHOIntraRNCHHOSR
(3.14)
100*.
._
rRNCIurAttOutInteHHO
erRNCIurSuccOutIntHHOrInterRNCIuHHOSR
(3.15)
100*.
._
rRNCCNAttOutInteHHO
erRNCCNSuccOutIntHHOInterRNCCNHHOSR
(3.16)
100*
.
.
.
.
.
.
.
.
rRNCCNAttOutInteHHO
rRNCIurAttOutInteHHO
aRNCrNodeBIntrAttOutInteHHO
aNodeBAttOutIntrHHO
erRNCCNSuccOutIntHHO
erRNCIurSuccOutIntHHO
raRNCerNodeBIntSuccOutIntHHO
raNodeBSuccOutIntHHO
HHOSR (3.17)
Unité : Pour cent
Type : PROPORTION
Seuil :> 85 %
h. Taux de handovers inter-RAT sortants réussis (Outgoing Inter RAT Handover success
rate)
Abréviations :
IRATHOSR.CS
IRATHOSR.PS
Définition 3.31 :
Ce KPI décrit la proportion entre les handovers sortants entre le 3G et le 2G réussis par
rapport aux tentatives, par domaine (CS/PS).
59
Formule
100*PrRe.
._
epOutCSlocAttIRATHO
SuccOutCSIRATHOCSIRATHOSR
(3.18)
100*.
._
RANAttOutPSUTIRATHO
TRANSuccOutPSUIRATHOPSIRATHOSR
(3.19)
Unité : Pour cent
Type : PROPORTION
Seuil :> 85 %
i. Mesures de débits (Throughput measurements)
Abréviations :
Sur l‟interface Iub :
MeanUserDataULIub.CS
MeanUserDataDLIub.CS
MeanUserDataULIub.PS
MeanUserDataDLIub.PS
Sur l‟interface Iu :
MeanUserDataULIuCS
MeanUserDataDLIuCS
MeanUserDataULIubPS
MeanUserDataDLIubPS
Définition 3.32 :
Ces KPIs décrivent les débits moyens par utilisateur des données qui passent par les interfaces
Iub ou Iu, en sens UL ou DL, et par domaine (CS/PS)
Formule
1000/8*])][.([.. CSULhputUserThrougIubCStaULIubMeanUserDa
(3.20)
1000/8*])][.([.. CSDLhputUserThrougIubCStaDLIubMeanUserDa
(3.21)
1000/8*])][.([.. PSULhputUserThrougIubPStaULIubMeanUserDa (3.22)
60
1000/8*])][.([.. PSDLhputUserThrougIubPStaDLIubMeanUserDa (3.23)
1000/8*]).([. ULhputUserThrougIuCStaULIuCSMeanUserDa (3.24)
1000/8*]).([DLroughputIuCSUserThtaDLIuCSMeanUserDa (3.25)
1000/8*]).([ULroughputIuPSUserThtaULIubPSMeanUserDa (3.26)
1000/8*]).([. DLhputUserThrougIuPStaDLIuPSMeanUserDa (3.27)
Unité : kbps
Type : CUMULATIF
3.3 Conclusion
Dans ce chapitre, on a détaillé le mécanisme de gestion de la QoS et de la NP par
l‟analyse des KPI, à savoir en premier lieu, l‟organisation des données statistiques à analyser ;
et en second lieu, l‟analyse des KPI définis par la Co-OP relatifs à l‟UTRAN d‟un réseau
UMTS dans lequel on a étudié les différents compteurs utilisés et défini les KPI. Dans le
chapitre suivant, nous nous proposerons d‟étudier les principales solutions d‟amélioration de
performance adoptées par les opérateurs.
61
CHAPITRE 4
LES PRINCIPALES SOLUTIONS D’AMELIORATION DE PERFORMANCE
4.1 Introduction
Dans ce chapitre, on introduira le processus d‟amélioration de performance d‟un
réseau mobile. Ensuite, nous entrerons en détail dans les principaux problèmes rencontrés lors
de la supervision de la performance de l‟UTRAN à travers les compteurs OMC, ainsi que les
solutions d‟amélioration de performance correspondante.
4.2 Amélioration de performance d’un réseau mobile
La Qualité de Service n‟est perçue que par l‟utilisateur final. Elle n‟est donc pas facile
a évaluée pour le réseau. La meilleure méthode pour superviser la QoS offerte aux utilisateurs
est par les plaintes des abonnés.
Un utilisateur est satisfait si à n‟importe quel moment n‟importe où dans le réseau, il
peut accéder à un service demandé, qu‟il soit connecté à la première tentative à chaque fois, et
que le service soit maintenu jusqu‟à ce qu‟il décide de le terminer.
En fixant des objectifs bien précis, en choisissant des seuils appropriés pour des indicateurs de
performance, c‟est ainsi que les opérateurs arrivent à satisfaire l‟utilisateur final et ainsi
maintenir une QoS élevée.
C‟est en ces termes que l‟amélioration de performance du réseau joue un très grand
rôle. En effet, pour arriver à satisfaire l‟utilisateur final, il faut que le réseau maintienne un
niveau d‟accessibilité, de maintenabilité et de mobilité élevé. Ces paramètres se reflètent à
partir des valeurs des indicateurs de performance comme le taux d‟établissements d‟appels
(accessibilité), le taux de coupures d‟appels (maintenabilité), le taux de soft handovers
(mobilité) etc…
Ces performances du réseau peuvent être maintenues grâce la supervision permanente de ces
paramètres et à l‟amélioration de performance à chaque problème constaté dans cette
opération d‟évaluation de la NP.
Le processus d‟amélioration de performance se présente généralement comme suit :
- On collectionne les données, à partir des compteurs OMC ou des drives tests ou par la
plainte des abonnés.
- On analyse les données, on concrétise les données reçues souvent par le calcul des
KPIs.
62
- On essaie de trouver, de localiser les problèmes dans le réseau.
- On choisit puis on applique les solutions adéquates à chaque problème : ajustement
des paramètres si nécessaires, réparation d‟équipement voire même remplacement des
anciens ou ajouts de nouveaux équipements.
- Et enfin on revient à la première étape. [24] [28]
Le diagramme ci-dessous résume ce processus d‟amélioration de performance.
Figure 4.01 : Processus d’amélioration de performance
4.3 Principales solutions d’amélioration de la performance de l’UTRAN suite à l’analyse
de compteurs OMC :
4.3.1 Accessibilité
Les KPIs qui reflètent ce problème d‟accessibilité du réseau sont : le taux de succès
d‟établissements d‟appels, d‟établissements de RAB et d‟établissements de connexions RRC.
[20]
Collecte des données
Seuil des KPIs
respectés ?
Calcul des KPIs
Localisation du
problème
Solutions d’amélioration de
performance appliquées
NON
OUI
63
4.3.1.1 Causes
Le faible taux d‟accessibilité s‟explique par plusieurs points :
Etablissement de connexion RRC rejeté (après 7 ré-établissements) ou demande de
connexion RRC sans réponse. Ceux-ci peuvent être dus à une congestion élevée. En
effet, si le réseau est trop chargé, il y a échecs d‟établissement de connexion RRC
parce qu‟il y a congestion de puissances (provenant de chaque terminal mobile) vers le
Node B. Il se peut aussi qu‟il n‟y ait plus assez de ressources dans le Node B ou au
niveau du RNC, voire qu‟il n‟y ait plus de codes disponibles. Rappelons que l‟UMTS
utilise le CDMA, par lequel on attribue un code à un utilisateur.
En plus de ces problèmes de congestion, on peut y ajouter le problème de couverture.
En effet sur des zones où la couverture est très faible, les liens descendants FACH et
RACH peuvent être irrégulièrement accédés entrainant ainsi un taux élevés d‟échecs
d‟allocations de ressources. Suite à cette qualité de couverture assez faible, le Node B
n‟arrive pas à communiquer avec le terminal mobile, par exemple le Node B n‟a pas
entendu le message RRC établissement de connexion achevé envoyé par le terminal
mobile, ou encore le terminal utilisateur n‟arrive pas à recevoir la réponse de la
demande de connexion venant du RNC, lors de l‟établissement de connexion, qui
entrainerait son échec.
Finalement, le problème peut venir d‟un mal fonctionnement d‟un équipement ou d‟un
défaut matériel, que ce soit au niveau du RNC, du Node B, ou du terminal utilisateur.
Echec d‟établissement de RAB : ici encore la congestion et manque de ressource au
niveau du Node B ou du RNC peut en être la cause, ainsi que la faible couverture (par
exemple le terminal mobile n‟arrive pas à recevoir le message de demande
d‟établissement provenant du RNC) et les éventuels défauts matériels. En plus, il se
pourrait que les paramètres de RAB envoyés par le CN soient jugés invalides par le
RNC, ou que la transmission sur l‟interface Iu ait été défaillante, qui entraînerait
l‟échec de l‟établissement.
Enfin, le taux d‟erreurs binaires peut être à l‟origine de l‟échec d‟établissement
d‟appels : les messages envoyés sur le lien ascendant (uplink) comme sur le lien
descendant (downlink) ne sont plus compréhensibles par les éléments du réseau et
interprétés comme invalides. [22] [23] [24] [27]
64
Il faut noter qu‟un appel ne peut être établi que si une connexion RRC et un RAB ne soit
établi avec succès. [25]
4.3.1.2 Solutions d‟amélioration de performance
Parmi les possibles solutions, on peut suggérer les suivantes :
En ce qui concerne la congestion, il faudrait activer l‟algorithme de contrôle de
congestion qui, lorsqu‟il détecte une congestion, il interdira l‟algorithme de contrôle
d‟admission (qui contrôle l‟allocation de ressources) du RRM ou Radio Resource
Management, d‟attribuer des ressources aux nouveaux appels, ou de satisfaire des
demandes de ressources additionnelles pour les appels existants, jusqu‟à ce que la
congestion soit résolue (terminaison d‟appels existants…).
D‟un autre côté, la manque de ressources du fait du chargement trop élevé du site peut
être remédiée en étendant les capacités des équipements (notamment en ajoutant de
nouveaux sites et ainsi de réduire le trafic passant par un Node B). Une autre manière
d‟augmenter la capacité sur l‟interface Iub est de diminuer le paramètre
StandAloneDCCHBitRate qui se trouve au niveau du RNC. Ce paramètre contrôle le
signalling radio bearer type (SRB). En diminuant sa valeur, on diminue la capacité
recquise pour l‟établissement d‟un appel. Cependant, on augmente ainsi le Call Setup
Time, c‟est-à-dire que l‟établissement d‟un appel prendrait plus de temps.
Il faudrait faire des mesures terrains dans ladite cellule pour connaitre la couverture, la
puissance en UL et en DL, le taux d‟erreurs binaires, etc…
Si une zone est effectivement non couverte, on peut procéder à l‟ajustement des
paramètres de l‟antenne pour mieux dominer la zone : down tilting (rabaisser
l‟inclinaison), ajuster l‟azimut (l‟orientation), réduire la hauteur de l‟antenne,
augmenter la puissance émettrice du Node B si nécessaire, etc…
On peut aussi ajouter de nouveau site pour mieux couvrir la zone.
Pour résoudre les problèmes liés aux paramètres invalides envoyés par le CN, il
faudrait regarder de près les messages de RAB setup au niveau du RNC : si les RAB
setup ont des paramètres corrects, le problème se situerait donc au niveau du RNC,
sinon au niveau du CN. Des tests sur l‟interface Iu ne seraient pas un luxe.
65
si le problème se trouve au niveau des équipements (mal fonctionnement ou
défaillance), une équipe de maintenance est nécessaire sur les lieux pour trouver le
problème et le régler en conséquence. [22] [23] [24] [25] [27]
4.3.2 Continuabilité
Les KPIs qui traduisent le faible taux de continuabilité du réseau sont : le taux de coupures
d‟appels et le taux coupures de connexion, lorsqu‟ils sont élevés.
4.3.2.1 Causes
Les coupures en pleine communication peuvent être dues à :
Une Faible couverture en UL ou en DL : les probabilités de coupures sont plus élevées
dans les zones où la couverture est très faible.
„‟Pilot pollution‟‟ : on appelle „pilot‟ le signal émis par les Node Bs distants. Le „‟pilot
pollution‟‟ apparait quand l‟UE détecte plusieurs signaux de même puissance
provenant des autres Node B distants, l‟utilisateur peut percevoir une nette
interférence pendant l‟appel. L‟UE met à jours trop fréquemment son „active set‟ (liste
des cellules qui sont en soft handover avec l‟UE). L‟interférence due au „pilot
pollution‟ peut entraîner une coupure.
„‟Missing neighbor‟‟ : ce phénomène se produit quand une puissance élevée (au-
dessus du seuil d‟handover) provenant d‟un Node B arrive jusqu‟au terminal, mais que
ce Node B ne figure pas dans la liste des cellules voisines (neighbor cells) de la cellule
actuelle.
Aucune ressource disponible : de même que pour les problèmes d‟accessibilité, la
surcharge du réseau peut entraîner une coupure.
Aux échecs d‟handovers : lorsqu‟un handover a échoué, ou s‟est effectué avec délai
significatif, il peut y avoir coupure.
66
Une libération anormale des connexions par l‟UTRAN : souvent la connexion est
interrompue si le RNC constate que la connexion radio avec l‟UE a été interrompue,
ou très détériorée. Le RAB est libéré, néanmoins la connexion RRC avec l‟UE est
toujours active. Cette libération du RAB est considérée comme une coupure de
communication. L‟appel est réinitialisé en ré-établissant le RAB.
Synchronisation perdue : la détérioration du lien radio, couverture faible, ou une faible
puissance du canal de synchronisation entraîne la perte de la synchronisation de l‟UE
avec le Node B, qui provoquera à son tour une coupure de l‟appel ou des connexions.
Il ne faut pas oublier qu‟une défaillance matérielle est aussi à l‟origine d‟une coupure
de communication.
En appel vidéo notamment, la coupure peut être due à une faible puissance en DL.
La coupure élevée dans le domaine paquet s‟explique comme suit : le réseau priorise
les appels circuits par rapport aux appels paquets, ainsi pendant les heures de pointes
(peak hours) ou notamment pour les UE qui sont assez loin du Node B, les appels
circuits sont priorisés entrainant des taux de coupures élevés des appels paquets. [22]
[23] [24] [27]
4.3.2.2 Solutions d‟amélioration de performance
Parmi les possibles solutions, on peut proposer les suivantes :
Pour éviter le phénomène de „pilot pollution‟ il faudrait faire des mesures terrains pour
vraiment savoir quelles sont les cellules qui interfèrent dans la cellule actuelle qui
causent le phénomène. Et on pourrait diminuer la puissance d‟émission des Node Bs
des „pilots‟ indésirables, ou effectuer un down tilting et les paramétrages nécessaires à
leurs antennes pour éviter cette interférence.
Le problème de „missing neighbor‟ peut être résolu comme pour le cas du „pilot
pollution‟. On peut aussi ajouter ladite cellule dans la liste des cellules voisines de la
présente cellule, et de supprimer dans cette liste celles vers lesquelles on a enregistré
peu voire aucun handover, en d‟autres termes, les cellules voisines non nécessaires.
67
Une autre solution aussi est d‟augmenter le seuil d‟handover dans le Node B de la
cellule actuelle. Ainsi, seront éliminés „pilots‟ indésirables, puis l‟« active set » peut
être mis à jour.
Les problèmes liés à la faible couverture, à la surcharge du réseau et aux congestions,
ainsi que ceux liés aux défaillances matérielles ou au mal fonctionnement d‟un ou des
équipements ont traités comme dans la section précédente.
Le problème de synchronisation peut se résoudre en augmentant la puissance du canal
SCH.
Pour pouvoir supporter un appel vidéo, il faut augmenter la puissance en DL. Pour ce
faire, il suffit d‟augmenter le paramètre CPICHtoRefRaBOffset dans le Node B. Ce
paramètre permet de fixer la puissance maximale de transmission en DL. Cependant,
cela pourrait mener à d‟autre problème. En effet, si cette puissance maximale est fixée
très haute, le Node B enverrait trop de puissance aux UE qui se trouvent tout près de
ce Node B, entrainant ainsi des problèmes aux UE (détérioration de l‟appareil…) ou
des coupures d‟appels.
Si l‟éventualité que les appels PS seraient atteints d‟un taux de coupure nettement
élevé par rapport aux appels CS apparaît, on pourra déduire que soit la capacité est
faible pour écouler le trafic, dans ce cas une extension de ressource serait nécessaire ;
soit que les utilisateurs les plus actifs sont situés assez loin du Node B, ce qui
constitue une erreur de planification. Il suffirait d‟installer un nouveau site près de
cette zone.
La solution qui fait l‟objet de recherche actuellement, pour améliorer l‟accessibilité et
la continuabilité dans les réseaux 3G et plus, est la gestion du protocole RRM
notamment l‟algorithme de contrôle d‟admission. Cet algorithme permet de gérer
l‟allocation de ressources radio du réseau. En paramétrant les seuils, on peut
augmenter le taux d‟accessibilité au détriment du taux de blocage, et vice-versa. En
effet, un seuil assez bas permettrait au réseau d‟admettre de nouveaux appels, mais la
congestion qui en suit du fait de la surcharge du réseau provoquerait une coupure
brusque des communications en cours.
68
Les problèmes liés aux handovers seront analysés dans la section suivante. [24] [27]
[29]
4.3.3 Mobilité
Les KPIs qui fournissent ce taux faible de mobilité sont les taux de handovers.
4.3.3.1 Causes :
Les causes de taux faibles de succès d‟handovers sont principalement les suivants :
Aucune ressource disponible dans la cellule cible, ou au niveau du RNC : en effet, si
le mobile se déplace dans une zone assez chargée, la cellule cible ne pourrait lui
allouer des ressources. L‟échec d‟handover est inévitable.
„‟Pilot pollution‟‟ : comme décrit plus haut, ce phénomène peut influencer le taux de
succès d‟handover. La détection du meilleur signal provenant des Node B voisins
devient difficile quand l‟UE détecterait plusieurs Node Bs de puissance supérieure au
seuil d‟handover, alors que l‟« active set » ne devrait lister que 3 Node B au
maximum. Le Node B de destination ne serait plus défini efficacement et entrainerait
l‟échec de l‟handover
„‟Missing neighbor‟‟ : de même, le „‟missing neighbor‟‟ affecterait le taux de succès
de l‟handover. Le Node B dont la puissance est jugé élevée par l‟UE ne figure pas
dans sa liste de cellules voisines. L‟handover échoue.
Faible couverture et détérioration du lien radio : comme dans la coupure d‟appel et
dans l‟échec d‟établissement de connexion, ces 2 facteurs peuvent facilement entraîner
l‟échec d‟un handover.
Paramètres d‟handover incorrect : il se peut rarement que les paramètres d‟handover
envoyés par le RNC vers l‟UE soient incorrects ou non-supportés. Ceci se produit
quand l‟UE passe d‟une cellule 3G à une autre 2G (cas d‟un inter-RAT handover). Il
se pourrait aussi que les informations (mesure de puissances des Node B voisins)
69
envoyée par l‟UE vers le RNC soient jugées par ce dernier comme invalides. Le RNC
annule donc l‟opération de handover.
Seuil d‟handover invalide : un paramètre dans le Node B fixe le seuil d‟handover pour
chaque cellule (puissance minimale des Node B distants pour qu‟un handover soit
initié). Si ce seuil est trop faible, cela pourrait provoquer le phénomène de „‟pilot
pollution‟‟.
Le RNC n‟a pas reçu la confirmation par l‟UE que l‟ancien lien ait été supprimé: en
effet, après que le Node B cible ait attribué un lien à l‟UE, l‟UE devrait supprimer
l‟ancien lien et envoyer au RNC un message qui indique que l‟opération ait été
accomplie avec succès. Si le RNC ne reçoit pas ce message de confirmation au bout
d‟un certain temps défini par les paramètres d‟handover dans le Node B, le handover
échoue.
Pendant un inter-RAT handover, il se peut que 2 cellules voisines du réseau 2G aient
la même BSIC (Base Station Identification Code). En conséquence, le SRNC pourrait
effectuer l‟handover avec la mauvaise station de base. Les paramètres seront invalides,
et l‟handover échouera. [24] [27] [29] [30]
4.3.3.2 Solutions d‟amélioration de performance
Pour y faire face, on peut proposer les solutions suivantes :
Face à l‟indisponibilité des ressources dans le Node B de destination, il faudrait qu‟on
diminue sa charge. La meilleure solution, bien que couteuse, serait d‟installer un
nouveau site.
Les problèmes de couverture, de „‟pilot pollution‟‟, de „‟missing neighbor‟‟, et de
défaillance matérielle seront traités comme précédemment.
Concernant le seuil d‟handover invalide, il faudrait ajuster un paramètre qui est
accessible dans le Node B. Ce paramètre permet à l‟UE de calculer le seuil d‟handover
minimum.
70
Des mesures terrains seront nécessaires pour connaître l‟origine du problème. Mettre à
jour si nécessaire la liste des cellules voisines du Node B, vérifier si une station de
base a la même BSIC qu‟une autre, vérifier si les messages de confirmation sont
perdues sur l‟interface air, ou que c‟est un problème au niveau du RNC… [24] [29]
[30]
4.4 Quelques exemples de modèles d’amélioration de performance d’un réseau mobile
Les KPIs liés à l‟accessibilité et à la continuabilité des communications sont les plus
surveillés par les opérateurs pour la supervision de la performance de leur réseau, et ainsi
d‟assurer une bonne QoS pour les utilisateurs.
Parmi les solutions proposées antérieurement, on peut citer l‟amélioration du taux
d‟accessibilité par l‟ajout de nouveaux serveurs, et celle de la continuabilité par la réduction
de la charge du lien montant.
4.4.1 Amélioration du taux d’établissement d’appels par l’ajout de nouveaux serveurs
Le taux d‟établissement d‟appels d‟un réseau mobile est défini comme étant le rapport
entre le nombre de tentatives d‟établissement de connexion qui ont abouti, et le nombre total
de tentatives : [20]
( )
(4.01)
D‟autre part, il peut aussi être exprimé par :
( ) ( ) (4.02)
Où le taux de blocage BR (Blocking Rate) étant le rapport entre le nombre d‟échecs
d‟établissement d‟appels et le nombre total de tentatives.
La loi d‟Erlang B définit le taux de coupure en fonction du nombre de serveurs et du
trafic (exprimé en Erlang) à écouler.
( )
∑
(4.03)
Où A représente le trafic (en Erlang) généré par l‟ensemble des utilisateurs.
71
N représente le nombre de ressources radio.
BR est le taux de blocage correspondant.
La formule (4.03) peut être prise comme un modèle d‟amélioration du taux d‟accessibilité
d‟un réseau mobile. En effet :
- Pour un trafic à écouler A, et un nombre de ressources radio N1 , on trouve le taux de
blocage BR1 du système.
- Pour le même trafic A, et un nombre de ressources radio N2 , le taux de blocage est de
BR2 .
D‟après l‟expression du taux de blocage BR dans la relation (4.03), on peut écrire les
inégalités suivantes :
Si,
Alors,
∑
∑
Et en remontant à l‟équation (4.02), on peut déduire que :
( ) ( )
D‟où
Où représente le taux de succès d‟établissement d‟appels correspondant à un nombre
de ressources radio pour le même trafic A.
En conclusion, pour un trafic à écouler A, augmenter le nombre de ressources radio N permet
d‟augmenter le taux d‟établissement d‟appels CSSR. [31] [32] [33] [34]
4.4.2 Amélioration du taux de coupure d’appels par la réduction de la charge du lien
montant d’une cellule
Le taux de coupure de communication CallDR est défini comme étant le rapport entre
le nombre de communications anormalement coupées, c‟est-à-dire qui n‟ont pas été coupées à
l‟initiative de l‟utilisateur, et le nombre total de communications établies. [20]
72
( )
(4.04)
Pour satisfaire au mieux l‟utilisateur, on cherche à minimiser ce KPI.
Une autre définition de ce KPI a été trouvée dans un laboratoire (voir [35]) où un site
d‟essai a été configuré en vue de trouver une relation entre la charge du lien montant (uplink
load) sur l‟interface air, et le taux de coupure d‟appels CallDR, pour des différents types de
services (voix et données) à des intervalles de 168 heures pendant 2160 heures. Le résultat est
représenté par la figure 4.02 sous matlab.
Figure 4.02 : Taux de coupure d’appel en fonction de la charge du lien montant
On peut constater que le taux de coupure d‟appels est une fonction affine de la charge du lien
montant, fonction représentée par la relation (4.05) :
( ) ( ) (4.05)
Où représente la charge du lien montant.
73
D‟après les études décrites dans l‟ouvrage [36], l‟expression de la charge du lien
montant est exprimée par la relation (4.06) :
∑
∑
(4.06)
Où représente la puissance reçue en dBm par utilisateur transmettant sur le lien montant
d‟une cellule
: le nombre d‟utilisateurs
: la puissance en dBm de bruit de fond (background noise) sur le lien montant
En supposant que tous les appareils mobiles émettent en moyenne à une puissance de 121mW
(pour l‟UMTS), on peut réécrire la relation (4.06) comme suit :
(4.07)
Où représente la puissance moyenne en dBm d‟émission d‟un appareil mobile.
On peut donc écrire la relation entre le nombre d‟utilisateurs et le taux de coupure d‟appels :
( )
(4.08)
En tenant compte de la relation (4.05) et de la relation (4.07), on peut écrire les
inégalités qui suivent:
Pour une puissance de bruit , si :
Alors :
( ) ( )
74
D‟où :
où : est le taux de coupure d‟appels correspondant à une charge du lien montant
qui correspond elle-même à un nombre d‟utilisateurs .
On peut donc conclure que pour diminuer le taux de coupure d‟appels C , on peut
réduire le nombre d‟utilisateurs dans la cellule. [35] [36] [37]
Pour ce faire, il suffirait de réduire le rayon de la cellule et d‟ajouter d‟autres sites pour
dominer la région en termes de couverture.
4.5 Conclusion
Dans ce chapitre nous venons de voir le processus d‟amélioration de performance des
réseaux mobiles à partir des KPI. Ensuite, nous nous sommes focalisés sur les principales
améliorations de performance adoptées par les opérateurs. Et nous nous proposés d‟étudier
l‟efficacité de quelques exemples de ces solutions d‟améliorations de performance à partir de
modèles.
Pour terminer, entrons dans le chapitre concernant la simulation sous matlab.
75
CHAPITRE 5
SIMULATION SOUS MATLAB DE L’ANALYSE DES KPI RELATIFS A L’UTRAN
DEFINIS PAR LA Co-OP EN VUE D’UNE AMELIORATION
5.1 Introduction
Ce dernier chapitre porte sur la description d‟une simulation sous le logiciel Matlab,
d‟une analyse statistique des KPI décrits dans le chapitre précédent. À partir des formules de
calcul des KPI et des compteurs définis par le rapport technique du 3GPP TR 32.814 vu
précédemment, nous allons essayer de faire l‟analyse statistique de la QoS offerte par
différentes cellules d‟un réseau fictif avec comme outil le logiciel MATLAB. Les exemples
d‟amélioration de performance vus antérieurement seront ensuite appliqués sur des cellules
choisies.
5.2 Description de la simulation
La présente simulation est effectuée sous Matlab Version 7.5.0 (R2007b).
Matlab (Matrix Laboratory) est un logiciel de calcul numérique, de visualisation graphique et
de programmation destiné aux ingénieurs et aux scientifiques, avec un langage simple à
utiliser et où les problèmes et les solutions sont exprimés par des notations mathématiques
familières. Matlab est idéal pour :
- les Mathématiques et Calcul numérique,
- les simulations, création de prototype,
- l‟analyse de données et visualisation,
- les développements d‟application qui inclut des interfaces graphiques.
5.2.1 Paramètres de la simulation
Étant donné que les informations portant sur l‟évaluation de la QoS et de la NP d‟un réseau
PLMN sont directement liées à la survie du réseau, l‟opération ne doit donc se faire qu‟à
l‟intérieur de l‟entreprise, pour pouvoir gérer la concurrence et pour des raisons de sécurité.
Par conséquent, les données du réseau qui concerne la QoS et la NP sont protégées par des
contrats de confidentialité et ne sont accessibles qu‟au personnel de l‟entreprise.
76
Les paramètres de simulation décrits ci-dessous sont donc des données fictives. Néanmoins,
elles sont rationnelles et inspirées de données réelles.
5.2.1.1 Niveau d‟études
Comme défini dans le chapitre précédent, l‟analyse de la QoS et de la NP peut se faire
à différents niveaux, que ce soit une vue d‟ensemble du réseau tout entier, ou pour des régions
déterminées, voire des éléments spécifiques du réseau.
Dans ce qui suit, on se limitera à l‟analyse de la performance au niveau de quelques
cellules d‟un réseau UMTS fictif.
5.2.1.2 Période d‟observation et période granulaire
Pour que les résultats soient les plus significatifs possibles, on a choisi la période
d‟observation comme l‟heure de pointe, c‟est-à-dire le moment de la journée où
habituellement la cellule est la plus chargée. La période granulaire est de 60 minutes.
Typiquement, l‟heure de pointe des cellules prises en considération se situerait entre 17
heures et 20 heures du soir.
5.2.1.3 Description des cellules
Les cellules analysées dans la présente simulation seraient au nombre de 5. Ceci nous
permet d‟observer les cas les plus diversifiés.
Les cellules sont supposées appartenir au même réseau UMTS, au même MSC, mais à des
différents RNC, à l‟exception des cellules n°2 et n°5 qui appartienne au même RNC.
La cellule n°1 couvrirait une petite ville située au périphérique d‟une grande ville ; la
cellule N°2 appartiendrait à une ville moyennement peuplée ; de même que la cellule N°5 ; la
cellule N°3 desservirait une zone commerciale, et enfin la cellule N°4 couvrirait une portion
assez grande d‟une ville très active (trafic élevé).
5.2.1.4 Valeurs des paramètres
Pour la présente simulation, on va considérer l‟hypothèse que les valeurs des
compteurs seraient obtenues à partir des données brutes enregistrées dans la base de données
de l‟OMC.
Les compteurs étant au nombre de 66, et compte tenu du nombre de cellules qui est de
5, les 330 valeurs des compteurs qui ont permis d‟obtenir les résultats de la section suivante
sont résumées dans le tableau 5.01.
77
Compteurs Cell1 Cell2 Cell3 Cell4 Cell5
Etablissement
de RAB
Co
nve
rsat
ion
nel
le
CS Succ Sans attente 42 68 56 145 71
CS Succ Avec attente 5 15 19 46 16
CS Tentatives 48 84 78 221 88
PS Succ Sans attente 15 91 92 71 90
PS Succ Avec attente 4 12 10 35 11
PS Tentatives 24 105 103 113 102
Dif
fusi
on
en f
lux t
endu
CS Succ Sans attente 15 68 52 74 70
CS Succ Avec attente 7 9 25 23 10
CS Tentatives 23 78 77 132 80
PS Succ Sans attente 13 87 85 75 88
PS Succ Avec attente 4 21 26 55 23
PS Tentatives 25 108 111 152 111
Inte
ract
ive
CS Succ Sans attente 13 45 44 56 41
CS Succ Avec attente 7 21 20 45 20
CS Tentatives 21 67 65 102 63
PS Succ Sans attente 19 77 78 68 56
PS Succ Avec attente 6 4 7 45 25
PS Tentatives 31 82 86 143 82
Bac
kgro
und
CS Succ Sans attente 13 42 43 55 51
CS Succ Avec attente 1 12 9 34 8
CS Tentatives 15 55 52 97 61
PS Succ Sans attente 5 66 65 81 56
PS Succ Avec attente 2 15 18 32 31
PS Tentatives 10 83 84 121 88
Etablissement
de connexion
RRC
Co
nve
rsat
ion
nel
l
e
Succ Originating 63 137 153 292 125
Succ Terminating 43 93 148 148 119
Att Originating 64 138 155 354 126
Att Terminating 45 94 152 233 121
Dif
fusi
on
en f
lux
tend
u
Succ Originating 45 133 142 157 105
Succ Terminating 27 75 136 141 102
Att Originating 48 135 144 164 108
78
Etablissement
de connexion
RRC Att Terminating 28 77 139 153 104
Inte
ract
ive
Succ Originating 63 119 109 138 86
Succ Terminating 23 58 97 136 79
Att Originating 65 120 112 244 87
Att Terminating 25 59 99 231 82 B
ackgro
und
Succ Originating 34 90 91 150 60
Succ Terminating 17 46 89 98 47
Att Originating 35 91 93 153 61
Att Terminating 19 47 91 121 48
Libération Iu
CS Demande de l’UTRAN Tentatives 3 4 7 12 10
CS Libération par le CN Tentatives 112 215 231 461 334
PS Demande de l’UTRAN Tentatives 5 3 11 17 6
PS Libération par le CN Tentatives 165 321 339 530 191
Libération
RAB
CS Demande Sans libération Iu 1 3 6 5 2
CS Après libération Iu 1 2 5 7 4
PS Demande Sans libération Iu 1 2 11 9 3
PS Après libération Iu 1 5 4 3 5
Ajout lien
radio (UE)
Succès 35 61 71 65 42
Tentatives 36 63 73 67 51
Hard
Handover
Intra-NodeB Succès 6 10 11 31 23
Tentatives 7 11 12 36 26
Inter-NodeB Succès 3 8 7 32 17
Tentatives 3 9 8 34 21
Inter-RNC via Iur Succès 2 3 1 15 3
Tentatives 2 3 1 16 3
Inter-RNC via CN Succès 1 2 3 17 2
Tentatives 1 2 3 18 2
Inter-RAT
handover
CS Succès 6 17 9 21 15
Tentatives de préparation 7 20 11 23 16
PS Succès UTRAN 12 14 18 36 13
PS Tentatives UTRAN 14 16 21 41 15
Débits Sur Iub CS UL 4590 4861 4653 1249 4026
79
Débits
Sur Iub
CS DL 5191 5456 5182 1354 4153
PS UL 2829 5810 5903 2563 4232
PS DL 6971 21308 19592 4614 18941
Sur Iu
CS UL 4892 4522 4834 4267 5025
CS DL 4923 4642 5324 4528 5158
PS UL 5302 4934 4915 5521 5386
PS DL 19091 18528 19543 18951 18534
Tableau 5.01 : Valeurs des compteurs (Source [38])
Il est important de noter que ces données, bien que fictives, sont inspirées de valeurs
réelles. Leurs ordres de grandeurs sont extraits de données de l‟opération journalière d‟un
réseau existant.
Les valeurs de ces compteurs peuvent être modifiées par un utilisateur, à travers
l‟interface graphique.
5.2.2 Résultats de la simulation
5.2.2.1 Valeurs des KPI calculés :
Ces valeurs sont obtenues à partir des formules du chapitre 3, c‟est-à-dire les formules
3.01 jusqu‟à 3.27.
Avant la visualisation des résultats, les valeurs des KPIs seront affichées dans la
fenêtre de commande du logiciel Matlab.
Elles seront affichées comme suit :
KPI =
Où « KPI » représente le nom abrégé du KPI, et « » la valeur de ce KPI pour la i-ème
cellule.
5.2.2.2 Visualisation :
En appuyant sur le bouton « Visualiser », on pourra voir une à une la projection des
différents KPIs. Une légende s‟affichera automatiquement pour mieux apprécier les
histogrammes.
80
Les éventuels pointillés en rouge représentent le seuil pour un KPI donné. Rappelons
que les seuils considérés dans cet ouvrage sont, faute de standardisation, des
recommandations de Nokia Siemens Network et de Huawei Technology.
Figure 5.01: Taux d’établissements de RAB réussis
81
Figure 5.02: Taux d’établissements de connexions RRC réussies
Figure 5.03: Taux de succès d’établissements d’appels
82
Figure 5.04: Taux de coupures de connexion Iu
Figure 5.05: Taux de coupure d’appels
83
Figure 5.06: Taux de Soft Handovers réussis
Figure 5.07: Taux de succès de hard handovers sortants
84
Figure 5.08: Taux de handovers inter-systèmes réussis
Figure 5.09: Mesures de débits
85
5.3 Analyse et amélioration de performance
Pour l‟exemple qu‟on a pris, voici les analyses des KPI pour chaque cellule et les
solutions proposées en vue d‟une amélioration de performance :
5.3.1 Cellule n°1
5.3.1.1 Analyse des résultats
Capacité :
On peut visualiser sur la figure 5.09 le débit moyen par utilisateur sur les interfaces Iub et Iu.
On peut constater que d‟une manière générale, la cellule n°1 a un débit acceptable par rapport
aux autres cellules. Néanmoins, le débit moyen en UL pour la transmission paquet sur
l‟interface Iub est très bas si on le compare à ceux des autres cellules. De même pour le débit
DL. Sur l‟interface Iu, on voit que le débit est élevé, c‟est-à-dire que les cellules avoisinantes
ont un débit assez. Ce qui nous conduit à déduire que le problème se situe au niveau de la
cellule et non au niveau du RNC, et dans le domaine paquet seulement.
Accessibilité :
La figure 5.03 nous montre que la cellule n°1 souffre d‟un très faible taux
d‟établissement d‟appels : Si on regarde la figure 5.02, on peut facilement déduire que ce
n‟est pas dû aux échecs d‟établissement de connexion RRC. C‟est forcément dû aux taux de
succès d‟établissement de RAB. En effet la figure 5.01 nous montre que le taux
d‟établissement de RAB est très faible. Cependant on peut remarquer que du côté du domaine
circuit, il est au-dessus du seuil. On peut donc conclure que ce faible taux d‟accessibilité
n‟atteint que le domaine paquet.
Continuabilité :
Le taux de coupure de connexion Iu est tolérable d‟après la figure 5.04. Mais le taux
de coupure d‟appels est très élevé. En regardant de près la figure 5.05, on peut constater que
le taux de coupure dans le domaine paquet est très significatif. Ce qui pourrait expliquer ce
taux de coupures nettement au-dessus du seuil fixé. De même que pour l‟accessibilité, on peut
déduire que le taux de coupures élevé n‟est ressenti que dans le domaine paquet.
86
Mobilité :
La cellule n°1 ne souffre d‟aucun problème quand à accomplir des handovers, que ce
soit le soft handover, le hard handover sortant ou l‟inter-système hard handover. Leurs taux
avoisinent les seuils fixés ou les dépassent largement.
5.3.1.2 Amélioration
La cellule offre une QoS très dégradée dans le domaine paquet. Il est très probable que
la cause en est que la plupart des utilisateurs sont situés loin du Node B. Atteindre les
utilisateurs nécessitent beaucoup de ressources, ce qui oblige le réseau à privilégier les appels
circuit par rapport aux appels paquet. En effet, les appels paquets nécessitent peu de
ressources par rapport aux appels paquet.
Ceci constituerait donc une erreur évidente de planification. Le Node B n‟est pas situé
à l‟endroit idéal pour dominer la zone. La meilleure solution, bien qu‟elle soit couteuse serait
d‟installer un nouveau site, sur la zone la plus active. On pourrait néanmoins déplacer le Node
B, mais ceci influencerait la planification des cellules voisines, voire toutes les cellules de la
région.
5.3.2 Cellule n°2
5.3.2.1 Analyse des résultats
Capacité :
Le débit moyen offert aux utilisateurs dans la cellule n°2, que ce soit en UL ou en DL,
dans le domaine paquet ou dans le domaine circuit, est toujours très élevé si on le compare
aux autres cellules. De même que le débit moyen enregistré sur le lien Iu.
Accessibilité
Le taux d‟établissement de connexion RRC est très élevé, nettement au-dessus du
seuil. De même pour le taux d‟établissement de RAB, que ce soit dans le domaine paquet ou
dans le domaine circuit. Il parait évident que le taux de succès d‟établissement d‟appels soit
au-dessus du seuil.
Continuabilité :
Le taux de coupures de connexion Iu est nettement au-dessous du seuil, dans le
domaine circuit comme dans le domaine paquet. De même pour le taux de coupure d‟appels.
87
Mobilité :
Concernant les taux d‟handovers, ils avoisinent les seuils fixés. La cellule ne souffre
d‟aucun problème par rapport à la mobilité des utilisateurs.
5.3.2.2 Amélioration
La QoS offerte aux utilisateurs est très bonne. La cellule ne souffre d‟aucun problème
évident que ce soit au niveau de la capacité, accessibilité, de continuabilité ou de mobilité.
Les utilisateurs peuvent être satisfaits de la qualité de service offert par le réseau. La
performance constatée sur cette cellule peut faire l‟objet de référence pour les autres cellules
voisines, voire même du réseau tout entier, pour les prochaines analyses.
5.3.3 Cellule n°3
5.3.3.1 Analyse des résultats
Capacité
La cellule n°03 offre sur le lien Iub, elle offre un débit acceptable (figure 5.09) : dans
le domaine circuit le débit moyen avoisine les 40 kbps, en UL comme en DL ; et dans le
domaine paquet en UL le débit moyen est légèrement en dessous de 50 kbps, et en DL il est
au-dessus des 150 kbps. Les mêmes débits sont constatés au niveau de l‟interface Iu.
Accessibilité:
Concernant l‟accessibilité, le taux de succès d‟appels de la cellule n°3 avoisine le seuil fixé :
96.9241 % (figure 5.03). Le taux de succès d‟établissement de connexion RRC est de 97.98 %
(figure 5.02) et le taux de succès d‟établissement de RAB est de 98.93 % (figure 5.01).
Continuabilité :
Le taux de coupure de connexion Iu est très élevé par rapport aux autres cellules. Il avoisine le
seuil : 3.03 % (figure 5.04). Et le taux de coupure d‟appels est nettement supérieur au seuil
fixé : 4.0062 % (figure 5.05).
Mobilité :
Le taux d‟Handovers réussis avoisine les seuils fixés. La cellule gère très bien les
différents handovers qui s‟y passent. En effet, le taux de succès de Soft Handovers est de
97.26 % (figure 5.06) et le taux de Hard Handover est de 91.66 % (figure 5.07).
88
5.3.3.2 Amélioration
Le taux de coupures d‟appels du réseau est trop élevé. Cela n‟est pas dû à un problème
de couverture puisque le taux d‟accessibilité au réseau est relativement élevé. Et en aucun cas
ça ne pourrait être à cause d‟échecs d‟handovers d‟après le taux d‟handovers.
Le problème se situerait dans la charge du réseau du fait du nombre relativement élevé
d‟utilisateurs actifs émettant dans la cellule.
La solution la plus adaptée serait de rétrécir la cellule en diminuant son rayon, afin de réduire
la charge du réseau. Cette solution sera vue dans le paragraphe 5.4.1. L‟ajout de nouveaux
sites serait ensuite nécessaire pour dominer la zone.
5.3.4 Cellule n°4
5.3.4.1 Analyse des résultats
Capacité :
Le débit offert aux utilisateurs relativement bas, par rapport aux autres cellules (figure
5.09) : dans le domaine circuit, en UL comme en DL, le débit arrive à peine à 10 kbps. Dans
le domaine paquet, il est de 20 kbps en UL et de 37 kbps en DL. Cependant, le problème est
propre à la cellule parce que le débit sur l‟interface Iu est assez élevé.
Accessibilité :
Le taux d‟établissement d‟appels, est très en-dessous du seuil fixé : 66 % (figure 5.03)
; tout comme le taux de succès d‟établissement de connexion RRC : 76 % (figure 5.02) ; et le
taux d‟établissement de RAB : 86 % (figure 5.01).
Continuabilité :
Les taux de coupures sont relativement élevés, dans le domaine circuit comme dans le
domaine paquet. Effectivement, le taux de coupures de connexion est légèrement en-dessous
du seuil fixé : 2.92 % (figure 5.04). Et le taux de coupures d‟appels est au-dessus du seuil :
2.55 % (figure 5.05).
Mobilité
La mobilité ne présente aucun problème dans cette cellule, il n‟y a aucun problème au
niveau des différents handovers. En effet, le taux de succès de handovers varie entre 86 % et
97 %, ce qui est acceptable (figure 5.06, figure 5.07, figure 5.08).
89
5.3.4.2 Amélioration
Le débit très bas offert à chaque utilisateur nous prouve que le réseau n‟arrive pas à
acheminer correctement les données utilisateurs. Ceci se traduit par le taux de coupure
relativement élevé et surtout par le taux d‟accessibilité très faible. Le manque de ressource est
donc la source du problème.
On pourrait ajouter de nouveaux serveurs pour pouvoir augmenter le nombre de
ressources radios.
Cette solution d‟amélioration de performance sera utilisée dans le paragraphe 5.4.2.
5.3.5 Cellule n°5
5.3.5.1 Analyse des résultats
Capacité :
La capacité de la cellule est acceptable, par rapport aux autres cellules, on ne notifie
pas une grande différence majeure au niveau des débits offerts par utilisateur : les débits dans
le domaine circuit, ainsi que le débit en UL dans le domaine paquet sur les interfaces Iub et Iu
varient entre 30 kbps et 45 kbps ; en DL dans le domaine, il avoisine les 150 kbps (figure
5.09).
Accessibilité :
De même, le taux d‟établissement d‟appels est assez élevé par rapport aux autres
cellules :.96.93 % (figure 5.03). Le taux d‟établissement de RAB est même très élevé :
98.81% (figure 5.01).
Continuabilité :
Le taux de coupure par contre est supérieur au seuil fixé : 2.09 % (figure 5.05) ; de
même que le taux de coupure de connexion : 3.04 % (figure 5.04).
Mobilité :
Le taux d‟handover est très dégradé. En effet, les handovers inter-Node Bs : 80.95 %
(figure 5.07) et les soft handovers : 82.35 % (figure 5.06), sont les plus affectés. Les autres
handovers ont un taux de succès acceptables, variant entre 86 % et 100 % (figure 5.07 et
figure 5.08).
90
5.3.5.2 Amélioration
C‟est un problème de handover. Cela pourrait expliquer le taux de coupure de
communication et de connexion élevés. Comme ce sont les handovers inter-Node B qui sont
les plus affectés, on peut déduire que le problème se situe au niveau des cellules voisines.
Un „‟pilot pollution‟‟ peut être à l‟origine de ce problème, ou un „‟missing neighbor‟‟.
Il faudrait d‟abord faire des mesures terrains pour confirmer l‟analyse.
S‟il s‟avère que le phénomène de „‟pilot pollution‟‟ est à l‟origine du problème, il
faudrait augmenter le seuil d‟handover. Ceci n‟est pourtant pas très recommandé car l‟avis
d‟un expert serait nécessaire pour pouvoir ajuster ce paramètre. On peut cependant diminuer
la puissance des cellules voisines, ou effectuer un down tilting pour que la puissance
d‟émission du Node B voisin reçue par un UE de la cellule n°05 soit réduite pour diminuer les
effets de „‟pilot pollution‟‟.
Concernant le „‟missing neighbor‟‟, la solution la plus adaptée serait de revoir la liste
des cellules voisines du Node B, d‟y ajouter le Node B qui a causé le „‟missing neighbor‟‟ et
de supprimer les cellules qui effectuent peu, voire même qui n‟effectuent aucun handover
avec la cellule en question.
5.4 Solutions d’amélioration de performance proposée pour les cellules n°3 et n°4
Dans cette section nous allons appliquer les solutions d‟amélioration décrites dans le
paragraphe 4.3.2 du chapitre précédent à la cellule n°3 et celle décrite dans le paragraphe
4.3.1 à la cellule n°4.
5.4.1 Réduction de la charge du lien montant de la cellule n°3
En rétrécissant le rayon de la cellule, on arrive à réduire le nombre d‟utilisateurs, et
donc de réduire la charge du lien montant comme on l‟a vu dans le paragraphe 4.3.2 du
chapitre 4.
Dans ce qui suit, nous allons voir l‟influence de la réduction du nombre d‟utilisateurs
émettant dans la cellule n°3 sur le taux de coupure des appels.
91
Figure 5.10 : Nombre d’utilisateurs de la cellule n°3
Si le nombre d‟utilisateurs dans la cellule n°4 est de M1 = 500 utilisateurs, lorsqu‟on le
diminuera à M2 = 100 utilisateurs, le taux de coupure évoluera en conséquence, comme le
montre la figure 5.11.
Figure 5.11 : Evolution du taux de coupure d’appels de la cellule n°3
On peut constater qu‟avant l‟amélioration par la réduction de la charge du lien
montant, le taux de coupure a été largement au-dessus du seuil fixé qui est de 2%: 4.0062 %
92
Après l‟amélioration, le taux de coupure CallDR a été réduit au-dessous du seuil : 1.9382 %
5.4.2 Augmentation du nombre de ressources radio de la cellule n°4
En ajoutant de nouveaux serveurs, on arrive à augmenter le nombre de ressources
radios disponibles, et donc de réduire le taux de blocage comme on l‟a vu dans le paragraphe
4.3.1 du chapitre 4.
Dans ce qui suit, nous nous proposons de voir l‟influence de l‟augmentation du
nombre de ressources radio dans la cellule n°4 sur le taux de succès d‟établissement d‟appels.
Figure 5.12 : Nombre de ressources radio dans la cellule n°4
Si l‟on suppose que N1 = 40 ressources radio écoulent le trafic dans la cellule n°4
avant l‟amélioration, lorsqu‟on l‟augmentera à N2 = 75, le taux de succès d‟établissement
d‟appels évoluera comme le montre la figure 5.13.
93
Figure 5.13 : Evolution du taux de succès d’établissement d’appels dans la cellule n°4
On peut voir qu‟avant l‟amélioration par l‟augmentation du nombre de canaux radios,
le taux de succès d‟établissement d‟appels a été nettement au-dessous du seuil fixé qui est de
97% : 66.2826 %
Après l‟amélioration, le taux CSSR de la cellule a été augmenté au-dessus du seuil :
97.8212%
5.5 Conclusion
Dans ce chapitre, on a décrit la simulation de l‟analyse statistique des indicateurs clés
de performance. Les résultats obtenus ont fait l‟objet d‟une aide à la décision. En effet, après
avoir analysé les résultats, on a pu émettre des solutions d‟amélioration de performance.
Parmi ces solutions, on en a appliquées sur des cellules choisies, et on a pu prouver leur
efficacité.
94
CONCLUSION GENERALE
Avec l‟essor rapide qu‟elle connait, la téléphonie mobile s‟impose de plus en plus
comme le moyen le plus privilégié de communication et conquiert davantage de parts de
marché en ciblant tous les profils de consommateurs. Le nombre d‟utilisateurs qui croit de
façon exponentielle, et les services offerts de plus en plus nombreux et nécessitant des
technologies de plus en plus complexe, il s‟avère donc que la qualité, dans le domaine de la
téléphonie mobile, notamment dans les réseaux de troisième génération qui sont
définitivement plus complexes que les réseaux des générations, constitue une source
importante de différenciation, et le maintien de la qualité des communications s'avère
obligatoire pour faire face à la dégradation de la qualité de service perçue par les utilisateurs
finaux. Le suivi de cette qualité nécessite l‟observation permanente de l‟état de
fonctionnement du réseau et de toutes ses performances. L‟objectif principal de ce travail est
de décrire comment l‟analyse de données recueillies dans les compteurs OMC implémentés
par les différents constructeurs sous forme d‟indicateurs permet de superviser la performance
d‟un réseau UMTS en détectant les problèmes du réseau et en appliquant les configurations
physiques et logiques à différents niveaux, qui constituent les solutions d‟amélioration de
performance du réseau, et ainsi de maintenir une qualité de service satisfaisante à offrir aux
usagers.
Par rapport aux autres méthodes de supervision de la performance du réseau, l‟analyse
des indicateurs de performance via les compteurs OMC permet une supervision presque à
temps réel de la performance du réseau et de la qualité de service à différents niveaux : d‟une
vue d‟ensemble du réseau tout entier aux cellules individuelles. Dans ce travail, on s‟est
concentré sur les études des cellules. A chaque évènement qui survient : tentative d‟appel,
coupure d‟appel, etc…, des messages protocolaires sont transmis ou envoyés entre les entités
du réseau. Ces messages sont comptés par les compteurs appropriés, et permettent ainsi de
base de données pour calculer les différents indicateurs de performance, plus facile à
interpréter que les données brutes recueillies. A leur tour, ces indicateurs constituent une
information importante d‟aide à la décision en vue d‟une amélioration du réseau.
Cependant, la définition de ces compteurs est propre à chaque constructeur. Ainsi, il
est difficile pour un réseau « multi-vendeur » de réellement évaluer la performance du réseau.
Néanmoins, un effort de coopération entre huit grands constructeurs d‟équipements UMTS
dans le monde nous a permis de définir les plus importants indicateurs de performance relatifs
95
au réseau d‟accès de l‟UMTS, de faire une simulation d‟analyse de ces indicateurs et
d‟interpréter les résultats en vue d‟une amélioration de la qualité de service. Elle nécessite par
contre une bonne connaissance du système UMTS et de ses fonctionnalités, de bonnes
compétences analytiques, et beaucoup d‟expérience. D‟autres mécanismes peuvent être mis
en œuvre parallèlement à l‟analyse des indicateurs pour garantir la qualité de service dans le
réseau UMTS, comme les mesures terrains (Drive test) et les plaintes des abonnés. Ces
mécanismes ont leurs avantages et leurs inconvénients. En somme, la combinaison de ces
trois approches pourrait être la plus appropriée.
Ces dernières années, un mécanisme d‟automatisation de supervision et d‟amélioration
de la qualité du réseau ont fait l‟objet de recherche, connus sous le nom d‟optimisation
intelligente ou « Intelligent Optimization ». L‟objectif est de créer un outil capable de
recueillir les données, de calculer les indicateurs de performance, mais surtout de les
interpréter pour détecter les problèmes et de proposer les solutions d‟optimisation
appropriées. Mais jusqu‟à présent, les résultats n‟ont pas encore donnés entière satisfaction
aux opérateurs mobiles.
96
ANNEXES
ANNEXE 1
LISTE DES COMPTEURS RELATIFS A L’UTRAN SPECIFIES PAR LE 3GPP TS
32.403
A1.1. Compteurs relatifs à la gestion du RAB
4.1.1.1 RAB establishment for CS domain
- Attempted RAB establishments for CS domain
- Successful RAB establishments without queuing for CS domain
- Failed RAB establishments without queuing for CS domain
- Successful RAB establishments with queuing for CS domain
- Failed RAB establishments with queuing for CS domain
4.1.1.2 RAB establishmentfor PS domain
- Attempted RAB establishments for PS domain
- Successful RAB establishments without queuing for PS domain
- Failed RAB establishments without queuing for PS domain
- Successful RAB establishments with queuing for PS domain
- Failed RAB establishments with queuing for PS domain
4.1.1.3 RAB modification for CS domain
- Attempted RAB modifications for CS domain
- Successful RAB modifications without queuing for CS domain
- Failed RAB modifications without queuing for CS domain
- Successful RAB modifications with queuing for CS domain
- Failed RAB modifications with queuing for CS domain
97
4.1.1.4 RAB modification for PS domain
- Attempted RAB modifications for PS domain
- Successful RAB modifications without queuing for PS domain
- Failed RAB modifications without queuing for PS domain
- Successful RAB modifications with queuing for PS domain
- Failed RAB modifications with queuing for PS domain
4.1.1.5 RAB release request by CN for CS domain
- Attempted RAB releases for CS domain
- Successful RAB releases without queuing for CS domain
- Failed RAB releases without queuing for CS domain
- Successful RAB releases with queuing for CS domain
- Failed RAB releases with queuing for CS domain
4.1.1.7 RAB release request by CN for PS domain
- Attempted RAB releases for PS domain
- Successful RAB releases without queuing for PS domain
- Failed RAB releases without queuing for PS domain
- Successful RAB releases with queuing for PS domain
- Failed RAB releases with queuing for PS domain
A.1.1.8 RAB setup time
- RAB CS connection set-up time (Mean)
- RAB CS connection set-up time (Maximum)
- RAB PS connection set-up time (Mean)
- RAB PS connection set-up time (Maximum)
98
A.1.1.9 RAB release request by UTRAN
- RAB release requests for CS domain
- RAB release requests for PS domain
A.1.2 Compteurs relatifs aux signalisations d‟établissements de connexion
- Attempted signalling connection establishments for CS domain
- Attempted signalling connection establishments for PS domain
A.1.3 Compteurs relatifs à l‟établissement de connexion RRC
A.1.3.1 RRC connection establishments
- Attempted RRC connection establishments
- Failed RRC connection establishments
- Successful RRC connection establishments
A.1.3.2 RRC connection establishment setup time
- RRC connection set-up time (Mean)
- RRC connection set-up time (Max)
A.1.4 Compteurs relatifs au ré-établissement de connexion RRC
- Attempted RRC re-establishments
- Failed RRC re-establishments
- Successful RRC re-establishments
A.1.5 Compteurs relatifs à la liberation de connexion RRC
- Attempted RRC connection releases on DCCH
- Attempted RRC connection releases on CCCH
A.1.6 Compteurs relatifs à la connexion RLC
- Number of RLC blocks sent (per Mode)
99
- Number of RLC blocks Received (per Mode)
- Discarded RLC blocks by RNC
- Number of Retransmitted RLC blocks in Acknowledge Mode
A.1.7 Compteurs relatifs au Soft handover
A.1.7.1 Radio link additions to active link set (UE side)
- Attempted radio link additions to active link set (UE side)
- Successful radio link additions to active link set (UE side)
- Failed radio link additions to active link set (UE side)
A.1.7.2 Radio link deletions from active link set (UE side)
- Attempted radio link deletions from active link set (UE side)
- Successful radio link deletions from active link set (UE side)
A.1.8 Compteurs relatifs aux procédures de gestion du lien radio
- Considered radio link management procedures
- Relation between Iub measurements and Iur measurements
- Attempted radio link setups on Iub
- Successful radio link setups on Iub
- Failed radio link setups on Iub
- Radio link setups on Iur
- Attempted radio link setups on Iur
- Successful radio link setups on Iur
- Failed radio link setups on Iur
- Attempted radio link additions on Iub
- Successful radio link additions on Iub
100
- Failed radio link additions on Iub
- Attempted radio link additions on Iur
- Successful radio link additions on Iur
- Failed radio link additions on Iur
- Attempted radio link deletions on Iub
- Successful radio link deletions on Iub
- Radio link deletions on Iur
- Attempted radio link deletions on Iur
- Successful radio link deletions on Iur
A.1.9 Compteurs relatifs au handover interfréquence
A.1.9.1 Outgoing intra-NodeB hard handovers
- Attempted outgoing intra-NodeB hard handovers
- Successful outgoing intra-NodeB hard handovers
- Failed outgoing intra-NodeB hard handovers
A.1.9.2 Outgoing inter-NodeB, intra-RNC hard handovers
- Attempted outgoing inter-NodeB, intra-RNC hard handovers
- Successful outgoing inter-NodeB, intra-RNC hard handovers
- Failed outgoing inter-NodeB, intra-RNC hard handovers
A.1.9.3 Outgoing inter-RNC hard handovers via Iur
- Attempted outgoing inter-RNC hard handovers via Iur
- Successful outgoing inter-RNC hard handovers via Iur
- Failed outgoing inter-RNC hard handovers via Iur
101
A.1.9.4 Relocation preparation for outgoing inter-RNC hard handovers switching in the
CN
- Attempted relocation preparation for outgoing inter-RNC hard handovers switching
in the CN
- Successful relocation preparation for outgoing inter-RNC hard handovers switching
in the CN
- Failed relocation preparation for outgoing inter-RNC hard handovers switching in
the CN
A.1.9.5 Outgoing inter-RNC hard handovers switching in the CN
- Attempted outgoing inter-RNC hard handovers switching in the CN
- Successful outgoing inter-RNC hard handovers switching in the CN
- Failed outgoing inter-RNC hard handovers switching in the CN
A.1.10 Compteurs relatifs à la Relocalisation
A.1.10.1 Relocations for CS domain
- Attempted relocation preparations with UE involved for CS domain
- Successful relocation preparations with UE involved for CS domain
- Failed relocation preparations with UE involved for CS domain
- Attempted relocation preparations with UE not involved for CS domain
- Successful relocation preparations with UE not involved for CS domain
- Failed relocation preparations with UE not involved for CS domain
- Attempted relocations resource allocations with UE involved for CS domain
- Successful relocation resource allocations with UE involved for CS domain
- Failed relocation resource allocations with UE involved for CS domain
- Attempted relocations resource allocations with UE not involved for CS domain
102
- Successful relocation resource allocations with UE not involved for CS domain
- Failed relocation resource allocations with UE not involved for CS domain
- Successful relocations for CS domain
A.1.10.2 Relocations for PS domain
- Attempted relocation preparations with UE involved for PS domain
- Successful relocation preparations with UE involved for PS domain
- Failed relocation preparations with UE involved for PS domain
- Attempted relocation preparations with UE not involved for PS domain
- Successful relocation preparations with UE not involved for PS domain
- Failed relocation preparations with UE not involved for PS domain
- Attempted relocations resource allocations with UE involved for PS domain
- Successful relocation resource allocations with UE involved for PS domain
- Failed relocation resource allocations with UE involved for PS domain
- Attempted relocations resource allocations with UE not involved for PS domain
- Successful relocation resource allocations with UE not involved for PS domain
- Failed relocation resource allocations with UE not involved for PS domain
- Successful relocations for PS domain
A.1.11 Compteurs relatifs aux handovers inter-système CS
- Attempted relocation preparation for outgoing circuit switched inter-RAT handovers
- Successful relocation preparation for outgoing circuit switched inter-RAT handovers
- Failed relocation preparation for outgoing circuit switched inter-RAT handovers
- Attempted outgoing circuit switched inter-RAT handovers
- Successful outgoing circuit switched inter-RAT handovers
103
- Failed outgoing circuit switched inter-RAT handovers
- Attempted incoming circuit switched inter-RAT handovers
- Successful incoming circuit switched inter-RAT handovers
- Failed incoming circuit switched inter-RAT handovers
A.1.12 Compteurs relatifs aux handovers inter-système PS
- Attempted outgoing packet switched inter-RAT handovers, UTRAN controlled
- Successful outgoing packet switched inter-RAT handovers, UTRAN controlled
- Failed outgoing packet switched inter-RAT handovers UTRAN controlled
- Successful outgoing packet switched inter-RAT handovers, UE controlled
A.1.13 Compteurs relatifs à la libération de connexion Iu
A.1.13.1 Iu connection release request by UTRAN
-Attempted Iu connection release request by UTRAN for CS domain
- Attempted Iu connection release request by UTRAN for PS domain
A.1.13.2 Iu connection release by CN
- Attempted Iu connection release by CN for CS domain
- Attempted Iu connection release by CN for PS domain
- Successful Iu connection release by CN for CS domain
- Successful Iu connection release by CN for PS domain
A.1.14 Compteurs relatifs aux ressources de code TDD
- UTRAN Cell Max Downlink Code Resources Used
- UTRAN Cell Max Uplink Code Resources Used
A.1.15 Compteurs relatifs aux porteuses TDD d‟une cellule UTRAN
- Mean Transmitted Carrier Power of an UTRAN Cell
104
- Maximum Transmitted Carrier Power of an UTRAN Cell
- Mean Received Total Wideband Power of an UTRAN Cell
- Maximum Received Total Wideband Power of an UTRAN Cell
A.1.16 Compteurs relatifs aux ressources de code FDD
- Code Resources Used of an FDD mode UTRAN Cell
- Unsuccessful requests for service
- Unsuccessful requests for service, per cause
- Mean Inter-arrival Time (Circuit Switched)
- Attempted Transmission of Paging Messages, per BSC
- Unsuccessful Transmission of Paging Messages, per BSC
- Attempted IMMEDIATE ASSIGNMENT Procedures, per BSC
- Successful IMMEDIATE ASSIGNMENT Procedures, per BSC
- Successful Internal Handovers, intra-CELL, per BSC
- Unsuccessful Internal Handovers, intra-CELL, per BSC
- Successful Internal Handovers per BSC
- Successful Internal Handovers per cause
- Unsuccessful Internal Handovers with reconnection to old channels, per BSC
- Unsuccessful Internal Handovers with loss of connection, per BSC
- Flush Requests Received
- Paging Requests Received from SGSN
- Mean Inter-arrival Time (Packet Switched)
- Number of octets of uplink BSSGP PDUs
- Number of octets of downlink BSSGP PDUs
105
ANNEXE 2
L’INTERFACE GRAPHIQUE DE LA SIMULATION
Pour lancer la simulation, il faut ouvrir le fichier « Accueil.fig ».
La page d‟accueil s‟affiche comme l‟indique la figure A2.01 ci-dessous.
Figure A2.01: Fenêtre d’accueil
En appuyant sur « info », quelques informations concernant l‟application, notamment
l‟objectif du présent ouvrage, s‟afficheront dans l‟éditeur de Matlab.
En appuyant sur « Quitter », on bascule vers la fermeture de l‟application (cf figure A2.07).
Le bouton « Continuer >> » permet d‟afficher la fenêtre suivante qui concerne la saisie
de la valeur des différents compteurs nécessaires aux calculs de chaque KPI. La figure A2.02
montre par exemple la fenêtre dans laquelle on peut saisir la valeur des compteurs nécessaires
au calcul du taux de succès d‟établissement de RAB.
106
Figure A2.02: Fenêtre de compteurs d’établissement de RAB
Des valeurs par défaut sont affichées sur les différents champs. Cependant, il est
possible de les modifier. En choississant le bouton « Cell 1 », on saisit les valeurs de chaque
compteur. Et on passe à la cellule suivante.
Le bouton « Retour » permet de revenir à la fenêtre précédente.
Le bouton « Continuer » nous ouvre la fenêtre suivante, dans laquelle on peut saisir de
la même manière que précédemment les valeurs des compteurs relatifs au calcul du KPI
suivant.
On procède ainsi jusqu‟à la dernière fenêtre de saisie des valeurs de compteurs.
Dans cette dernière fenêtre, le bouton « Continuer » est remplacé par le bouton
« Visualiser ». En cliquant sur ce bouton, on peut visualiser les différents KPIs comme le
montre la figure A2.03.
107
Figure A2.03 : Fenêtre de visualisation des KPI
Le menu « Fichier » permet de choisir entre les sous-menus suivants :
- Nouveau (Ctrl + N) : permettant de revenir à la première fenêtre de saisie des valeurs
des compteurs.
- Accueil (Ctrl + H) : permettant de revenir à la fenêtre d‟accueil.
- Quitter (Ctrl + Q)
Le pop-up menu permet de choisir le KPI à visualiser.
Le bouton « Exemples d‟amélioration » permettra de basculer vers la fenêtre de choix
d‟amélioration de performance, décrite par la figure A2.04.
108
Figure A2.04 : Fenêtre de choix d’amélioration
Cette fenêtre permet de choisir entre les deux exemples d‟amélioration proposés par
l‟application.
Le bouton « Amélioration Call Setup Success Rate » permettra d‟améliorer le taux de
succès d‟établissement d‟appels. Tandis que le bouton « Amélioration Call Drop Rate »
permettra d‟améliorer le taux de coupure d‟appels d‟une cellule.
En cliquant sur l‟un d‟eux, on basculera vers une fenêtre qui permet de choisir les
paramètres d‟amélioration et la cellule à améliorer. La figure A2.05 montre la fenêtre
correspondante à l‟amélioration du taux de succès d‟établissement d‟appels.
Figure A2.05 : Paramètres d’amélioration du CSSR
Des valeurs par défaut sont déjà afficher mais il est possible de les modifier.
109
Le bouton « OK » permet de visualiser le résultat après l‟amélioration comme on le décrit
dans la figure A2.06.
Figure A2.06 : Visualisation d’amélioration du CSSR
Comme on peut le constater, on peut visualiser le résultat par rapport à la valeur du
KPI avant l‟amélioration, pour une même cellule.
Enfin pour quitter l‟application, il faut cliquer sur le bouton « Quitter ».
Une fenêtre de confirmation s‟affiche alors comme le montre la figure A2.07.On
clique sur « Oui » et l‟application sera fermée.
Figure A2.07 : Confirmation de la fermeture de l’application
110
BIBLIOGRAPHIE
[1] Lescuyer P., « UMTS », NORTEL Network, 4 Octobre 2004
[2] Lescuyer P., « Principe, architectures et services de l’UMTS », 3e Edition, 2006
[3] Ralaivao H., « Radiocommunications 3G », Cours I5 – TCO/STM, Département
Télécommunication.- E.S.P.A., A.U. : 2011-2012
[4] Makke R., « Qualité de Service et Performances des Protocoles de Transport dans
l’UTRAN », Thèse, E.N.S.T. Paris, 03 Juillet 2003.
[5] Razafimanantsoa F.H.V., « Réseau d’accès UTRAN de l’UMTS », Mémoire de fin
d‟études – TCO/Génie des Télécommunications et des Réseaux, Département
Télécommunication – E.S.P.A., A.U. : 2006-2007
[6] Hadjar O. R., « Analyse, Implémentation et Evaluation de performance de la future
méthode d’accès HSDPA », Mémoire de fin d‟étude, Faculté des études supérieures,
Université Laval, A.U. : 2005-2006
[7] Saida H., « Développement d’un outil de traitement et d’analyse des traces de
l’interface A », Projet de fin d‟études, SUP‟COM, A.U. : 2004-2005.
[8] Radu A., « Evaluation de la Qualité de Service par l’utilisateur final dans les
systèmes mobiles », 12 mars 2004
111
[9] UIT-T Recommandation E.800, « Terms and definitions related to quality of service
and network performance including dependability. », Septembre 2008
[10] UIT-T Recommandation G.1000, « Qualité de service des communications: cadre et
définitions. », Nov 2001
[11] Kyriazakos S., Papaoulakis N., Nikitopoulos D., Gkroustiotis E., « A Comprehensive
Study and Performance Evaluation of Operational GSM and GPRS Systems under
Varying Traffic Conditions », Heroon - University of Athens, 2002.
[12] ETSI Technical Report ETR 003, « Network Aspects (NA);General aspects of Quality
of Service (QoS) and Network Performance (NP) », Oct 2004
[13] M‟barki R, « Conception et développement d’un outil d’aide à l’analyse des
indicateurs qualité d’un réseau GPRS », Projet de fin d‟études, SUP‟COM, A.U. :
2006-2007
[14] Pipikakis M., «Evaluating and improving the Quality of Service of second generation
cellular systems», Ericsson Documentation, 2004.
[15] Bilal H., Zafrullah M. and Islam M. K., « Radio Frequency Optimization and QoS
Evaluation in Operational GSM Network », WCECS, 2009.
[16] 3GPP TS 52.402, « Performance Management (PM); Performance measurements -
GSM », Décembre 2007.
112
[17] 3GPP TS 32.403 v 7.1.0., « Performance Management (PM); Performance
measurements - UMTS and combined UMTS/GSM», Décembre 2005.
[18] Colin F., Houllier J.R., « L'optimisation des réseaux cellulaires assistée par
ordinateur : le Iogiciel RNO (Radio Network Optimization)», Alcatel Research and
Innovation, 2003.
[19] Ramiz R., « Evaluating and Selecting the Most Appropriate Key Performance
Indicators (KPIs) to maximise the Visibility of Network Performance », Yildiz
Technical University Article – Turkey, 2005
[20] 3GPP TR 32.814, « Telecommunication management; UTRAN and GERAN Key
Performance Indicators (KPI) », Mars 2007.
[21] R. Kreher, « UMTS Performance Measurement », John Wiley & Sons, 2006
[22] T-Mobile USA, « UMTS Network KPI, Appendix U12 », T-Mobile USA Inc, 2013
[23] Ericsson, « UMTS Interview Q&A », Ericsson, http://www.Telecom.Cloud.net
[24] R. Sandhu, A. Bispo, D. Platero, « GUIDELINE for 3G RF OPTIMIZATION »,
Nokia Siemens Network, 2007.
[25] Fox D., « UMTS Signaling Flow Diagrams », Technology CND, 2001.
113
[26] 3GPP TR 32.410 v 9.0.0, « Key Performance Indicators (KPI) for UMTS and GSM »,
Septembre 2009.
[27] Wei W., « UTRAN KPI Analysis Guide », Huawei Technology, 2005.
[28] Wallstrom M., « Automation of Mobile Radio Network Performance and Fault
Management », Nokia Network, 2007
[29] Randrianandrasana M. E., « Etude et performance du Soft Handover dans le réseau
UMTS », Mémoire de fin d‟études – TCO/RS, Département Télécommunication –
E.S.P.A., A.U. : 2009-2010.
[30] Hurtado A. F. C., « UMTS Capacity simulation study », Faculty of Electrical
Engineering, Mathematics and Computer Science, University of Twente, 2005
[31] Erlebach K., Jóskiewicz Z., Ney M., « UTRAN Transmission Infrastructure Planning
and Optimisation », 2007
[32] Popova L, Koch W., « Analytical Performance Evaluation of Mixed Services with
Variable Data Rates for the Uplink of UMTS », Universitat Erlangen-Nurnberg,
Germany, 2006
[33] Akl R., Nguyen S., « UMTS Capacity and Throughput Maximization for Different
Spreading Factors », Departement of Computer Science and Engineering, University
of North Texas, 2006
114
[34] Kaushik V., Kumar S., Sharma K., « Improvement of Call Blocking Probability in
UMTS », International Journal of Latest Research in Science and Technology,
Vol.1,Issue 3 :Page No.299- 303 ,September-October 2012
[35] Uzoma O., « Correlation between Uplink Noise, Uplink Load and Call Drop Rate in
a WCDMA Network », International Journal of Computer Applications (0975 – 8887)
Volume 66– No.5, March 2013
[36] Lundin E. G., « Uplink Load in CDMA Cellular Radio Systems », pp. 9-13, 43,pp 27-
28, 2005.
[37] Al-Qahtani S., Mahmoud A., « Uplink Admission ontrol in WCDMA », 2005.
[38] Données d’opération de mesures de performance journalière, Performance and QoS
Department, Opérateur étranger, 18 Septembre 2009.
115
PAGE DE RENSEIGNEMENTS
Nom : RANDRIAMANANJARA
Prénoms : Mandamahefa
Adresse : Lot AKT I 05 Manjaka Alakamisy-
Fenoarivo
Tana 102
Madagascar
Tel : 033 14 954 96
E-mail : [email protected]
Titre du mémoire Analyse de la Performance et de la Qualité de Service d‟un réseau
UMTS.
Nombre de pages : 116
Nombre de tableaux : 6
Nombre de figures : 34
Mots clés : KPI, QoS, Network Performance, UMTS, UTRAN, Compteurs OMC
Directeur de mémoire : M. RAKOTOMALALA Mamy Alain
116
RESUME
La norme UMTS est certainement l‟un des succès industriels de ces dernières années,
notamment dans le secteur des Télécommunications. Face à la croissance exponentielle du
nombre d‟utilisateurs et les nouveaux services de plus en plus complexes, les opérateurs ont
pour obligation de superviser en permanence la qualité de service offerts aux utilisateurs, par
l‟amélioration de la performance de leur réseau. Cet ouvrage propose une des méthodes de
supervision de la performance du réseau, en vue d‟une amélioration de la performance. Le
calcul des indicateurs de performance des compteurs OMC permet de trouver les problèmes
du réseau au plus vite et d‟appliquer la solution d‟amélioration la plus adéquate.
ABSTRACT
UMTS is one of the most outstanding industrial successes during these last years. The
requirement to enhance user service by monitoring the network performance becomes an
operator‟s priority. UMTS operators use different mechanisms to supervise the network
performance. In this paper, we study on of them: analyzing key performance indicator via
OMC counters, specifically those related to UMTS radio access network. It was proved that
this way is helpful to check the network‟s problem as soon as possible, and to find the suitable
optimization solution in order to improve network performance.
