Pfe

Support Réseau d’Accès

Rapport de Projet de Fin d’Etudes
Tuteur : Vincent Huriet (UNRA Alcatel)

Christophe Le Roquais
Jean-François Vandemoortele

Département Télécommunications, Services et Usages

Du 10 Février 2003 au 06 Juin 2003

Orange UNR Lyon Vaise

Résumé
Niveau de diffusion
Mesure de la qualité de service du réseau GPRS côté utilisateur pour Contrôlée 2
interprétation au niveau BSS. Implémentation d’une solution
Interne 3
automatisée de tests de performances. Modes opératoires.
Libre 4

OrangeFrance
Reproduction interdite sans autorisation préalable


Validation
Nom Entité Date
Le Roquais Christophe
Auteur(s) DRA/DEX/UNRA 08/06/03
Vandemoortele JF
Vérificateur(s) Vincent Huriet DRA/DEX/UNRA 10/06/03
Approbateur(s)

Historique de mise à jour
Version Auteur Objet
0.1 Le Roquais Christophe Création du document
Vandemoortele JF

1.0 Le Roquais Christophe Correction après relecture de Vincent Huriet
Vandemoortele JF

Mots clés
Automatisation, GPRS, tests, ping, FTP, HTTP, WAP

OrangeFrance


SOMMAIRE :

INTRODUCTION.............................................................................................................................................................4

GLOSSAIRE .....................................................................................................................................................................5

1 CONDUITE DE PROJET : .....................................................................................................................................6
1.1 DEMARCHE : ......................................................................................................................................................6
1.2 PLANIFICATION : ................................................................................................................................................7
1.2.1 Planning et organisation en binôme : ...........................................................................................................7
1.2.2 Etape 1 : semaines 7 et 8...............................................................................................................................8
1.2.3 Etape 2 : Semaines 11 à 13 ...........................................................................................................................8
1.2.4 Etape 3 : Semaines 14 à 16 ...........................................................................................................................9
1.2.5 Etape 4 : Semaine 18.....................................................................................................................................9
1.2.6 Etape 5 : Semaines 20 à 23 ...........................................................................................................................9
1.3 COMMUNICATION ET RETOUR CLIENT : ............................................................................................................10
2 PRESENTATION DE LA SOLUTION : .............................................................................................................11
2.1 PRESENTATION SOMMAIRE DU RESEAU GPRS :................................................................................................11
2.2 ARCHITECTURE GLOBALE : ADEQUATION AVEC LE PROTOCOLE DE TEST .........................................................12
2.3 DESCRIPTION TECHNIQUE DE LA SOLUTION ......................................................................................................14
2.3.1 Introduction et prérequis : ..........................................................................................................................14
2.3.2 Description de l’implémentation des outils de tests :..................................................................................18
2.3.3 Présentation des délivrables : .....................................................................................................................28
2.4 VALIDATION ET EXPERIMENTATIONS ...............................................................................................................30
3 ANALYSE DES RESULTATS : ...........................................................................................................................31

CONCLUSION : .............................................................................................................................................................33

REMERCIEMENTS : ....................................................................................................................................................33

INDEX DES FIGURES : ................................................................................................................................................34

BIBLIOGRAPHIE : .......................................................................................................................................................34

ANNEXES .......................................................................................................................................................................35
ANNEXE 1 : PROTOCOLE DE TEST (CHEF DE PROJET : PHILIPPE GABARD) ....................................................................35
ANNEXE 2 : CODES OPERATOIRES D’UN ECHANGE WAP .................................................................................................36
ANNEXE 3 : DIAGRAMME DE GANTT...........................................................................................................................37

OrangeFrance


Introduction
L’Unité Nationale Réseau d’Accès (UNRA) d’Orange France s’occupe de gérer le réseau national d’Orange
pour la partie radio appelée encore BSS (Base Station Subsystem). Les infrastructures BSS s’appuient sur
trois constructeurs : Alcatel, Nortel et Motorola. C’est pour cette raison que l’UNRA est composée de trois
entités s’occupant chacune d’un constructeur. Les activités de l’UNRA consistent principalement à évaluer,
optimiser, migrer et superviser le réseau d’accès. Une autre activité non négligeable consiste à offrir un
support technique pour les Unités Régionales (UR) d’Orange.

Le réseau de données GPRS étant une technologie récente, il n’existe pas actuellement de protocole de
mesures standardisé permettant d’établir des comparatifs entre constructeurs, entre paliers ou encore
simplement pour vérifier la qualité du service offert par le réseau d’accès. Un groupe de travail impliquant
différents acteurs s’est mis en place pour réfléchir à un protocole de tests répondant à ce besoin.

Notre Projet de Fin d’Etudes s’inscrit au sein de ce groupe de travail en qualité de participant à l’élaboration
de ce protocole de tests et en tant que développeurs d’une solution logicielle correspondant au protocole
établi.

Il nous a donc été proposé de participer à la définition d’un ensemble de tests de performances pour
quantifier et qualifier le réseau d’accès pour le GPRS. Pour automatiser ces tests, nous avons développé une
solution logicielle basée sur des scripts évolués. Ces scripts permettent d’acquérir les mesures de Qualité de
Service et de les traiter automatiquement.

Différentes entités du groupe France Télécom sont impliquées dans ce projet de grande ampleur. Le groupe
de travail, dirigé par Philippe GABARD (Responsable Etudes GPRS), a pour but de définir les spécifications
des tests de performances GPRS. France Télécom R&D apporte son expertise technique et son expérience
acquise lors des expérimentations obtenues sur les plate-formes de tests. Les Unités Régionales (UR) et
l’UNRA sont concernées en premier lieu par le projet car ils constituent les utilisateurs finaux. Vincent
HURIET (Skill Centre Field Testing & Support Expert GSM Alcatel) a pris part à ce projet en tant que
responsable pour l’UNRA. Au sein de l’UNRA et dans le cadre du PFE, nous nous sommes engagés à
fournir une solution logicielle répondant aux spécifications du protocole de tests.

Le projet de PFE a été crée à l’initiative du Groupe Support Réseaux d’Accès Alcatel (GSRA Alcatel).
Vincent HURIET a été l’initiateur de ce projet et il nous a encadré pendant les 11 semaines de projet. Même
si le projet a été lancé par le GSRA Alcatel, la solution a été développée dans le souci d’une compatibilité
multi constructeurs. Martin PASQUIER (Ingénieur GSRA) a suivi notre projet et nous a donné des
informations techniques qui nous ont permis de mieux comprendre le GPRS.

L’Unité Nationale Réseau (L'UNR est l'entité chargée d'exploiter le cœur de réseau mobile d'Orange…) a
quant à elle, été informée de notre projet car notre solution pourrait être adaptée à leurs besoins en effectuant
peu de modifications.

Remarque : dans la suite du document, toutes les adresses IP confidentielles ont été volontairement cachées.

OrangeFrance


Glossaire

PFE : Projet de Fin d’Etudes
GPRS : General Packet Radio Service
UNR : Unité Nationale Réseau
UNRA : Unité Nationale Réseau d’Accès
UR : Unité Régionale
OMC : Operation and Maintenance Center (logiciel de supervision du réseau)
FT R&D : France Télécom Recherche et Développement
DTRS : Direction Technique Réseau et Services
BSS : Base Station Subsystem (rensemble des équipements radios : BTS, BSC, PCU,…)
GSS : Cœur de réseau GPRS
GGSN : Gateway GPRS Support Node (routeur vers les réseaux GPRS de données ou externes)
SGSN : Serving GPRS Support Node (routeur connecté à un ou plusieurs BSS)
MFS : Multi-BSS Fast Packet Server
PCU : Packet Coding Unit
Interface Gb : interface entre le PCU et le SGSN
APN : Access Point Name
MTU : Maximum Transmission Unit
RWIN : TCP Receive Window Size
RAS : Remote Access Service
TLLI : Temporary Logical Link Identifier (identifiant temporaire à l'établissement d'une communication)
IMSI : International Mobile Suscriber Identifier ( identifiant inclus dans la carte SIM)
URL : Unified Ressource Locator (adresse internet)
WAP : Wireless Application Protocol (accès Internet depuis un mobile)

OrangeFrance


1 Conduite de projet :

1.1 Démarche :

Lorsque nous sommes arrivés à Orange, nous avions à rédiger un protocole de tests permettant de mesurer la
qualité de services du réseau GPRS côté utilisateur. Ce protocole de tests, dont la finalisation a été déléguée
par la suite à un groupe de travail géré par Philippe Gabard, était à l’état de draft pendant la durée de notre
projet. Nous avons donc concentré nos efforts plutôt dans le cœur de la mission qui nous avait été confiée,
c’est-à-dire l’implémentation d’outils de tests fiables et de documents permettant aux techniciens et
ingénieurs de réaliser ces tests dans de bonnes conditions.

Nous avons ainsi organisé notre projet selon un cycle en V, en partant nécessairement de l’expression des
besoins, après analyse de l’existant. Notre travail a donc été dans un premier temps de prendre en compte les
modes opératoires existants selon lesquels les tests étaient effectués et il s’avère que les protocoles pour
certains types de mesures n’étaient pas très précis et étaient souvent fondés sur des mesures manuelles.

