• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Pfe
 

Pfe

on

  • 3,170 views

 

Statistics

Views

Total Views
3,170
Views on SlideShare
3,170
Embed Views
0

Actions

Likes
2
Downloads
105
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Pfe Pfe Document Transcript

    • Support Réseau d’AccèsRapport 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 VaiseRésumé Niveau de diffusionMesure de la qualité de service du réseau GPRS côté utilisateur pour Contrôlée 2interprétation au niveau BSS. Implémentation d’une solution Interne 3automatisée de tests de performances. Modes opératoires. Libre 4 OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsValidation 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 JFMots clésAutomatisation, GPRS, tests, ping, FTP, HTTP, WAP OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsSOMMAIRE :INTRODUCTION.............................................................................................................................................................4GLOSSAIRE .....................................................................................................................................................................51 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 : ............................................................................................................102 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 ...............................................................................................................303 ANALYSE DES RESULTATS : ...........................................................................................................................31CONCLUSION : .............................................................................................................................................................33REMERCIEMENTS : ....................................................................................................................................................33INDEX DES FIGURES : ................................................................................................................................................34BIBLIOGRAPHIE : .......................................................................................................................................................34ANNEXES .......................................................................................................................................................................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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsIntroductionL’Unité Nationale Réseau d’Accès (UNRA) d’Orange France s’occupe de gérer le réseau national d’Orangepour la partie radio appelée encore BSS (Base Station Subsystem). Les infrastructures BSS s’appuient surtrois constructeurs : Alcatel, Nortel et Motorola. C’est pour cette raison que l’UNRA est composée de troisentité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 unsupport 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 demesures standardisé permettant d’établir des comparatifs entre constructeurs, entre paliers ou encoresimplement pour vérifier la qualité du service offert par le réseau d’accès. Un groupe de travail impliquantdiffé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’élaborationde 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 pourquantifier et qualifier le réseau d’accès pour le GPRS. Pour automatiser ces tests, nous avons développé unesolution logicielle basée sur des scripts évolués. Ces scripts permettent d’acquérir les mesures de Qualité deService 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 groupede travail, dirigé par Philippe GABARD (Responsable Etudes GPRS), a pour but de définir les spécificationsdes tests de performances GPRS. France Télécom R&D apporte son expertise technique et son expérienceacquise lors des expérimentations obtenues sur les plate-formes de tests. Les Unités Régionales (UR) etl’UNRA sont concernées en premier lieu par le projet car ils constituent les utilisateurs finaux. VincentHURIET (Skill Centre Field Testing & Support Expert GSM Alcatel) a pris part à ce projet en tant queresponsable 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êmesi 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é desinformations techniques qui nous ont permis de mieux comprendre le GPRS.L’Unité Nationale Réseau (LUNR est lentité chargée dexploiter le cœur de réseau mobile dOrange…) aquant à elle, été informée de notre projet car notre solution pourrait être adaptée à leurs besoins en effectuantpeu de modifications.Remarque : dans la suite du document, toutes les adresses IP confidentielles ont été volontairement cachées. OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsGlossairePFE : Projet de Fin d’EtudesGPRS : General Packet Radio ServiceUNR : Unité Nationale RéseauUNRA : Unité Nationale Réseau d’AccèsUR : Unité RégionaleOMC : Operation and Maintenance Center (logiciel de supervision du réseau)FT R&D : France Télécom Recherche et DéveloppementDTRS : Direction Technique Réseau et ServicesBSS : Base Station Subsystem (rensemble des équipements radios : BTS, BSC, PCU,…)GSS : Cœur de réseau GPRSGGSN : 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 ServerPCU : Packet Coding UnitInterface Gb : interface entre le PCU et le SGSNAPN : Access Point NameMTU : Maximum Transmission UnitRWIN : TCP Receive Window SizeRAS : Remote Access ServiceTLLI : Temporary Logical Link Identifier (identifiant temporaire à létablissement dune 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès1 Conduite de projet : 1.1 Démarche :Lorsque nous sommes arrivés à Orange, nous avions à rédiger un protocole de tests permettant de mesurer laqualité de services du réseau GPRS côté utilisateur. Ce protocole de tests, dont la finalisation a été déléguéepar la suite à un groupe de travail géré par Philippe Gabard, était à l’état de draft pendant la durée de notreprojet. 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 etingé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 desbesoins, après analyse de l’existant. Notre travail a donc été dans un premier temps de prendre en compte lesmodes opératoires existants selon lesquels les tests étaient effectués et il s’avère que les protocoles pourcertains 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 quia é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’étaientfixé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 dedé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 basantsur 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é relativementlongue et qui demandait aussi bien des tests unitaires que des tests d’intégration avec plusieurs types deconfigurations.Tout au long du projet, nous avons axé notre action, avec Vincent Huriet, sur la communication autour duprojet, avec des présentations aux acteurs de l’UNR, de l’UNRA mais également aux UR et aux filialesd’Orange. OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès 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éeminimale du PFE est fixée à 10 semaines pendant cette période. Après avoir évalué le coût du projet enhommes/jour, il s’est avéré qu’il nous fallait plus de 10 semaines pour atteindre les objectifs souhaités. C’estpour cela que notre PFE a duré au total 11 semaines, une semaine ayant été prise sur les congés deprintemps.Comme nous n’avions pas choisi la même option de spécialité, nous n’étions pas toujours ensemble chezOrange. Nous avons eu 9 semaines en commun et 2 semaines où nous étions seuls chez Orange. Cetteorganisation 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 juinNous avons crée un diagramme de GANTT au début du projet pour planifier le projet et pour se donner desdates butoirs. Ce diagramme est fourni en Annexe 3. Ce diagramme nous a permis de fixer les grandes lignesdirectrices 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 objectifspré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 dusujet, 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès 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 bonmoyen 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 mieuxsituer l’activité de l’équipe GSRA. Un de nos collègues nous a notamment montré l’OMC Alcatel (logicielde supervision du GSM/GPRS). Nous avons fait plusieurs réunions avec Vincent HURIET pour bien ciblerles 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 documentationsqui 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 modemGPRS. Cela a permis de faire des tests simples : connectivité au réseau GPRS, navigation sur Internet enutilisant 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écifiquesau réseau GPRS à partir de différentes interfaces. Parmi ces outils, le logiciel TOM4, de l’éditeur NemoTechnologies, est une solution qui permet de capturer les messages passant par le lien radio. Il récupère parexemple le débit instantané par timeslot et peut, après acquisition, traiter les données et les représenter sousforme 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 voirtous les champs des messages capturés. Le K12 est un outil très puissant qui nous a beaucoup servi pendantle 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’explicationdes 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 dugroupe de travail. Cette réunion avait pour but de confronter les avis de chacun des acteurs du groupe detravail 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 lestests les plus couramment utilisés. Nous avons recherché des outils de Ping et de FTP gratuits, fiables etrépondant aux spécifications du protocole de tests. Pour tester la fiabilité des outils sélectionnés, nous avonscomparé les résultats qu’ils fournissaient avec les résultats obtenus par l’analyseur de protocole Ethereal. OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès 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 deFTP. 1.2.4 Etape 3 : Semaines 14 à 16 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 desré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 larédaction finale du protocole de tests, ainsi que la présentation dune préversion de nos scripts.. 1.2.5 Etape 4 : Semaine 18 Développement des scripts HTTP et WAPOutre les tests de Ping et de FTP, nous avons voulu développer l’automatisation des tests HTTP et WAP. Surle 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 testdes scripts Ping et FTP. 1.2.6 Etape 5 : Semaines 20 à 23 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. Lesscripts ont également été complétés pour assurer une compatibilité entre les versions anglaises et françaisesde 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 nosscripts car les scripts pourraient également les aider à effectuer des tests de performances pour le corenetwork. 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsNous avons rédigé de nombreux documents relatifs à notre solution. Nous avons écrit des procéduresd’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 nousfamiliariser avec les équipements GSM/GPRS d’Alcatel. Nous avons lancé des tests de mesures deperformances avec notre solution et nous avons utilisé l’analyseur de protocoles K12. Le K12 nous anotamment 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 parquelqu’un qui ne connaissait pas du tout notre outil. Ce « Blind test » nous a permis de corriger quelquesdé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 denotre outil ce qui a permis d’avoir un retour rapide et de corriger les derniers bugs et problèmes d’ergonomie. Revues d’avancementTout au long de ce PFE, nous avons été amenés à faire part de l’état d’avancement de notre projet aussi bienauprè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 pourbut 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’étatd’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éralune réunion par semaine pour faire le point sur l’état d’avancement du projet. Ces réunions duraient environune 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 questionsd’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 etreconnaître un produit est la clé pour que l’outil soit généralisé au sein d’Orange, et qie des benchmarkssoient possibles entre les différents constructeurs de matériel BSS, en plateforme de test FT R&D et en zoneexpérimentale.. De plus, cela contribue à donner une image positive des actions de l’UNRA en matièred’expertise technique.Nous avons organisé trois présentations principales, d’1h30 chacune, montrant l’avancement du projet et laplus-value qu’apporte notre solution. Cela permet aussi bien d’avoir un retour d’expérience descollaborateurs 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 utilisateurspotentiels 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, ilfaut s’assurer que le fonctionnement de la solution est abordable par tous, au niveau du déploiement et del’utilisation.Par l’intermédiaire de Vincent Huriet, la solution a été présentée dans la filiale d’Orange en Roumanie (SkillCenter 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsPour tester la facilité d’exploitation de notre solution, Il a été organisé un "blind test" avec un ingénieur dugroupe support Motorola (UNRA), Cédric Pascal. L’objectif de ce test était de mettre en évidence lesdifficultés qu’aurait une personne extérieure au projet et pas forcément experte en informatique, pourinstaller et utiliser les tests de mesures de performance. Au premier abord, nous avons mis en évidence desdéfauts d’intuitivité au niveau de l’interface homme-machine. Nous avons pu à la suite de cet entretienamé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 nonné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 possibledenvoyer des messages multimédias (MMS) ou encore de naviguer plus rapidement sur le WAP en utilisantun téléphone GPRS au lieu d’un téléphone GSM. Le GPRS est un réseau qui permet d’échanger des donnéespar le mode "Paquet" contrairement au GSM qui permet d’échanger de la voix en mode "Circuit". Au niveauradio, chaque donnée peut être transportée dans des trames contenant 8 timeslots. Sur ces 8 timeslots, seuls 4timeslots en général sont réservés pour le transfert de data et les 4 autres pour des communications voix. Surchacun 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 duncodage de canal donné (le "coding scheme" CS-1, CS-2,…). Sur le réseau BSS Alcatel, seul le CS-1 et CS-2sont 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 lacheminement de 3 ou 4 timeslots en downlink et 1 ou 2timeslots en uplink, ce qui propose des débits de lordres de 40kbit/s en downlink et 10 kbit/s en uplink..Le GPRS permet daccéder au réseau Internet. En effet, un téléphone portable GPRS offre les fonctionnalitésdun 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès 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 testPour lélaboration des tests de performances GPRS, la DTRS a élaboré un protocole de tests spécifique quidétaille de manière précise les paramètres à utiliser pour configurer les tests. Ces tests s’appuient sur desproprié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 surl’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 desexpé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. Cesserveurs fournissent un accès FTP et HTTP. Nous avons développé nos scripts de manière à ce quilsré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 à lutilisateur de rentrerles paramètres quil désire. Par exemple, si le protocole de tests était amené à évoluer alors loutil sadapteraitsans modifications aux nouvelles spécifications.Un extrait du protocole de test est disponible en annexe 1.Larchitecture de notre solution est relativement simple. Nous avons développé des outils pour quatre typesde tests : Ping, FTP, HTTP et WAP. Larchitecture des outils de Ping, FTP et HTTP sont très semblablesdans leur conception alors que loutil de WAP a une architecture quelque peu différente.Les outils de Ping, FTP et HTTP sappuient sur des scripts VBScript et des macros Excel. Nous avons choisila solution des scripts VBScript et Excel car dans une installation normalisée « Orange », Excel et le moteurde script WScript, permettant d’exécuter les scripts, sont fournis en standard et permettent uneautomatisation aisée. Cela répond également aux contraintes d’intégration spécifiées dans le cahier des OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accèscharges. 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 demettre en forme les résultats. Lorsque lon exécute un script, les actions suivantes se déroulentsuccessivement au cours du temps : Script VBScript : Script VBScript : Macro Excel : Macro Excel : Exécution des tests Exécution dExcel 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 dExcel fichier .txt entrée Figure 3 : Architecture simplifiée de la solutionLe test de WAP est différent des autres tests dans le sens où il nest pas entièrement automatisé. Il ne reposeque sur une macro Excel de post-traitement des traces brutes. Les traces brutes dune communication WAPsont obtenues en utilisant un analyseur de protocole qui sappelle le K12 de Tektronix. Les traces obtenuespar le K12 sont très difficiles à interpréter pour un œil non averti. La macro Excel de traitement des tracesK12 permet de retrouver les pages WAP qui ont été consultées avec son temps daffichage. Figure 4 : Tektronix K1205 : analyseur de protocolesEnfin, 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès • 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 automatisablesré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 enannexe 1) :Type de test CaractéristiquesPing Série de 101 pings Taille de PDU : 56 et 1460 octets Délai entre chaque émission : 0, 2 et 7 sFTP Série de 10 transferts en downlink et 10 transferts en uplink Trois fichiers de taille différente à chaque fois : 100ko, 500ko et 1moHTTP Série de 20 chargements de pages (textes + images)WAP Série de 20 chargements de prépage, puis de la page daccueil OrangeNous nous étions dirigés vers des outils qui étaient utilisés aussi bien à FT R&D qu’à Orange, enl’occurrence WS_Ping Pro pack de l’éditeur IPSwitch et le FTP de la commande dos. Dans un premiertemps, le ping de la commande dos n’a pas été envisagé car il n’offrait pas de paramètre pour gérer le délaientre chaque émission de ping en mode natif. Nous avions également la possibilité d’utiliser un autre logicielspécialisé, Tom 4, de l’éditeur Nemo Technologies, qui est un analyseur de réseau en temps réel surl’interface radio. Il permet de récupérer à l’aide d’un mobile à traces (le Sagem OT190 dans notre cas) entreautres 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 lapossibilité de créer un script de lancement de transfert FTP. Finalement, nous n’avons que très peu utilisé cetoutil pour plusieurs raisons, car tout d’abord il n’y en avait qu’un seul pour tout l’UNRA (problème dedisponibilité) 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accèsupload), ce qui limite le débit théorique en download à 13.4*3 ~ 40 kbit/s (en CS2). Lavantage certain duTom4 par rapport à une solution plus simple est dobtenir le débit par timeslot en kbit/s lors du transfert et devoir 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 190Par 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 satisfaisantespuisque nous souhaitions automatiser « WS_Ping_ProPack », un logiciel en mode fenêtré. Chacune descommandes émulées à la place de l’utilisateur étaient censées naviguer dans l’interface graphique, mais cettesolution était très sensible aux éléments extérieurs (popup qui s’ouvre inopinément, utilisateur qui change lefocus d’une fenêtre,…). Nous nous sommes donc orientés vers des outils en ligne de commande, à l’instar duFTP dos. Nous avons donc repris le ping dos et essayé de trouver une solution pour émuler les délais entrechaque émission de ping.En consultant le support de Microsoft, nous avons trouvé une solution pour assigner un délai entre chaqueping :Source :http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000serv/support/faqw2kcp.aspHow 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>nulTo sleep for 15 seconds, type:ping - n 16 127.0.0.1>nulUne autre solution pourrait être d’utiliser la commande « PING 1.1.1.1 -n 60 -w 1000 >NUL ». De cettefaçon, on utilise le paramètre de timeout –w pour recréer une temporisation. En effet, l’adresse 1.1.1.1n’étant pas valide, le système va attendre 1000 ms entre chaque ping pour attendre une réponse qu’il nerecevra jamais.Nous avons ensuite vérifié avec Ethereal que cette propriété du ping donnait des résultats plausibles. Dansl’exemple ci-dessous, nous retrouvons dans la colonne « Delta » le délai entre chacune des requêtes. Ons’aperçoit que le délai de 2 secondes fixé entre une requête « echo reply » et la requête « echo request » OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accèssuivante 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 5000Réponse de 111.111.111.111 : octets=56 temps=1242 ms TTL=253C:TESTS_GPRSPING>ping.exe 111.111.111.111 -n 1 -l 56 -w 5000Réponse de 111.111.111.111 : octets=56 temps=771 ms TTL=253C:TESTS_GPRSPING>ping.exe 111.111.111.111 -n 1 -l 56 -w 5000Réponse de 111.111.111.111 : octets=56 temps=891 ms TTL=253C:TESTS_GPRSPING>ping.exe 111.111.111.111 -n 1 -l 56 -w 5000Réponse de 111.111.111.111 : octets=56 temps=862 ms TTL=253C:TESTS_GPRSPING>ping.exe 111.111.111.111 -n 1 -l 56 -w 5000Réponse de 111.111.111.111 : octets=56 temps=741 ms TTL=253 Figure 7 : Capture Ethereal, 5 ping à 56 octets, Délai 2sEn s’appuyant sur les commandes dos “ping” et “FTP”, nous avons basé la solution sur des scripts et desmacros 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 desscripts « 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 letraitement 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 BasicApplication) 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 fonctiond’un fichier en entrée, la macro oriente le type de traitement à effectuer à l’ouverture d’Excel. Si aucunfichier « Type_Test.txt » n’est trouvé, alors Excel n’effectuera aucun traitement. Pour assurer la rétro OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accèscompatibilité avec Excel 97, il faudrait redéfinir des fonctions qui ont été introduites sous Excel 2000, maisce nétait prioritaire dans laccomplissement du projet.Les scripts ne nécessitent pas l’installation d’un interpréteur ni d’un compilateur additionnel, mais nousavons 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 HostConcernant le support du multilinguisme, nous avons assuré la compatibilité avec des installations deWindows en français et en anglais car les filiales d’Orange à létranger utilisent en général Windows enversion anglaise. Cela est important car Excel ne calcule pas de la même manière suivant s’il est en versionfrançaise ou anglaise. Nous avons également veillé à bien documenter tous les scripts aussi bien en françaisquen anglais. Potentiellement, une personne connaissant le langage Visual Basic est capable d’apporter desmodifications pour personnaliser la solution.Pour pouvoir configurer aisément ces scripts, nous avons externalisé dans des fichiers les variables contenantdes chemins vers les répertoires et fichiers de l’application, mais aussi les paramètres des tests, tels lenombre de transferts FTP par exemple. Pour quun utilisateur non initié puisse facilement configurer lesscripts, nous avons crée en Delphi une interface graphique (GUI) intuitive, qui sera introduite par la suite.Une de nos contraintes était également dutiliser des outils fiables. Par exemple, nous nous sommes servis delanalyseur de protocole "Ethereal" ou encore de lanalyseur 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsLes logiciels suivants sont facultatifs et permettent d’avoir une autre vision pour investiguer dans d’autresdirections : - 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 etde débit, mais ils permettent également d’enregistrer de façon automatisé des traces Ethereal pourinvestigation ultérieure. Tout le paramétrage de ces scripts peut être effectué à partir d’une interfacegraphique en Delphi. Cela évite un grand nombre de manipulations par l’utilisateur, puisque l’interfaces’occupe de copier les fichiers au bon endroit, selon les chemins fournis par l’utilisateur. Nous avons choiside 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 vbsConcernant la macro Excel qui effectue tous les post-traitements, nous l’avons découpé en 5 modules, dont 4sont assignés à chacun des tests. Comme mentionné ci-dessus, le fichier « MacroDemarrageGPRS.xla » doitimpérativement se trouver dans le répertoire XLStart de l’installation d’Office. Tout fichier se trouvant dansce répertoire sera automatiquement ouvert lors du lancement d’Excel. Le répertoire « varMacro » (cf figureci-dessous) contient le fichier « varMacro.txt », fichier de variable contenant le chemin vers l’installation denotre package. Cela permet notamment de sauvegarder le fichier Excel à la fin de l’exécution de la macro. OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès Figure 10 : Répertoire XLStart de linstallation dOfficeLe premier module « auto_open » définit une macro qui sexécute automatiquement si elle trouve un fichierdont le chemin est contenu dans la variable "Type_test_File" et qui contient soit le mot PING, soit le motFTP, soit le mot HTTP.Pour vérifier que le fichier xla a bien été pris en compte par Excel, il suffit douvrir Excel et dentrer auclavier le raccourci Alt+F11 (ou menu Outils>Macro>Visual Basic Editor). Normalement, un projet VBAdoit porter le nom "MacroDemarrageGPRS.xla" et doit comporter 5 modules. Figure 11 : Visual Basic Editor : découpage de la macro en 5 modulesLors de l’exécution des scripts Ping, FTP et HTTP, chacun des scripts lance Excel et fait en sorte que le bonmodule de la macro se lance. Il est possible, directement à partir des fichiers de traces générés lors desscripts, de rejouer les macros. Toutefois, il faut veiller au chemin indiqué dans le fichier « varMacro.txt » OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accèsdans le répertoire « XLStart », puisque la macro Excel sauvegardera à l’issue de son exécution un nouveaufichier Excel dans le répertoire spécifié dans le fichier « varMacro.txt », avec dans le nom du fichier la dateet heure courante. Suivant le type de test, le fichier Excel sera sauvegardé dans le répertoire « Results » de lasous arborescence du package correspondant. Par exemple, un fichier de traces Ping peut être rejoué à partirdu 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ésultatVoici une série de diagrammes présentant l’implémentation de chacun des outils de tests Ping, FTP etHTTP : 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 duserveur de tests. Comme nous l’avons précisé ci-dessus, nous avons à notre disposition deux serveurs de tests OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accèsdont l’accessibilité est déterminée par la charge réseau à un moment donné. Ces pings permettent donc derepé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 ICMPLes 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès Figure 15 : Post-traitement macro Excel Ping selon le protocole de testTests 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsDe même, pour déterminer le serveur disponible parmi les deux serveurs de tests, nous émettons une série de4 ping qui permet de déterminer l’adresse IP qui sera utilisée lors des transferts FTP. Le principe de ce scriptest 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 Le chemin du fichier « TYPE_TEST.txt » qui permettra à la macro Excel de déterminer le type de 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 FTPLes données obtenues en sortie sont : Les mesures « brutes » 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 testsTests HTTP :Ce test permet de mesurer le temps de chargement d’une page web. Du point de vue du client utilisateur, laconsultation de pages web est une application courante d’une connexion RAS avec modem GPRS et c’est ence 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accèsreflète concrètement ce qu’un client d’Orange perçoit et de l’autre nous n’avions pas à notre disposition despages web de référence sur les serveurs de test. Pour prévenir les aléas du cache du navigateur InternetExplorer, nous avons fourni un fichier « .reg » permettant d’obliger le navigateur à vider son cache à chaquefois qu’il se ferme.Le script lance donc Internet Explorer, charge une page à partir de son URL, puis referme le navigateur, etainsi de suite jusqu’à ce que le nombre de chargement de pages soit atteint. Dans le protocole de test, ilfallait effectuer vingt chargements à la suite pour obtenir des statistiques. Nous utilisons des fonctions devbscript pour récupérer la taille des pages lancées. Notre solution gère les pages avec des frames, du texte etdes images. Il savère toutefois que les résultats renvoyés par les fonctions vbscript, en loccurrence"document.filesize", ne reflète pas de façon certaine (cela dépend des types de pages, si elles comportent dujavascript,…) la taille exacte de la page visitée. Nous nutilisons que le navigateur Internet Explorer car il estaisément automatisable à partir de code en vbscript et est standard sur les machines dOrange. Les tests ontété effectués avec la version 5.5 dInternet 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. Cettepage 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 HTTPVoici 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 » Le chemin du fichier « TYPE_TEST.txt » qui permettra à la macro Excel de déterminer le type de test Le chemin vers l’application Excel Une variable indiquant si l’on souhaite ou pas une capture Ethereal pendant les transferts HTTP OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsLes données obtenues en sortie sont : Les mesures « brutes » 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 uneapplication déjà couramment utilisée par les usagers du téléphone mobile. De plus, la pile de protocole WAPest dissociée de TCP/UDP ce qui permettra davoir des résultats totalement indépendants des autres tests. OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsNous avons décidé de capturer les communications WAP avec le K12 (analyseur de protocoles) surlinterface Gb et deffectuer ensuite un post-traitement macro-Excel pour en faire ressortir la communicationWAP que lon a initiée. Les mesures ne sont donc plus automatisées comme précédemment pour les autresscripts Ping, FTP et HTTP.Nous avons préalablement effectué quelques tests avec WinWap 3.1 Pro, un émulateur Wap implémentant sapropre pile wap (http://www.winwap.org/index.html). WinWap se connecte au réseau GPRS avec le mobileMotorola T280 (APN orange.fr) et remplace intégralement le navigateur embarqué du mobile par uneapplication Windows. Nous avons pu avec Ethereal obtenir comment étaient codés en hexadécimal lesrequêtes WTP et WSP. Cela nous a bien aidé pour enchaîner avec le K12.Nous navons pas poursuivi avec cette solution car ce logiciel est un shareware limité dans le temps et, quela pile protocolaire wap implémentée ne reflétaient pas forcément celle intégrée au téléphone mobile, ce quiaurait eu des conséquences au niveau des mesures. Nous avons donc préféré poursuivre avec lanalyseurK1205, qui permet dobtenir lensemble des messages Wap transitant par linterface Gb. Figure 21 : Capture Ethereal de trafic généré par WinwapNotre solution consiste à effectuer des post-traitements sur ces fichiers de capture bruts K12. Ces tracesdoivent être ensuite exportées vers Microsoft Excel pour appliquer un filtre qui permettra de ne sélectionnerque 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 dobtenir au final un tableau Excel retraçantle parcours des pages WAP visitées lors dune communication. Elle permet de mettre en évidence le temps dechargement de chaque page WAP.Voici le fonctionnement chronologique du filtrage sous Excel : OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès Premier Filtre : on garde tous les messages WAP Les traces contenues dans le fichier .txt contiennent tous les détails des protocoles (90% de linformation nenous est pas utile). On parcourt toutes les lignes de traces à laide de la fonction "Filtre_MessagesWAP()"pour récupérer seulement lheure, le type, le n°IMSI, le n°TLLI, lurl des messages. LUrl est décodée àpartir des codes opératoires hexadécimaux. Pour cela, la fonction qui transforme lhexadécimal en ASCII aété entièrement recodée. On récupère lidentifiant TLLI de notre communication WAPLes numéro IMSI et TLLI ne sont présents en même temps que dans le message "APAC" ( APAC = ActivatePDP Context Accept Request, ce qui signifie quun 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 lemessage « APAC ». On récupère le TLLI grâce à la fonction "TLLI_MaComWAP". Deuxième filtre : on garde seulement les messages WAP de notre communicationMaintenant que le TLLI de la communication WAP qui nous intéresse est connue, on peut appliquer unsecond filtre "Filtre_MaComWAP" sur les messages WAP pour ne garder que ceux appartenanteffectivement à la communication qui nous intéresse. On calcule les temps daffichage des temps WAPLes messages "GET" sont uniques et nous servent de référence pour repérer les temps de début et de fin dechargement de page. La fonction "Temps_Chargements()" parcourt les cellules pour repérer les "GET" etappelle 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 tableauTous 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écodantles valeurs hexadécimales dans les traces K12), le temps de chargement de la prépage d’accueil Orange, letemps de chargement du portail wap Orange,… Dans la figure ci-dessus, on met en évidence le temps qu’unutilisateur attendra pour obtenir sa page d’accueil. Le test de la figure ci-dessus a été effectué avec le Sagemmy-X5, en Wap couleur, ce qui alourdit nécessairement les traces comme la taille des pages est plusimportante. OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès 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 comprenanttous les scripts suivant une arborescence définie. Dans la dernière version 1.1 que nous avons eu l’occasionde produire, nous avons inclus des scripts pour windows 98 et des fichiers permettant de modifier la base deregistres de windows 2000 pour changer les paramètres de MTU, de RWin,…, qui ont une influence nonné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 pardéfaut, mais sous Windows 2000, si ce n’est pas explicitement rajouté à la base de registres, ces paramètresde 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 nousavons paramétré Windows pour préparer les séries de mesures : création d’une connexion Ras, Planificationde tâches, modification des valeurs de la base de registres pour optimiser la pile TCP/IP, configurer Etherealsous 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsPar exemple, lors des mesures de nuit, il est impératif de retirer dans les options avancées d’alimentation deWindows la mise en veille prolongée. Cela peut être la source, même en journée, de déconnexion de laconnexion 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’Accès 2.4 Validation et expérimentationsA 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 desproblèmes logiciels et matériels. En effet, nous avons diagnostiqué avec Eric Touron, ingénieur du groupeSupport Nortel, un problème avec les liaisons infrarouges entre PC et mobile. La liaison fausse les résultatsde ping, pour certains délais entre chaque émission (délai 2s). En refaisant exactement les mêmes tests avecun cable série ou USB, nous avions des résultats tout à fait corrects. De même, nous étions étonné par lesrésultats anormalement élevés des transferts FTP en upload. Nous avions en général 1,80ko/s, soit 14,4 kbit/sen 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 lafenêtre d’émission était vide, alors que le serveur FTP renvoyait par la suite les acquittements pour chacundes paquets de la fenêtre d’émission (soit 17 520 octets à acquitter). Le temps de transfert était donccomplètement faussé et le débit également. Tests de nuitDès les premières versions des scripts Ping et FTP, nous avons voulu mettre à lépreuve ces outils pourvérifier la cohérence des résultats. Pour cela, nous avons effectué des tests en journée ainsi que des tests denuit. Les tests de nuit étaient programmés pour se lancer à une certaine heure grâce à lutilisation duplanificateur de tâches Windows. Lintérêt des tests de nuit était de disposer de beaucoup de temps libre pourlexécution des scripts et d’un réseau public peu ou pas perturbé. Par exemple, le test de FTP conforme auprotocole 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), à lacampagne, sous couverture du BSS Nortel. Cela permet d’obtenir des résultats en journée sur le réseaupublic en principe peu perturbé par le trafic ambiant, contrairement aux mesures effectuées à Lyon. Enassignant 4 timeslots pour des transferts PDCCH sur certains secteurs de la BTS, nous avons pu testeressentiellement les transferts FTP en upload et en partage de charge (plusieurs mobiles uploadent en mêmetemps), 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. EtherealParallèlement à lexécution des scripts, nous avons lancé des captures avec lanalyseur 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 dinvestiguer différents problèmes rencontrés. Parexemple, cest avec Ethereal que nous avons pu mettre en évidence un problème de fermeture de session FTPpar hôte distant et un problème au niveau des résultats fournis par la commande FTP dos en upload. K1205Pour pouvoir utiliser lanalyseur de protocoles K12, il faut se rendre sur site et se connecter sur une interfaceGSM/GPRS à savoir Abis, Gb ou encore Gi.Nous avons utilisé lappareil 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 descaptures K12 sur linterface Gb. Cela nous a permis de voir en détail les messages passant entre le BSS et le OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsGSS. Toutes les communications passaient par un BSS reproduit dans une petite salle, de la micro BTSjusqu’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 tracesK12.Nous avons élaboré plusieurs scénarios de communications WAP pour le K12, avec avant chaque set demesures 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 lanalyseur 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 enmaquette avec le BSS Alcatel, qu’à Lyon sous couverture du BSS Nortel. Par contre, nous avons puinvestiguer dans plusieurs directions, grâce aux documents de FT R&D pour évaluer d’où pouvait provenirles problèmes survenus lors des mesures. OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsPar exemple, lors des transferts FTP, nous avons fréquemment obtenu des messages indiquant la fermeturede la connexion par l’hôte distant, en fin de transfert du fichier. Cela a pour effet de ne pas nous fournir destatistique sur la taille du fichier transféré, le temps de transfert et le débit et de couper la connexion pour lestransferts suivants. Le problème survient surtout lors de transferts de gros fichiers. Lorsque nous effectuonsen parallèle des captures Ethereal, il s’avère qu’il y a un déséquencement au niveau des acquittements despaquets, ce qui a pour effet de demander à la suite plusieurs paquets de type « Duplicate Ack ». D’après laRFC 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 perdudé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 trouverla cause exacte.Pour les tests de ping, nous avons pu effectuer quelques captures avec le K12 pour regarder comment sontsegmentés les paquets sur le réseau. Lorsque nous avons des ping ayant une PDU de 56 octets (+ 28 octetsd’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, ilssont 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 desmoyennes relativement bonnes, de l’ordre de 5ko/s (soit 40kbit/s) pour le download et 1,3 ko/s (soit 10,4kbit/s) pour l’upload. La plupart des tests ont été effectués en CS-2 (13,4kbit/s théorique par timeslot). Ilaurait é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, commenous travaillions sur un réseau très peu optimisé au niveau BSS. Avec plus de temps, il aurait été intéressantde créer des configurations temporaires sous l’OMC (outil de supervision Alcatel) pour voir l’impact deschangements de paramétrage du réseau. OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsConclusion :En 11 semaines actives de projet, nous avons non seulement livré une solution complète permettantd’effectuer des tests automatisés de performance du réseau GPRS, mais nous avons pu également avoir unevision pratique de l’architecture, de l’optimisation et de la supervision d’un réseau GPRS. D’un côté, nousavons énormément appris au niveau du développement de scripts et de macros en environnement Microsoftet nous avons également pu approcher de près les problématiques de l’optimisation des réseaux d’accèsGPRS, en utilisant des outils spécialisés .La solution que nous proposons, évolutive et documentée, permet d’effectuer des mesures en chaînes defaçon simple et de présenter les résultats dans un tableau Excel. Cette solution permet de gagner beaucoup detemps, notamment lorsque le protocole de tests demande de nombreux transferts pour avoir de meilleursrésultats statistiques. Pour information, d’après le protocole de Philippe Gabard, il faut environ 2h30 poureffectuer tous les tests de façon automatisée. Dans le cas de mesures manuelles, cela se compte en nombre dejours de mesures, dû à la mise en place de configurations de tests et de relève et analyse statistique demesures..Au niveau des améliorations immédiates du produit, il faudra trouver une alternative au client FTP dos, enraison de ses résultats erronés en upload, et éventuellement en fonction des besoins de compatibilité avecWindows 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, nousl’espérons sera utilisée au niveau des groupes supports, puis au sein des unités régionales et des filialesd’Orange. La solution a même été testée par Michel Lai, collègue de promotion en PFE à Orange sur laQualité de Service du réseau UMTS, et donne un aperçu quantitatif des performances de l’UMTS. Notresolution 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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsIndex des figures :FIGURE 1 : CHRONOLOGIE SIMPLIFIEE DU PROJET ................................................................................................................7FIGURE 2 : RESEAU GPRS COTE BSS................................................................................................................................12FIGURE 3 : ARCHITECTURE SIMPLIFIEE DE LA SOLUTION ...................................................................................................13FIGURE 4 : TEKTRONIX K1205 : ANALYSEUR DE PROTOCOLES ..........................................................................................13FIGURE 5 : DISPOSITIF DE TEST ..........................................................................................................................................14FIGURE 6 : NEMO TECHNOLOGIES TOM4 ET SAGEM OT 190.............................................................................................15FIGURE 7 : CAPTURE ETHEREAL, 5 PING A 56 OCTETS, DELAI 2S ......................................................................................16FIGURE 8 : PRINCIPE DE WINDOWS SCRIPT HOST ..............................................................................................................17FIGURE 9 : INTERFACE GRAPHIQUE POUR CONFIGURER LES SCRIPTS VBS ...........................................................................18FIGURE 10 : REPERTOIRE XLSTART DE LINSTALLATION DOFFICE ...................................................................................19FIGURE 11 : VISUAL BASIC EDITOR : DECOUPAGE DE LA MACRO EN 5 MODULES ..............................................................19FIGURE 12 : FICHIER DE RESULTAT ....................................................................................................................................20FIGURE 13 : FONCTIONNEMENT DU SCRIPT "PING" ............................................................................................................20FIGURE 14 : MESURES FILTREES ........................................................................................................................................21FIGURE 15 : POST-TRAITEMENT MACRO EXCEL PING SELON LE PROTOCOLE DE TEST .......................................................22FIGURE 16 : FONCTIONNEMENT DU SCRIPT "FTP" .............................................................................................................22FIGURE 17 : TRANSFERTS FTP SELON LE PROTOCOLE DE TESTS ........................................................................................23FIGURE 18 : FONCTIONNEMENT DU SCRIPT HTTP .............................................................................................................24FIGURE 19 : MESURES BRUTES ..........................................................................................................................................25FIGURE 20 : TRANSFERTS HTTP : 20 CHARGEMENTS DE LA PAGE « ORANGE.FR »............................................................25FIGURE 21 : CAPTURE ETHEREAL DE TRAFIC GENERE PAR WINWAP ..................................................................................26FIGURE 23 : ECHANGES PROTOCOLAIRES WAP ET TEMPS DE CHARGEMENT DES PAGES .....................................................28FIGURE 24 : DELIVRABLES ................................................................................................................................................29FIGURE 25 : ARBORESCENCE DU PROJET APRES INSTALLATION DU PACKAGE ....................................................................29FIGURE 27 : CAPTURES AVEC LANALYSEUR DE PROTOCOLES K12 (DEMANDE D’ACTIVATION DU PDP CONTEXT)...........31Bibliographie : [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 Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsAnnexesAnnexe 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 sizeExpected 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 repartitionOperation 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 sizeExpected results 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 varianceOperation 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.Expected results For each file size: Percentage of failure Average retrieval time Standard mean deviation OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsAnnexe 2 : codes opératoires d’un échange wap Taille Type de requête Sens UDP Trans(bytes) fert93 WSP-GET 0e 31 8d 12 40 … UL1104 WSP-REPLY 12 B1 8d 04 20 … DL11 WTP-ACK 18 31 8d UL WSP-CONNECT La connexion sest interrompue. On252 0e 50 b8 12 01 … UL redemande à se connecter44 WSP-CONNECT REPLY 12 d0 B8 02 8d … DL11 WTP-ACK 18 50 B8 UL35 WSP-GET 0e 50 b9 12 40 … UL972 WSP-REPLY 12 d0 b9 04 20 … DL11 WTP-ACK 18 50 b9 UL14 Extended Method GET-PDU 0e 50 ba 12 51 … UL18 WSP-REPLY 12 d0 ba 04 24 … DL11 WTP-ACK 18 50 Ba UL105 WSP-GET 0e 31 8e 12 40 … UL900 WSP-REPLY 12 b1 8e 04 20 … DL WSP-GET Get arrivant plus tôt que prévu (précision92 0e 3a bc 12 40 … UL horloge windows défaillante)11 WTP-ACK 18 31 8e UL OrangeFrance Reproduction interdite sans autorisation préalable
    • Support Réseau d’AccèsAnnexe 3 : Diagramme de GANTT OrangeFrance Reproduction interdite sans autorisation préalable