Vous êtes sur la page 1sur 79

Projet de fin d’étude

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


Option :

Réseaux et services mobiles

Rapport de Projet de fin d’études

Thème :

Développement d’un outil de post


traitement des mesures Drive Test

Réalisé par :

Idriss CHHIMA

Encadrant (s) :

M. Sami TABBANE

Mlle Erij SIOUD


Travail proposé et réalisé en collaboration avec

Année universitaire : 2010/2011

1
Projet de fin d’étude

‫الرحمان الرحيــم‬
ّ ‫بســـــــــــم هللا‬

Dédicace

Dieu Merci
Pour mes parents Salem et Mouna
Pour m’avoir poussé jusqu’au bout
Pour mes frères Dhaker, Montassar & ma Sœur Maroua
En leur souhaitant la réussite dans leurs études et leurs vies
A toute ma famille

Je dédie ce travail

Idriss

i
Projet de fin d’étude

Résumé

Le maintien d’une qualité de service acceptable pour un opérateur est une obligation
pour satisfaire ses clients et garantir ses revenus. Dans ce contexte, nous nous sommes
intéressés dans notre projet de fin d’étude à la réalisation d’un outil de post-traitement de
mesures Drive Test des réseaux cellulaires de deuxième et troisième génération.

Après une description de diverses méthodes d’évaluation des performances d'un réseau
mobile, nous présentons en détail la méthode de mesure Drive Test sur laquelle nous nous
sommes basés. Les mesures drive test sont traités par notre outil afin d'effectuer une analyse
de l’état du réseau et de proposer automatiquement ainsi des solutions d'optimisation et
d'ingénierie en cas de problèmes de QoS constatés.

L'application de post traitement développée intègre également des fonctionnalités


telles que des présentations graphiques et géographiques des mesures drive test introduites.

Mot Clés : GSM, UMTS, Drive test, KPI, qualité de service

ii
Projet de fin d’étude

Avant propos

Le présent travail a été élaboré dans le cadre de la préparation du diplôme d’Ingénieur


en Télécommunications option réseaux et services mobiles à l’École Supérieure des
Communications de Tunis (SUP’COM).

Ce projet a été effectué au sein de l’entreprise SFM Telecom. Le but du projet était de
concevoir et de développer un outil de post traitement de mesures Drive Test pour réseaux 2G
et 3G.

C’est avec un grand plaisir je tiens à remercier tous ceux qui m’ont aidé de près ou
loin à réaliser ce projet, je tiens à exprimer ma sincère gratitude et ma profonde
reconnaissance à mes encadreurs Mr. Sami TABBANE, mon enseignant à SUP’COM et Mme
Erij SIOUD, ingénieur réseau mobile au sein de SFM Technologies, pour leur soutien et les
conseils qui m’ont aidés à finaliser ce projet.

Enfin, je veux remercier tous les enseignants de SUP’COM pour la formation qu’ils
m’ont donnée."

iii
Projet de fin d’étude

Sommaire
LISTE DES FIGURES...........................................................................................................vii

LISTE DES TABLEAUX……………………………………………………………………ix

ACRONYMES………………………………………………………………………………..x

Introduction générale ...........................................................................................................1


Chapitre 1 : Ingénierie des réseaux cellulaires 2G/3G ........................................................ 2
I. Présentation .................................................................................................................3
II. Architecture de réseau GSM ........................................................................................3
1. Sous-système radio ...................................................................................................3
2. Sous-système réseau .................................................................................................4
3. Sous-système d'exploitation et de maintenance .........................................................5
III. Interface radio en GSM ............................................................................................5
1. Partage temps/fréquence ...........................................................................................5
2. Liaison radio ............................................................................................................7
3. Les canaux ...............................................................................................................7
4. Mode de transmission discontinue (DTX) .................................................................8
5. Le handover .............................................................................................................8
IV. Architecture de réseaux UMTS .................................................................................9
1. Réseau d’accès (UTRAN) ........................................................................................9
2. Réseau cœur .............................................................................................................9
V. Interface radio en UMTS ........................................................................................... 10
1. Contrôle de puissance ............................................................................................. 10
2. Le handover ...........................................................................................................11
3. Les canaux ............................................................................................................. 11
VI. La qualité de service dans les réseaux cellulaires .................................................... 12
VII. Les problèmes influents sur la QoS......................................................................... 15
VIII. Conclusion ............................................................................................................. 17
Chapitre 2 : Les techniques et les outils d’évaluation de performance ............................ 18
I. Présentation ............................................................................................................... 19
II. Techniques d’évaluation ............................................................................................ 19
1. Les compteurs OMC............................................................................................... 19
2. L’analyseur de protocole ........................................................................................ 20

iv
Projet de fin d’étude

3. Le Drive Test ......................................................................................................... 20


4. Record détaillé de l'appel (Call Detail Record ou CDR) ......................................... 21
5. Sonde ..................................................................................................................... 22
6. Enquête clients ....................................................................................................... 22
III. Étude comparative .................................................................................................. 22
IV. Les entités de réseau mobile intervenant dans les Drive test .................................... 23
1. Interface radio ........................................................................................................ 23
2. Environnement de mesures ..................................................................................... 23
V. Chaîne de mesure Drive Test ..................................................................................... 24
1. Mobile à trace......................................................................................................... 24
2. Équipement GPS .................................................................................................... 25
3. Ordinateur portable doté d'un logiciel d'acquisition ................................................. 25
VI. Le post traitement ................................................................................................... 25
VII. Etude préalable ....................................................................................................... 26
1. Etude de l'existant................................................................................................... 26
2. Solutions proposées ................................................................................................ 30
3. Solution retenue ..................................................................................................... 30
VIII. Cahier de charge de projet ...................................................................................... 30
1. Cadre de projet : ..................................................................................................... 30
2. Spécifications de l’outil à développer ..................................................................... 31
3. Méthodologie de travail .......................................................................................... 31
IX. Conclusion ............................................................................................................. 31
Chapitre3: Analyse et conception ...................................................................................... 32
I. Présentation ............................................................................................................... 33
II. Spécification des besoins ........................................................................................... 33
1. Les besoins fonctionnels ......................................................................................... 33
2. Les besoins non fonctionnels .................................................................................. 33
III. La description de la procédure d'analyse ................................................................. 34
IV. Les algorithmes utilisés .......................................................................................... 35
1. Détection d’un problème de couverture .................................................................. 35
2. Détection d’un problème d’interférence .................................................................. 37
3. Analyse des cellules voisines .................................................................................. 39
4. Détection des Handovers ........................................................................................ 41

v
Projet de fin d’étude

5. Autres problèmes.................................................................................................... 43
V. Solutions possibles ..................................................................................................... 44
VI. Cas d'utilisation ......................................................................................................44
VII. Les diagrammes de séquence .................................................................................. 45
VIII. Conclusion ............................................................................................................. 46
Chapitre4: Réalisation de l'outil et évaluation .................................................................. 47
I. Présentation ............................................................................................................... 48
II. Environnement du travail ........................................................................................... 48
1. Langage de programmation .................................................................................... 48
2. Les extensions nécessaires ...................................................................................... 49
III. Les interfaces ......................................................................................................... 50
1. L’authentification ................................................................................................... 50
2. Importation de fichier et choix de système .............................................................. 50
3. Réglage de paramètres ............................................................................................ 51
4. Analyse et présentation graphique ..........................................................................52
IV. Les tables créées par l’application ..........................................................................57
V. Évaluation de l’outil ................................................................................................... 58
1. Avantages............................................................................................................... 58
2. Désavantages ..........................................................................................................58
VI. Conclusion ............................................................................................................. 58
Conclusion générale............................................................................................................ 59
Annexe ................................................................................................................................ 60
I. ANNEXE A ............................................................................................................... 61
1. Fichier Drive-Test d’un réseau GSM : .................................................................... 61
2. Fichier Drive-Test d’un réseau UMTS : .................................................................. 63
II. ANNEXE B ............................................................................................................... 65
1. Les fichiers Drive Test : ......................................................................................... 65
Bibliographie ...................................................................................................................... 67
Webographie....................................................................................................................... 67

vi
Projet de fin d’étude

Liste des figures


Figure 1: Architecture du GSM...............................................................................................3
Figure 2: Le multiplexage en GSM .........................................................................................5
Figure 3: Technique d’accès multiple en GSM........................................................................6
Figure 4: Liaison radio en GSM ..............................................................................................7
Figure 5: Architecture de l’UMTS ..........................................................................................9
Figure 6: Le principe de la technologie CDMA..................................................................... 10
Figure 7: Technique de supervision en GSM ........................................................................ 14
Figure 8: Stratégie d’optimisation des réseaux ......................................................................15
Figure 9: Phénomène de respiration de cellule en UMTS (Cell-breathing) ............................ 16
Figure 10: Différentes sources d’interférence ........................................................................ 16
Figure 11: Processus d’optimisation avec la méthode Drive Test ..........................................21
Figure 12: Chaîne de mesure Drive Test ............................................................................... 24
Figure 13: Démarche de projet .............................................................................................. 26
Figure 14: Exemple d’utilisation géographique de l’outil MapInfo ....................................... 27
Figure 15: sélection SQL avec MapInfo ................................................................................ 27
Figure 16: Carte géographique avec TEMS...........................................................................28
Figure 17: mesures sur les cellules voisines en UMTS sous Agilent ......................................29
Figure 18: Schéma fonctionnel de l’outil .............................................................................. 31
Figure 19: Schéma synoptique de l’application ..................................................................... 34
Figure 20: Organigramme de détection de problème de couverture en GSM ......................... 36
Figure 21: Organigramme de détection de problème de couverture en UMTS ....................... 37
Figure 22: Organigramme de détection de problème d’interférence en GSM......................... 38
Figure 23: Organigramme de détection de problème d’interférence en UMTS ...................... 39
Figure 24: Informations à propos des cellules voisines à partir d’un fichier Drive-Test en
GSM..................................................................................................................................... 40
Figure 25: Les niveaux de champs des cellules voisines ........................................................ 40
Figure 26: Informations à propos des cellules voisines à partir d’un fichier Drive-Test en
UMTS .................................................................................................................................. 41
Figure 27: Détection de Handover en GSM ..........................................................................42
Figure 28: Détection de Handover en UMTS ........................................................................ 43
Figure 29: Diagramme UseCase de l’application .................................................................. 45
Figure 30: Diagramme de séquence « Authentification » ...................................................... 45

vii
Projet de fin d’étude

Figure 31: Diagramme de séquence « Analyse » ................................................................... 46


Figure 32: Interface d’authentification .................................................................................. 50
Figure 33: Importation de fichier et choix de système ........................................................... 50
Figure 34: Réglage de paramètres ......................................................................................... 51
Figure 35: Statistiques de paramètre RSCP ...........................................................................52
Figure 36: Exemple de représentation géographique ............................................................. 53
Figure 37: Les observations détectables par l’application en GSM ........................................ 54
Figure 38: Exemple de détection des trous de couverture en UMTS ......................................54
Figure 39: Affichage géographique de problème de couverture ............................................. 55
Figure 40: Détection de problème de pilot pollution ............................................................. 55
Figure 41: Changement de cellule ......................................................................................... 56
Figure 42: Détection de l’interférence ................................................................................... 56
Figure 43: Exemple de sélection selon un critère donné ........................................................ 57

viii
Projet de fin d’étude

Liste des tableaux


Tableau 1: Organisation des trames en GSM ..........................................................................6
Tableau 2: Tables des canaux logiques GSM ..........................................................................8
Tableau 3: Exemple d’étude de la couverture à l’aide de RX LEV ........................................ 35

ix
Projet de fin d’étude

Acronymes
AGCH Access Grant Channel
AICH Acquisition Indicator Channel

Auc Autentication Center


BCCH Broadcast Control Channel
BSC Base Station Controller
BSS Base Station Sub-system
BTS Base Tranceiver System
CBCH Cell Broadcast Channel

CCCH Common Control Channel


CDR Call Detail Record
CPICH Common Pilot Channel
CTCH Common Traffic Channel
DCCH Dedicated Control Channel
DPCH Dedicated Physical Channel
DTCH Dedicated Traffic Channel

DTX Discontinuous transmission


EIR Equipment Identity Register
FACCH Fast Associated Control Channel
FCCH Frequency Correction Channel
FDMA Frequency-Division Multiple Access
GGSN Gateway GPRS Support Node

GMSC Gateway Mobile Switching Centre