Après identification des besoins, nous avons rédigé un premier document de spécifications fonctionnelles qui
a été validé par Vincent Huriet, ce qui nous a permis de cadrer le périmètre du projet. Des contraintes fortes
étaient mentionnées dans ce document :Déployable sur les PC portables d’Orange, sans acquisition de
licences supplémentaires.
Automatisation aisée, précise et paramétrable
Facilité et souplesse d’exploitation
Précision des résultats (temps entre chaque ping respecté, taille de paquet correcte,…)
Pérennité de la solution
Adéquation avec le set de mesures fixé par le groupe de travail de Philippe Gabard
Adaptabilité à tous les mobiles du marché

Nous avons ensuite réalisé un état de l’art des logiciels qui répondraient aux spécifications que l’on s’étaient
fixées. Nous nous sommes d’abord intéressés aux logiciels permettant de réaliser les tests de latence où
plusieurs outils ont été identifiés et testés selon les critères des spécifications. En ce qui concerne les tests de
débit, nous nous sommes surtout basés sur le FTP de la commande DOS, outil éprouvé sur le terrain et utilisé
par FT R&D et les UR d’Orange.

Après sélection des outils, nous avons conçu une solution automatisable de tests de performance se basant
sur des scripts, dont l’architecture sera détaillée dans la suite du document.

Cette phase de conception a été suivie par l’implémentation de la solution, phase qui a été relativement
longue et qui demandait aussi bien des tests unitaires que des tests d’intégration avec plusieurs types de
configurations.

Tout au long du projet, nous avons axé notre action, avec Vincent Huriet, sur la communication autour du
projet, avec des présentations aux acteurs de l’UNR, de l’UNRA mais également aux UR et aux filiales
d’Orange.

OrangeFrance


1.2 Planification :

1.2.1 Planning et organisation en binôme :

Le PFE s’est déroulé entre février et juin 2003 en alternance avec les cours d’option à l’INSA. La durée
minimale du PFE est fixée à 10 semaines pendant cette période. Après avoir évalué le coût du projet en
hommes/jour, il s’est avéré qu’il nous fallait plus de 10 semaines pour atteindre les objectifs souhaités. C’est
pour cela que notre PFE a duré au total 11 semaines, une semaine ayant été prise sur les congés de
printemps.

Comme nous n’avions pas choisi la même option de spécialité, nous n’étions pas toujours ensemble chez
Orange. Nous avons eu 9 semaines en commun et 2 semaines où nous étions seuls chez Orange. Cette
organisation n’a pas été trop gênante car les semaines de début et de fin de PFE étaient communes.

Le PFE étant en alternance avec les cours, il a été découpé en cinq étapes :
- Du 10 au 21 février
- Du 17 au 28 mars
- Du 7 au 18 avril
- Du 28 avril au 2 mai
- Du 12 mai au 6 juin

Nous avons crée un diagramme de GANTT au début du projet pour planifier le projet et pour se donner des
dates butoirs. Ce diagramme est fourni en Annexe 3. Ce diagramme nous a permis de fixer les grandes lignes
directrices pour le projet. Suite aux différents évènements non prévisibles, nous n’avons pas forcément suivi
à la lettre le diagramme de GANTT. Nous avons cependant travaillé dans le souci d’atteindre les objectifs
prévus. La figure suivante montre de manière simplifiée l’évolution du projet au cours des semaines.

Etape 1 :
Définition claire et précise du
sujet, Analyse de l’existant, Etape 2 et 3 :
Recherche documentaires Evaluation des outils
potentiels, Développement des Etape 4 :
scripts Ping et FTP Développement des
scripts http et WAP Etape 5 :
Derniers déboguages, production de
notices/documents, transfert de
compétences, présentation des
délivrables

10 fév. 22 fév. 18 avr. 2 mai
2003 2003 2003 2003

Figure 1 : Chronologie simplifiée du projet

OrangeFrance


1.2.2 Etape 1 : semaines 7 et 8

Familiarisation avec l’environnement de travail (3 jours) :

Nous sommes arrivés à l’UNRA le 10 février 2003. Les deux premiers jours, nous avons occupé
temporairement les bureaux de l’équipe GSRA en attendant que notre bureau soit installé. Cela a été un bon
moyen pour faire connaissance avec les membres de l’équipe à laquelle nous étions rattachés.
Nous nous sommes familiarisés avec le système d’information d’Orange (compte NT, compte Mail,
applications…). Chaque membre de l’équipe nous a expliqué son métier ce qui nous a permis de mieux
situer l’activité de l’équipe GSRA. Un de nos collègues nous a notamment montré l’OMC Alcatel (logiciel
de supervision du GSM/GPRS). Nous avons fait plusieurs réunions avec Vincent HURIET pour bien cibler
les objectifs du projet.

Documentation et tests basiques de GPRS (2 jours) :

Une fois familiarisés avec l’environnement de travail, nous nous sommes mis à chercher des documentations
qui pouvaient nous servir de base pour le projet.
Nous avons lu des documentations techniques pour mieux nous familiariser avec le réseau GPRS.
Parallèlement nous avons découvert de façon pratique le réseau GPRS en effectuant des connexions modem
GPRS. Cela a permis de faire des tests simples : connectivité au réseau GPRS, navigation sur Internet en
utilisant un mobile GPRS.

Initiation au TOM4 (1 jour) :
Nous nous sommes intéressés aux équipements existants qui permettent d’acquérir des données spécifiques
au réseau GPRS à partir de différentes interfaces. Parmi ces outils, le logiciel TOM4, de l’éditeur Nemo
Technologies, est une solution qui permet de capturer les messages passant par le lien radio. Il récupère par
exemple le débit instantané par timeslot et peut, après acquisition, traiter les données et les représenter sous
forme de graphiques. Nous avons donc pendant une journée exploré les caractéristiques de cet outil.

Initiation au K1205 (1 jour) :
Le K1205 de Tektronix est également un outil utilisé couramment pour capturer les messages GSM/GPRS.
C’est un analyseur de protocoles hardware qui permet de capturer les messages sur différentes interfaces :
Abis, Gb, Gi. Le visualiseur appelé K12 Viewer peut être installé sur n’importe quel PC et permet de voir
tous les champs des messages capturés. Le K12 est un outil très puissant qui nous a beaucoup servi pendant
le projet.

Listage des paramètres et des tests (3 jours) :
Nous avons remis à Vincent HURIET un dossier de spécifications fonctionnelles du projet avec l’explication
des tests que l’on préconisaient en tenant compte des paramètres en jeu.
Nous avons participé à une réunion par pont téléphonique avec Philippe GABARD et les autres acteurs du
groupe de travail. Cette réunion avait pour but de confronter les avis de chacun des acteurs du groupe de
travail sur le Draft 0.3 du protocole de tests.

1.2.3 Etape 2 : Semaines 11 à 13

Evaluation des outils de tests Ping et FTP pouvant être utilisés (5 jours)
Nous nous sommes dans un premier temps intéressés seulement aux tests de Ping et de FTP car ce sont les
tests les plus couramment utilisés. Nous avons recherché des outils de Ping et de FTP gratuits, fiables et
répondant aux spécifications du protocole de tests. Pour tester la fiabilité des outils sélectionnés, nous avons
comparé les résultats qu’ils fournissaient avec les résultats obtenus par l’analyseur de protocole Ethereal.

OrangeFrance


Choix des outils de tests (1 jour)
Après avoir évalué les différents outils du marché nous avons sélectionné ceux qui allaient nous servir.

Développement des scripts Ping et FTP (4 jours)
Nous avons programmé les premières versions des scripts permettant d’automatiser les tests de Ping et de
FTP.


Finalisation des scripts Ping et FTP (4 jours)
Nous avons finalisé l’automatisation des scripts Ping et FTP.

Développement d’un script de connexion automatique (2 jours)
Pour pouvoir lancer une connexion au réseau GPRS de façon automatique, nous avons développé un script.

Validation de ces tests (3 jours)
Nous avons lancé en journée et toutes les nuits les tests Ping et FTP pour savoir s’il fournissaient des
résultats cohérents.

Réunion du groupe de travail à Paris (1 jour)
Nous sommes allés à Paris pour assister à la réunion du groupe de travail. Cette réunion avait pour but la
rédaction finale du protocole de tests, ainsi que la présentation d'une préversion de nos scripts..

1.2.5 Etape 4 : Semaine 18

Développement des scripts HTTP et WAP
Outre les tests de Ping et de FTP, nous avons voulu développer l’automatisation des tests HTTP et WAP. Sur
le même principe que les tests de Ping et de FTP, nous avons écrit des scripts d’automatisation.
Parallèlement, les premiers tests du grouep support Motorola en zone expérimentale débutaient, avec le test
des scripts Ping et FTP.


Finalisation des scripts et déboggage des derniers problèmes (5 jours)
Les tests ont été finalisés avec des ajouts de commentaires et une compatibilité entre Win98 et Win2000. Les
scripts ont également été complétés pour assurer une compatibilité entre les versions anglaises et françaises
de Windows.
Suite aux tests menés quotidiennement, des bogues ont été corrigés.

Présentation de la solution à l’UNRA et à l’UNR (1 jour)
Nous avons présenté notre solution aux équipes de l’UNRA et de l’UNR. L’UNR serait intéressée par nos
scripts car les scripts pourraient également les aider à effectuer des tests de performances pour le core
network. L’UNRA a été intéressée par les apports de notre solution notamment en termes de gains de temps.

Finalisation des documents (4 jours)

OrangeFrance


Nous avons rédigé de nombreux documents relatifs à notre solution. Nous avons écrit des procédures
d’installation et d’utilisation des différents outils.

Tests en plate-forme (2 jours)
Nous sommes partis deux jours en plate-forme sur le site de FTR&D à Paris. Nous avons pu à ce titre nous
familiariser avec les équipements GSM/GPRS d’Alcatel. Nous avons lancé des tests de mesures de
performances avec notre solution et nous avons utilisé l’analyseur de protocoles K12. Le K12 nous a
notamment servi pour capturer des traces WAP.

Blind Tests et support terrain (3 jours)
Pour avoir un retour client sur la facilité d’emploi de notre solution, nous avons fait faire les tests par
quelqu’un qui ne connaissait pas du tout notre outil. Ce « Blind test » nous a permis de corriger quelques
détails dans l’ergonomie de note solution.
De la même façon, des équipes de l’UNRA Nortel et Motorola sont allés sur le terrain et se sont servies de
notre outil ce qui a permis d’avoir un retour rapide et de corriger les derniers bugs et problèmes d’ergonomie.

Revues d’avancement
Tout au long de ce PFE, nous avons été amenés à faire part de l’état d’avancement de notre projet aussi bien
auprès d’Orange qu’auprès de l’INSA. Dans le cadre de l’étude Services&Usages, nous avons rencontré
deux fois nos tuteurs Humas. La première réunion avec les tuteurs Humas était le 5 février 2003 et avait pour
but de nous donner des pistes de réflexion pour l’étude Services&Usages. La deuxième réunion appelée
« Revue de PFE » a eu lieu au milieu du projet, le 5 mai 2003. Cette réunion a permis de faire part de l’état
d’avancement de notre réflexion sur les Services&Usages.

Nous avons eu de nombreuses réunions avec Vincent HURIET, notre tuteur Orange. Nous tenions en général
une réunion par semaine pour faire le point sur l’état d’avancement du projet. Ces réunions duraient environ
une heure et permettaient notamment de fixer des priorités sur les différentes tâches à compléter. Grâce à
leurs bonnes connaissances du GPRS, Vincent et Martin pouvaient également répondre à nos questions
d’ordre technique.

1.3 Communication et retour client :

La communication autour du projet a été primordiale durant tout le projet puisque le fait de faire connaître et
reconnaître un produit est la clé pour que l’outil soit généralisé au sein d’Orange, et qie des benchmarks
soient possibles entre les différents constructeurs de matériel BSS, en plateforme de test FT R&D et en zone
expérimentale.. De plus, cela contribue à donner une image positive des actions de l’UNRA en matière
d’expertise technique.

Nous avons organisé trois présentations principales, d’1h30 chacune, montrant l’avancement du projet et la
plus-value qu’apporte notre solution. Cela permet aussi bien d’avoir un retour d’expérience des
collaborateurs du cœur de réseau GPRS (UNR), que des collaborateurs des différentes entités de l’UNRA
(Nortel, Motorola et Alcatel). Ces réunions permettent également de se mettre à la portée des utilisateurs
potentiels de la solution et de mettre en relief des difficultés inhérentes à l’ergonomie de la solution. En effet,
les connaissances informatiques de chacune des personnes que nous avons rencontrées étant différentes, il
faut s’assurer que le fonctionnement de la solution est abordable par tous, au niveau du déploiement et de
l’utilisation.

Par l’intermédiaire de Vincent Huriet, la solution a été présentée dans la filiale d’Orange en Roumanie (Skill
Center User Group à Bucarest) et à 6 autres filiales (Cameroun, Senegal, Madagascar, Egypte, Pays-Bas,
Thaîlande) pour montrer le potentiel des outils que nous avons développés.

OrangeFrance


Pour tester la facilité d’exploitation de notre solution, Il a été organisé un "blind test" avec un ingénieur du
groupe support Motorola (UNRA), Cédric Pascal. L’objectif de ce test était de mettre en évidence les
difficultés qu’aurait une personne extérieure au projet et pas forcément experte en informatique, pour
installer et utiliser les tests de mesures de performance. Au premier abord, nous avons mis en évidence des
défauts d’intuitivité au niveau de l’interface homme-machine. Nous avons pu à la suite de cet entretien
améliorer l’ergonomie de l’interface client.

Globalement, la solution implémentée a été bien accueillie, comme elle présente un nombre d’avantages non
négligeables par rapport aux tests manuels existants.

2 Présentation de la solution :

2.1 Présentation sommaire du réseau GPRS :

Le réseau GPRS a été mis en place pour offrir de nouveaux services aux usagers. Il est par exemple possible
d'envoyer des messages multimédias (MMS) ou encore de naviguer plus rapidement sur le WAP en utilisant
un téléphone GPRS au lieu d’un téléphone GSM. Le GPRS est un réseau qui permet d’échanger des données
par le mode "Paquet" contrairement au GSM qui permet d’échanger de la voix en mode "Circuit". Au niveau
radio, chaque donnée peut être transportée dans des trames contenant 8 timeslots. Sur ces 8 timeslots, seuls 4
timeslots en général sont réservés pour le transfert de data et les 4 autres pour des communications voix. Sur
chacun des timeslots, on alloue des ressources liées aux canaux logiques PDTCH (transfert de data), TCH
(communication voix), BCCH, … Les canaux logiques PDTCH fournissent un débit unitaire en fonction d'un
codage de canal donné (le "coding scheme" CS-1, CS-2,…). Sur le réseau BSS Alcatel, seul le CS-1 et CS-2
sont utilisés et le débit par timeslot théorique est respectivement de 9,6 kbit/s et 13,4 kbit/s.

Les téléphones mobiles du marché peuvent exploiter plusieurs timeslots en downlink et en uplink.
Couramment, on trouve des terminaux supportant l'acheminement de 3 ou 4 timeslots en downlink et 1 ou 2
timeslots en uplink, ce qui propose des débits de l'ordres de 40kbit/s en downlink et 10 kbit/s en uplink..

Le GPRS permet d'accéder au réseau Internet. En effet, un téléphone portable GPRS offre les fonctionnalités
d'un modem. De cette façon, on peut utiliser tous les services courants comme la consultation de pages Web,
les transferts de fichiers par FTP, la consultation et l’envoi de mails, l’écoute de musique instantanée
(streaming)…

Voici un schéma représentant les couches protocolaires du réseau GPRS au niveau BSS :

OrangeFrance


Um Abis/Ater Gb

Application

IP/X25

SNDCP SNDCP

LLC LLC

Relay

RLC BSSGP
RLC BSSGP

MAC MAC NS NS

Relay
L2-GCH
L2-GCH
GSM-RF L1bis L1bis
GSM-RF L1-GCH L1-GCH

MS BTS BSC/MFS SGSN

Figure 2 : Réseau GPRS côté BSS

2.2 Architecture globale : Adéquation avec le protocole de test

Pour l'élaboration des tests de performances GPRS, la DTRS a élaboré un protocole de tests spécifique qui
détaille de manière précise les paramètres à utiliser pour configurer les tests. Ces tests s’appuient sur des
propriétés du BSS (tel que le Downlink_TBF_release chez Alcatel, le Keep Alive chez Nortel). Par exemple,
pour effectuer les tests de latence, il faut effectuer des séries de 101 pings à la suite sur un serveur sur
l’interface Gi, c’est-à-dire en sortie de GGSN, accessible uniquement à partir de l’APN « orange-pilote »
(l’APN « orange.fr » est publique et « orange-pilote » est une APN réservée en interne pour des
expérimentations). Nous disposons de deux serveurs de tests dont l’accès est régit par un partage de charge,
c’est-à-dire qu’un seul des deux serveurs peut répondre à un moment t, en fonction du trafic reçu. Ces
serveurs fournissent un accès FTP et HTTP. Nous avons développé nos scripts de manière à ce qu'ils
répondent de manière précise au protocole de tests, en prenant en compte en amont le test de connectivité
aux serveurs de test. Toutefois, nous avons réalisé une solution flexible qui permet à l'utilisateur de rentrer
les paramètres qu'il désire. Par exemple, si le protocole de tests était amené à évoluer alors l'outil s'adapterait
sans modifications aux nouvelles spécifications.

Un extrait du protocole de test est disponible en annexe 1.

L'architecture de notre solution est relativement simple. Nous avons développé des outils pour quatre types
de tests : Ping, FTP, HTTP et WAP. L'architecture des outils de Ping, FTP et HTTP sont très semblables
dans leur conception alors que l'outil de WAP a une architecture quelque peu différente.

Les outils de Ping, FTP et HTTP s'appuient sur des scripts VBScript et des macros Excel. Nous avons choisi
la solution des scripts VBScript et Excel car dans une installation normalisée « Orange », Excel et le moteur
de script WScript, permettant d’exécuter les scripts, sont fournis en standard et permettent une
automatisation aisée. Cela répond également aux contraintes d’intégration spécifiées dans le cahier des

OrangeFrance


charges. Ces solutions ne nécessitent pas d’achat de licences supplémentaires, sont standards et pérennes,
évolutives et supportent le multilinguisme.