GMSK Gaussian Minimum Shift Keying
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile Communications
HLR Home Location Register

HSDPA High Speed Downlink Packet Access

x
Projet de fin d’étude

IMEI International Mobile Equipment Identity

ITU International Telecommunication Union


KPI Key Performance Indicator
LTE Long Term Evolution
MSC Mobile Switching Centre
NSS Network Sub-System
OMC Operation and Maintenance Center

OSS Operation Support Subsystem


PCCH Paging Control Channel
PCH Paging Channel
QAM Quadrature Amplitude Modulation
QoS Quality Of Service
QPSK Quadrature Phase Shift Keying
RACH Random Access Channel

RLT Radio Link Timeout


RNC Radio Network Controller
SACCH Slow Associated Control Channel
SCH Synchronization Channel
SDCCH Stand-alone Dedicated Control Channel
SGSN Serving GPRS Support Node

SQL Structured Query Language


TCH Traffic Channel
TDMA Time Division Multiple Access
TRX Transceiver
UMTS Universal Mobile Telecommunications System
UTRAN Universal Terrestrial Radio Access Network

VAD Voice Activity Detector


VLR Visitors Location Register
WCDMA Wideband Code Division Multiple Access

xi
Projet de fin d’étude

Introduction générale

Les réseaux radio mobiles ont connu des évolutions avec des différentes générations
de systèmes radio. Tout est commencé avec les communications basées sur les systèmes
analogiques avant l’apparition des systèmes numériques avec la deuxième génération. Le
GSM représente un système célèbre de cette génération où il a connu un succès considérable
dans le monde entier. La troisième génération a été marquée par l’UMTS qui n’est qu’un
système cellulaire conçu afin d’améliorer les services multimédia. Les opérateurs mobiles,
quelque soit le système utilisé dans leurs réseaux, sont demandés à garder une bonne qualité
de service pour garantir un nombre d’abonnés accepté.

Dans ce contexte, l’opérateur doit contrôler son réseau au cours du temps pour détecter
et résoudre les problèmes indésirables. Cela nécessite la consécration des procédures et des
méthodes. En effet, chaque méthode porte des caractéristiques spécifiques et peut donner une
vision sur une partie donnée de réseau.

Dans le premier chapitre, nous parlerons d’une façon générale des réseaux mobiles
GSM et UMTS en donnant leurs architectures et les principales caractéristiques de leurs
interfaces radio.

Concernant le deuxième chapitre, nous allons présenter les différentes méthodes


possibles pour la maintenance de réseau en s’intéressant particulièrement à la méthode Drive
Test et à l’objectif de post traitement des mesures prises avec cette méthode. Une partie sera
consacrée pour l’étude préalable où nous allons étudier quelques outils connus d’analyse de
performance.

Dans le troisième chapitre de ce projet, nous analyserons la partie de spécification des


besoins qui va nous aider à définir les grandes fonctionnalités de l’outil et de mettre
l’application désirée dans son cadre technique. De plus, nous donnerons les procédures
nécessaires à implémenter dans l’application pour assurer les fonctionnalités exigées. Une
partie sera consacrée à la conception qui va nous aider à développer l’outil.

Le dernier chapitre portera sur la réalisation de l’application avec des illustrations sur
les histogrammes représentant les statistiques et les représentations géographiques avec la
mention des commentaires.

Développement d’un outil de post traitement des mesures Drive Test- Page 1
Idriss CHHIMA- SUP’COM- SFM 2011
Chapitre 1 : Ingénierie des réseaux cellulaires 2G/3G

Développement d’un outil de post traitement des mesures Drive Test- Page 2
Idriss CHHIMA- SUP’COM- SFM 2011
I. Présentation

Les réseaux mobiles sont développés de plus en plus grâce au progrès technologique
ainsi de la leur popularisation. Ces réseaux ont été conçus pour la première fois pour
transporter la voix. Cependant, ces réseaux ont évolué très rapidement pour fournir des autres
services tel que le transport de data et l’accès à l’internet.
Dans les réseaux mobiles, l’interface radio permet la transmission des données entre
l’utilisateur final et son opérateur. Le fait que les ressources radio sont rares, une optimisation
est mise en place pour profiter le plus possible de la bande passante.
Dans ce chapitre, nous allons définir les concepts fondamentaux des interfaces radio
des réseaux GSM et UMTS, ainsi que les problèmes gênants dans les réseaux cellulaires après
avoir définir leurs architectures générales.

II. Architecture de réseau GSM

L’architecture de GSM est donnée par la figure1 :

Figure 1: Architecture du GSM

1. Sous-système radio

Le BSS (Base Station Sub-system) contient les BTS et les BSC et il s’occupe de la
transmission radioélectrique ainsi que la gestion des ressources radio.

Développement d’un outil de post traitement des mesures Drive Test- Page 3
Idriss CHHIMA- SUP’COM- SFM 2011
 BTS: La station de base (Base Transceiver Station) représente le relais radio qui relie
le téléphone mobile au réseau et elle s’occupe de la gestion physique du lien radio.
 BSC: Le rôle du contrôleur de station de base (Base Station Controller) est de gérer
un ou plusieurs BTS et il est responsable de l’allocation des ressources, le contrôle de
puissance et la gestion des handovers.

2. Sous-système réseau

Le NSS (Network Station Sub-system) : contient les commutateurs (MSC) ainsi que les
bases de données (HLR, VLR, AuC, EIR). Il assure aussi les fonctions de routage et de
commutation et l’interconnexion avec le réseau téléphonique fixe. De plus, il s’occupe de la
gestion de mobilité, la sécurité et la confidentialité.
 MSC: le centre de commutation du service mobile (Mobile Service Switching Centre)
gère plusieurs BSC et joue le rôle d’un commutateur dans le réseau GSM.
 VLR: l'enregistreur de localisation des visiteurs (Visitors Location Register). C’est
une base de données qui contient des informations à propos des abonnées qui se
trouvent dans un BSS associé à un MSC. Les informations sont effacées lorsque le
mobile quitte cette zone.
 HLR: l'enregistreur de localisation nominal (Home Location Register) possède les
informations nécessaires à la gestion des communications d'un certain nombre
d'abonnés. Il contient les informations caractérisant le mobile (paramètres uniques)
ainsi que d’autres informations indiquant la dernière position connue de cet
utilisateur (VLR/MSC).
 EIR: l'enregistreur des identités des équipements EIR (Equipement Identity Register)
est une base de données contenant le numéro international de l'équipement IMEI
(International Mobile Equipement Identity) permettant ainsi son identification.
L’opérateur peut alors désactiver le téléphone mobile qui aurait été volé.
 AuC : c’est le centre d’authentification (Authentication Center) qui mémorise pour
chaque abonné une clé secrète et il gère le chiffrement des données. Aussi, il est
associé à une HLR.
 GMSC: Gateway-MSC : c’est une fonction supplémentaire de MSC pour assurer la
communication entre le mobile et les abonnées du réseau fixe.

Développement d’un outil de post traitement des mesures Drive Test- Page 4
Idriss CHHIMA- SUP’COM- SFM 2011
3. Sous-système d'exploitation et de maintenance

L’OSS (Operation Sub-System) joue le rôle de superviseur dans la norme GSM. Il


peut détecter les anomalies dans le réseau et les traiter à partir des OMC.
 OMC: le centre d’exploitation et de maintenance (The Operations and Maintenance
Center). Ce système est responsable des opérations de commercialisation et
d’administration (abonnement, statistiques, taxation) ainsi que d’autres fonctions de
sécurité et de configuration système.

III. Interface radio en GSM

1. Partage temps/fréquence

La norme GSM utilise les technologies d’accès multiple fréquentiel et temporel