Les tests automatiques sont lancés par des scripts VBScripts et des macros Excel qui permettent ensuite de
mettre en forme les résultats. Lorsque l'on exécute un script, les actions suivantes se déroulent
successivement au cours du temps :

Script VBScript : Script VBScript : Macro Excel : Macro Excel :
Exécution des tests Exécution d'Excel Lancement de la macro Enregistrement des
avec enregistrement avec le fichier de Excel de traitement de résultats et fermeture
des traces dans un traces .txt en résultats sur les traces d'Excel
fichier .txt entrée

Figure 3 : Architecture simplifiée de la solution

Le test de WAP est différent des autres tests dans le sens où il n'est pas entièrement automatisé. Il ne repose
que sur une macro Excel de post-traitement des traces brutes. Les traces brutes d'une communication WAP
sont obtenues en utilisant un analyseur de protocole qui s'appelle le K12 de Tektronix. Les traces obtenues
par le K12 sont très difficiles à interpréter pour un œil non averti. La macro Excel de traitement des traces
K12 permet de retrouver les pages WAP qui ont été consultées avec son temps d'affichage.

Figure 4 : Tektronix K1205 : analyseur de protocoles

Enfin, nous ne prenons pas en compte la connexion, ni la déconnexion du modem du mobile GPRS au PC.
Nous donnons à travers la documentation qui a été rédigée des pistes pour automatiser la connexion RAS
(Remote Access Service), notamment en ligne de commande avec « rasdial ».

Au niveau du matériel que nous avons utilisé pour effectuer des tests, nous nous sommes basés sur les
éléments suivants :
• Un PC Portable Windows 2000 Professionnel
• MTU = 1500 o et RWIN = 17520 o (paramétrage TCP)

OrangeFrance


• Un mobile GPRS, principalement le Motorola T280 (4+1)
• Un câble de liaison PC-mobile USB ou série
• Une carte SIM supportant les connexions aux APN « orange-pilote » et « orange.fr »

Figure 5 : Dispositif de test

2.3 Description technique de la solution

2.3.1 Introduction et prérequis :

Au début du projet, nous sommes partis dans plusieurs directions pour trouver des solutions automatisables
répondant aux spécificités qui étaient fixées.

Voici un résumé du protocole de test sur lequel nous avons contribué (la version originale est disponible en
annexe 1) :

Type de test Caractéristiques
Ping Série de 101 pings
Taille de PDU : 56 et 1460 octets
Délai entre chaque émission : 0, 2 et 7 s
FTP Série de 10 transferts en downlink et 10 transferts en uplink
Trois fichiers de taille différente à chaque fois : 100ko, 500ko et 1mo
HTTP Série de 20 chargements de pages (textes + images)
WAP Série de 20 chargements de prépage, puis de la page d'accueil Orange

Nous nous étions dirigés vers des outils qui étaient utilisés aussi bien à FT R&D qu’à Orange, en
l’occurrence WS_Ping Pro pack de l’éditeur IPSwitch et le FTP de la commande dos. Dans un premier
temps, le ping de la commande dos n’a pas été envisagé car il n’offrait pas de paramètre pour gérer le délai
entre chaque émission de ping en mode natif. Nous avions également la possibilité d’utiliser un autre logiciel
spécialisé, Tom 4, de l’éditeur Nemo Technologies, qui est un analyseur de réseau en temps réel sur
l’interface radio. Il permet de récupérer à l’aide d’un mobile à traces (le Sagem OT190 dans notre cas) entre
autres le nombre de timeslots utilisés lors d’un transfert, la qualité du signal radio, le type de codage de canal
(CS1, CS2,…),… De plus, le logiciel permet de réaliser des scripts de scénarios. Par exemple, il y avait la
possibilité de créer un script de lancement de transfert FTP. Finalement, nous n’avons que très peu utilisé cet
outil pour plusieurs raisons, car tout d’abord il n’y en avait qu’un seul pour tout l’UNRA (problème de
disponibilité) et pour réaliser des tests, la solution était trop coûteuse pour être mise à disposition en quantité
aux techniciens et ingénieurs. De plus, le mobile à traces est un 3+1 (3 timeslots en download et 1 slot en

OrangeFrance


upload), ce qui limite le débit théorique en download à 13.4*3 ~ 40 kbit/s (en CS2). L'avantage certain du
Tom4 par rapport à une solution plus simple est d'obtenir le débit par timeslot en kbit/s lors du transfert et de
voir les allocations de timeslots en fonction du temps. La majorité des tests qui ont été faits par la suite l’ont
été avec le Motorola T280, un mobile GPRS 4+1.

Figure 6 : Nemo Technologies Tom4 et Sagem OT 190

Par la suite, nous avons investigué autour de logiciels d’automatisation de saisie utilisateur, comme
« AutoIt » (http://www.hiddensoft.com/AutoIt/) ou encore « GroundControl »
(http://www.acrasoft.com/gc.html). Les premières tentatives avec ces outils n’étaient pas satisfaisantes
puisque nous souhaitions automatiser « WS_Ping_ProPack », un logiciel en mode fenêtré. Chacune des
commandes émulées à la place de l’utilisateur étaient censées naviguer dans l’interface graphique, mais cette
solution était très sensible aux éléments extérieurs (popup qui s’ouvre inopinément, utilisateur qui change le
focus d’une fenêtre,…). Nous nous sommes donc orientés vers des outils en ligne de commande, à l’instar du
FTP dos. Nous avons donc repris le ping dos et essayé de trouver une solution pour émuler les délais entre
chaque émission de ping.

En consultant le support de Microsoft, nous avons trouvé une solution pour assigner un délai entre chaque
ping :

Source :
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000serv/support/
faqw2kcp.asp

How can I get a batch file to 'sleep' for n seconds?
Answer: The Windows 2000 Resource Kits provide sleep.exe to allow a batch file to sleep for n seconds.

You can emulate this behavior by using the PING (P acket I nterN et Groper) command:

ping - n se con ds+ 1 127.0.0.1>nul

To sleep for 15 seconds, type:

ping - n 16 127.0.0.1>nul

Une autre solution pourrait être d’utiliser la commande « PING 1.1.1.1 -n 60 -w 1000 >NUL ». De cette
façon, on utilise le paramètre de timeout –w pour recréer une temporisation. En effet, l’adresse 1.1.1.1
n’étant pas valide, le système va attendre 1000 ms entre chaque ping pour attendre une réponse qu’il ne
recevra jamais.

Nous avons ensuite vérifié avec Ethereal que cette propriété du ping donnait des résultats plausibles. Dans
l’exemple ci-dessous, nous retrouvons dans la colonne « Delta » le délai entre chacune des requêtes. On
s’aperçoit que le délai de 2 secondes fixé entre une requête « echo reply » et la requête « echo request »

OrangeFrance


suivante est respecté. De plus, la colonne delta permet également de vérifier le RTD (Round Trip Delay)
fourni par la commande dos.

Voici ce que l’on obtient après filtrage des résultats de la commande dos :

C:TESTS_GPRSPING>ping.exe 111.111.111.111 -n 1 -l 56 -w 5000
Réponse de 111.111.111.111 : octets=56 temps=1242 ms TTL=253





Figure 7 : Capture Ethereal, 5 ping à 56 octets, Délai 2s

En s’appuyant sur les commandes dos “ping” et “FTP”, nous avons basé la solution sur des scripts et des
macros Excel, comme mentionné ci-dessus. Les scripts sont des fichiers « wsf » (Windows Script File),
contenant du code XML. Cela permet d’ajouter des fonctionnalités supplémentaires par rapport aux scripts
« vbs » traditionnels (souvent à tort associé à du code malicieux par les antivirus). Parmi les avantages des
scripts « wsf », on retrouve le fait de pouvoir inclure du code facilement, avec l’instruction « include »,
utiliser plusieurs langages de scripts dans le même fichier, ajouter des constantes dans le code, stocker tout le
traitement dans un seul fichier grâce au XML,…

En ce qui concerne les macros Excel que nous avons développé, elles sont décrites en vba (Visual Basic
Application) pleinement compatibles avec Excel 2000 et sont centralisées dans un seul fichier
« MacroDemarrageGPRS.xla » situé dans le répertoire « XLStart » de l’installation d’Office. En fonction
d’un fichier en entrée, la macro oriente le type de traitement à effectuer à l’ouverture d’Excel. Si aucun
fichier « Type_Test.txt » n’est trouvé, alors Excel n’effectuera aucun traitement. Pour assurer la rétro

OrangeFrance


compatibilité avec Excel 97, il faudrait redéfinir des fonctions qui ont été introduites sous Excel 2000, mais
ce n'était prioritaire dans l'accomplissement du projet.

Les scripts ne nécessitent pas l’installation d’un interpréteur ni d’un compilateur additionnel, mais nous
avons travaillé avec la version 5.6 de WScript (le moteur de script de Windows : Windows Script Host),
mise à jour qui n’est pas installée par défaut et que nous fournissons dans le délivrable.

Figure 8 : Principe de Windows Script Host

Concernant le support du multilinguisme, nous avons assuré la compatibilité avec des installations de
Windows en français et en anglais car les filiales d’Orange à l'étranger utilisent en général Windows en
version anglaise. Cela est important car Excel ne calcule pas de la même manière suivant s’il est en version
française ou anglaise. Nous avons également veillé à bien documenter tous les scripts aussi bien en français
qu'en anglais. Potentiellement, une personne connaissant le langage Visual Basic est capable d’apporter des
modifications pour personnaliser la solution.

Pour pouvoir configurer aisément ces scripts, nous avons externalisé dans des fichiers les variables contenant
des chemins vers les répertoires et fichiers de l’application, mais aussi les paramètres des tests, tels le
nombre de transferts FTP par exemple. Pour qu'un utilisateur non initié puisse facilement configurer les
scripts, nous avons crée en Delphi une interface graphique (GUI) intuitive, qui sera introduite par la suite.

Une de nos contraintes était également d'utiliser des outils fiables. Par exemple, nous nous sommes servis de
l'analyseur de protocole "Ethereal" ou encore de l'analyseur de bande passante en temps réel "NetMeter"
pour valider nos résultats.

Pour synthétiser les prérequis logiciels de notre solution :

- Windows 2000 Professionnel ou Windows 98 (ne supporte pas toutes les fonctionnalités) en
version française ou anglaise
- Excel 2000 en version française ou anglaise (testé avec la version 9.0.4402 SR –1)
- Wscript 5.6
- K1205, stack Gb "iw_Gb_fr.stk"

OrangeFrance


Les logiciels suivants sont facultatifs et permettent d’avoir une autre vision pour investiguer dans d’autres
directions :
- Ethereal et Winpcap (testé avec les version Ethereal 0.9.11 – Winpcap
2.3) (http://www.ethereal.com/ et http://winpcap.polito.it/)
- NetMeter (http://readerror.gmxhome.de/)
- K1205 Viewer : pour éditer les traces Wap

2.3.2 Description de l’implémentation des outils de tests :

Chacun des scripts Ping, FTP et HTTP réalise non seulement la capture des mesures de temps de réponse et
de débit, mais ils permettent également d’enregistrer de façon automatisé des traces Ethereal pour
investigation ultérieure. Tout le paramétrage de ces scripts peut être effectué à partir d’une interface
graphique en Delphi. Cela évite un grand nombre de manipulations par l’utilisateur, puisque l’interface
s’occupe de copier les fichiers au bon endroit, selon les chemins fournis par l’utilisateur. Nous avons choisi
de la développer en Delphi pour avoir une application légère, autonome (sans machine virtuelle) et facile à
développer (car son développement n’était pas prioritaire par rapport aux scripts).

Figure 9 : Interface graphique pour configurer les scripts vbs

Concernant la macro Excel qui effectue tous les post-traitements, nous l’avons découpé en 5 modules, dont 4
sont assignés à chacun des tests. Comme mentionné ci-dessus, le fichier « MacroDemarrageGPRS.xla » doit
impérativement se trouver dans le répertoire XLStart de l’installation d’Office. Tout fichier se trouvant dans
ce répertoire sera automatiquement ouvert lors du lancement d’Excel. Le répertoire « varMacro » (cf figure
ci-dessous) contient le fichier « varMacro.txt », fichier de variable contenant le chemin vers l’installation de
notre package. Cela permet notamment de sauvegarder le fichier Excel à la fin de l’exécution de la macro.

OrangeFrance


Figure 10 : Répertoire XLStart de l'installation d'Office
Le premier module « auto_open » définit une macro qui s'exécute automatiquement si elle trouve un fichier
dont le chemin est contenu dans la variable "Type_test_File" et qui contient soit le mot PING, soit le mot
FTP, soit le mot HTTP.

Pour vérifier que le fichier xla a bien été pris en compte par Excel, il suffit d'ouvrir Excel et d'entrer au
clavier le raccourci Alt+F11 (ou menu Outils>Macro>Visual Basic Editor). Normalement, un projet VBA
doit porter le nom "MacroDemarrageGPRS.xla" et doit comporter 5 modules.

Figure 11 : Visual Basic Editor : découpage de la macro en 5 modules

Lors de l’exécution des scripts Ping, FTP et HTTP, chacun des scripts lance Excel et fait en sorte que le bon
module de la macro se lance. Il est possible, directement à partir des fichiers de traces générés lors des
scripts, de rejouer les macros. Toutefois, il faut veiller au chemin indiqué dans le fichier « varMacro.txt »

OrangeFrance


dans le répertoire « XLStart », puisque la macro Excel sauvegardera à l’issue de son exécution un nouveau
fichier Excel dans le répertoire spécifié dans le fichier « varMacro.txt », avec dans le nom du fichier la date
et heure courante. Suivant le type de test, le fichier Excel sera sauvegardé dans le répertoire « Results » de la
sous arborescence du package correspondant. Par exemple, un fichier de traces Ping peut être rejoué à partir
du module 2 de la macro Excel. Lorsque cette dernière aura fini son traitement, le résultat sera stocké dans
« [Répertoire d’installation de notre solution]PingResult ».

Figure 12 : Fichier de résultat

Voici une série de diagrammes présentant l’implémentation de chacun des outils de tests Ping, FTP et
HTTP :

Tests de latence du réseau : Ping

Connection APN Orange-pilote

1 min

Génération script batch
(PING_GPRS.wsf)

Exécution script batch Création fichier type
(PingBatchFile.bat) Excel
(TYPE_TEST.txt)
25 min
Collecte des résultats
(TRACE_PING_GPRS.

Macro auto_open Excel (module
1)
Sélection de la macro à exécuter
1 min
Exécution macro PING_GPRS
(module 2 de
MacroDemarrageGPRS.xla)

Figure 13 : Fonctionnement du script "Ping"

Le script « Ping_GPRS.wsf » envoie dès son lancement une série de 4 pings pour trouver l’adresse IP du
serveur de tests. Comme nous l’avons précisé ci-dessus, nous avons à notre disposition deux serveurs de tests

OrangeFrance


dont l’accessibilité est déterminée par la charge réseau à un moment donné. Ces pings permettent donc de
repérer le serveur online disponible.

Les paramètres en entrée du script sont les suivants :
Les deux adresses IP des serveurs de tests
Un tableau d’adresse IP contenant les IP des serveurs à pinguer
Un tableau contenant les délais entre chaque émission de ping
Un tableau contenant les tailles des PDU ICMP
Le nombre de ping par mesures
La durée (timeout en ms) au-delà duquel un paquet ICMP est considéré comme perdu
Le chemin du fichier batch « PingBatchFile.bat »
Le chemin du fichier de trace « TRACE_PING_GPRS.txt »
Le chemin du fichier « TYPE_TEST.txt » qui permettra à la macro Excel de déterminer le type de
test
Le chemin d’accès à l’application Excel
Une variable indiquant si l’on souhaite ou pas une capture Ethereal pendant les requêtes ICMP

Les résultats en sortie sont les suivants :
Les mesures « brutes »
Les mesures « filtrées »
Les statistiques pour chacun des tests (temps de réponse moyen, temps de réponse minimum, temps
de réponse maximum, écart-type, Pourcentage d’erreurs, nombres de ping réussis)

Voici les résultats après post-traitement par la macro Excel :

Figure 14 : Mesures filtrées

OrangeFrance


Figure 15 : Post-traitement macro Excel Ping selon le protocole de test

Tests de débits : FTP

Connection APN Orange-pilote

1 min

Exécution script vbs
(FTP_GPRS.wsf)

Génération d’un fichier de
commandes FTP Création fichier type Excel
(FTP_ACCESS.txt) 1h30 (TYPE_TEST.txt)

Collecte des résultats
(TRACE_FTP_GPRS.txt)

Macro auto_open Excel (module 1)
Sélection de la macro à exécuter suivant
le fichier TYPE_TEST.txt
1 min
Exécution macro FTP_GPRS (module 3
de MacroDemarrageGPRS.xla)

Figure 16 : Fonctionnement du script "FTP"

OrangeFrance


De même, pour déterminer le serveur disponible parmi les deux serveurs de tests, nous émettons une série de
4 ping qui permet de déterminer l’adresse IP qui sera utilisée lors des transferts FTP. Le principe de ce script
est similaire à celui du ping.

Voici les paramètres en entrée :
Les deux adresses IP des serveurs de tests
Login et mot de passe d’accès en lecture et en écriture
Le chemin du répertoire où l’on stocke les fichiers à uploader
Le chemin du répertoire où l’on stocke les fichiers downloadés
Un tableau contenant les chemins des fichiers que l’on souhaite downloader depuis le serveur de test
Un tableau contenant les chemins des fichiers que l’on souhaite uploader vers le serveur de test
Le nombre de transferts en download
Le nombre de transferts en upload
test
Le chemin du fichier de trace « TRACE_FTP_GPRS.txt »
Le chemin d’accès à l’application Excel
Une variable indiquant si l’on souhaite ou pas une capture Ethereal pendant les transferts FTP

Les données obtenues en sortie sont :
Les mesures « filtrées »
Les statistiques pour chacun des tests (nombre de transferts, temps moyen de transfert, écart-type du
temps de transfert, débit moyen, écart-type sur le débit, et le pourcentage d’erreurs)

Voici ce que l’on obtient après post-traitement de la macro Excel :

Figure 17 : Transferts FTP selon le protocole de tests

Tests HTTP :

Ce test permet de mesurer le temps de chargement d’une page web. Du point de vue du client utilisateur, la
consultation de pages web est une application courante d’une connexion RAS avec modem GPRS et c’est en
ce sens que nous avons créé un script pour mesurer en chaîne le temps de chargement de sites de références.
Pendant le projet, les principaux tests ont été réalisés sur l’APN publique « orange.fr », car d’un côté cela

OrangeFrance


reflète concrètement ce qu’un client d’Orange perçoit et de l’autre nous n’avions pas à notre disposition des
pages web de référence sur les serveurs de test. Pour prévenir les aléas du cache du navigateur Internet
Explorer, nous avons fourni un fichier « .reg » permettant d’obliger le navigateur à vider son cache à chaque
fois qu’il se ferme.

Le script lance donc Internet Explorer, charge une page à partir de son URL, puis referme le navigateur, et
ainsi de suite jusqu’à ce que le nombre de chargement de pages soit atteint. Dans le protocole de test, il
fallait effectuer vingt chargements à la suite pour obtenir des statistiques. Nous utilisons des fonctions de
vbscript pour récupérer la taille des pages lancées. Notre solution gère les pages avec des frames, du texte et
des images. Il s'avère toutefois que les résultats renvoyés par les fonctions vbscript, en l'occurrence
"document.filesize", ne reflète pas de façon certaine (cela dépend des types de pages, si elles comportent du
javascript,…) la taille exacte de la page visitée. Nous n'utilisons que le navigateur Internet Explorer car il est
aisément automatisable à partir de code en vbscript et est standard sur les machines d'Orange. Les tests ont
été effectués avec la version 5.5 d'Internet Explorer.

Nous avons effectué les tests essentiellement avec les sites « orange.fr » et « google.fr ». La page
« orange.fr » accessible à partir d’un mobile est allégée par rapport à la page institutionnelle Orange. Cette
page ne contient que 2 images, avec du texte et des liens et pèse moins de 10ko.

Connection APN Orange.fr

1 min

Exécution script vbs
(HTTP_GPRS.wsf)

Génération d’un fichier de Création fichier type Excel
traces HTTP (TYPE_TEST.txt)
(TRACE_HTTP_GPRS.txt)

Macro auto_open Excel (module 1)
Sélection de la macro à exécuter suivant
le fichier TYPE_TEST.txt
1 min
Exécution macro HTTP_GPRS (module
4 de MacroDemarrageGPRS.xla)

Figure 18 : Fonctionnement du script HTTP

Voici les paramètres en entrée :
Un tableau contenant les URL à charger
Un nombre d’affichage de page par URL
Le chemin vers le fichier de trace « TRACE_HTTP_GPRS.txt »
test
Le chemin vers l’application Excel
Une variable indiquant si l’on souhaite ou pas une capture Ethereal pendant les transferts HTTP

OrangeFrance


Les données obtenues en sortie sont :
Les statistiques pour chacun des tests (temps moyen de chargement, temps minimum de chargement,
temps maximum de chargement, écart-type du temps de chargement, débit moyen indicatif (dépend
de la taille de la page renvoyée par la fonction « document.fileSize » en vbs), taille de la page, le
pourcentage d’erreurs (calculé sur la taille de la page retournée : si la page a une taille différente de
la taille maximum sur toutes les pages relevé lors de la série de tests, alors elle est considérée en
erreur))

Voici ce que l’on obtient après post-traitement de la macro Excel :

Figure 19 : Mesures brutes

Figure 20 : Transferts HTTP : 20 chargements de la page « orange.fr »

Les tests Wap :

Les communications WAP sont intéressantes dans notre protocole de tests car elles représentent une
application déjà couramment utilisée par les usagers du téléphone mobile. De plus, la pile de protocole WAP
est dissociée de TCP/UDP ce qui permettra d'avoir des résultats totalement indépendants des autres tests.

OrangeFrance


Nous avons décidé de capturer les communications WAP avec le K12 (analyseur de protocoles) sur
l'interface Gb et d'effectuer ensuite un post-traitement macro-Excel pour en faire ressortir la communication
WAP que l'on a initiée. Les mesures ne sont donc plus automatisées comme précédemment pour les autres
scripts Ping, FTP et HTTP.

Nous avons préalablement effectué quelques tests avec WinWap 3.1 Pro, un émulateur Wap implémentant sa
propre pile wap (http://www.winwap.org/index.html). WinWap se connecte au réseau GPRS avec le mobile
Motorola T280 (APN orange.fr) et remplace intégralement le navigateur embarqué du mobile par une
application Windows. Nous avons pu avec Ethereal obtenir comment étaient codés en hexadécimal les
requêtes WTP et WSP. Cela nous a bien aidé pour enchaîner avec le K12.

Nous n'avons pas poursuivi avec cette solution car ce logiciel est un shareware limité dans le temps et, que
la pile protocolaire wap implémentée ne reflétaient pas forcément celle intégrée au téléphone mobile, ce qui
aurait eu des conséquences au niveau des mesures. Nous avons donc préféré poursuivre avec l'analyseur
K1205, qui permet d'obtenir l'ensemble des messages Wap transitant par l'interface Gb.

Figure 21 : Capture Ethereal de trafic généré par Winwap

Notre solution consiste à effectuer des post-traitements sur ces fichiers de capture bruts K12. Ces traces
doivent être ensuite exportées vers Microsoft Excel pour appliquer un filtre qui permettra de ne sélectionner
que les informations pertinentes.

La macro Excel "Macro_WAP_K12" permet de traiter les traces contenues dans le fichier .txt qui a été
exporté à partir du K12 (ou du K12 Viewer). Cette macro permet d'obtenir au final un tableau Excel retraçant
le parcours des pages WAP visitées lors d'une communication. Elle permet de mettre en évidence le temps de
chargement de chaque page WAP.

Voici le fonctionnement chronologique du filtrage sous Excel :

OrangeFrance


Premier Filtre : on garde tous les messages WAP
Les traces contenues dans le fichier .txt contiennent tous les détails des protocoles (90% de l'information ne
nous est pas utile). On parcourt toutes les lignes de traces à l'aide de la fonction "Filtre_MessagesWAP()"
pour récupérer seulement l'heure, le type, le n°IMSI, le n°TLLI, l'url des messages. L'Url est décodée à
partir des codes opératoires hexadécimaux. Pour cela, la fonction qui transforme l'hexadécimal en ASCII a
été entièrement recodée.

On récupère l'identifiant TLLI de notre communication WAP
Les numéro IMSI et TLLI ne sont présents en même temps que dans le message "APAC" ( APAC = Activate
PDP Context Accept Request, ce qui signifie qu'un PDP context a été ouvert). La récupération du TTLI
(identifiant temporaire) de la communication souhaitée se fera donc en recherchant le numéro IMSI dans le
message « APAC ». On récupère le TLLI grâce à la fonction "TLLI_MaComWAP".

Deuxième filtre : on garde seulement les messages WAP de notre communication
Maintenant que le TLLI de la communication WAP qui nous intéresse est connue, on peut appliquer un
second filtre "Filtre_MaComWAP" sur les messages WAP pour ne garder que ceux appartenant
effectivement à la communication qui nous intéresse.

On calcule les temps d'affichage des temps WAP
Les messages "GET" sont uniques et nous servent de référence pour repérer les temps de début et de fin de
chargement de page. La fonction "Temps_Chargements()" parcourt les cellules pour repérer les "GET" et
appelle la fonction "Calcul_Temps()" pour calculer la différence de temps entre un "GET" et le dernier
"ACK" avant le prochain "GET".

On met en forme les résultats dans un tableau
Tous les résultats recueillis par les fonctions précédentes sont consignés dans un tableau avec mise en forme.

En sortie de la macro, on obtient des paramètres intéressants, tels que les URL visitées (obtenues en décodant
les valeurs hexadécimales dans les traces K12), le temps de chargement de la prépage d’accueil Orange, le
temps de chargement du portail wap Orange,… Dans la figure ci-dessus, on met en évidence le temps qu’un
utilisateur attendra pour obtenir sa page d’accueil. Le test de la figure ci-dessus a été effectué avec le Sagem
my-X5, en Wap couleur, ce qui alourdit nécessairement les traces comme la taille des pages est plus
importante.

OrangeFrance


Figure 23 : Echanges protocolaires Wap et temps de chargement des pages

2.3.3 Présentation des délivrables :

Nous avons créé avec l’installateur « Setup2go » (http://dev4pc.com/setup2go.html) un package comprenant
tous les scripts suivant une arborescence définie. Dans la dernière version 1.1 que nous avons eu l’occasion
de produire, nous avons inclus des scripts pour windows 98 et des fichiers permettant de modifier la base de
registres de windows 2000 pour changer les paramètres de MTU, de RWin,…, qui ont une influence non
négligeable sur les performances de la connexion RAS. D’ailleurs, une étude de FT R&D [Mart 01] a montré
que les paramètres optimaux de la pile TCP/IP de windows sont atteints pour une valeur de MTU égale à
1500 octets et de RWin à 17520 octets. Sous Windows 98, ce ne sont pas forcément des valeurs usine par
défaut, mais sous Windows 2000, si ce n’est pas explicitement rajouté à la base de registres, ces paramètres
de MTU et de RWin sont présent par défaut.

Nous avons rédigé plusieurs documentations permettant à un utilisateur de prendre en main nos outils et nous
avons paramétré Windows pour préparer les séries de mesures : création d’une connexion Ras, Planification
de tâches, modification des valeurs de la base de registres pour optimiser la pile TCP/IP, configurer Ethereal
sous windows 2000, et un document de troubleshooting recensant des problèmes courants (et leurs solutions)
que nous avons constaté lors de notre phase d’expérimentation.

OrangeFrance


Par exemple, lors des mesures de nuit, il est impératif de retirer dans les options avancées d’alimentation de
Windows la mise en veille prolongée. Cela peut être la source, même en journée, de déconnexion de la
connexion RAS, comme la mise en veille coupe tous les périphériques consommateurs d’énergie.

Figure 24 : Délivrables

Figure 25 : Arborescence du projet après installation du package

OrangeFrance


2.4 Validation et expérimentations

A travers ces différents tests, nous avons accumulé des séries de mesures et de statistiques qui nous ont aidé
à diagnostiquer des problèmes aussi bien au niveau des scripts, de l’utilisation de ces scripts, que des
problèmes logiciels et matériels. En effet, nous avons diagnostiqué avec Eric Touron, ingénieur du groupe
Support Nortel, un problème avec les liaisons infrarouges entre PC et mobile. La liaison fausse les résultats
de ping, pour certains délais entre chaque émission (délai 2s). En refaisant exactement les mêmes tests avec
un cable série ou USB, nous avions des résultats tout à fait corrects. De même, nous étions étonné par les
résultats anormalement élevés des transferts FTP en upload. Nous avions en général 1,80ko/s, soit 14,4 kbit/s
en moyenne sur un timeslot alors qu’en CS-2, le débit théorique du GPRS est de 13,4 kbit/s. Avec Ethereal,
nous avons découvert que le FTP dos arrêtait son timer en fin de transfert lorsque le buffer, c’est-à-dire la
fenêtre d’émission était vide, alors que le serveur FTP renvoyait par la suite les acquittements pour chacun
des paquets de la fenêtre d’émission (soit 17 520 octets à acquitter). Le temps de transfert était donc
complètement faussé et le débit également.

Tests de nuit
Dès les premières versions des scripts Ping et FTP, nous avons voulu mettre à l'épreuve ces outils pour
vérifier la cohérence des résultats. Pour cela, nous avons effectué des tests en journée ainsi que des tests de
nuit. Les tests de nuit étaient programmés pour se lancer à une certaine heure grâce à l'utilisation du
planificateur de tâches Windows. L'intérêt des tests de nuit était de disposer de beaucoup de temps libre pour
l'exécution des scripts et d’un réseau public peu ou pas perturbé. Par exemple, le test de FTP conforme au
protocole de tests pouvait durer presque deux heures, après une série de 10 download et 10 upload (A Lyon,
nous étions sous couverture BSS Nortel.)

Tests en ZE (Zone expérimentale)
Nous avons eu l’occasion de participer à une journée de mesures à côté de Bourgoin-Jallieu (38), à la
campagne, sous couverture du BSS Nortel. Cela permet d’obtenir des résultats en journée sur le réseau
public en principe peu perturbé par le trafic ambiant, contrairement aux mesures effectuées à Lyon. En
assignant 4 timeslots pour des transferts PDCCH sur certains secteurs de la BTS, nous avons pu tester
essentiellement les transferts FTP en upload et en partage de charge (plusieurs mobiles uploadent en même
temps), avec plusieurs types de mobiles GPRS (Motorola C330, Motorola T280, Sagem OT190). C’est grâce
à ces tests que nous avons mis en évidence les résultats aberrants en FTP uplink.

Ethereal
Parallèlement à l'exécution des scripts, nous avons lancé des captures avec l'analyseur réseau Ethereal.
Ethereal était installé sur notre PC portable de tests et nous a permis de vérifier la conformité des résultats
émis par les scripts. De plus, Ethereal nous a permis d'investiguer différents problèmes rencontrés. Par
exemple, c'est avec Ethereal que nous avons pu mettre en évidence un problème de fermeture de session FTP
par hôte distant et un problème au niveau des résultats fournis par la commande FTP dos en upload.

K1205

Pour pouvoir utiliser l'analyseur de protocoles K12, il faut se rendre sur site et se connecter sur une interface
GSM/GPRS à savoir Abis, Gb ou encore Gi.

Nous avons utilisé l'appareil lorsque nous nous sommes déplacés à Paris sur la plate-forme de tests FTR&D.
Lors du lancement de nos tests de performances sur la plate-forme Alcatel, nous avons lancé en parallèle des
captures K12 sur l'interface Gb. Cela nous a permis de voir en détail les messages passant entre le BSS et le

OrangeFrance


GSS. Toutes les communications passaient par un BSS reproduit dans une petite salle, de la micro BTS
jusqu’au MFS (le MFS est le nom d’Alcatel pour PCU Packet Control Unit).

Notre priorité était de récupérer des traces WAP K12 pour valider notre macro Excel de traitement de traces
K12.

Nous avons élaboré plusieurs scénarios de communications WAP pour le K12, avec avant chaque set de
mesures le vidage du cache du navigateur embarqué dans le mobile. Le mobile de test était le sagem My-X5.

Voici les différents scénarios :

- Connexion à "Orange"
- Connexion à "Orange" puis rubrique "Météo"
- Connexion à "Orange" puis "Yahoo" et enfin "Yahoo Actualités"

Figure 27 : Captures avec l'analyseur de protocoles K12 (Demande d’activation du PDP context)

3 Analyse des résultats :
Nous n’avons eu que très peu de temps pour analyser les résultats que nous avons obtenus aussi bien en
maquette avec le BSS Alcatel, qu’à Lyon sous couverture du BSS Nortel. Par contre, nous avons pu
investiguer dans plusieurs directions, grâce aux documents de FT R&D pour évaluer d’où pouvait provenir
les problèmes survenus lors des mesures.

OrangeFrance


Par exemple, lors des transferts FTP, nous avons fréquemment obtenu des messages indiquant la fermeture
de la connexion par l’hôte distant, en fin de transfert du fichier. Cela a pour effet de ne pas nous fournir de
statistique sur la taille du fichier transféré, le temps de transfert et le débit et de couper la connexion pour les
transferts suivants. Le problème survient surtout lors de transferts de gros fichiers. Lorsque nous effectuons
en parallèle des captures Ethereal, il s’avère qu’il y a un déséquencement au niveau des acquittements des
paquets, ce qui a pour effet de demander à la suite plusieurs paquets de type « Duplicate Ack ». D’après la
RFC 2581 (TCP Congestion Control), la cause provient de problèmes de réseau. D’abord, cela peut être dû à
des segments perdus dans le réseau. Dans ce cas, tous les segments arrivants après ce paquet perdu
déclencheront des « Duplicate Acks ». Les « Duplicate Acks » peuvent également provenir d’un ré
ordonnancement des paquets de données dans le réseau. Enfin, cela peut dû à des réplications de paquets
« Ack » ou des segments de données par le réseau. Nous n’avons pas pu investiguer plus loin pour en trouver
la cause exacte.

Pour les tests de ping, nous avons pu effectuer quelques captures avec le K12 pour regarder comment sont
segmentés les paquets sur le réseau. Lorsque nous avons des ping ayant une PDU de 56 octets (+ 28 octets
d’entête IP+ICMP), nous avons avec toutes les entêtes un paquet de taille 122 octets pour le « echo request »
et 138 octets pour le « echo reply » au niveau de l’interface Gb. Pour les paquets de taille 1460 octets, ils
sont fragmentés en trois paquets de respectivement 535, 535 et 533 octets pour le « echo request » et 551,
551 et 549 octets pour le « echo reply ».

Au niveau des débits observés lors de toutes les mesures que nous avons effectuées, nous avons des
moyennes relativement bonnes, de l’ordre de 5ko/s (soit 40kbit/s) pour le download et 1,3 ko/s (soit 10,4
kbit/s) pour l’upload. La plupart des tests ont été effectués en CS-2 (13,4kbit/s théorique par timeslot). Il
aurait été intéressant de réaliser des mesures sous couverture Motorola en CS-3/4.

En ce qui concerne les résultats des mesures obtenues en maquette, ils étaient relativement mauvais, comme
nous travaillions sur un réseau très peu optimisé au niveau BSS. Avec plus de temps, il aurait été intéressant
de créer des configurations temporaires sous l’OMC (outil de supervision Alcatel) pour voir l’impact des
changements de paramétrage du réseau.

OrangeFrance


Conclusion :
En 11 semaines actives de projet, nous avons non seulement livré une solution complète permettant
d’effectuer des tests automatisés de performance du réseau GPRS, mais nous avons pu également avoir une
vision pratique de l’architecture, de l’optimisation et de la supervision d’un réseau GPRS. D’un côté, nous
avons énormément appris au niveau du développement de scripts et de macros en environnement Microsoft
et nous avons également pu approcher de près les problématiques de l’optimisation des réseaux d’accès
GPRS, en utilisant des outils spécialisés .

La solution que nous proposons, évolutive et documentée, permet d’effectuer des mesures en chaînes de
façon simple et de présenter les résultats dans un tableau Excel. Cette solution permet de gagner beaucoup de
temps, notamment lorsque le protocole de tests demande de nombreux transferts pour avoir de meilleurs
résultats statistiques. Pour information, d’après le protocole de Philippe Gabard, il faut environ 2h30 pour
effectuer tous les tests de façon automatisée. Dans le cas de mesures manuelles, cela se compte en nombre de
jours de mesures, dû à la mise en place de configurations de tests et de relève et analyse statistique de
mesures..
Au niveau des améliorations immédiates du produit, il faudra trouver une alternative au client FTP dos, en
raison de ses résultats erronés en upload, et éventuellement en fonction des besoins de compatibilité avec
Windows 98 et Excel 97, il faudra réécrire des portions de codes.

Enfin, nous avons beaucoup travaillé au niveau de la communication pour promouvoir la solution, qui, nous
l’espérons sera utilisée au niveau des groupes supports, puis au sein des unités régionales et des filiales
d’Orange. La solution a même été testée par Michel Lai, collègue de promotion en PFE à Orange sur la
Qualité de Service du réseau UMTS, et donne un aperçu quantitatif des performances de l’UMTS. Notre
solution pourra sans nul doute s’adapter au paramétrage de l’UMTS et ainsi trouver de nouveaux utilisateurs.

Remerciements :

Nous tenons à remercier tout particulièrement :
- Vincent Huriet et Luc-Henri Pampagnin pour nous avoir accueilli à l’UNRA et nous avoir donner du
temps et des moyens pour mener à bien ce projet de fin d’études.
- Martin Pasquier (UNRA Alcatel), Eric Touron (UNRA Nortel) et Cédric Pascal (UNRA Motorola)
pour leur participation active au projet.
- Toute l’équipe des groupes supports Motorola, Nortel et Alcatel pour leur aide et leur sympathie.
- Toute l’équipe du Core Network GPRS pour leur écoute et leur retour d’expérience.

OrangeFrance


Index des figures :
FIGURE 1 : CHRONOLOGIE SIMPLIFIEE DU PROJET ................................................................................................................7
FIGURE 2 : RESEAU GPRS COTE BSS................................................................................................................................12
FIGURE 3 : ARCHITECTURE SIMPLIFIEE DE LA SOLUTION ...................................................................................................13
FIGURE 4 : TEKTRONIX K1205 : ANALYSEUR DE PROTOCOLES ..........................................................................................13
FIGURE 5 : DISPOSITIF DE TEST ..........................................................................................................................................14
FIGURE 6 : NEMO TECHNOLOGIES TOM4 ET SAGEM OT 190.............................................................................................15
FIGURE 7 : CAPTURE ETHEREAL, 5 PING A 56 OCTETS, DELAI 2S ......................................................................................16
FIGURE 8 : PRINCIPE DE WINDOWS SCRIPT HOST ..............................................................................................................17
FIGURE 9 : INTERFACE GRAPHIQUE POUR CONFIGURER LES SCRIPTS VBS ...........................................................................18
FIGURE 10 : REPERTOIRE XLSTART DE L'INSTALLATION D'OFFICE ...................................................................................19
FIGURE 11 : VISUAL BASIC EDITOR : DECOUPAGE DE LA MACRO EN 5 MODULES ..............................................................19
FIGURE 12 : FICHIER DE RESULTAT ....................................................................................................................................20
FIGURE 13 : FONCTIONNEMENT DU SCRIPT "PING" ............................................................................................................20
FIGURE 14 : MESURES FILTREES ........................................................................................................................................21
FIGURE 15 : POST-TRAITEMENT MACRO EXCEL PING SELON LE PROTOCOLE DE TEST .......................................................22
FIGURE 16 : FONCTIONNEMENT DU SCRIPT "FTP" .............................................................................................................22
FIGURE 17 : TRANSFERTS FTP SELON LE PROTOCOLE DE TESTS ........................................................................................23
FIGURE 18 : FONCTIONNEMENT DU SCRIPT HTTP .............................................................................................................24
FIGURE 19 : MESURES BRUTES ..........................................................................................................................................25
FIGURE 20 : TRANSFERTS HTTP : 20 CHARGEMENTS DE LA PAGE « ORANGE.FR »............................................................25
FIGURE 21 : CAPTURE ETHEREAL DE TRAFIC GENERE PAR WINWAP ..................................................................................26
FIGURE 23 : ECHANGES PROTOCOLAIRES WAP ET TEMPS DE CHARGEMENT DES PAGES .....................................................28
FIGURE 24 : DELIVRABLES ................................................................................................................................................29
FIGURE 25 : ARBORESCENCE DU PROJET APRES INSTALLATION DU PACKAGE ....................................................................29
FIGURE 27 : CAPTURES AVEC L'ANALYSEUR DE PROTOCOLES K12 (DEMANDE D’ACTIVATION DU PDP CONTEXT)...........31

Bibliographie :
[Pasq 02] Martin Pasquier, « Protocole de mesure technique Ping », 27/12/02

[Gaba 03] Philippe Gabard, «Network Trial GPRS Performances Tests», 17/04/03

[Mart 01] Jean-Yves Martineau, Eric Brunel, Sylvie Fouquet, Fabrice Ramirez, « Problématique de
la mesure du temps de connexion aux services WAP (FT R&D) », 16/08/01

[Meye 02] Vincent MEYER, « ALCATEL SOLDE B6 – ORGANISATION DES MESURES
GPRS », 31/01/02

[Agop 03] Jean-Paul Agopian, « Mesures GPRS », v1.0

[FTMUR] FTM UR, « Mesures Qualité Data », UR hebdo et UR Sxx

[Mart 01] Jean-Yves Martineau, « Interaction des couches TCP/IP et des couches GPRS v1.1 » (FT
R&D), 20/09/2001

OrangeFrance


Annexes
Annexe 1 : Protocole de test (chef de projet : Philippe Gabard)

Operation FTP files downloaded from test Server, using Dos Tool :
Use dedicated jpg files of 100 Kbytes, 500 Kbytes, 1 Mbytes
Do series of at least 10 times for each file size

Expected results For each file size:
Throughput per Tslot averaged on the 10 transfers - typically 10 Kbits/s/TS for CS
1-2; 15Kbit/s/TS for CS3-4
Standard deviation
Percentage of FTP failure (typically under 1 % for BSS causes)
Failure causes repartition

Operation FTP files uploaded to dedicated Test Server :
Use dedicated jpg files of 100 Kbytes, 500 Kbytes, (1 Mbytes)
Do series of at least 10 times for each file size

Throughput per Tslot averaged on the 10 transfers - typically 10 Kbits/s/TS;
14Kbit/s/TS for CS3-4 (those values are based on Motorola CS3-4 throughput
measurements)
Standard deviation
Percentage of FTP failure (typically under 1 % for BSS causes)
Failure causes repartition.

Operation Do a serie of at least 101 ping MS to Test Server for each ICMP frame size and each
delay between pings :
TOOL : WS Ping Pro is used by FTR&D. UNRA will propose its tool when it is
validated (see § 2.1)
Delay between each ping : 0 sec., 2 sec. and 7 sec.
This is the delay between ping reception N-1 and ping emission N
Size of ICMP frame: 56 bytes (1 LLC frame), 1460 bytes (max MTU)
Timeout = 10 sec.

Expected results For each ICMP frame size and each delay :
Percentage of failure (typically less than 1%)
Average RTD. The first ping is not taken into account since it does not benefit
from the delayed TBF release feature.
Max value
Mean variance

Operation Web pages download from Test Server:
TOOL : UNR tool exists.
Use predefined pages, one with text only, one with text plus a picture and one with
text plus 3 or 4 pictures with no links to other URL
Deactivate the browser cache
Do series of 20 times for each pages size
Web browser Internet Explorer V5.5.

Percentage of failure
Average retrieval time
Standard mean deviation

OrangeFrance


Annexe 2 : codes opératoires d’un échange wap

Taille Type de requête Sens
UDP Trans
(bytes) fert
93 WSP-GET 0e 31 8d 12 40 … UL
1104 WSP-REPLY 12 B1 8d 04 20 … DL
11 WTP-ACK 18 31 8d UL
WSP-CONNECT La connexion s'est interrompue. On
252 0e 50 b8 12 01 … UL redemande à se connecter

44 WSP-CONNECT REPLY 12 d0 B8 02 8d … DL
11 WTP-ACK 18 50 B8 UL
35 WSP-GET 0e 50 b9 12 40 … UL
972 WSP-REPLY 12 d0 b9 04 20 … DL
11 WTP-ACK 18 50 b9 UL
14 Extended Method GET-PDU 0e 50 ba 12 51 … UL
18 WSP-REPLY 12 d0 ba 04 24 … DL
11 WTP-ACK 18 50 Ba UL
105 WSP-GET 0e 31 8e 12 40 … UL
900 WSP-REPLY 12 b1 8e 04 20 … DL
WSP-GET Get arrivant plus tôt que prévu (précision
92 0e 3a bc 12 40 … UL horloge windows défaillante)

11 WTP-ACK 18 31 8e UL

OrangeFrance


Annexe 3 : Diagramme de GANTT

OrangeFrance

Pfe

Contenu connexe

Tendances

En vedette

Pfe