simultanément pour optimiser l’utilisation des ressources radio. Nous utilisons des fréquences
espacées de 200 Khz dans la bande de 900 Mhz (890-915 Mhz pour la liaison montante
(mobile vers BTS) et 935-960 Mhz pour la liaison descendante (BTS vers mobile), en notant
qu’on peut trouver aussi le GSM 1900 Mhz. Chaque fréquence est divisée elle même en 8
slots de temps.

Figure 2: Le multiplexage en GSM

Généralement, nous trouvons dans chaque cellule 4 TRX (fréquence) divisée en 8 times slot
(8 communications pour la même fréquence dans le temps) comme indique la figure
suivante :

Développement d’un outil de post traitement des mesures Drive Test- Page 5
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 3: Technique d’accès multiple en GSM

Pour organiser les trames et bien gérer la répétition périodique de slots dans la trame
TDMA, la norme GSM propose un découpage :

Découpage Composition Durée

1 trame 8 IT de 577 µs 4,615 ms

multitrame 26 26 trames de 4,615 ms 119,99 ms

multitrame 51 51 trames de 4,615 ms 235,365 ms

supertrame 26 26 multitrames 51 (1326 trames) 6,119 s

supertrame 51 51 multitrames 26 (1326 trames) 6,119 s

hypertrame 2048supertrames (2.715.648 trames) 03 h 28 mn 53 s 760 ms

Tableau 1: Organisation des trames en GSM

Développement d’un outil de post traitement des mesures Drive Test- Page 6
Idriss CHHIMA- SUP’COM- SFM 2011
2. Liaison radio

L’interface Um (ou interface air) assure la liaison radio entre le mobile et la BTS comme le
montre la figure 4 :

Figure 4: Liaison radio en GSM

3. Les canaux

Pour mieux gérer l’accès aux ressources radio, la norme GSM définit deux types de
canaux :

 Canal physique : représente la ressource physique accordée à une


communication. C’est est un couple composé d’une fréquence et d’un time slot.
 Canal logique : il s’agit d’un ensemble de slots dans une multi-trame qui
transporte une catégorie d’informations avec une périodicité bien définie.
plein-débit (13 kbit/s)
voix
Canal de trafic demi-débit
TCH
données 2,4 kbits/s

BCCH = information système

Canaux de Diffusion (voie balise) SCH = synchronisation et identification


contrôle
FCCH = calage sur fréquence porteuse
SACCH
Contrôle commun PCH = appel du mobile

Développement d’un outil de post traitement des mesures Drive Test- Page 7
Idriss CHHIMA- SUP’COM- SFM 2011
RACH = accès aléatoire

AGCH = allocation de ressource

CBCH = messages courts diffusés

SDCCH = signalisation

Contrôle dédié SACCH = supervision de la liaison

FACCH = exécution du handover

Tableau 2: Tables des canaux logiques GSM

4. Mode de transmission discontinue (DTX)

La transmission discontinue est un mécanisme pour conserver l’énergie en permettant


au mobile d’être inactif pendant les périodes d’inactivité vocale. Ce mécanisme nécessite un
détecteur VAD (Voice Activity Detection) pour la détection de la présence ou l’absence de
parole.

5. Le handover

Le handover est un ensemble de techniques pour changer la cellule dans les réseaux
mobiles au cours de communication. Dans le GSM, nous avons un hard handover où le
mobile libère l’ancien lien avant l’établissement du nouveau lien avec la BTS cible.

Développement d’un outil de post traitement des mesures Drive Test- Page 8
Idriss CHHIMA- SUP’COM- SFM 2011
IV. Architecture de réseaux UMTS

Figure 5: Architecture de l’UMTS


L’architecture de l’UMTS ne s’éloigne pas de celle de GSM sauf qu’il y a
l’introduction des entités pour le transport des données (introduites dés le GPRS (2.5G)). De
plus, les composantes de ce réseau n’ont pas toutes les mêmes fonctionnalités avec les
changements des protocoles et des technologies surtout dans l’interface radio.

1. Réseau d’accès (UTRAN)

Dans ce domaine, nous trouvons la station de base NodeB et le RNC. En effet, le


NodeB est équivalent au BTS en GSM avec l’utilisation de nouvelles technologies d’accès,
tandis que le RNC (Radio Network Controller) assure le routage de communications entre les
NodeB et le réseau cœur. De plus, il contrôle la puissance et l’allocation des ressources.

2. Réseau cœur

Ce réseau est chargé de commutation et de routage des communications. Il est


composé de deux parties :

 Domaine paquet : est utilisé généralement pour les applications multimédia et la


navigation internet. Il est composé de SGSN et GGSN. Le premier maintient les
informations nécessaires pour l’acheminement des données (l’identification, le
profil,…) et le deuxième joue le rôle de commutateur vers le réseau internet et les
autres réseaux externes de transmission de données.

Développement d’un outil de post traitement des mesures Drive Test- Page 9
Idriss CHHIMA- SUP’COM- SFM 2011
 Domaine circuit : est semblable au réseau cœur de GSM. Ce domaine est conçu pour
la transmission de voix et est composé du MSC, GMSC. Ainsi, nous trouvons les
bases de données (HLR, VLR, AuC, EIR) qui sont des éléments communs entre ce
domaine et le domaine paquet.

V. Interface radio en UMTS

La technologie d’accès multiples utilisé en UMTS est la CDMA (comme indiqué


dans la figure 6). Elle permet aux différents usagers d’envoyer leurs communications sous la
même bande passante en donnant pour chacun un code qui assure une communication unique
propre à lui.

Figure 6: Le principe de la technologie CDMA

1. Contrôle de puissance

Dans le WCDMA, une technique importante est introduite pour le contrôle de


puissance. Elle consiste à augmenter la puissance de transmission quand la qualité du signal
reçu est faible et de diminuer la puissance de transmission quand la qualité du signal en
réception atteint un seuil donné. Ceci permet une communication fiable entre l’émetteur et le
récepteur. Ainsi, la technique de contrôle de puissance réduit les interférences (intra et inter-
cellules) causées par la puissance de transmission trop importante des autres utilisateurs. Par
conséquent, la capacité du système est ainsi augmentée et nous trouvons trois types :

 Open loop : dans les sens montants seulement pour ajuster la puissance sur l’accès
aléatoire en estimant le “path loss”, niveau d’interférence sur l’UPLINK (BCH).

Développement d’un outil de post traitement des mesures Drive Test- Page 10
Idriss CHHIMA- SUP’COM- SFM 2011
 Outer loop: Pour déterminer la valeur de l’étape du “closed-loop”.
 Closed-loop (sens montant et sens descendant) : baisser ou augmenter la puissance par
étape.

2. Le handover

Nous avons vu que le type de handover utilisé en GSM est le hard handover. Dans
l’UMTS, un nouveau type est utilisé : c’est le soft handover où le mobile peut se connecter
simultanément à plusieurs cellules pendant un appel.

3. Les canaux

Comme en GSM et GPRS, on distingue les canaux physiques et les canaux logiques
auxquels viennent s'ajouter un type intermédiaire : les canaux de transport.

 Les canaux logiques

Ces canaux logiques sont de deux types: les canaux de contrôles (control channels) et les
canaux de trafic (traffic channels). Ils peuvent tous deux transporter des informations dédiées
à une communication ou à plusieurs (canaux communs).

 Les canaux logiques de contrôle:


o Le BCCH (broadcast control channel) : est utilisé pour envoyer des
informations de nature système au mobile, qui lui permettront notamment de se
synchroniser avec le réseau et d'y faire des demandes d'accès.
o Le PCCH (paging control channel) : est employé pour envoyer des pagings au
mobil, c'est-à-dire afin de lui signifier que le réseau tente de le contacter.
o Le DCCH (dedicated control channel) : sert à envoyer et recevoir des
informations de côntrole d'une communication donnée pour un mobile donné.
o Le CCCH (common control channel) : est utilisé pour envoyer ou recevoir des
informations de signalisation des mobiles non encore connectés au réseau,
notamment lors de la phase d'établissement d'appel.
 les canaux logiques de trafic:
o le DTCH (dedicated traffic channel) : utilisé pour transmettre des données sur
un canal de communication connecté au réseau d'un mobile donné.

Développement d’un outil de post traitement des mesures Drive Test- Page 11
Idriss CHHIMA- SUP’COM- SFM 2011
o Le CTCH (common traffic channel) : utilisé pour transmettre des informations
à un groupe d'utilisateurs donné. C’est la fonction "appel de groupe"

 Les canaux physiques

 Les canaux physiques uplink dédiés => le DPCH (DPDCH et DPCCH sont
multiplexés I/Q sur la radio, ce qui est équivalent à deux modulations MP2
orthogonales indépendamment de l'axe I et de l'axe Q et le canal d'accès PRACH
(physical random acess channel)
 Les canaux physiques downlink
o Les canaux physiques downlink dédiés DPCH (dedicated physical channel) et
les canaux physiques communs (le canal de balise CPICH, SCH primaire
(synchronisation slot), SCH secondaire (synchronisation trame), P-CCPCH, S-
CCPCH, AICH: le canal d'indication d'acquisition, PDSCH.
Nous avons vu que la notion de canaux logiques correspond à la nature des informations à
transmettre et que la notion de canaux physiques correspond à celle du vecteur de support
physique sur l'interface radio.

 Les canaux de transport

Une troisième notion existe dans l'UTRAN qui est celle de canaux de transport qui
définissent la façon dont les informations issues des canaux logiques sont codées et
transportées sur les canaux physiques (QoS...). [1]

VI. La qualité de service dans les réseaux cellulaires


L’opérateur cherche à éviter les défaillances techniques qui peuvent laisser les clients
penser à immigrer vers des autres opérateurs. Pour cela, il est nécessaire de donner un service
acceptable.

L’ITU–T définit la QoS comme l’effet global produit par la qualité de fonctionnement
d’un service qui détermine le degré de satisfaction de l’usager du service [2].

Nous trouvons des paramètres de qualité de service qui peuvent servir à définir des
niveaux de service, par exemple la QoS peut être jugée avec :

Développement d’un outil de post traitement des mesures Drive Test- Page 12
Idriss CHHIMA- SUP’COM- SFM 2011
 Le débit : nombre de bits transmis par unité de temps. Dans le réseau UMTS, c’est
primordiale de fournir un débit acceptable pour le transfert de données pour l’usager.
 Le délai : le temps accordé pour transmettre les données de l’émetteur vers le
récepteur. Ce temps inclus le temps de propagation et le temps d’attente passé dans les
nœuds lors de congestion.
 La Gigue : la gigue indique les variations des instants significatifs définissant un
signal numérique par rapport aux positions qu'ils devraient occuper dans le temps.
 Le taux de pertes de paquet : indique le pourcentage de paquets qui n’atteignent pas
leurs destinations.

Encore, il y a d’autres paramètres influant sur la QoS comme le BER (taux d’erreur
binaire), taux de succès d'appel, taux d'appels bloqués,...

Pour garantir une qualité de services acceptable pour le client, des procédures de
contrôle et de maintenance sont mises en place. Après des mesures de qualité, l’opérateur
utilise des outils pour déterminer les statistiques et les analyses concernant les paramètres qui
indiquent la performance (KPIs). Ces clés peuvent être prises par plusieurs interfaces et
diverses entités de réseau, soit de sous système radio ou de cœur de réseau.

Essentiellement, pour mesurer la performance d’un réseau, ces méthodes sont les plus
utilisées (seront plus détaillées dans le chapitre suivant):

 Drive Test.
 Analyseur de protocole
 Mesures OMC
 traitements de CDRs
 des sondes actives ou passives
 utiliser des enquêtes clientèle

Les KPIs (Key Performance Indicators ou en français indicateurs clés de performance


(ICP)) sont des indicateurs mesurables qui permettent de diagnostiquer la qualité et
déterminer les problèmes pour un réseau dans le but d’assurer une bonne qualité de service.
Nous trouvons deux types des KPIs :

Développement d’un outil de post traitement des mesures Drive Test- Page 13
Idriss CHHIMA- SUP’COM- SFM 2011
 KPI qui indique un événement déroulé dans le réseau (exemple : taux des coupures
des appels, taux de succès d’établissement des appels, taux des handovers
réussites,…).
 KPI radio qui représente une mesure radio dans l’interface d’accès (exemple :
RXLEV, RXQUAL,… en GSM et RSCP, RXPOWER, EC/I0,… en UMTS).

Chaque méthode est implantée dans un sous-système de réseau comme illustré par la
figure 7 (exemple pour le GSM) :

Figure 7: Technique de supervision en GSM


Pour le réseau de troisième génération (UMTS), nous trouvons aussi les mêmes
méthodes que pour le GSM, sauf que les interfaces ne possèdent pas les mêmes
caractéristiques puisque il y a eu une implémentation de nouvelles technologies. Citons à titre
d’exemple le lien radio. En effet, nous trouvons dans l’UMTS des nouveaux paramètres dus à
l’utilisation de la méthode d’accès CDMA.

Selon son besoin et à partir de ces KPI mesurés, l’opérateur peut optimiser son réseau
en suivant une stratégie comme illustrée dans la figure suivante :

Développement d’un outil de post traitement des mesures Drive Test- Page 14
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 8: Stratégie d’optimisation des réseaux
Les conditions primordiales que l’opérateur doit les respecter sont en général :

 Bonne couverture : chaque usager cherche à se communiquer avec son réseau


dans l’endroit où il se trouve.
 Bonne qualité : l’usager cherche la fiabilité lors de l’envoi des données sur le
réseau. Aussi, il veut que ses conversations vocales soient claires.
 Débit de données : l’opérateur doit fournir un accès à son réseau avec des
débits prévus.

VII. Les problèmes influents sur la QoS


Les principaux problèmes qui influent sur la qualité des appels et que l’opérateur cherche
à les éviter sont:

 Mauvaise couverture : ce problème se manifeste lorsque le mobile ne peut pas


communiquer dans un réseau (les ondes émises n’arrivent pas à la station de base la
plus proche ou bien celles émises par la station de base n’arrivent pas avec une
puissance détectable). De plus, si le réseau est très chargé, le mobile trouve une
difficulté pour se communiquer. Dans l’UMTS, un tel cas mène au phénomène appelé
respiration de cellules (où la zone de couverture est réduite si la station de base est
saturée).

Développement d’un outil de post traitement des mesures Drive Test- Page 15
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 9: Phénomène de respiration de cellule en UMTS (Cell-breathing)

 Interférence : nous parlerons de ce phénomène lorsque les signaux des autres


mobiles ou stations de base influent sur la qualité de signal. Nous trouvons trois
types d’interférence en GSM:

 Interférence co-canal : c’est lorsque des émetteurs radio émettent sur la


même fréquence que l’on souhaite capter.
 Interférence sur canal adjacent : ce phénomène est dû à l’utilisation des
canaux assez proches dans le spectre de fréquence.
 Interférence co-site : si on ne respecte pas une distance minimale entre les
fréquences au sein d’un même site.

Aussi, nous pouvons distinguer l’interférence selon son source (intracellulaire ou


intercellulaire) comme illustré par la figure 10 :

Figure 10: Différentes sources d’interférence

Développement d’un outil de post traitement des mesures Drive Test- Page 16
Idriss CHHIMA- SUP’COM- SFM 2011
En UMTS, grâce à l’utilisation des codes orthogonaux, nous ne trouvons pas ces types
d’interférence. La seule chose qui gêne est le décalage temporaire entre les codes des signaux
dus à la différence entre les chemins de parcours ce qui touche l’orthogonalité des codes.

 Dominance : se manifeste par les endroits où la puissance reçue par la cellule


serveuse est inférieure à celle d’une autre cellule voisine..

En UMTS, les mesures indiquant les caractéristiques des cellules voisines sont
prises à partir du canal P-CPICH de chaque cellule.

*P-CPICH (Primary Common Pilot Channel) : c’est un canal descendant qui


diffuse le signal pilote avec une puissance constante et une séquence des bits connues pour
aider le terminal à estimer le canal (c’est un canal de référence pour une cellule donnée).

*Pilot pollution: c’est un type d’interférence Co-canal dans les systèmes


CDMA quand le signal pilote d’une cellule distante est puissant.

 Coupure d’appel : c’est pour caractériser le maintien de la communication. Par


exemple, on peut calculer le taux de coupure en GSM à l’aide de paramètre RLT
(coupure s’il prend la valeur 0).
 Le taux d’erreur : si ce taux est élevé donc la communication n’est pas fiable et
peut donner des communications incompréhensives.
 Les Handovers : parfois le mobile ne réussit pas à changer la cellule ; ce qui peut
mener à une coupure d’appel.
Cette liste de problème n’est pas exhaustive, il y en a des autres qui peuvent influer sur
la qualité de service.

VIII. Conclusion
Dans ce chapitre, nous avons donné les concepts fondamentaux des réseaux mobiles
2G/3G ainsi que les principaux spécifications de leurs interfaces radio. De plus, nous avons
mentionné l’importance de la qualité de services pour l’opérateur et les problèmes gênants à
éviter. Dans le chapitre suivant, nous allons définir les techniques d’évaluation des
performances et en s’intéressant particulièrement à la méthode Drive Test.

Développement d’un outil de post traitement des mesures Drive Test- Page 17
Idriss CHHIMA- SUP’COM- SFM 2011
Chapitre 2 : Les techniques et les outils d’évaluation
de performance

Développement d’un outil de post traitement des mesures Drive Test- Page 18
Idriss CHHIMA- SUP’COM- SFM 2011
I. Présentation

Après la phase de déploiement et d’ouverture commerciale d’un réseau cellulaire, une


autre phase de contrôle et d’optimisation est nécessaire afin de convaincre les clients et
d’améliorer la qualité de service et de profiter des ressources radio limitées.
Dans ce deuxième chapitre, nous allons parler des méthodes utilisées pour le contrôle des
réseaux et en particulier la méthode Drive Test en donnant la chaîne de mesure nécessaire
pour le faire.

II. Techniques d’évaluation

1. Les compteurs OMC

L’OMC (Operation and Maintenance Center) est un élément de base dans les réseaux
mobiles qui sert à superviser le réseau. Il est composé de compteurs qui sont caractérisés par
des informations à propos des abonnés enregistrés et qui sont utiles à améliorer la qualité de
service de système. Il existe deux types d’OMC :
 OMC-R : gère la partie radio de réseau.
 OMC-S : gère la partie commutation du réseau.
Nous pouvons utiliser les mesures de l’OMC dans plusieurs domaines :
 Optimisation et planification du réseau.
 Statistiques.
 Détermination des problèmes dans un réseau.
 Analyse en temps réel.

Les données de ces compteurs doivent être transformées en KPI avec des formules
prédéfinies qui servent généralement à analyser le déroulement des appels et donner des
statistiques sur l’établissement, la coupure et la perte des sessions ainsi que détecter les
cellules où il y a des anomalies. [3]

Pour chaque indicateur (calculé à partir de valeurs brutes données par les compteurs),
nous déclarons un seuil qui représente une valeur qui sépare deux états de la qualité de service
(acceptable et non acceptable). Ainsi, des alertes sont déclarées pour avertir le système lors
d’un dépassement de seuil ou s’il y a des variations fortes des indicateurs. La détection de
dépassement de seuil est faite à l’aide de l’algorithme suivant :

Développement d’un outil de post traitement des mesures Drive Test- Page 19
Idriss CHHIMA- SUP’COM- SFM 2011
Pour chaque cellule du réseau

Pour chaque indicateur évalué sur cette cellule

Si indicateur = seuil_zone alors alerter cette cellule

Fin pour

Fin pour

Cette méthode est appliquée sur une période d’observation donnée et elle se base sur
des analyses système en donnant une vue complète dans le temps et dans l’espace sur le
réseau. Ainsi, elle peut être utile pour donner des paramètres de QoS comme le volume de
trafic, les indicateurs sur les handovers, l’accessibilité au réseau et d’autres mesures.
Cependant, elle ne donne pas des informations précises sur la liaison radio.

2. L’analyseur de protocole

Cette méthode consiste à analyser les données échangées sur une interface donnée à
l’aide d’un outil d’acquisition pour gérer des indicateurs permettant de donner des
informations sur l’état de réseau à un moment donné. Ces mesures sont faites pour les deux
sens (montant et descendant).
La procédure est de capturer les données qui circulent sur une interface afin de
l’analyser avec un outil spécialisé pour donner des paramètres qui indiquent l’efficacité et les
coupures des appels, les handovers (causes, taux d’échec,…), l’efficacité d’envoi des SMS…
Cette méthode est aussi utilisée dans les réseaux mobiles de dernières générations. En
effet, à l’introduction de la transmission des données, des autres mesures sont opérationnelles
telle que le temps de latence moyen des paquets (FTP, http,…), les tailles des buffers, les
statistiques indiquant la signalisation et la transmission des données par session. Cette
méthode donne des paramètres significatifs de QoS comme le débit, le délai ainsi que d’autres
statistiques à propos de transmission de paquets. La capture de données peut être sur
différentes interfaces (Abis, A,… en GSM, Lu, Gn, Gi, Iub, Iur en UMTS…).

3. Le Drive Test

Le Drive Test est un outil nécessaire pour chaque opérateur durant le cycle de vie de
son réseau. C’est un moyen pour analyser convenablement les problèmes qu’on peut les
rencontrer dans l’interface radio dans le lien descendant avec une bonne précision de

Développement d’un outil de post traitement des mesures Drive Test- Page 20
Idriss CHHIMA- SUP’COM- SFM 2011
géolocalisation des anomalies. Le principe de cette opération est d’utiliser une voiture qui
contient des équipements (représentée par la figure 11) aptes à détecter et enregistrer des
paramètres logiques reflétant des mesures radio dans une zone géographique donnée et qui
agissent directement sur la QoS.
Cette méthode permet d’évaluer la couverture, la capacité et l’interférence. Aussi, elle
donne des informations sur les Handovers, les coupures de lien radio, les cellules voisines,…

Figure 11: Processus d’optimisation avec la méthode Drive Test


A partir de ces mesures, l’opérateur peut diagnostiquer les problèmes et intervenir
pour régler les pannes. De plus, ces mesures sont primordiales pour un processus
d’optimisation

4. Record détaillé de l'appel (Call Detail Record ou CDR)

Pour chaque appel d’un téléphone mobile, nous trouvons un correspondant CDR (Call
Detail Record). Cet enregistrement peut contenir des informations que l’opérateur les utilisent
pour l’identification des abonnés, la facturation des appels, les services obtenus,
l’acheminement des appels,…
La collecte des données relatives au trafic en CDR peut aider l’opérateur à générer des
statistiques et tirer les problèmes récurrents.

Développement d’un outil de post traitement des mesures Drive Test- Page 21
Idriss CHHIMA- SUP’COM- SFM 2011
5. Sonde

Cette méthode consiste à utiliser une sonde connectée au réseau pour capturer les flux.
Elle est utilisée sur les différentes interfaces et donne des mesures brutes utiles pour analyser
la performance. Nous trouvons des fournisseurs connus dans le monde de télécommunications
comme Tekelek et Astelia.

6. Enquête clients

Le contrôle de la qualité de services des opérateurs exige une évaluation continue de la


part de leurs clients. Donc, les opérateurs cherchent de recueillir les opinions de leurs clients
avec des enquêtes.

III. Étude comparative


La différence majeure entre les outils décrits précédemment est l’endroit où les
mesures sont prises. Les compteurs, OMC par exemple, se basent sur des mesures systèmes.
Pour cela, ils produisent des résultats sur le réseau entier. Néanmoins, le problème est qu’ils
ne permettent pas une comparaison concurrentielle puisque chaque constructeur possède ses
propres messages et que cette méthode ne permet pas d’analyser convenablement l’interface
radio.

Les mesures faites avec les analyseurs de protocoles permettent de détailler les
événements capturés dans les deux sens (montant et descendant). Aussi, ces mesures sont plus
utiles pour l’analyse radio et sont plus exhaustives. Cependant, l’inconvénient de cette
méthode est qu’elle est coûteuse ( problème de mise en œuvre). Les sondes se basent sur
l’analyse de flux transférés sur les différentes interfaces et elles permettent des autres
fonctionnalités telles que la surveillance en temps réel.

La méthode Drive Test est la plus efficace pour l’analyse de l’interface radio. Elle
donne des mesures avec des informations géographiques précises. Aussi, elle permet
d’analyser les réseaux concurrents. Cependant, l’inconvénient de Drive Test est que cette
méthode est fonctionnelle sur un seul sens (descendant) et elle n’apporte pas une vision
générale sur le réseau. L’enquête clients et les CDRs ne donnent que des informations
générales et ils sont souvent suivis par d’autres opérations si l’opérateur détecte des anomalies
ou insatisfactions des usagers.

Développement d’un outil de post traitement des mesures Drive Test- Page 22
Idriss CHHIMA- SUP’COM- SFM 2011
IV. Les entités de réseau mobile intervenant dans les Drive test

1. Interface radio

Dans le GSM (2G), la technologie d’accès multiple utilisée est le FD-TDMA


(Frequency Division – Time Division Multiple Access). C’est un mode hybride entre TDMA
et FDMA. Un canal occupe une bande de 200 kHz. Une trame TDMA dure 4,615 ms et est
divisée en 8 timeslots de 577 µs. Un canal physique est défini par un timeslot sur une
fréquence particulière. La modulation utilisée en GSM et GPRS (2,5G, une évolution de GSM
pour ajouter le transfert de données) est une GMSK (Gaussian Minimum Shift Keying),
offrant un débit brut d’environ 270 Kbit/s par slot. Dans l’EDGE (2,75G), il y a eu
l’introduction de la modulation 8-PSK (8-Phase-shift keying) dans le but d’augmenter le
débit.

En UMTS (3G), la technologie d’accès multiple utilisé est WCDMA (Wideband Code
Division Multiple Access). Dans cette technologie, nous utilisons une technique d’étalement
de spectre après la numérisation de la voix et sa compression qui consiste à multiplier le
signal avec un code de débit 3,84 Mb/s et en utilisant un canal de largeur 5 MHz. La
modulation utilisée est le QPSK (en HSDPA (3G+) où il y eu l’ajout de la modulation 16-
QAM (Quadrature amplitude modulation) dans les bonne conditions). Les codes sont
orthogonaux pour assurer l’accès multiple. D’où un code est associé à chaque communication,
ce qui permet de l’identifier.

2. Environnement de mesures

Le Drive Test est conçu pour les mesures de performances sur l’interface radio (Um en
GSM ou Uu en UMTS). Il indique en temps réel la couverture et la qualité du signal. Avec
ces mesures terrain, nous pouvons identifier les problèmes influents au niveau de réseau
d’accès et qui sont captés par l’usager mobile dans un lieu donné afin d’optimiser la qualité de
service avec des actions convenables. Généralement, cette opération suit les plaintes des
clients qui ont des problèmes dans leurs maisons ou bureaux.
Les paramètres principaux donnés avec cette méthode sont : la puissance de signal
reçu, les taux d’erreur binaire, les coordonnées géographiques du point de mesure, des
informations concernant l’opérateur, des mesures prises des cellules voisines, ainsi que des
informations indiquant des événements déroulés au cours de mesure (Handover, coupure

Développement d’un outil de post traitement des mesures Drive Test- Page 23
Idriss CHHIMA- SUP’COM- SFM 2011
d’appel,…). Ces paramètres sont reliés à des facteurs extérieurs qui influent sur le réseau,
parmi ces facteurs nous pouvons citer :
 Changement des conditions naturelles,
 Ajout des nouveaux bâtiments ou des arbres,
 Augmentation de nombre des abonnés,
 Variation de trafic selon le temps et les circonstances.

V. Chaîne de mesure Drive Test

Figure 12: Chaîne de mesure Drive Test


La méthode de Drive Test utilise les équipements embarqués sur une voiture qui sont
présentés dans la figure 12.

1. Mobile à trace

C’est un mobile de test équipé d’un logiciel spécial capable de s’interconnecter à un


micro-ordinateur pour transférer les mesures effectuées. Il peut faire toutes les opérations d’un
autre mobile et, en plus, il possède quelques fonctionnalités avancées comme la porte série
qui permet à l’utilisateur de l’interconnecter au micro-ordinateur et un Hyper terminal qui sert
à taper les commandes nécessaires à effectuer les opérations de mesures. Ce mobile doit avoir
une capacité qui lui permet de se communiquer avec le réseau désiré (GSM, GPRS,
UMTS,…) et une capacité de récupération de données échangées avec la station de base sur
l’interface radio. Nous avons aussi récupérer des données sur des cellules voisines
(généralement 6 cellules voisines en GSM et 4 en UMTS) comme la puissance reçue et

Développement d’un outil de post traitement des mesures Drive Test- Page 24
Idriss CHHIMA- SUP’COM- SFM 2011
l’identifiant de cellules. Ces données sont émises en temps réel à l’ordinateur portable où elles
seront stockées dans un fichier.

2. Équipement GPS

Le GPS (Global Positioning System) , qui est appelé « système de positionnement


mondial » en français, est un système de positionnement par les satellites. Son principe de
fonctionnement consiste à déterminer la distance entre le récepteur GPS et plusieurs satellites
(3 satellites au moins) afin de calculer les coordonnées de ce récepteur. Le GPS est
opérationnel sur la porteuse de 1575 MHz. Les paramètres données par le GPS est :
 Latitude : représente la distance par rapport à l’équateur. Sa valeur varie entre
0° à l’équateur jusqu'à 90° aux pôles (signe – pour le demi sud la terre).
 Longitude : représente l’emplacement est-ouest sur la terre d’un point donné
par rapport à la longitude de référence sur Terre (le méridien de Greenwich).
Sa valeur varie entre 0° et 180° (signe – pour la partie ouest de la terre).

A titre d’exemple, citons l’emplacement de la société SFM définit par : latitude =


36,830 NORD ; Longitude = 10,187 EST.

3. Ordinateur portable doté d'un logiciel d'acquisition

Cet ordinateur nous permet de traiter les données récupérées par le mobile à trace et le
GPS en les visualisant en temps réel et les enregistrer dans des fichiers pour l’analyser en
mode hors-ligne. Cet ordinateur doit être équipé par une carte interface RS 232 pour établir la
liaison entre son port série et la sortie série du mobile à trace.
De plus, il nous faut un onduleur pour assurer l’alimentation des tous les équipements
de mesure.
Après les meures Drive Test, on passe au post traitement qui consiste à traiter ces
mesures avec des outils spécialisés.

VI. Le post traitement


A partir des fichiers Drive Test, nous pouvons analyser les données pour déterminer
les anomalies qui se trouvent dans le réseau. Les données mesurées par l’opération Drive Test
sont regroupées dans l’annexe A. Des algorithmes sont mises en place pour détecter les
problèmes avec des seuils prédéfinis. Cette étape s’appelle le post-traitement qui représente
une étape importante dans le cycle de vie du réseau cellulaires.

Développement d’un outil de post traitement des mesures Drive Test- Page 25
Idriss CHHIMA- SUP’COM- SFM 2011
VII. Etude préalable
L’étude préalable nous permet d’identifier les conditions de réalisation de
l’application : étude de l’existant, étude critique, les améliorations possibles, les solutions
proposées et la solution retenue.

Étude préalable

Spécification de besoin Cahier des charges Architecture application


général
Analyse Architecture technique

Conception

Réalisation

Implémentation

Figure 13: Démarche de projet

1. Etude de l'existant

Comme le post-traitement représente une procédure vitale dans le cycle de vie de


réseau, plusieurs outils sont disponibles pour assurer cette étape. Parmi eux, les plus connus
sont :

MapInfo :

MapInfo est un logiciel puissant pour les analyses géographiques des données crée
dans les années 1980 aux États-Unis. Il est conçu pour pouvoir visualiser les relations entres
les données et la géographique. Ce logiciel est utilisé dans plusieurs domaines. On s’intéresse
au domaine de télécommunication.

Avec MapInfo, nous pouvons analyser les données d’un fichier Drive Test
géographiquement. La figure 14 représente un exemple de l’utilisation de MapInfo pour
afficher le paramètre RXLEV (en GSM) mesuré sur une carte graphique.

Développement d’un outil de post traitement des mesures Drive Test- Page 26
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 14: Exemple d’utilisation géographique de l’outil MapInfo

Avec l’option Analyse thématique, nous pouvons dessiner les mesures avec des
couleurs indiquant leurs niveaux (dans la figure précédente, le couleur vert indique une bonne
qualité, le couleur bleu pour une qualité moyenne, et le couleur rouge pour une mauvaise
qualité)

Figure 15: sélection SQL avec MapInfo


Avec l’option sélection SQL, nous pouvons afficher les mesures qui ont un caractère
prédéfini.

Enfin, MapInfo dispose d’un langage de programmation (MapBasic) pour étendre ses
fonctionnalités géographiques. Ce langage est structuré de type BASIC qui permet à ses
utilisateurs de créer des applications cartographiques puissantes. Avec MapInfo, nous
pouvons importer, exporter des données de différents types : texte, base de données, Excel,
etc.

Développement d’un outil de post traitement des mesures Drive Test- Page 27
Idriss CHHIMA- SUP’COM- SFM 2011
TEMS :

TEMS est une marque disposée par Ericsson. Cet outil (installé sur le PC) est utilisé
dans la chaîne de mesure Drive Test et pour le post-traitement. Aussi, il peut générer un
fichier utilisable par MapInfo. Les ingénieurs peuvent l’utiliser pour accélérer le dépannage
de réseau en leur permettant de trouver rapidement les problèmes de capacité réseau et les
problèmes causés par les anomalies RF. De plus, il permet de déterminer si un problème est
lié à un abonné particulier ou à des modèles téléphoniques spécifiés. Encore à l’aide de
TEMS, l’ingénieur peut créer des cartes géographiques indiquant la qualité de réseau mobile
en utilisant la géo-localisation. Aussi, il peut identifier les emplacements des problèmes de
performances réseau, tels que les appels interrompus et pollution de pilote dans un
environnement WCDMA.

Figure 16: Carte géographique avec TEMS


A partir de l’exemple donné par la figure 16, l’utilisateur peut définir les
emplacements des cellules en important un fichier .CEL à l’application contenant les
coordonnées du site.

Agilent :

Agilent représente la filiale de test et mesure de HP. Il peut aider les opérateurs à
optimiser leurs réseaux cellulaires en leur fournissant les outils permettant de collecter les
mesures Drive Test et les fonctionnalités nécessaires pour le post-traitement.

Agilent donne des histogrammes (la figure 17 est un exemple), des représentations
graphiques comme il peut fonctionner comme analyseur de spectre.

Développement d’un outil de post traitement des mesures Drive Test- Page 28
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 17: mesures sur les cellules voisines en UMTS sous Agilent
Enfin, Agilent offre aussi la fonctionnalité des analyseurs de protocoles où il peut
décoder les trames envoyées sur une interface donnée pour étudier l’état d’un réseau.

Actix :

Actix est un leader dans l’analyse et l’optimisation de réseau mobile, avec plus de 230
opérateurs clients, dont 25 sont parmi les 30 premiers opérateurs du monde entier. Fondée en
1992, aujourd’hui Actix possède des bureaux principaux au Royaume-Uni, États-Unis, la
Malaisie, l’Allemagne, le Japon, le Brésil et la Chine. En 1997, Actix a inventé le premier
outil multifournisseur de post-traitement pour l’analyse de réseaux mobiles, Analyzer, qui est
l’actuel standard de facto mondiale. En 2007, Actix mis au point une nouvelle catégorie de
logiciels pour l’automatisation des analyses de réseaux mobiles et l’optimisation, la plate-
forme d’optimisation. Comme les opérateurs sont confrontés à une vague de nouveaux défis
engendrés par une absorption massive de l’internet mobile, des grands opérateurs dans les
Amériques, en Europe et en Asie-Pacifique ont adopté la plate-forme d’optimisation
ActixOne. [4]

Aussi, il existe des autres outils de post-traitement très connus parmi eux nous
pouvons citer : Nemo de Nokia, Genex Prob, Accuver,…

Parmi les outils présentés, il y a des outils qui peuvent donner des analyses
géographiques puissants. Aussi, il y a des autres qui peuvent être intégré dans la chaîne de
mesures. En outre, ils sont des logiciels sophistiqués pour le post-traitement des données.
Cependant, comme nous pouvons remarquer dans la figure 14, cette représentation peut être
non précise (des points dessinés dans la mer). Aussi, il faut mentionner que ces logiciels sont

Développement d’un outil de post traitement des mesures Drive Test- Page 29
Idriss CHHIMA- SUP’COM- SFM 2011
couteux (par exemple une version ancienne de MapInfo coûte plus que 1000 €, ce qui
représente une contrainte pour l’utilisateur). De plus, ils sont volumineux (ils prennent
beaucoup de mémoires).

Ces logiciels donnent des représentations sur des cartes graphiques et des
histogrammes sur les paramètres mesurés sans donner les anomalies dans le réseau
(l’utilisateur sera demandé d’analyser ces représentations avec ses connaissances techniques).

2. Solutions proposées

a) Développer un module pour un outil donnée pour détecter les problèmes et les
afficher et qui intègre les connaissances techniques pour mieux analyser les
données.
b) Développer notre propre application qui peut répondre aux besoins de post-
traitement et qui peut donner des fonctionnalités semblables aux autres outils
existants et en intégrant des connaissances techniques pour repérer les problèmes.

3. Solution retenue

Vu que les outils définis précédemment ne sont pas gratuits et que l’intégration d’un
module nécessite la maîtrise d’un nouveau langage spécifique, nous avons choisi la solution
(b) qui consiste à développer notre propre outil pour le post-traitement des fichiers Drive Test.

VIII. Cahier de charge de projet

1. Cadre de projet :

Après une opération de mesures Drive-Test, l’ingénieur radio doit être apte à récupérer
les données mesurées par le mobile à trace avec un GPS et les analyser afin de déterminer les
problèmes avec un outil installé.

L’objet de mon stage est donc de concevoir et développer un tel outil qui peut analyser
et traiter les données d’un fichier Drive-Test pour les deux réseaux GSM et UMTS.

Ce stage s’est déroulé au sein de l’entreprise SFM Technologies qui apporte


l’expertise et la formation dans les domaines des réseaux de télécommunications et des
technologies d’accès ainsi que l’élaboration de plans d’affaires. [5]

Développement d’un outil de post traitement des mesures Drive Test- Page 30
Idriss CHHIMA- SUP’COM- SFM 2011
2. Spécifications de l’outil à développer

Il faut concevoir et développer un outil qui à partir des données Drive-Test peut
donner une vision sur la qualité de réseau dans les points visités. L’outil est donc peut nous
donner ces services :

 Tracer des histogrammes indiquant des statistiques sur la qualité de service.


 Tracer les points mesurés sur une carte géographique avec une représentation
indiquant la qualité de service.
 Déterminer les principaux problèmes trouvés dans le lien radio.
 Proposer des solutions utiles.
- Statistiques

Outil de post-traitement -Analyses géographiques


Fichier Drive Test des mesures Drive Test
-Problèmes reconnus

-Solution proposés
Figure 18: Schéma fonctionnel de l’outil

3. Méthodologie de travail

1- Etude bibliographique sur les réseaux GSM et UMTS, les Drives-tests, le post-
traitement.
2- Conception de l’outil.
3- Développement de l’outil.
4- Validation de l’outil et amélioration.

IX. Conclusion
Dans ce chapitre, nous avons parlé des principaux méthodes utilisées pour la
supervision de la QoS et la spécification de chacune vis-à-vis aux paramètres QoS. Aussi,
nous avons vu que l’analyse de l’existant va nous aider à avoir une idée générale sur les
fonctionnalités qui correspondent au post-traitement. En effet, cette étude nous a aidés à
élaborer l'innovation que l'on souhaite apporter.
Dans le chapitre suivant, nous allons passer à l’étape la plus sensible dans le cycle de
vie d’une application : c’est l’étape de conception qui nous permet de donner les grandes
lignes de la phase de réalisation.

Développement d’un outil de post traitement des mesures Drive Test- Page 31
Idriss CHHIMA- SUP’COM- SFM 2011
Chapitre3: Analyse et conception

Développement d’un outil de post traitement des mesures Drive Test- Page 32
Idriss CHHIMA- SUP’COM- SFM 2011
I. Présentation
Après avoir défini les objectifs de notre application et avoir cité les principales
fonctionnalités prévues, nous passons à la phase d’analyse et de conception. La conception
représente une phase primordiale et influente sur le cycle de développement d’une
application.

Dans ce chapitre, nous allons décrire la méthodologie de travail de notre outil et les
algorithmes (présentés avec des organigrammes) que nous devons les implanter pour détecter
des problèmes définis à partir de fichier Drive Test.

II. Spécification des besoins

1. Les besoins fonctionnels

Les besoins fonctionnels présentent les fonctionnalités de base que l’application doit
les fournir. Dans notre cas, ces besoins sont:

 Récupération des données mesure Drive Test à partir d’un fichier EXCEL.
 Analyse des données et détection des anomalies.
 Proposition de solutions pour les problèmes détectés.
 Analyse géographique de paramètres mesurés.
 Affichages des statistiques sous forme des histogrammes.
 Faire un reply des scénarios pris par les mesures effectués dans le mode déconnecté.
 L’application doit être paramétrable (c'est-à-dire si nous changeons des seuils, le
système doit mettre en considération ce changement dans la prochaine utilisation et
n’utilise pas des seuils par défaut).

2. Les besoins non fonctionnels

Les besoins non fonctionnels représentent les exigences qui influent sur les
fonctionnalités de base auxquels le système doit répondre. Dans le cas de notre application,
ces exigences non fonctionnelles sont :

 L’application doit être simple à utiliser.


 L’application doit posséder des bonnes interfaces qui donnent aux utilisateurs l'envie
d'y utiliser.

Développement d’un outil de post traitement des mesures Drive Test- Page 33
Idriss CHHIMA- SUP’COM- SFM 2011
 Le déplacement entre les interfaces doit être souple et facile.
 L’accès à cette application doit être sécurisé. Pour cela, il faut prévoir un module
d’authentification ;
 La réponse de l’application doit être rapide.

III. La description de la procédure d'analyse

Figure 19: Schéma synoptique de l’application

L’entrée de l’application est un fichier de mesures Drive Test pris à l’aide d’une
chaîne de mesures. Avec ce fichier, l’analyse est faite point par point de mesure pour détecter
les anomalies et transformer les données en statistiques. En effet, cette application permet
d’exécuter les tâches suivantes :

− Identification de l’utilisateur : l'utilisateur s'identifie en saisissant le nom et le mot de


passe. Si ces données sont erronées, le système lui redemandera de les saisir, sinon, il
aura accès à l’application.
− Importation de données : l’utilisateur parcourt le fichier source de données pour le
traiter et l’analyser.
− Chargement de données : cette étape est effectuée une fois le choix de la source est
terminé.
− Choix de système : l’utilisateur choisit le système de réseaux à étudier (GSM ou
UMTS).
− Analyse approfondie, génération des statistiques et analyse géographique : à partir des
données, l’utilisateur peut visualiser les mesures sous forme histogrammes et carte
géographique.

Développement d’un outil de post traitement des mesures Drive Test- Page 34
Idriss CHHIMA- SUP’COM- SFM 2011
− Détection des problèmes et proposition des solutions : le système affiche des
informations générales sur les anomalies ainsi que des solutions possibles.

IV. Les algorithmes utilisés


Pour détecter les problèmes, il faut implanter des algorithmes avec des connaissances
techniques requis. Pour chaque problème, nous trouvons des procédures qui aident à le
détecter.

1. Détection d’un problème de couverture

Dans les réseaux mobiles, chaque antenne couvre une zône géographique bien
déterminée qui peut étendre sur un diamètre de 30 Km en GSM, rurale. Le problème de
couverture apparaît lorsque les ondes émises par le mobile n'arrivent pas à la station de base la
plus proche, ou bien lorsque celles émises par l'antenne dans le sens descendant n'arrivent pas
avec une puissance suffisamment détectable par le téléphone portable. La couverture dépend
de la puissance d’émission de l’antenne, la distance entre le mobile et la station de base, ainsi
que les facteurs géographiques (obstacles, relief, climat,…). De plus, si la station de base est
chargée avec plusieurs communications jusqu'à la saturation des ses ressources, les appels ne
passent pas.

RX LEV (dBm) Niveau de la couverture

Entre -110 et -90 Mauvaise (pas de couverture)

Entre -90 et -70 Moyenne

Entre -70 et -47 Bonne


Tableau 3: Exemple d’étude de la couverture à l’aide de RX LEV
Dans le GSM, le paramètre RXLEV (niveau de signal mesuré en DBm) reflète la
couverture. Si la valeur de RXLEV est bonne, alors nous avons une bonne couverture et vice
versa. Dans la figure 20, nous donnons le procédure de détection de problème de couverture
(les seuils sont juste des exemples) :

Développement d’un outil de post traitement des mesures Drive Test- Page 35
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 20: Organigramme de détection de problème de couverture en GSM
En UMTS, il ne suffit pas que le niveau du signal (RXPOWER) soit excellent pour
avoir une bonne couverture, il faut aussi vérifier un autre paramètre (EC/I0) qui représente le
rapport signal sur interférence. Puisque dans l’UMTS nous utilisons la technologie d’accès
CDMA, nous devons prendre en considération l’interférence des autres utilisateurs qui
utilisent la même bande de fréquence.

Développement d’un outil de post traitement des mesures Drive Test- Page 36
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 21: Organigramme de détection de problème de couverture en UMTS

2. Détection d’un problème d’interférence

Les interférences représentent une source de brouillage fréquente dans les réseaux
mobiles. Ce phénomène se produit généralement lorsqu’il y a une grande demande sur les
ressources radio, ce qui exige l’utilisation des fréquences adjacents dans une zone limitée en
GSM et l’utilisation d’une même fréquence avec plusieurs codes en UMTS. Cette utilisation
peut gêner la qualité radio. Nous ne pouvons parler de ce phénomène que dans les zones
couvertes avec le réseau mobile spécifique à étudier (GSM ou UMTS). Dans ce cas, la qualité
mesurée avec les taux d’erreur binaires nous informe si l’interférence existe ou non. Pour
cela , la procédure de détection de ce problème passe à la vérification de couverture puis à
l’analyse de qualité.

La détection de ce problème en GSM est peut être assurée à l’aide d’une procédure
illustrée avec la figure 22 :

Développement d’un outil de post traitement des mesures Drive Test- Page 37
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 22: Organigramme de détection de problème d’interférence en GSM
Dans cet organigramme, nous avons choisi de vérifier la qualité du lien radio afin de
juger s’il y a interférence ou non. Ensuite, avec le niveau de champ, nous pouvons déterminer
le niveau d’interférence si elle existe.

En UMTS, le BLER nous donne le taux d’erreur bloc qui indique la qualité du lien
radio. Si sa valeur est faible, alors le mobile n’a pas de difficulté en se communiquant avec le
réseau. Sinon, nous devons analyser le niveau de champ totale (RXPOWER) et les paramètres
EC/I0 et EB/N0 pour connaitre le niveau d’interférence.

Dans la figure 23, nous présentons la chronologie de détection d’interférence en


UMTS :

Développement d’un outil de post traitement des mesures Drive Test- Page 38
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 23: Organigramme de détection de problème d’interférence en UMTS

3. Analyse des cellules voisines

Des mesures sur les cellules voisines dans les réseaux mobiles sont mentionnées dans un
fichier Drive Test. Nous pouvons parler de l’effet de dominance entre les cellules voisines qui
cause une grande interférence et qui gêne la qualité de service.

Dominance en GSM :
Les KPI donnés par les cellules voisines sont : RxLev, BSIC, FREQ. A l’aide de ces
informations, nous pouvons analyser s’il y a un problème de dominance (les points où la
cellule serveuse est faible que la voisine la plus puissante).

Développement d’un outil de post traitement des mesures Drive Test- Page 39
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 24: Informations à propos des cellules voisines à partir d’un fichier Drive-Test en GSM
Nous parlons de dominance si le niveau du champ (RxLev) d’une cellule voisine au moins
dépasse le RxLev mesuré de cellule serveuse

Figure 25: Les niveaux de champs des cellules voisines


Autrement si RxLev_voisine(i) > RxLev_serveuse (pour i entre 1 et 6), au moins pour
une seule cellule, alors nous parlons d’un problème de dominance.
Aussi, nous pouvons parler d’un autre type de dominance lorsque plusieurs voisines ont
des puissances proches de la puissance serveuse, donc leur somme peut gêner la
communication radio. Nous pouvons savoir les endroits où se trouve ce type de dominance
lorsque trois cellules voisines au moins ont un RxLev supérieure au RxLev_serveuse – 6Db.

Dominance en UMTS

Les mesures indiquant les caractéristiques des cellules voisines sont prises à partir de
canal P-PICH de chaque cellule.

Dans un réseau WCDMA, chaque cellule envoi un signal pilote sur le canal P-CPICH
(primaire canal pilote commun). Ce signal est utilisé pour distinguer les cellules les uns des

Développement d’un outil de post traitement des mesures Drive Test- Page 40
Idriss CHHIMA- SUP’COM- SFM 2011
autres dans un réseau et il est généralement transmis avec une vitesse constante. Le paramètre
EC/I0 (énergie chip sur interférence) est utilisé pour indiquer la qualité du lien radio entre le
mobile et une cellule particulière. [6]

Figure 26: Informations à propos des cellules voisines à partir d’un fichier Drive-Test en UMTS

Nous parlons de Pilot pollution si la différence entre Ec/I0 de la cellule serveuse avec
celles des cellules voisines dépasse un seuil fixé pour trois cellules au moins. Dans ce cas, la
qualité est dégradée.

Voila l’algorithme qui nous permet de détecter ce problème :

c=0

Tant que cell_i dans la liste des voisines

Si Ec/I0 (cell_i) >= (Ec/I0(serving) – seuil) alors

c = c+1

Finsi

Fin tant que

Si c >= 3 alors

Pilot pollution

Finsi

4. Détection des Handovers

Pour détecter l’emplacement de cet évènement, il suffit de déterminer les points où


l’identité de cellule change. La figure 26 donne un exemple de handover en GSM :

Développement d’un outil de post traitement des mesures Drive Test- Page 41
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 27: Détection de Handover en GSM
Il faut mentionner qu’en GSM, le BSIC (Base Station Identity Code) est utilisé pour la
différenciation des stations qui utilisent les mêmes fréquences. Le couple (fréquence, BSIC)
permet de déterminer parfaitement une cellule sur une zone donnée. Nous utilisons le même
BSIC à l’intérieur d’un motif (le plus petit nombre de cellules voisines contenant une et une
seule fois l'ensemble des canaux radio alloué à l’opérateur).

Dans l’UMTS, nous considérons que 20 à 40% des mobiles d’une zone sont en
situation de Soft Handover (connecté à 2 cellules à la fois). Dans l’UMTS, il y a deux types
de handovers : soit changement de cellules où changement de fréquence.
Dans la figure 27, un exemple pour chaque type de Handover est donné (l’UC-ID est
un identifiant unique donné à chaque cellule, il combine le RNC-ID et le C-ID) :

Développement d’un outil de post traitement des mesures Drive Test- Page 42
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 28: Détection de Handover en UMTS

5. Autres problèmes

 Coupure du lien radio en GSM: dans le fichier Drive-Test le champ RLT (Radio
Link Timeout) représente un compteur qui indique la qualité du lien radio.

L’algorithme avec lequel on calcule le RLT est le suivant :

RLT max = x (x entier entre 16 et 20)

RLT courant= x

Si (SACCH = NO) // Le mobile n’arrive pas à décoder l’information portée dans SACCH

RLT courant = RLT courant - 1

Sinon RLT courant = RLT courant + 2 / RLT courante < x

Si RLT courant = 0 coupure du lien radio

Donc:

Développement d’un outil de post traitement des mesures Drive Test- Page 43
Idriss CHHIMA- SUP’COM- SFM 2011
En UMTS, le fichier Drive Test donne les tentatives d’établissement des appels ainsi
que les résultats (échoués ou réussis). Ce qui nous permet de calculer le taux de réussite
d’établissement des appels.

V. Solutions possibles
Selon les statistiques, l’application peut déterminer s’il y a un problème gênant dans le
réseau et propose des solutions qui exigent l’intervention des techniciens. Ces solutions sont :

 Ajout des stations de base.


 Changement de puissance d’émission des antennes.
 Agir sur les paramètres antennaires (Tilt, Azimut, diagramme de rayonnement,…).
 Réviser le plan de fréquence et la distribution des codes en UMTS.

Chaque fois nous agissons sur les paramètres de site. Il faut prendre en compte les
conséquences indésirables possibles. Cependant, comme l’environnement est dynamique, il
faut faire des mesures Drive Test périodiques pour poursuivre l’état de réseau.

VI. Cas d'utilisation


Le diagramme de cas d’utilisation est une solution UML (en anglais Unified Modeling
Language ou « langage de modélisation unifié ») pour représenter le modèle conceptuel et
permettre de structurer les besoin de l’utilisateur. De plus, ce diagramme permet de classer les
acteurs. Néanmoins, il est limité aux préoccupations "réelles" des utilisateurs ; il ne présente
pas de solution d'implémentation et ne forme pas un inventaire fonctionnel du système.

Le diagramme Use-Case (cas d’utilisation) de notre application est fait à l’aide de l’outil
StarUML :

Développement d’un outil de post traitement des mesures Drive Test- Page 44
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 29: Diagramme UseCase de l’application

VII. Les diagrammes de séquence


Le diagramme de séquence nous aide à représenter la succession chronologique des
opérations réalisées par l’utilisateur. Le diagramme de séquence suivant nous explique la
première tâche faite par l’utilisateur (l’authentification) :

Figure 30: Diagramme de séquence « Authentification »

Développement d’un outil de post traitement des mesures Drive Test- Page 45
Idriss CHHIMA- SUP’COM- SFM 2011
Pour un traitement spécifique d’un problème à partir de fichier EXCEL, le diagramme de
séquence est le suivant :

Figure 31: Diagramme de séquence « Analyse »

VIII. Conclusion
Dans ce chapitre, nous avons achevé la phase d’analyse des besoins qui sert à
caractériser l’objectif du travail. En fait, il faut développer une application qui nous permet,
en plus que l’analyse géographique et statistiques des données, de détecter les problèmes et
proposer des solutions à partir des mesures Drive Test.

Encore dans ce chapitre nous avons décrit avec une façon détaillée les principales
procédures à implémenter lors du développement de l’outil ce qui va nous aider à mettre en
œuvre l’ensemble des conditions et des fonctionnalités que nous devons les respecter.

Le dernier chapitre sera consacré à la réalisation de l’outil et la validation.

Développement d’un outil de post traitement des mesures Drive Test- Page 46
Idriss CHHIMA- SUP’COM- SFM 2011
Chapitre4: Réalisation de l'outil et évaluation

Développement d’un outil de post traitement des mesures Drive Test- Page 47
Idriss CHHIMA- SUP’COM- SFM 2011
I. Présentation

Après avoir achevé la phase d’analyse qui nous permet de définir les algorithmes
nécessaires pour l’application, et après avoir abordé la phase de conception, nous passons à la
phase de réalisation où nous allons développer notre outil en intégrant les fonctionnalités
nécessaires mentionnés dans le cahier de charge.

Ainsi, la première partie de ce chapitre sera consacrée à présenter l’environnement du


travail et les interfaces développées pour l’utilisation de l’application. La deuxième partie
s’intéresse à la validation et les perspectives possibles pour l’amélioration de notre projet.

II. Environnement du travail

1. Langage de programmation

Pour développer l’application, nous avons choisi le langage C# avec Microsoft Visual
Studio. C# est un langage récent. Il a été disponible en versions beta successives depuis
l’année 2000 avant d’être officiellement disponible en février 2002 en même temps que la
plate-forme .NET 1.0 de Microsoft à laquelle il est lié. C# ne peut fonctionner qu’avec cet
environnement d’exécution. Celui-ci rend disponible aux programmes qui s’exécutent en son
sein un ensemble très important de classes. En première approximation, on peut dire que la
plate-forme .NET est un environnement d’exécution analogue à une machine virtuelle Java.
On peut noter cependant deux différences :

• Java s'exécute sur différents OS (windows, unix, macintosh) depuis ses débuts. En
2002, la plate-forme .NET ne s'exécutait que sur les machines Windows. Depuis
quelques années le projet Mono [http://www.mono-project.com] permet d'utiliser la
plate-forme .NET sur des OS tels qu’Unix et Linux. La version actuelle de Mono
(février 2008) supporte .NET 1.1 et des éléments de .NET 2.0.

• la plate-forme .NET permet l'exécution de programmes écrits en différents langages. Il


suffit que le compilateur de ceux-ci sache produire du code IL (Intermediate Language),
code exécuté par la machine virtuelle .NET. Toutes les classes de .NET sont disponibles
aux langages compatibles .NET ce qui tend à gommer les différences entre langages

Développement d’un outil de post traitement des mesures Drive Test- Page 48
Idriss CHHIMA- SUP’COM- SFM 2011
dans la mesure où les programmes utilisent largement ces classes. Le choix d'un langage
.NET devient affaire de goût plus que de performances.

En 2002, C# utilisait la plate-forme .NET 1.0. C# était alors largement une « copie » de
Java et .NET une bibliothèque de classes très proche de celle de la plate-forme de
développement Java. Dans le cadre de l'apprentissage du langage, on passait d'un
environnement C# à un environnement Java sans être vraiment dépaysé. On trouvait même
des outils de conversion de code source d'un langage vers l'autre. Depuis, les choses ont
évolué. Chaque langage et chaque plate-forme de développement a désormais ses spécificités.
Il n'est plus aussi immédiat de transférer ses compétences d'un domaine à l'autre.

C# 3.0 et le framework .NET 3.5 amènent beaucoup de nouveautés. La plus importante est
probablement LINQ (Language Integrated Query) qui permet de requêter de façon uniforme,
d'une façon proche de celle du langage SQL, des séquences d'objets provenant de structures
en mémoire telles que les tableaux et les listes, de bases de données (SQL Server uniquement
pour le moment - février 2008) ou de fichiers XML. [7]

2. Les extensions nécessaires

ZedGraph : cette librairie est destinée pour le développement sous la plateforme .NET. Pour
faire et configurer des plusieurs types de graphes, il faut télécharger le fichier ZedGraph.dll et
l’ajouter à Visual Studio pour l’utiliser dans notre projet (les histogrammes).

Koogra : comme notre application va utiliser comme entrée un fichier EXCEL, un module
sera nécessaire à ajouter pour lire les données de ce fichier. Le fichier koogra.dll peut faire
l’affaire et peut être implémenté sous la plateforme .NET.

Développement d’un outil de post traitement des mesures Drive Test- Page 49
Idriss CHHIMA- SUP’COM- SFM 2011
III. Les interfaces

1. L’authentification

Figure 32: Interface d’authentification


Pour avoir accès à l’application, l’utilisateur doit taper l’identifiant et le mot de passe
correctement. Dans le cas échéant, une nouvelle interface sera affichée, sinon le système
demandera l’utilisateur de taper ces paramètres de nouveau.

2. Importation de fichier et choix de système

Figure 33: Importation de fichier et choix de système

Développement d’un outil de post traitement des mesures Drive Test- Page 50
Idriss CHHIMA- SUP’COM- SFM 2011
Les données mesurées avec l’opération Drive Test sont enregistrées dans un fichier
EXCEL. Pour les analyser, il faut importer ce fichier en choisissant le réseau sous lequel les
mesures sont prises (GSM ou UMTS). L’interface présentée dans la figure 33 s’affiche. Dans
ce que suit, nous allons donner un exemple de mesure Drive Test pris dans la zône de
Hammam Lif (banlieue sud de Tunis) avec un réseau UMTS.

3. Réglage de paramètres

Pour que l’application exécute les algorithmes implémentés, il faut définir les seuils
nécessaires. Dans l’interface présentée dans la figure 34, nous pouvons voir l’onglet chargé
pour ce réglage. Après le choix de KPI, nous pouvons fixer les seuils. Nous avons choisi de
fixer trois niveaux de qualité. Chaque qualité sera représentée par une couleur dans
l’affichage géographique.

Figure 34: Réglage de paramètres

Développement d’un outil de post traitement des mesures Drive Test- Page 51
Idriss CHHIMA- SUP’COM- SFM 2011
Aussi, il faut définir les coordonnées extrêmes de la carte géographique pour le
fonctionnement de l’outil. Cette définition peut être soit manuelle où nous donnons la forme
décimale de ces coordonnées soit nous pouvons importer un fichier texte qui contient ces
informations (ceci est indiqué dans la figure 34).

4. Analyse et présentation graphique

 Affichages des statistiques

L’outil permet d’afficher les statistiques indiquant la variation d’un KPI donné comme
indiqué dans l’exemple de la figure 35 :

Figure 35: Statistiques de paramètre RSCP

 Présentation géographique

Après la définition des paramètres nécessaires pour la carte géographique et


l’importation d’une image qui représente la zone où les mesures sont prises, l’utilisateur peut
afficher la variation d’un KPI dans l’espace comme illustré dans la figure suivante :

Développement d’un outil de post traitement des mesures Drive Test- Page 52
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 36: Exemple de représentation géographique
 Détection des problèmes :

Comme nous avons parlé dans les parties précédentes des problèmes gênants dans les
réseaux cellulaires, l’outil nous donne des informations à propos des anomalies définies lors
du développement. Nous avons défini pour l’UMTS quatre problèmes ou observations que le
système peut les détecter. Après que l’utilisateur choisit le problème qu’il veut l’analyser,
l’application lui affiche des statistiques et même une représentation géographique comme
indiquée dans la figure 36.

Dans la figure 38 le Combo Box nous permet de choisir le problème est affiché :

Développement d’un outil de post traitement des mesures Drive Test- Page 53
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 37: Les observations détectables par l’application en GSM
Par exemple, si nous cliquons sur la couverture, la figure suivante s’affiche :

Figure 38: Exemple de détection des trous de couverture en UMTS


Comme nous avons indiqué dans la partie de conception, pour détecter le problème de
couverture dans l’UMTS, il faut analyser les deux paramètres RXPOWER qui indiquent le
niveau de champs total et EC/I0 qui représente la portion utilisable de signal sur le lien radio.
Si un paramètre parmi eux est inférieur à un seuil défini, un problème de couverture est
détecté.

Dans la figure 39, nous présentons les points mal couverts dans une carte
géographique :

Développement d’un outil de post traitement des mesures Drive Test- Page 54
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 39: Affichage géographique de problème de couverture
Aussi, l’application nous permet de détecter le problème de pilot pollution comme indiqué
dans la figure suivante :

Figure 40: Détection de problème de pilot pollution

Développement d’un outil de post traitement des mesures Drive Test- Page 55
Idriss CHHIMA- SUP’COM- SFM 2011
Figure 41: Changement de cellule
Dans la figure 41, nous remarquons l’emplacement où il y a eu un changement de cellule.

Figure 42: Détection de l’interférence

Développement d’un outil de post traitement des mesures Drive Test- Page 56
Idriss CHHIMA- SUP’COM- SFM 2011
Dans la figure précédente, les points où il y a le problème de l’interférence sont présentés.

 Sélection : l’utilisateur peut sélectionner les points vérifiant des critères donnés et les
afficher graphiquement. Dans la figure 42, nous donnons un exemple de sélection des
points où le paramètre RSCP est entre -110 et -90 Dbm :

Figure 43: Exemple de sélection selon un critère donné

IV. Les tables créées par l’application


Au cours de l’exécution de l’application, des tables qui contiennent les paramètres
sont créées automatiquement dans le répertoire « C:/SFM » sous formes des fichiers .Txt. Les
principales tables sont :
 Table seuils : contient les seuils définis pour les KPIs utilisés (il y a une table pour
chaque système cellulaire)
 Tables pour les problèmes : ces tables sont utilisées au cours de programme pour
enregistrer les points où il y a un problème détecté temporairement pour l’utiliser
ultérieurement.
 Table sélection : il contient les points qui vérifient des conditions définies par
l’utilisateur.

Développement d’un outil de post traitement des mesures Drive Test- Page 57
Idriss CHHIMA- SUP’COM- SFM 2011
V. Évaluation de l’outil
Évaluer l’application revient à comparer les résultats obtenus aux objectifs fixés.
L’objectif de notre projet était de concevoir et de développer une application permettante
l’évaluation de performances d’un réseau cellulaire à partir d’un fichier contenant des
mesures pris avec l’opération Drive Test.

1. Avantages

 L’outil est simple à utiliser.

 Une grande précision dans la représentation géographique.

 Intégration des connaissances techniques dans l’outil.

 Des interfaces compréhensibles et claires pour l’utilisateur.

2. Désavantages

 Nécessite une préparation de carte graphique.

 Il faut ajouter une option « Agrandir » pour l’affichage géographique.

 L’analyse technique n’est pas exhaustive.

 Proposition des solutions en devinant à partir des statistiques.

VI. Conclusion
Dans ce chapitre, nous avons présenté d’une façon détaillée notre outil pour que
l’utilisateur arrive à comprendre comment l’appliquer.

Cet outil est opérationnel pour les deux réseaux cellulaires de deuxième et troisième
génération. Certes les analyses et les présentations données par notre application vont nous
donner les informations nécessaires pour déterminer les ambigüités dans un réseau donné.

Cette application peut être améliorée en intégrant plus des connaissances techniques
et en ajoutant plus des paramètres radio pour chaque réseau.

Développement d’un outil de post traitement des mesures Drive Test- Page 58
Idriss CHHIMA- SUP’COM- SFM 2011
Conclusion générale

Ce rapport présente notre travail de projet de fin d’études qui avait déroulé sous le
thème développement d’un outil de post traitement des mesures Drive Test pour les réseaux
mobiles.
En effet, il s’agit de la réalisation d’une application qui permet à l’utilisateur
d’analyser les données mesurées sur terrain par l’opération Drive Test et qui donne des
recommandations nécessaires pour la procédure d’optimisation en se basant sur des
statistiques et des observations.
Pour la réalisation de ce projet, nous avons tout d’abord commencé à exprimer
l’importance de la qualité de service dans le cycle de vie d’un réseau ainsi que les méthodes
de maintenance qui aide l’opérateur mobile à satisfaire ce besoin et en particulier la méthode
Drive Test. En effet il s’agit d’une méthode efficace pour le contrôle de l’interface radio.
Ensuite nous avons donné les outils existants les plus connus afin de donner une perspective
sur l’outil qu’on désir développer. Nous avons abordé, par la suite, les procédures nécessaires
pour la détection des problèmes que nous devons l’intégrer dans l’outil ainsi que la phase de
la conception. Enfin, nous avons présenté les résultats obtenus du fonctionnement de
l’application développée.
Comme les réseaux mobiles s’évoluent de temps en temps, la maintenance de
l’interface radio reste une priorité chez les opérateurs surtout avec la limitation des ressources
radio. Pour cela, l’opération Drive Test est vitale pour mesurer et ajuster les paramètres radio.
Après l’utilisation de cette opération dans les systèmes GSM et UMTS, le Drive Test est
utilisé aussi dans le système LTE avec des nouveau KPIs caractérisant les technologies
utilisées dans ce réseau. Donc, l’outil peut être extensible pour le post traitement des fichiers
Drive Test contenants des mesures prises pour un réseau LTE ou même pour un réseau de
quatrième génération.

Développement d’un outil de post traitement des mesures Drive Test- Page 59
Idriss CHHIMA- SUP’COM- SFM 2011
Annexe

Développement d’un outil de post traitement des mesures Drive Test- Page 60
Idriss CHHIMA- SUP’COM- SFM 2011
I. ANNEXE A

1. Fichier Drive-Test d’un réseau GSM :

Les indicateurs donnés par ce fichier indiquent la qualité du réseau mesurés dans des points
définis (avec ses latitudes et longitudes). Les principaux KPI sont :

Cell ID (2G) : c’est un nombre unique qui permet d’identifier une BTS au sein d’une
zone de localisation (défini avec un LAC (location area code)) ou même au sein d’un
réseau.
BCCH CH Num : donne l’identifiant du canal BCCH (Broadcast Control Channel).
TCH CH Num : donne l’identifiant du canal TCH (Trafic Channel).
BSIC : Base Station Identity Code : c’est un code distinguant 2 BTS utilisant la même
fréquence en voie balise, le BSIC est utilisé encore pour déterminer la séquence
d’apprentissage (coloriage des bursts).
Time Slot Num : comme la trame en GSM est divisée en 8 Time slots, on définit pour
chaque slot un numéro, ce paramètre représente le Time slot sur le quel on a pris les
mesures.
LAC : Location Area Code : un groupe des BTS définissent une région qui sera
représenté par un LAC (transmise dans la signalisation).
Channel Type : type de canal sur la quel la connexion est établie.
Serving Rx Power : puissance totale reçue de la station de base.
Rx Lev : pour juger la qualité de la liaison radio on utilise ce paramètre et on définit :
 Rx Lev Full : c’est une mesure sur tous les bursts de la trame sans exception.
 Rx Lev Sub : c’est une mesure sur les bursts effectivement utilisés.
RxQual : mesure la qualité de signal, de même que Rx Lev, il existe Rx Qual Full et
RxQual Sub. Il est obtenu en effectuant une quantification du taux d'erreurs binaires BER
(Bit Error Ratio) suivant la correspondance du tableau suivant :
Correspondance RxQual i <> BER
RxQual Niveau de qualité i BER, plage de Valeur
valeur représentative
0 BER < 0.2 % 0.14 %
1 0.2 % <= BER < 0.4 % 0.28 %
2 0.4 % <= BER < 0.8 % 0.57 %
3 0.8 % <= BER < 1.6 % 1.13 %
4 1.6 % <= BER < 3.2 % 2.26 %
5 3.2 % <= BER < 6.4 % 4.53 %
6 6.4 % <= BER < 12.8 % 9.05 %
7 12.8 % <= BER 18.10 %
Tableau A. Variation de RxQual

Développement d’un outil de post traitement des mesures Drive Test- Page 61
Idriss CHHIMA- SUP’COM- SFM 2011
FER Total : FER (Frame Erasure Ratio): c’est la quantité des trames de parole balayé
sur la quantité des trames de parole transmis (chaque trame contient 260 bits).
Tx Lev : niveau de la puissance transmise.
TA : Timing Advance : est utilisé pour déterminer la distance entre le mobile et la
station de base en déterminant le délai de propagation.
TA FROM TO
0 0 µs (0m) 3.69µs (553.5m)
1 3.69µs (553.5m) 7.38µs (1107m)
2 7.38µs (1107m) 11.07µs (1660.5m)
3 11.07µs (1660.5m) 14.76µs (2214m)
… … …
63 232.47µs (34.87km) 236.16µs (35.42km)
Tableau B. Différente valeur de TA
RLT(MAX) : RLT : Radio Link Timeout : compteur qui aide à déterminer le taux de
coupure des appels, si le MS reçoit correctement le block SACCH (Slow Associated
Control Channel) durant la communication cette valeur (RLT) est incrémenté par 2 (tant
que inférieure à une valeur maximale), sinon elle sera décrémenter par 1, si elle atteint 0
l’appel est coupée. RLT(MAX) est la valeur qu’au-delà on n’incrémente pas le compteur
RLT (valeur fixé par l’opérateur et varie entre 16 et 20).
RLT(Current) : la valeur de RLT courant, elle est calculée à l’aide de l’algorithme
suivant :
RLT max = x (x entier entre 16 et 20)
RLT courant= x
Si (SACCH = NO)
RLT courant = RLT courant - 1
Sinon RLT courant = RLT courant + 2 / RLT courante < x
Si RLT courant = 0 coupure du lien radio
DSC : Downlink Signal Failure Counter : Compteur de bursts non-décodés sur le
canal PCH. initialement DSC égale au plus proche entier de 90 / PRP avec PRP c’est la
Paging Repeat Period (Nombre de "multi-trame_51", pendant lesquels le mobile espace
son écoute du canal "PCH" (Paging Channel), valeur entre 2 et9).
Par la suite, le MS essaye de décoder un message dans son sous-canal de Paging, la valeur
de DSC sera incrémenté par 1(jamais au delà de l’entier de 90/PRP la plus proche) si le
message est bien décodé, sinon on décrémente DSC par 4.
Si la valeur DSC tombe à 0, une autre cellule est ré-sélectionnée.
Cette mesure est effectuée lorsque le mobile est en veille.

Développement d’un outil de post traitement des mesures Drive Test- Page 62
Idriss CHHIMA- SUP’COM- SFM 2011
2. Fichier Drive-Test d’un réseau UMTS :

Dans l’UMTS, avec les améliorations dans le sous-système radio, nous définissons des
nouveaux KPI.

Un fichier Drive-Test nous donne ces principaux KPI :

UC-ID : UMTS CELL IDENTITY : pour identifier la cellule dans tout le réseau, UC-ID
= RNC-ID+C-ID.
RNC-ID : représente l’identité de le RNC (Radio Network Controller).
C-ID : identité locale d’une cellule dans un RNC.
Frequency : la fréquence utilisée au cours de mesure.
RRC State : RRC c’est l’abréviation de Radio Resource Control, Lorsqu’une
communication est établie par un équipement usager, une connexion de type RRC est
établie entre celui-ci et un RNC du réseau d’accès UTRAN.son rôle est la gestion de la
connexion de signalisation établie entre l’UTRAN et le mobile, le RRC State indique le
type de canal alloué.
MCC : Mobile Country Code : Code de pays dans le plan GSM/UMTS (605 pour la
Tunisie).
MNC : Mobile Network Code : est utilisé avec le MCC pour donner un identifiant
unique pour un opérateur.
MCC MNC Marque Opérateur
605 01 Orange Orange Télécom
605 02 Tunicell Tunisie Télécom
605 03 Tunisiana Orascom Telecom Tunisie
Tableau C. Les identifiants des opérateurs tunisiens.
LAC : Location Area Code : un groupe des Node B définissent une région qui sera
représenté par un LAC
RX Power : La puissance de signal reçu.
TX Power : La puissance émise par la Node B.
SIR: Signal To Interference Ratio: rapport signal sur interférence.
BLER : Block Error Rate : c’est le pourcentage des blocs RLC erronés par rapport au
nombre total des blocs RLC transmis, l’équation suivante donne l’équation de BLER :
BLER= *100%. BLER est mesuré en UL et DL
direction
SF : Spreading Factor : c’est le facteur d’étalement, SF = durée symbole de signal
initial sur durée symbole de code utilisé au cours de l’étalement de spectre. Dans le fichier
Drive-Test on peut lire le SF dans le deux sens (montant et descendant).
Best PSC : Best Primary Synchronisation Code: les cellules envoient un code modulé
de 256 chips chaque slot (sur le canal SCH) afin que le MS peut choisir la cellule dont la
qualité est la meilleure.

Développement d’un outil de post traitement des mesures Drive Test- Page 63
Idriss CHHIMA- SUP’COM- SFM 2011
Best EC/I0 : EC/I0 représente le rapport de l’énergie pilote reçue sur l’énergie totale
reçue, aussi elle représente la portion utilisable du spectre.
Best RSCP : Received Signal Code Power : c’est la puissance reçue du signal utile
multiplié par un code d’étalement. On peut comparer les valeurs des différents signaux afin
de choisir le code optimal pour la communication (elle est mesurée que dans la voix
descendant).
Combined EC/I0 :
TOP 1 PSC : la meilleure mesure PSC des cellules voisines.
TOP 2 PSC : la deuxième meilleure mesure PSC des cellules voisines.
TOP 3 PSC : la troisième meilleure mesure PSC des cellules voisines.
TOP 4 PSC : la quatrième meilleure mesure PSC des cellules voisines.
TOP 1 EC/I0 : la meilleure mesure EC/I0 des cellules voisines.
TOP 2 EC/I0 : la deuxième meilleure mesure EC/I0 des cellules voisines.
TOP 3 EC/I0 : la troisième meilleure mesure EC/I0 des cellules voisines.
TOP 4 EC/I0 : la quatrième meilleure mesure EC/I0 des cellules voisines.
CQI : Channel Quality Indicator : c’est une mesure indiquant la qualité de canal, si
cette valeur est élevée on parle d’une qualité bonne et vise versa.
Système type : le type de système 3G utilisé (WCDMA, HSUPA, HSPA,…).

Développement d’un outil de post traitement des mesures Drive Test- Page 64
Idriss CHHIMA- SUP’COM- SFM 2011
II. ANNEXE B

1. Les fichiers Drive Test :

Comme nous avons mentionnés, l’entrée de l’application est un fichier EXCEL qui
contient des mesures Drive Test, les colonnes se réfèrent à l’identification des paramètres et
les lignes représentent la variation de ces paramètres au cours de temps comme montre
l’exemple en UMTS dans la figure suivante :

Figure A. Exemple de fichier Drive Test (réseau UMTS)

Les paramètres données indique des informations à propos de l’opérateur, niveau de signal, la
qualité, taux d’erreur binaire, les cellules voisines, etc., comme illustré dans l’annexe B

Dans notre projet ce fichier est généré par l’outil ACCUVER, dans la figure suivante nous
donnons un exemple sur la suivie en temps réel des KPI avec cet outil :

Développement d’un outil de post traitement des mesures Drive Test- Page 65
Idriss CHHIMA- SUP’COM- SFM 2011
Figure B. Variation des KPI en temps real affiché à l’aide d’ACCUVER

Développement d’un outil de post traitement des mesures Drive Test- Page 66
Idriss CHHIMA- SUP’COM- SFM 2011
Bibliographie

[1] principes de radiocommunication de troisième génération Thierry lucidarme

[6]Impact of Pilot Pollution on SHO Performance Tero Isotalo, Jarno Niemelä, Jakub

Borkowski and Jukka Lempiäinen

[7] APPRENTISSAGE DU LANGAGE C# 2008 et du Framework .NET 3.5

Serge Tahé - ISTIA - Université d'Angers Mai 2008

Webographie

[2] ITU-T www.itu.int – site officiel de l’Union Internationale des Télécommunications

(Dernière consultation 22-6-2011)

[3] http://wapiti.telecom-lille1.eu (Dernière consultation 20-6-2011)

[4] www.actix.com (Dernière consultation 3-6-2011)

[5] http://www.sfmtelecom.com (Dernière consultation 9-6-2011)

Développement d’un outil de post traitement des mesures Drive Test- Page 67
Idriss CHHIMA- SUP’COM- SFM 2011