Rapport de stage ST40sousix.free.fr/stef/cours/stage/A07_CHENEVOY_ST40_RAPPORT.pdf · O Rapport de...

35
Rapport de stage ST40 Automne 2007 Chenevoy Stéphane Département génie Informatique France Telecom - Orange 8, rue du Dauphiné 69424 Lyon Outils de Remontée d' Incohérences et de Corrections massives par Xml Tuteur en entreprise Patrick Ainard-Simonet Suiveur UTBM Abdel Jalil Abbas-Turki Université de Technologie Belfort-Montbéliard

Transcript of Rapport de stage ST40sousix.free.fr/stef/cours/stage/A07_CHENEVOY_ST40_RAPPORT.pdf · O Rapport de...

Rapport de stage ST40 Automne 2007

Chenevoy Stéphane Département génie Informatique

France Telecom - Orange 8, rue du Dauphiné

69424 Lyon

Outils de Remontée d'Incohérences et de Corrections massives par Xml

Tuteur en entreprise

Patrick Ainard-Simonet

Suiveur UTBM

Abdel Jalil Abbas-Turki Université de Technologie

Belfort-Montbéliard

Chenevoy Stéphane - 2 - Sept. 2007 – Fév. 2008

Remerciements

Je tiens particulièrement à remercier Patrick Ainard-Simonet qui m‟a encadré pendant toute la

durée de mon stage avec beaucoup de sympathie. Merci également à Nicolas Schlewitz et Grégory Veille qui m‟ont aidé à maintes occasions

d‟un point de vue technique en informatique et téléphonie mobile. Merci aux deux équipes de l‟Ingénierie Radio et Qualité Plaque, et plus particulièrement la

Zone 1 pour son accueil chaleureux. Je remercie également Émeline, stagiaire au sein de l‟IRQP, pour ses remarques pertinentes

sur mon travail et pour les moments conviviaux que nous avons pus partager.

Je ne saurais oublier Romain Biard, stagiaire ayant initié le travail un semestre auparavant et qui m‟a aidé à différentes reprises sur le projet.

Enfin, merci à Victor Lopes, administrateur système et Antoine Faillie, ingénieur à l‟Unité de Pilotage Réseau Ile de France pour leur aide dans l‟aboutissement du projet.

Chenevoy Stéphane - 3 - Sept. 2007 – Fév. 2008

Sommaire

Remerciements ...................................................................................................... 2

Sommaire .............................................................................................................. 3

1 Introduction..................................................................................................... 4

2 Présentation de l‟entreprise .............................................................................. 5

3 Présentation du sujet ...................................................................................... 10

4 Mise en œuvre ............................................................................................... 17

5 Bilan ............................................................................................................. 28

6 Conclusion .................................................................................................... 31

7 Bibliographie ................................................................................................ 32

Table des illustrations .......................................................................................... 33

Table des matières ............................................................................................... 34

Chenevoy Stéphane - 4 - Sept. 2007 – Fév. 2008

1 Introduction

Dès l'apparition des premiers réseaux en téléphonie mobile à la fin des années 80, personne

n'aurait parié qu'un tel moyen de communication prendrait autant d'ampleur. Pour preuve,

l'opérateur historique, France Telecom se trouve aujourd'hui confronté à des problèmes de système d'informations dûs à un nombre très important d‟antennes relais implantées dans toute la France.

La concurrence est aujourd'hui rude avec les quelques grands opérateurs en téléphonie

mobiles tels que SFR ou Bouygues Telecom. Chacun s'active pour avoir une couverture réseau la plus grande possible avec la meilleure qualité.

C'est en coulisse, à l'Unité de Pilotage Réseau Centre-Est appartenant au groupe France

Telecom que j'ai effectué mon stage de milieu d'étude d‟école d'ingénieur. Celui ci s'est déroulé au

sein du département radio où travaillent de nombreux ingénieurs en réseaux mobiles dont le but est de développer et d'effectuer la maintenance de la couverture radio du réseau Français. Pour cela,

l'utilisation de plusieurs logiciels leur est nécessaire. Nous nous intéresserons à l‟outil NetAct Planner développé par Nokia dont la fonction

principale est la simulation de couverture radio. Cet outil se dote d'une base de données dont le

contenu doit être le plus à jour possible par rapport aux données terrain.

Durant six mois, j'ai repris le projet Oricox qui avait été initié par un étudiant de l'UTBM un semestre auparavant. Le rôle principal de cette application est la récupération de données terrain à jour afin de détecter puis corriger les incohérences de la base de données de NetAct Planner. L‟outil

contient aussi quelques petits modules facilitant l'utilisation de NetAct Planner avec d'autres logiciels. L'objectif de mon stage fut d'améliorer diverses fonctions concernant la détection

d'incohérences ainsi que de développer d'autres petits modules tournant autour du logiciel de Nokia. D'autre part, une partie importante de ce stage s'est articulée autour de la déployabilité d'Oricox pour toutes les Unités de Pilotage Réseaux.

Dans un premier temps nous commencerons par une présentation du groupe France Telecom

ainsi que du contexte dans lequel le stage s'est déroulé. Ensuite une présentation du sujet sera faite avec le cahier des charges qui en découle. Puis nous expliquerons les choix de mise en œuvre avec son déroulement. Enfin nous terminerons par le bilan pour l‟entreprise et le bilan au niveau

technique et humain qu'une telle expérience a pu m‟apporter.

Chenevoy Stéphane - 5 - Sept. 2007 – Fév. 2008

2 Présentation de l’entreprise

2.1 Présentation générale du Groupe France Telecom (FT)

Avec un effectif de près de 189 000 salariés1, dont environ 107 000 en France, France Telecom est un acteur majeur dans le monde des télécommunications, en France, mais également au

niveau international. Cette entreprise, initialement entreprise publique, aujourd‟hui privée, a une large gamme d‟offres commerciales, dans le domaine de la téléphonie fixe et mobile, ainsi que celui

de l‟accès à Internet, pour les particuliers ou pour les entreprises. Pas moins de 167,8 millions de clients (+9,8% par rapport à la même période en 2006) , dont 106,9 millions (+16%) rien que pour la téléphonie mobile (hors MVNO 2), ont choisi FT comme opérateur, ce qui fait de l‟entreprise la

première sur le marché français.

Les activités mobiles sont un moteur important de la croissance du groupe : le chiffre d‟affaires au troisième trimestre 2007 était de 39 420 millions d‟euros3 soit une augmentation de +3,5% par rapport à la même période en 2006. En France, 46,8% du marché revient à France

Telecom, avec un chiffre d‟affaires France de 7 millions d‟euros1. Sous la marque Orange, France Telecom est présent dans plusieurs pays d‟Europe,

notamment au Royaume-Uni (activité fixe, mobile et Internet, chiffre d‟affaires UK de 1,7 millions d‟euros), en Espagne (fixe, mobile, Internet, chiffre d‟affaire Espagne 1,6 millions d‟euros) et en Belgique. Il est également présent au Moyen-Orient, en Afrique, et en Asie. .

Figure 1 : Implantation du groupe France Telecom dans le monde

1 Ch iffre du rapport des résultats du 3

ième trimestre 2007

2 Mobile Virtual Network Operators (opérateur de réseau mobile virtuel) : opérateur de téléphonie mobile ne

possédant pas d‟équipement radio, ni d‟infrastructure, qui contracte auprès des opérateurs traditionnels des forfaits

utilisateurs qu‟il revendra sous sa marque. (Exemple : Virgin Mobile, OL Mobile, Auchan, …) 3 Les résultats de l‟année 2007 ne sont pas encore disponibles

Chenevoy Stéphane - 6 - Sept. 2007 – Fév. 2008

Le groupe France Telecom a pour ambition de devenir le premier opérateur intégré en Europe

(« un opérateur domestique par pays4 »). Il lance ainsi en juin 2005 le plan NExT (Nouvelle Expérience des Télécommunications). Il a pour but de rassembler, dans les pays où l‟entreprise n‟est pas l‟opérateur historique, les différentes offres fixes, Internet et mobiles sous l‟enseigne

unique d‟Orange, permettant ainsi une convergence de services de communication. En France, l‟enseigne France Telecom, étant l‟opérateur historique, gardera tout de même

l‟activité de téléphonie fixe classique, mais les autres différentes marques, comme Wanadoo, Itinéris ou encore OLA ont été rassemblées sous la marque Orange en 2006. Un scénario du même type s‟est déroulé au Sénégal où l‟opérateur historique est Sonatel.

Avec ce plan d‟action, l‟opérateur historique de France espère ainsi gagner des parts de marché dans tous les pays où la société est implantée, mais également simplifier les services offerts

aux clients. Ainsi, cette simplification d‟offres a entraîné une simplification d‟organisation au sein de l‟entreprise, comme le regroupement en Unité de Pilotage Réseau des services de conception du fixe, de l‟Internet et du mobile, ou encore le rassemblement des laboratoires de recherche et

développement et du service markéting. Ce dernier oriente ainsi les recherches des laboratoires dans l‟optique d‟implantation du Groupe. Ils sont à l‟origine d‟Unik (un téléphone mobile qui fait

téléphone fixe une fois arrivé chez soi) qui est l‟offre qui illustre parfaitement le but de France Telecom.

2.2 Un peu d’histoire France Telecom est l‟opérateur historique de France. Son histoire commence au XIXème

siècle avec la création du ministère des postes et des télégraphes. Petit à petit, le ministère absorbe

le réseau de téléphonie fixe, géré alors par le privé. En 1889, la téléphonie fixe devient un service public géré par l‟État, et en 1923, le ministère se renommera Ministère des postes, des télégraphes

et de la téléphonie (PTT). En 1944, au lendemain de la seconde guerre mondiale, le Centre National d‟Étude des

Télécommunications (CNET) est créé, et a pour première mission de remettre en place le réseau de

télécommunication de la France. Le CNET permet de rattraper le retard de la France et contribue ainsi à l‟avènement de plusieurs innovations telles que le Minitel, le télétexte, les communications

par l‟image, … En 1988, la Direction Générale des Télécommunications (DGT) devient France Telecom. Il

faut attendre 1991 pour que l‟entreprise devienne autonome et soit séparée de la Poste.

La même année, apparaissent les premières expérimentations du réseau de téléphonie mobile GSM5. Deux ans après les premières offres commerciales apparaissent sous la marq ue Itinéris. Dès

lors, les offres ne cesseront de se multiplier. En 1996, France Telecom devient une société anonyme, France Telecom SA, et un an après,

la société sera cotée en bourse.

Parallèlement au développement du réseau mobile, France Telecom se la nce dans l‟accès à Internet en créant en mai 1996 le fournisseur d‟accès à Internet (FAI) Wanadoo, sous la tutelle de

France Telecom Interactive. Grâce à sa réputation d‟opérateur historique, Wanadoo perce rapidement sur ce marché, dépassant en mai 1998 le géant AOL. Dès lors, et avec l‟arrivée de l‟accès à Internet haut débit (l‟ADSL), le FAI restera premier.

4 Et re le premier fournisseur d‟accès à Internet, premier opérateur de téléphonie mobile et fixe. Cette philosophie

amène une « convergence des réseaux fixes et mobiles ». 5 GSM : Global System for Mobile communications, est une norme numérique pour la téléphonie de deuxième

génération. On nomme, souvent par abus de langage la 2G.

Chenevoy Stéphane - 7 - Sept. 2007 – Fév. 2008

L‟année 2000 marque un tournant : l‟opérateur historique rachète à Vodafone, Orange,

l‟opérateur majeur de téléphonie en Europe. France Telecom augmente ainsi considérablement ses parts de marché. En 2003, Itinéris, et autres OLA ou Mobicarte passent désormais sous la marque Orange.

En 2006 Orange devient l‟opérateur unique pour l‟accès à Internet (disparition de Wanadoo),

mais aussi pour la télévision et le téléphone par IP et bien sûr la téléphonie mobile en France. Aujourd‟hui, France Telecom Orange est une entreprise incontournable du monde de la

télécommunication, qu‟elle soit mobile, fixe, ou par internet.

2.3 Unité de Pilotage Réseau Centre Est (UPRCE)

2.3.1 Qu’est-ce qu’une Unité de Pilotage Réseau ?

L‟Unité de Pilotage Réseau (UPR), comme son nom l‟indique, est l‟entité au sein de FT

chargée de piloter le réseau mobile, et depuis l‟apparition de plan NExT, du fixe. Sous la Direction des Opérations France, l‟UPR est chargé de l‟entretien du réseau de téléphonie. Ainsi, dans le cas de la téléphonie mobile, l‟UPR est chargée de la gestion de la conception et de la maintenance du

réseau. La France a été découpée en 7 parties, chacune représentée par une UPR, qui aura des

objectifs dépendant des spécificités du matériel utilisé, de la géographie et de la diversité de population.

Les UPR du nord utilisent la technologie Alcatel et Nokia, et les UPR du sud (Toulouse,

Marseille et Lyon) Nortel.

Figure 2 : Découpage géographique des 7 UPR

Chenevoy Stéphane - 8 - Sept. 2007 – Fév. 2008

Les domaines d‟action des UPR, au niveau du réseau mobile, sont très variés :

- Création de nouveaux sites (étude de sites théoriques, recherche de sites, négociation de baux, choix des équipements, paramétrages des équipements, installation et mise en service.)

- Maintenance du réseau (détection de la dégradation de la qualité du réseau, réponse à des plainte de clients lorsque la cause du problème est identifiée comme étant une cause radio)

De chaque action dépend un service spécifique. Par exemple, le service de Detection,

Analysis et Operation détecte la dégradation de la qualité de service (système, radio ou trafic), rétablit la qualité de service à l‟aide d‟outils de détection et de prédiction radio, intègre les

nouveaux sites et les sites réaménagés. Le département Déploiement lui est composé de tous les chefs de projet. Ceux-ci sont en charge de la négociation des futurs sites ainsi que la supervision de leur aménagement.

Le département Conception-Programme, dont je faisais partie, fait le lien entre les études théoriques et les données terrains. Ainsi, sont intégrés trois services : Programme et Evolution du

Réseau, et les services d‟Ingénierie Radio et Qualité Plaque (IRQP). J‟ai donc intégré l‟équipe IRQP Zone 1.

2.3.2 Unité de Pilotage Réseau Centre Est (UPRCE)

Mon stage s‟est effectué au sein de l‟UPR Centre Est. Son domaine d‟action s‟étend sur les régions Bourgogne, Auvergne et Rhône-Alpes. C‟est l‟un des territoires de France le plus grand à

couvrir. Cette zone du réseau est très diversifiée : zone urbaine, zone rurale, montagne, vallée, lacs, … Elle possède également une répartition de la population inégale (zone de vie – zone de forte population, zone de plus faible densité de population, zone de très faible densité).

En accord avec les deux autres opérateurs (Bouygues Telecom et SFR), et le gouvernement français, France Telecom doit également couvrir des zones géographiques dites « zones blanches ».

Ces dernières, d‟un point de vue marketing, ne sont pas rentables, la densité de population locale n‟étant pas suffisante pour couvrir l‟investissement des équipements radio. Les accords mis en place ont pour but d‟aménager le territoire français de façon égale. Les opérateurs sont ains i

financés en partie par l‟Etat.

2.3.3 Département Conception et Programme, C&P

Le département dans lequel j‟ai évolué durant ces 5 mois et demi de stage est le service

conception et programme. Celui-ci est regroupé en deux services : Programme et Evolution du

Réseau (PER) et Ingénierie Radio et Qualité Plaque (IRQP)

Chenevoy Stéphane - 9 - Sept. 2007 – Fév. 2008

2.3.3.1 Le service Programme et Evolution du Réseau (PER)

Le service PER est en charge du pilotage des opérations de dimensionnement du réseau

mobile. L‟entité a deux principales activités : PER est chargé de l‟étude de rentabilité des futurs sites. Ainsi, lorsqu‟une plainte client ou des

objectifs marketing mènent à la création potentielle de sites, ce service doit en évaluer les bénéfices. De cette façon, si le trafic estimé n‟atteint pas un certain seuil, la création de site n‟est donc pas valable.

L‟autre activité est de dimensionner, d‟ajuster le potentiel des sites afin qu‟ils correspondent au trafic réel.

2.3.3.2 Le service Ingénierie Radio et Qualité Plaque

Le service dans lequel j‟ai travaillé, Ingénierie radio et qualité Plaque (IRQP), rassemble tous les ingénieurs Radio. A la tête d‟une zone géographique (nommée plaque) définie

par les services marketing, l‟ingénieur radio a pour objectif de maintenir une couverture radio de qualité, en GSM, et en UMTS6 selon le site. Il faut ainsi faire attention au dimensionnement des sites : si le trafic est trop important par rapport aux capacités du site, il faut alors ajouter le nombre

de sites nécessaires permettant d‟adapter au flux du trafic en faisant attention au paramétrage des antennes (déclaration de voisinage). Lorsqu‟une plainte est remontée par le service client et

identifiée comme ayant une cause radio, l‟ingénieur doit trouver (dans les 5 jours suivants l‟arrivée de la plainte au service) la raison du problème de couverture. Pour ce faire, il fait souvent appel à plusieurs outils. Il existe des applications permettant de remonter des données terrains telles que les

compteurs ou les actions se déroulant entre un mobile et la BTS, et des applications de prédictions radio permettent d‟avoir une couverture radio théorique en fonction de la géographie, des bâtiments,

ponts etc. La qualité globale du réseau sur une plaque est le critère d‟évaluation de l‟ingénieur. Il

y a ainsi toutes les semaines un tableau de bord contenant les valeurs des indicateurs, afin que le

responsable de la plaque puisse connaître sa position par rapport à son objectif. 6 UMTS : Universal Mobile Telecommunications System. C‟est l'une des technologies de téléphonie mobile de

troisième génération (3G) européenne

Chenevoy Stéphane - 10 - Sept. 2007 – Fév. 2008

3 Présentation du sujet

3.1 Contexte

Fin 2006, l'UPR Centre Est se dote d'un nouvel outil de prédiction radio nommé NetAct

Planner ou « NAP ». Cet outil possède diverses fonctionnalités dont la plus utilisée est la simulation

de couverture radio. En effet, grâce aux données radio (Sites GSM/UMTS), aux données géographiques (Collines, Montagnes etc.) et urbaines (Bâtiments, ponts, tunnels etc.), chaque

ingénieur peut visualiser la couverture de sa plaque. Pour cela NetAct Planner possède en arrière plan une base de données Oracle7 contenant toutes ses informations. Il est important de noter que cette base est très dense et que la moindre manipulation par l'utilisateur comme la navigation entre

chaque site ou la modification d'une série de paramètres, entraine des chargements assez longs. Cette dernière est inaccessible directement. Il n‟est possible de modifier les données de cette base

que par l'application graphique NetAct Planner.

Figure 3 : Exemple de couverture radio par NetAct Planner

7 Oracle est un système de gestion de base de données relationnel fourni par Oracle Corporation .

Chenevoy Stéphane - 11 - Sept. 2007 – Fév. 2008

Il existe 2 bases de données NAP auxquelles les utilisateurs peuvent se connecter :

- NetAct Planner Ref ou NAPRef: Cette base sert de référence concernant les données

terrains. Les mises à jour sont effectuées par le SIRES8 chaque semaine et non

quotidiennement. Ce choix a été fait car à chaque mise à jour de l'environnement, ce sont des milliers d‟informations sur les sites qui sont supprimées puis réinsérées. Ainsi cela

entraine des temps d'insertion et de « commit » extrêmement longs. Cette base sert exclusivement à la visualisation de statistiques pour France Telecom. On peut imaginer que si vous regardez une carte de la couverture radio de votre région dans un journal, cela

provient sûrement de NAPRef. De ce fait les ingénieurs ne doivent pas modifier les informations de cette base. Malgré la mise à jour du SIRES, il reste toutefois des

incohérences sur la technologie GSM qui apparaissent et qui doivent être corrigées par un ingénieur de l'UPR appelé le SAM9 NAP. Un audit de cohérence reprenant les cellules à corriger est effectué toutes les deux semaines afin que chaque SAM de chaque UPR

utilisant NetAct Planner puisse effectuer l'actualisation des données manuellement.

- NetAct Planner Etude ou NAPEtude : Contrairement à NAPRef, les ingénieurs peuvent modifier librement les données contenues dans NAPEtude. Cette base leur sert de test afin qu'ils puissent simuler la couverture après avoir inséré un nouveau site virtuel, changé les

paramètres d'une cellule existante pour optimiser sa couverture ou encore éviter du brouillage. Étant donné que de nombreuses informations changent chaque jour sur le

terrain (Substitution d'une fréquence par une autre, modification de la puissance d‟un émetteur, changement d'antennes etc.) il est crucial que les données à modifier soient fiables et donc actualisées quotidiennement pour assurer une visualisation « en temps

réel » de la couverture terrain. Chaque UPR utilisant NAPEtude possède sa propre base de données avec les sites de sa zone mais aussi les sites voisinant l‟UPR. En effet les

ingénieurs ont besoin des données de sites situées sur le contour de l'UPR lorsqu'ils effectuent des changements sur la couverture 2G. C'est notamment le cas pour les changements de fréquences où ils doivent éviter de créer du brouillage avec d'autres

cellules10 voisines.

Outre la fonctionnalité prédiction radio de NetAct Planner, il est possible d'importer ou

d'exporter les données pour une ou plusieurs cellules au format XML. Les ingénieurs utilisent

d'autres applications qui sont capables de traiter ces fichiers XML. C'est par exemple le cas de l'application Agora qui leur permet de faire des plans de fréquences11.

Lorsque NAPEtude a été mis à disposition des ingénieurs radio fin 2006, aucune mise à jour

quotidienne n'était effectuée. Étant donné que le nombre d'informations à mettre à jour

quotidiennement à la main était trop élevé, il a été décidé de recruter un stagiaire qui débuterait le projet nommé Oricox (“Outil de remontée d'incohérences et de correction massive par XML”). A

ses débuts le projet est destiné uniquement à l'UPR Centre Est. 8 SIRES : Système d‟Informat ion Réseau du groupe France Telecom

9 SAM : Soutient Application Métier. Il est le support d‟un outil utilisé au sein de l‟UPR. Les ingénieurs utilisant

l‟outil en question peuvent se tourner auprès du SAM pour demander conseils ou remonter des bugs. 10

Une cellu le est une zone de couverture émis par une antenne relais. 11

Un p lan de fréquence est un changement de toutes les fréquences des cellules pour une zone géographique donnée.

Chenevoy Stéphane - 12 - Sept. 2007 – Fév. 2008

Cette application permet de récupérer les informations provenant NAPEtude et de deux bases

de références :

BDE (Base de Données Équipements): Définie comme la base de données de référence des sites GSM et UMTS en exploitation. Elle regroupe une quantité importante d‟informations, aussi bien

sur l‟architecture d‟un site que sur ses équipements. Elle contient aussi des informations sur la situation géographique des sites ou encore l'état du site (« en construction », « en service »,

« fermé », etc.). Chaque ingénieur se doit de modifier directement depuis l'interface graphique de BDE les données des sites appartenant à sa plaque. Il est tout à fait possible de récupérer les données de la base BDE. Afin de faciliter l‟accès à ces

données et pour sécuriser les transferts sur le réseau, le SIRES de France Té lécom a mis en place l‟outil de requêtes « graphiques » Business Object.

BDRef : L‟outil web BDRef est une application France Telecom développée pour rassembler les

données de paramétrage des sites GSM / UMTS tel que les fréquences, la puissance, la bande etc. Il existe des dizaines de données de ce type pour chaque cellule.

Les données de BDRef sont directement récupérées de L'OMC. En effet chaque nuit les

données sont rapatriées puis traiter avant insertion, ce qui les rend fiables. Il est possible de

récupérer les données de cette base car l'équipe BDRef effectue des exports “textes” et “csv” de ces tables chaque matin sur un serveur FTP.

3.1.1 Principe d'Oricox

Figure 4 : Principe du rapatriement quotidien des données BDE / BDRef / NAP

Chenevoy Stéphane - 13 - Sept. 2007 – Fév. 2008

Chaque nuit une tâche automatisée (Cf. Figure 4) exécute des requêtes dans la base BDE via

Business Object afin de récupérer des fichiers CSV. Ensuite des informations provenant de BDRef sont téléchargées grâce à des scripts FTP. Enfin, des fichiers XML de NAP, exportés par le SIRES quotidiennement, sont copiés sur le serveur Oricox.

Il est nécessaire de récupérer les fichiers BDRef provenant de plusieurs UPR et non pas seulement de BDRef Nortel. En effet, comme nous l‟avons dit précédemment, les ingénieurs ont

besoin des données de sites situées sur le contour de l'UPR Centre Est lorsqu'ils effectuent des changements sur la couverture GSM.

Par ailleurs, nous pouvons noter qu'un “Hôte Windows” est nécessaire à l'exécution des

requêtes Business Object et la récupération des données NAP situées sur des serveurs Windows. Pour plus de robustesse et de stabilité, il a été décidé que le serveur Oricox serait logé sur un

serveur Linux. Une fois les données importées sur la machine Linux, celles-ci sont chargées dans la base

MySQL puis divers scripts s'exécutent de façon automatique afin de détecter :

- Les incohérences entre NAPEtude et les bases de références BDE/BDRef. - Certaines incohérences qui peuvent subsister sur BDE. Bien que le travail manuel de mise à

jour par les ingénieurs doive être fait régulièrement, il reste toujours des informations qui peuvent se révéler manquantes.

- Des incohérences sur NAPRef pour la technologie GSM, car même si un audit de cohérence

est effectué 2 fois par mois, le SAM NAP a jugé nécessaire de pouvoir contrôler les incohérences quotidiennement

3.1.2 Le site Oricox

Figure 5 : Accueil du site Oricox

Visualisation rapide de cellules

Menu incohérences

GSM (2G)

Menu

incohérences UMTS (3G)

Menu de mise à jour XML

Outils

ajoutés

Chenevoy Stéphane - 14 - Sept. 2007 – Fév. 2008

Le site propose différents menus :

- Visu Rapide : Une fois l'identifiant de la cellule entrée, l'utilisateur peut visualiser

rapidement la liste de ces incohérences grâce à une fenêtre popup.

- Incohérences 2G : Recherche et visualisation des incohérences GSM et sur NAPEtude,

NAPRef et BDE.

- Incohérences 3G: Recherche et visualisation des incohérences UMTS sur NAPEtude et

BDE.

Figure 6 : La recherche d'incohérences sur Oricox

La Figure 6 nous montre la recherche d'incohérence GSM pour l'application BDE. Après

avoir sélectionné les différentes options (Plaque, Type d' incohérence, Tri, Cellule Indoor / Outdoor)

situées sur le menu du haut, il est possible de lancer la recherche afin d'afficher les cellules correspondant aux critères entrés.

Formulaire

de

recherche

Liste

des

Incohérences

Chenevoy Stéphane - 15 - Sept. 2007 – Fév. 2008

Générer XML : Par un simple clique, le SAM NAP peut générer des XML contenant des données à jour à insérer dans l‟outil de prédiction radio. Il peut choisir de mettre à jour certains champs essentiels de NAP tels que les fréquences, l'état d'une cellule, ou bien faire une mise à jour globale

appelée “Push”. Cette mise à jour globale contient les paramètres essentiels évoqués précédemment ainsi que de nombreux autres. Ce push global n'existe qu'en GSM pour cette première version

d'Oricox.

Figure 7 : La création des fichiers XML

Outils : Ce menu propose deux modules :

- La création de candidats : Formulaire de création de sites virtuels au format XML qui est à insérer dans NetAct Planner. L‟outil de Nokia possède une fonctionnalité identique mais elle

s'est avérée bugée. - CRC : Formulaire de création d'un XML contenant les points critiques de communications

considérées réussies et de qualité correcte.

3.2 Problématiques

Beaucoup d'effort avaient été faits pour que l'application réponde aux mieux aux besoins qui avaient été énoncés dans le cahier des charges. Néanmoins il restait quelques bugs mineurs au niveau des scripts automatisés. D'autre part certains scripts de mise à jour XML pouvaient être améliorés afin

de donner des résultats encore plus fiables et de façon plus rapide.

Les fonctionnalités concernant les mises à jour XML pouvaient être améliorées dans le sens où il n'était pas possible de générer et télécharger plusieurs fois le même fichier. Certains fichiers, très longs à générer faisaient planter le navigateur au bout de 30Min. Il était impossible de visualiser

combien de cellules ou sites concernaient la mise à jour pour un fichier donné. En outre, d'autres types de mises à jour XML auraient été souhaitables.

Le formulaire de recherche pouvait être amélioré afin de sélectionner plusieurs type d'incohérences et de sélectionner des zones géographiques autres que celles des plaques.

Après présentation de l‟outil aux autres UPR, certaines ont évoqué le fait qu'il serait intéressant de

l'utiliser. Hors, de nombreuses modifications étaient nécessaires pour que l'application soit la plus flexible possible afin de prendre en compte des données spécifiques à chaque unité de pilotage.

D'autres petits modules pouvaient être rajoutés aidant les ingénieurs lors de certains travaux trop rébarbatifs. C'est notamment le cas lorsqu'ils envoient de nouveaux paramètres cellulaires à

l'Opération And Maintenance Center (OMC) qui se charge d‟effectuer la modification sur le terrain.

Chenevoy Stéphane - 16 - Sept. 2007 – Fév. 2008

En relations directe avec tous ces problèmes nous pouvons maintenant énoncer le sujet tel qu'il m'a été donné ...

“Poursuivre le travail de développement des outils informatiques permettant de garantir la

fiabilité des données de l’application NetAct Planner.

Trouver des solutions informatiques à tout problème d’incohérence ou de mise à jour

massive que nous pourrions rencontrer pendant la période du stage.

Développer des outils pour faciliter le transfert des données de NAP vers l’Operation And

Maintenance Center.

Il faudra impérativement garantir, par une programmation structurée et commentée, une

documentation détaillée et précise, la pérennité de ces outils.

La maintenance de ces outils devra pouvoir être assurée par des non informaticiens.”

3.3 Cahier des charges

Débogage :

- Déboguer certains scripts de génération des XML donnant des résultats non fiables ou bien qui ne peuvent pas être insérés dans NetAct Planner.

Amélioration de l'interface :

- Avoir la possibilité de sélectionner plusieurs incohérences lors d'une recherche - Permettre la sélection de la zone géographique Z1, Z2 ou “Hors UPR”. - Faire apparaitre le nombre de cellules mises à jour dans le nom du fichier XML.

- Générer automatiquement les fichiers de mise à jour durant la nuit.

Ajout de nouvelles mises à jour : - Mise à jour du trafic devant assurer la compatibilité de NetAct avec la nouvelle application

Agora NG

- Mise à jour des BSC pour une cellule ou un site. - Mise à jour de l'état Type pour une cellule.

- Mise à jour de la puissance pour une cellule. Déploiement de l'application :

- Installer l‟outil pour l'UPR Méditerranée, Ile De France et Sud Ouest.

Ajout de nouveaux modules : - Création d'un fichier Excel à partir de données NAP. La mise en forme des données de ce

fichier devra respecter un modèle existant.

- Création de Sites/Cellules dans NAP à partir de données d'un fichier Excel. - Vérifier la cohérence des données fréquences après simulation d'un plan de fréquences par

l‟outil Agora NG.

Chenevoy Stéphane - 17 - Sept. 2007 – Fév. 2008

4 Mise en œuvre

4.1 Outils

Les outils de développement utilisés lors de mon stage sont restés identiques à ceux utilisés

par le premier stagiaire.

En effet, le choix du langage PHP jumelé avec un serveur web Apache pour une application intranet multiutilisateur est un des plus courants de nos jours. Ce langage en perpétuel évolution

offre de bonnes performances même s‟ il reste un langage interprété. D‟autre part ses multitudes de fonctions sont parfaitement adaptées aux traitements de données d‟une telle application. Couplé au langage PHP, une base de données MySQL permet de manipuler rapidement les informations

nécessaires à l‟application. L‟avantage de ces deux outils de développement est qu‟ils sont libres et donc ne nécessitent

en aucun cas l‟acquisition d‟une License même dans le cadre de l‟utilisation par une entreprise.

Afin de garantir le bon fonctionnement de l‟application Oricox même en phase de

développement, il a été décidé d‟installer deux serveurs. Un premier serveur de développement sur lequel les programmeurs peuvent tester les

évolutions qu‟ils apportent. Celui ci a été installé sur un ordinateur de L‟UPR Centre Est. Parallèlement, un serveur de production fut mis en place afin que les utilisateurs puissent se

connecter à une version stable d‟Oricox. Ce dernier n‟a pas été installé directement à l‟UPR Centre

Est. Une demande auprès d‟un service d‟Orange permit d‟obtenir l‟installation de l‟application sur un “réel” serveur dont nous avions le contrôle.

Le système d‟exploitation utilisé pour le serveur de production est une distribution Linux

interne à France Telecom nommé Platon. Ce choix n‟a pas été un hasard, un tel système

d‟exploitation reste plus stable que le populaire Windows de Microsoft. La version utilisée pendant mon stage était estampillée G7R0. Celle ci possédait la version 5 de PHP et la version 4.3 de

MySQL. Un avantage notable de PHP 5 est la possibilité de lancer des scripts d irectement en ligne de commande, ce qui est un pré requis pour l‟automatisation de certaines tâches qui sont exécutées durant la nuit.

Le système d‟exploitation Ubuntu, qui est également une distribution Linux, fut utilisé pour le serveur de développement. Excepté le fait que la version de MySQL soit la 4, les différents outils

installés étaient identiques au serveur de production. Enfin, comme nous l‟avons dit dans la partie précédente une machine Windows restait

nécessaire pour l‟exécution des requêtes Business Object et le transfert des données NAP. Cette dernière restant problématique car il était nécessaire qu‟un compte utilisateur soit en permanence

connecté pour que les tâches automatisée s‟exécutent.

Chenevoy Stéphane - 18 - Sept. 2007 – Fév. 2008

4.2 Développement Étant donné que le projet Oricox avait déjà été commencé six mois auparavant par un autre

stagiaire, mon stage ne suit pas le déroulement classique de la création d‟une application, c‟est à dire “Analyse, Développement, Tests et Validation”. Néanmoins tous ces aspects ont été abordés

de façon non ordonnée. L‟ajout de fonctionnalité fait intervenir une part d‟analyse qui n‟existait pas au début du projet ou qui doit être repensée. Les phases suivantes étant bien sûr indispensables.

4.2.1 Préliminaire

Avant de commencer tout développement il a été jugé nécessaire que je comprenne de façon

globale le travail des ingénieurs radio et leurs domaines. Ce fut un préliminaire important afin de

pouvoir comprendre au mieux les applications existantes et ce qui a été défini dans le cahier des charges. Pour cela, la documentation sur les technologies utilisées et les explications d‟ingénieurs radio ont été très formatrices.

4.2.2 Fiabilisation et optimisation

Comme nous l‟avons évoqué précédemment, le travail fait par le premier stagiaire était dense,

mais effectué dans un laps de temps assez court. Les tests et la validation de l‟application avaient donc été moins bien effectués que le reste. De ce fait certains résultats se trouvaient erronés.

Dans un premier temps, il fut nécessaire de faire plusieurs modifications dans les scripts de

rapatriement des données.

Ceux ci s‟interrompaient pour différentes raisons : - Les scripts Shell d‟exécution des fichiers PHP ne contenaient pas toutes les variables

nécessaires à leur bon fonctionnement. - Il était nécessaire de rajouter une option importante pour l‟exécution d‟un script SQL qui

permet de ne pas arrêter l‟exécution d‟un script même en cas d‟erreur. Un exemple

flagrant d‟erreur était la suppression d‟index inexistant avant l‟insertion des données. On peut imaginer que l‟insertion des données avait échoué lors de la dernière exécution et que

l‟index n‟avait pu être recréé ensuite. - Sans prévenir, le service Orange supprima le mode de transfert FTP au profit du Secure-

FTP par sur le serveur de production. Ceci entraîna la réécriture des scripts de transfert.

Certaines modifications ont été faites au niveau des fichiers PHP. La principale source

d‟erreur venait de l‟utilisation de données NAP comme références plutôt que celle de BDE ou BDRef.

Enfin une partie d‟optimisation a été faite sur certaines requêtes permettant la génération des fichiers XML. L‟utilisation de clauses trop gourmandes en temps, telles que „LIKE‟ ou „NOT IN‟

ont été pour la plupart supprimées au profit d‟autres méthodes plus rapides.

Chenevoy Stéphane - 19 - Sept. 2007 – Fév. 2008

4.2.3 Ajout de mises à jour

Comme indiqué dans le cahier des charges, les mises à jour GSM pour les BSC, le trafic, la

puissance et l‟état Type des cellules ont été ajoutés. Toutefois, une autre méthode de création des fichiers XML a été utilisée afin de régénérer plusieurs fois ces mêmes fichiers dans la journée.

La méthode utilisée pour les autres scripts était :

Comparaison des états entre BDE (ou BDRef) et NetAct

Si l’information est erronée dans NetAct, on la corrige et on marque la cellule

Une fois la comparaison terminée, on génère ligne par ligne le XML pour les cellules marquées.

On s‟aperçoit donc que la table contenant les données NetAct Planner contient les bonnes

informations, donc le second lancement d‟un même script génère un fichier XML vide.

La nouvelle méthode utilisée est la suivante :

Comparaison des états entre BDE (ou BDRef) et NetAct

Si la ou les informations sont erronées dans NetAct, on enregistre les nouvelles en mémoire

(variables PHP) et on insère les données directement dans le fichier XML

Nous verrons par la suite qu‟une amélioration significative d‟Oricox permettra de palier au

problème de non régénération des fichiers des premiers scripts.

4.2.4 Déployabilité et améliorations générales d’Oricox

La déployabilité de l‟application Oricox nécessitait de nombreuses modifications. Pour palier

à certaines grosses lacunes d‟Oricox et faciliter ces nombreuses modifications, j‟ai proposé à mon

tuteur plusieurs évolutions. Une première phase de modification a débuté en octobre et a permis le déploiement rapide de l‟application pour les UPR souhaitant l‟utiliser. La seconde phase est une

proposition que j‟ai faite à mon tuteur en entreprise pour la fin de mon stage.

4.2.4.1 Phase 1

4.2.4.1.1 Coté programmeur

En me penchant sur les sources de la version du site développée par le premier stagiaire, j‟ai

pu remarquer que le code était énormément répétitif, notamment au niveau de l‟interface graphique. La division en fenêtre (“Frame” en HTML) du site ne facilitait guère la compréhension des fichiers

et la réutilisabilité du code. L‟unique avantage de ce type de division est qu‟elle permettait de créer simplement des fenêtres informant l‟utilisateur du chargement d‟un fichier.

Pour palier au problème de répétitivité du code et aussi réduire le nombre de fichiers, j‟ai

décidé d‟utiliser l‟inclusion de fichiers en PHP et la division en cadre (“Div” en HTML) des différentes parties du site. Cette méthode est maintenant utilisée par la majorité des sites que l‟on

rencontre sur le net.

Chenevoy Stéphane - 20 - Sept. 2007 – Fév. 2008

Un allègement du code source a donc été effectué. Un fichier CSS a été créé afin de séparer la

structure et le style du site. L‟outil Ajax permit d‟informer l‟utilisateur du chargement d‟un fichier. L‟avantage principal

de cette fonctionnalité du langage JavaScript est le rafraichissement d‟une partie d‟une page Web.

Cette “partie de page” peut être rafraichie lors du chargement d‟un fichier, à ce moment l‟utilisateur peut en être informé. Une fois le fichier chargé cette “partie de page” peut être rafraichie avec de

nouvelles données.

Figure 8 : une page web dynamique grâce à Ajax

Il existe cependant des inconvénients :

- Le langage JavaScript doit être activé sur le navigateur de l‟utilisateur. - Le référencement des pages web dans les moteurs de recherches est impossible car les

robots d'indexation ne sont pas en mesure d'indexer les contenus engendrés dynamiquement.

- Il n‟est pas simple de déboguer du code JavaScript.

Hors, la distribution Windows interne à France Telecom nommée “e-buro” possède une

version du navigateur Internet Explorer avec le langage JavaScript Activée. D‟autre part, le site est une application exclusivement intranet et n‟a pas pour but d‟être indexé. Ainsi seul le dernier problème subsistait mais ce n‟était qu‟un inconvénient pour le programmeur et l‟utilisation du

navigateur Mozilla Firefox fut d‟une aide significative pour le débogage du code JavaScript.

Afin d‟améliorer la clarté de l‟application pour le programmeur, de nombreux fichiers ont été renommés :

- xml_<nomDeLaMiseAJour>.php pour les scripts générant un fichier XML.

- frm_< nomDuFormulaire>.php pour les formulaires. - menu_<nomDuMenu>.php pour les 2 menus de mises à jour.

- ajax_<nomFichier>.php pour les scripts exécutés avec Ajax. La structure des dossiers a elle aussi été repensée. Il y a maintenant une séparation entre les

fichiers PHP exécutés la nuit et ceux du site. Des dossiers contenant uniquement les données générées ont été créés.

La majorité des constantes intégrées au code sources ont été déplacées dans une table SQL de

configuration. L‟utilité de cette méthode est de pouvoir les modifier directement depuis l‟interface

utilisateur.

Chenevoy Stéphane - 21 - Sept. 2007 – Fév. 2008

4.2.4.1.2 Coté utilisateur

L‟interface graphique globale a été repensée (Cf. Figure 9). Les technologies 2G, 3G ainsi que les petits modules qui n‟ont pas de liens avec la recherche d‟incohérences apparaissent dans

trois cadres différents.

Figure 9 : Nouvelle accueil du site Oricox

Un menu horizontal permet d‟accéder à différentes informations concernant Oricox : - Fichiers références : les fichiers NAP, BDE, BDRef avec leurs dates et tailles.

- Fichier crées : Les fichiers XML crées avec leurs dates et taille (Cf. Figure 10). Cela

résout donc le problème de recréation d‟un même fichier dans la même journée. Ceux ci peuvent être supprimés par l‟utilisateur.

- Administration : Cette section sera gérée par le SAM NAP de chaque UPR utilisant Oricox. Elle permet de paramétrer différentes valeurs comme l‟identifiant et le mot de

passe administrateur ainsi que certaines valeurs servant à la détection d‟incohérences. Par exemple, la puissance d‟un émetteur qui est inférieur à 37dBm et supérieur à 44dBm sera détectée en incohérence pour les cellules de l‟UPR Centre Est.

Il arrive quelquefois que les exports de fichiers NAP réalisés auto matiquement par le SIRES

ne soient pas faits correctement. Pour avertir l‟utilisateur de ce problème, la page d‟accueil affiche directement cette date avec un avertissement si nécessaire.

Le nombre de cellules contenu dans un fichier XML est maintenant inséré dans le nom du fichier.

Chenevoy Stéphane - 22 - Sept. 2007 – Fév. 2008

Figure 10 : Affichage des fichiers XML crées

Figure 11 : Nouveau formulaire de recherche d’incohérences

Chenevoy Stéphane - 23 - Sept. 2007 – Fév. 2008

Le formulaire contenant les options de l‟affichage d‟incohérences (Cf. Figure 11) a été refait

afin de pouvoir sélectionner plusieurs incohérences. Il est maintenant possible de sélectionner des régions comme zone géographique. Une fois les incohérences affichées, il est possible de les trier par noms, incohérences, identifiants NAP, CI12 ou Plaques.

Le nombre d‟incohérence est affiché à coté de chacune d‟entre elle.

4.2.4.2 Phase 2

Début janvier l‟application BDRef jusqu‟alors divisée en plusieurs bases a évolué pour ne

devenir qu‟une seule et même base contenant les informations de paramétrage des sites de toute la

France. Ainsi nous avons pu obtenir les exports de données pour toute la France. Depuis l‟ajout de certaines fonctionnalités (Puissance notamment) et en vue de la création d‟un futur Push en 3G

plusieurs nouvelles tables BDRef étaient importées et pesaient très lourd. Le temps d‟insertion de toutes ces données dans la base pouvait durer jusqu‟à une vingtaine de minutes. L‟application Oricox avait jusqu‟à maintenant une base par UPR. Ainsi il était nécessaire d‟injecter pour chaque

base une quantité importante d‟informations. Nous pouvons imaginer dans le pire des cas que l‟application soit utilisée par les sept UPR et donc que le temps d‟insertion des données soit

multiplié par sept. Pour plus de rapidité lors des mises à jour, la suppression des données inutiles de chaque table BDRef aurait été nécessaire pour chaque base, ce qui aurait allongé le temps de mise à disposition de l‟outil sachant que les informations BDRef ne sont disponibles qu‟à partir de 7h /

7h30 du matin. Il a donc été décidé d‟unifier toutes les bases Oricox en une seule contenant les informations

pour toute la France. Les avantages à cela :

- Un gain de place au niveau des informations à stocker. - Un gain de temps au niveau de l‟insertion des données.

- La maintenance de l‟application est facilitée pour diverses raisons. Dans la « Phase 1» les requêtes Business Object devaient être copiées puis modifiées pour chaque base Oricox. Ainsi onze requêtes multipliées par le nombre de bases étaient nécessaires. Grâce à

l‟unification, onze requêtes contenant les informations pour toute la France sont nécessaires. Cela diminue le nombre de scripts nécessaire à l‟application BDE mais aussi

à l‟application BDRef. - Cela facilite l‟ajout de nouvelles UPR.

En contrepartie, il était nécessaire de stocker les informations de NAPEtude et NAPRef de

chaque UPR dans la même base. Comme nous l‟avons évoqué dans la présentation du sujet, chaque UPR possède sa base NAPEtude. Ainsi il est tout à fait possible que certains sites soient présents dans 2 bases différentes. Il a donc été nécessaire de revoir en partie la modélisation de la base

Oricox afin de prendre en compte ces cas de doublons et d‟identifier les sites qui appartenaient à chaque UPR. La majorité des requêtes du site ont donc été revues. Les scripts automatisés de

transfert des données et d‟import dans la base ont été revus et clarifiés au maximum.

12

CI : Cell Identity, identifiant de cellu le composé de 5 chiffres. Il est utilisé dans la majorité des bases de données.

Chenevoy Stéphane - 24 - Sept. 2007 – Fév. 2008

Figure 12 : Audit de cohérence NAPRef

Un audit de cohérence à été ajouté au site (Cf. Figure 12). Celui ci s‟effectue chaque matin à

la fin de la mise à jour de l‟outil et a pour objectif de décompter et répertorier les cellules concernées par certaines incohérences. Cet audit ne prend en compte que les cellules dont l‟état est « En Service » ou « A ouvrir » dans NAPEtude et NAPRef.

Outre le travail effectué sur l‟application, une documentation aidant la prise en main de

l‟application par un programmeur a été créée. Cette demande à été faite par l‟UPR Ile de France, car depuis fin janvier un étudiant travaille sur de nouvelles fonctionnalités à ajouter au projet. Ce rapport explique brièvement la structure du site ainsi que les fonctionnalités de chaque script.

Chenevoy Stéphane - 25 - Sept. 2007 – Fév. 2008

4.2.5 Modules ajoutés

Plusieurs petits modules ont été ajoutés à Oricox. Ceux ci n‟ont pas de liens avec la recherche

d‟incohérences mais ils utilisent les informations de références de la base Oricox ainsi que certaines

fonctionnalités utiles du langage PHP.

4.2.5.1 Paramétrage

Afin d‟effectuer la modification de certains paramètre cellulaires, les ingénieurs envoient au

centre de maintenance un fichier Excel. Ce fichier était crée jusqu‟à maintenant par une macro Excel prenant en entrée un export de 3 fichiers XML de NAP. Le fichier Excel doit contenir aussi

des informations qui ne sont pas dans ces exports. Certaines informations proviennent de BDE ce qui oblige l‟ingénieur à lancer cette application et faire des recherches. Ainsi plusieurs manipulations sont nécessaires pour un ingénieur, ce qui engendre une perte de temps.

Étant donné qu‟Oricox récupère des informations provenant de BDE un nouveau module a été ajouté pour éviter ce travail manuel.

Un formulaire propose à l‟utilisateur d‟insérer les exports des 3 fichiers NAP, puis d‟insérer

quelques informations sur la ou les cellules. Ensuite il pourra lancer la génération du fichier Excel.

Figure 13 : Le forumulaire de paramètrage

PHP n‟inclut pas à l‟origine d‟outils pour créer un fichier Excel. J‟ai utilisé le package PEAR contenant de nombreuses librairies bien documentées. Une librairie nommée phpexcelreader

permettait la création de ce type de fichier.

Chenevoy Stéphane - 26 - Sept. 2007 – Fév. 2008

4.2.5.2 Création de sites depuis un fichier Excel

Régulièrement une liste des sites appartenant à la concurrence est reçue à l‟UPR Centre Est

sous la forme de fichier Excel. Il a donc été jugé intéressant de voir ces sites directement dans l‟outil de prédiction radio NAP.

Ainsi à l‟inverse du module précédent, celui- ci permet la création de fichiers XML NAP depuis un fichier Excel. Un formulaire demande à l‟utilisateur de rentrer le fichier Excel, puis la génération des fichiers XML de NAP est automatique.

Tout comme le module précédent une librairie du package PEAR a été utilisée. Elle se

nomme php_writeexcel.

4.2.5.3 Vérification de plan de fréquences

Afin de vérifier les résultats de l‟outil Agora dans sa fonctionnalité de plan de fréquence un

module Oricox a été crée. Il prend en entrée un fichier texte généré par Agora contenant la liste des cellules du plan de fréquences ainsi que les nouvelles informations sur les fréquences.

Etant donné qu‟Oricox contient les informations de référence au niveau du voisinage et des

fréquences il est possible de vérifier pour chaque cellule (aussi appelée serveuse): - Si les fréquences interfèrent pour chaque voisine.

- S‟il n‟y a aucun couple BSIC/BCCH13 identique pour chaque voisine - S‟il n‟y a aucun couple BSIC/BCCH identique pour chaque voisine de voisine.

La méthode utilisée est la suivante : - Création d‟un univers virtuel contenant les nouvelles données générées par Agora ainsi

que les données cellules en dehors du plan de fréquence. Toutes ces données sont stockées dans une table de la base Oricox.

- Pour chaque cellule on effectue les vérifications citées précédemment. Les relations de

voisinages sont connues grâce aux informations BDRef. - Chaque serveuse ne vérifiant pas une des règles est affichée ainsi que les informations

relatives à ces problèmes. Il apparaitra l‟identifiant de la voisine (ou voisine de voisine) et le type de problème.

4.2.5.4 Fichier de retune

Très similaire au module de Paramétrage, le formulaire « Fichier de retune » permet de récupérer les informations Fréquences des cellules contenues dans un export NAP. Ces données sont extraites puis insérées dans un fichier Excel.

Cette manipulation est effectuée lorsqu‟un ingénieur souhaite changer certaines fréquences d‟une ou plusieurs cellules. Ce fichier sera ensuite envoyé à l‟Operation And Maintenance Center.

13

Le couple BCCH/BSIC permet l‟identification d‟une cellule.

Chenevoy Stéphane - 27 - Sept. 2007 – Fév. 2008

4.3 Planning

Mois septembre octobre novembre Décembre janvier février

Semaines 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 1 2 3 4 5 6

Familiarisation avec les technologie GSM/UMTS

Prise en main rapide de l'outils NAP

Familiarisation avec la premiere version d'Oricox

Debogage et fiabilisation des données

Ajout de nouvelles mises à jour

Modification de l'outil pour facilité le déploiement

Ajout de nouveaux modules

Unification des bases Oricox

Documentation / formation du nouveau stagiaire

Planning prévisionnel

Planning réel

Comme nous pouvons le constater, le planning réel respecte assez bien le planning prévisionnel. Ce dernier avait été prévu assez large ce qui a permis d‟effectuer notamment

l‟unification des différentes bases en fin de stage.

4.4 Problèmes rencontrés

Il n‟a pas été aisé de reprendre le projet du stagiaire précédent. Le travail effectué était dense

et la structure ainsi que la lisibilité du code avaient été quelque peu délaissés au profit du bon fonctionnement de l‟application à l‟œil de l‟utilisateur. Dans ces conditions le débogage de l‟application a été d‟autant plus dur.

Le temps de traitements des scripts était un problème crucial auquel je n‟avais encore jamais

eu à me confronter. En effet, il m‟est arrivé de manipuler des tables pesant plusieurs centaines de mégaoctets m‟obligeant à faire attention à la moindre ligne de code et à la structure des requêtes, ce qui n‟avait pas été le cas durant les projets scolaires effectués auparavant.

Une partie des bogues et soucis de mises qui ont été constatés provenait le plus souvent d‟un

problème de données plutôt que de script. Il y avait diverses raisons à cela : - Les évolutions du système d‟informations : Les applications s‟articulant autour d‟Oricox

évoluent en fonction du réseau et des nouvelles technologies qui apparaissent. Toute

modification sur ces bases peut entrainer des résultats incohérents sur Oricox. - L‟unicité des données : Il n‟a pas été rare de constater, par exemple, une même cellule en

doublon avec des informations différentes dans une même base de données. - Les problèmes informatiques : Il est arrivé plusieurs fois que le serveur ait quelques

heures de décalage. D‟autre part l‟hôte Windows nécessitait que le compte d‟un ingénieur

soit activé. Etant donné qu‟il arrivait que le PC soit redémarré la nuit par le service réseau, la mise à jour n‟était pas correctement faite.

- Les erreurs de manipulation par l‟utilisateur. Cela concerne notamment les petits modules. Je me suis donc rapidement habitué à vérifier en premier les informations traitées plutôt que

les traitements.

Chenevoy Stéphane - 28 - Sept. 2007 – Fév. 2008

D‟un point de vue organisationnel, en plus du cahier des charges, il a fallu s‟adapter aux

nombreuses demandes d‟évolutions et report de bugs des utilisateurs de l‟application. Certaines demandes étaient légitimes, d‟autres infaisables car une application Web a des limites. Le service dans lequel j‟étais n‟étant pas spécialisé en informatique, il fut nécessaire d‟expliquer de façon

simple ces limites.

Enfin, le dernier point du cahier des charges a été le plus flou pour moi. Le fait de concevoir

une application qui sera déployée au niveau nationale se doit d‟être la plus robuste et claire possible au niveau de l‟interface mais aussi et surtout au niveau du code source. Il m‟a donc été difficile de comprendre comment penser en « non informaticien ».

5 Bilan

5.1 Bilan pour l’entreprise

De nombreuses évolutions sont apparues avec cette nouvelle version d‟Oricox. Des évolutions

pour faciliter la vie de l‟utilisateur car c‟est le but premier de l‟application, mais aussi des

évolutions pour faciliter le travail du programmeur qui aura à maintenir et faire évoluer l‟application d‟envergure nationale.

Coté utilisateur, les quelques grosses lacunes de l‟interface ont été corrigées telles que les

problèmes de téléchargement. Plusieurs améliorations de l‟interface avec, entre autre, de nouvelles

sections pour les fichiers permettent de visualiser rapidement les soucis d‟import de données et les mises à jour à faire. L‟affinage de la recherche d‟incohérence permet un travail plus précis des

ingénieurs. Les quelques mises à jour et modules ajoutés permettent un gain en temps et la fiabilité des données recueillies. L‟unification des bases permet d‟avoir des données disponibles le plus tôt possible dans la journée.

Coté programmeur, de gros changements permettent maintenant de mieux comprendre la

structure et le fonctionnement de l‟application. L‟application à été repensée pour prendre en compte son déploiement au niveau national, que ce soit au niveau de l‟application Web, des scripts automatisés ou la base de données. Il est maintenant beaucoup plus simple de prendre en compte

une nouvelle UPR.

Il est difficile de chiffrer économiquement l‟apport à l‟entreprise d‟un tel stage, néanmoins il est indéniable que le temps gagné pour la mise en cohérence des données radio est l‟atout majeur d‟Oricox. Auparavant, seuls quelques plans de fréquences pouvaient être planifiés par an sur des

surfaces relativement restreintes, ceci en raison du temps de mise œuvre et de correction des données provenant de NAPEtude. Aujourd‟hui le temps de préparation d‟un plan de fréquence a été

divisé par cinq ce qui incite les ingénieurs à en réaliser plus régulièrement et sur de plus grosses surfaces. En outre, le travail quotidien des ingénieurs sur la création, la maintenance ou encore l‟optimisation des sites est amélioré grâce à une vision plus fidèle du terrain, de leur outil de

prédiction radio. De ce fait nous pouvons dire qu‟indirectement, un tel outil participe à la bonne qualité du

réseau mobile de France Telecom.

Chenevoy Stéphane - 29 - Sept. 2007 – Fév. 2008

5.2 Bilan personnel

5.2.1 Techniques

Au début de mon stage mes connaissances du monde de la radio étaient insignifiantes. J‟ai donc eu à me familiariser avec ce domaine particulièrement riche, et à en comprendre le b.a.-ba. Le

fait de travailler chez France Telecom m‟a permis de m‟imprégner des termes techniques les plus utilisés, mais également du jargon du métier. De plus, j‟ai pu avoir un aperçu des mét iers liés aux réseaux mobiles, et notamment à celui d‟ingénieur radio.

Ce stage m‟a également permis d‟améliorer mes connaissances dans le domaine des bases de

données, et de la conception d‟un site web. En effet, bien qu‟ayant reçu une formation sur les bases de données en début de cursus scolaire, je me suis vite rendu compte qu‟il y avait encore beaucoup plus à apprendre notamment au niveau de l‟optimisation.

Concernant la création d‟un site Web, j‟ai pu améliorer la conception de l‟IHM. J‟ai pu me rendre compte de l‟importance de cette dernière, puisqu‟elle est le reflet de la facilité de navigation.

Au cours de ce projet, j‟ai eu à approfondir mes connaissances du langage PHP. Je me suis rapidement rendu compte qu‟il était important de respecter certa ines règles de bases de la programmation (souplesse du code, compréhension etc.), ce qui est d‟autant plus vrai pour les

projets de grande taille. Enfin, le fait de travailler à la fois avec un environnement Windows et Linux a été très

intéressant. J‟ai pu comparer les atouts et inconvénients de chaque système d‟exploitation par rapport au rôle qu‟ils avaient dans ce projet.

5.2.2 Humain

Durant le stage, j‟ai eu l‟occasion de travailler avec différentes personnes : les ingénieurs

radio de mon service, mais également ceux l‟UPR Ile de France et Méditerranée. Avec du recul, je

comprends mieux l‟importance de la communication en entreprise.

Avec près de 5 mois et demi passés au sein d‟une équipe, je comprends maintenant l‟importance des relations entre collègues et de l‟ambiance de travail. En effet, tout au long de mon stage, j‟étais rattachée à l‟équipe IRQP Z1. Cependant, les utilisateurs du projet étaient aussi ceux

de l‟IRQP Z2, j‟ai ainsi pu m‟entendre avec les deux équipes. Mes relations de travail n‟étaient donc pas exclusives, j‟ai ainsi pu apprendre à m‟adapter au caractère de chacun.

Chenevoy Stéphane - 30 - Sept. 2007 – Fév. 2008

5.3 Perspectives

Début Février, Patrick, mon tuteur en entreprise, a décidé de reprendre un stagiaire pour

poursuivre le développement du projet. Son rôle sera principalement d‟adapter l‟application à la

nouvelle version de NetAct Planner qui arrivera très prochainement.

L‟UPR Ile de France a lui aussi décidé d‟employer un étudiant en alternance qui travaillera sur de nouvelles mises à jour à intégrer dans NAP par rapport à d‟autres fonctionnalités qui ne sont pas utilisées sur l‟application BDRef à l‟UPR Centre Est.

Malgré un gros travail sur le déploiement de l‟application, il est encore possible de faire de

nombreuses améliorations sur l‟optimisation et les fonctionnalités de l‟application. Un problème qui surviendra très prochainement sera la modification des identifiants cellules qui seront mise s en place sur toutes les bases de données en remplacement du CI.

Le projet sera bientôt installé sur de nouveaux serveurs dans le cadre du projet FAST

(Fabriquer des Applications Sur le Terrain), ainsi nous pouvons espérer qu‟une partie des problèmes informatiques observés jusqu‟à maintenant disparaitront.

Chenevoy Stéphane - 31 - Sept. 2007 – Fév. 2008

6 Conclusion

Après vingt quatre semaines passées à France Telecom, j‟ai pu découvrir le monde de l‟entreprise. Le fait de travailler dans un service d‟ingénierie m‟a permis d‟entrevoir le travail d‟ingénieur et les responsabilités qui sont les leurs.

Le développement a été pour moi l‟occasion d‟approfondir un langage de programmation très

utilisé de nos jours, le PHP. Cela m‟a également permis d‟améliorer mes scripts, de les rendre plus clairs, plus exploitables et maintenables par des personnes extérieures au projet. J‟ai également, à plusieurs reprises, dû considérer l‟aspect temps de calculs, variable dont je ne tenais pas forcément

compte dans le cadre d‟un projet scolaire.

Le fait d‟avoir travaillé sur un projet concret et d‟avoir pu communiquer avec les acteurs et utilisateurs m‟a permis de mieux comprendre les enjeux des applications informatiques. Il a été aussi très gratifiant de voir que le projet prenait de l‟envergure. Cela m‟a encouragé à développer en

ayant le sens du travail bien fait.

Avoir effectué ce stage de mi-parcours au sein de France Telecom a été décisif et a confirmé mon choix d‟orientation à l‟UTBM puisque j‟hésitais entre les différentes filières proposées par l‟école. Finalement ce sera l‟« Ingénierie des Logiciel et de la Connaissance » que je choisirai à

mon retour de stage.

Travailler dans un domaine qui n‟était pas uniquement orienté informatique fut très enrichissant. Ce sera un atout indéniable pour mon avenir professionnel.

Enfin, le cadre très agréable et chaleureux dans lequel s‟est déroulé mon stage a grandement

contribué à la satisfaction personnelle d‟une telle expérience.

Chenevoy Stéphane - 32 - Sept. 2007 – Fév. 2008

7 Bibliographie

Radio « Principes fondamentaux du GSM », B. Lagrange, édition Eyrolles http://www.girodon.com/telech/telcos/telecom1.htm http://www.commentcamarche.net/telephonie-mobile/gsm.php3

Informatique

www.phpfrance.fr : définitions des fonctions en PHP http://www.manuelphp.com/ : aide sur PHP

www.ubuntu.fr : configuration du serveur Linux

www.commentcamarche.net : pour les problèmes de débogage

www.mysql.com : fonctions de MySQL

UNIX Guide de l‟utilisateur, Dominique BOUILLET, Edition Marketing, 1990, Paris.

Divers www.wikipedia.fr : Ressources sur l‟entreprise France Telecom http://www.orange.com/fr_FR/groupe/presence/ : Ressources sur l‟entreprise France Telecom http://www.ogaca.org/espaceabonne/fillon.pdf : Bilan financier France Telecom

Chenevoy Stéphane - 33 - Sept. 2007 – Fév. 2008

Table des illustrations

Figure 1 : Implantation du groupe France Telecom dans le monde .................................................... 5 Figure 2 : Découpage géographique des 7 UPR .................................................................................. 7

Figure 3 : Exemple de couverture radio par NetAct Planner ............................................................. 10 Figure 4 : Principe du rapatriement quotidien des données BDE / BDRef / NAP ............................ 12

Figure 5 : Accueil du site Oricox ....................................................................................................... 13 Figure 6 : La recherche d'incohérences sur Oricox............................................................................ 14 Figure 7 : La création des fichiers XML............................................................................................ 15

Figure 8 : Une page web dynamique grâce à Ajax ............................................................................ 20 Figure 9 : Nouvelle accueil du site Oricox ........................................................................................ 21

Figure 10 : Affichage des fichiers XML crées................................................................................... 22 Figure 11 : Nouveau formulaire de recherche d‟incohérences .......................................................... 22 Figure 12 : Audit de cohérence NAPRef ........................................................................................... 24

Figure 13 : Le forumulaire de paramètrage ....................................................................................... 25

Chenevoy Stéphane - 34 - Sept. 2007 – Fév. 2008

Table des matières

Remerciements ...................................................................................................... 2

Sommaire .............................................................................................................. 3

1 Introduction..................................................................................................... 4

2 Présentation de l‟entreprise .............................................................................. 5

2.1 Présentation générale du Groupe France Telecom (FT) ....................................................... 5

2.2 Un peu d‟histoire ................................................................................................................... 6 2.3 Unité de Pilotage Réseau Centre Est (UPRCE) .................................................................... 7

2.3.1 Qu‟est-ce qu‟une Unité de Pilotage Réseau ? ................................................................ 7 2.3.2 Unité de Pilotage Réseau Centre Est (UPRCE) ............................................................. 8 2.3.3 Département Conception et Programme, C&P .............................................................. 8

2.3.3.1 Le service Programme et Evolution du Réseau (PER) ........................................... 9 2.3.3.2 Le service Ingénierie Radio et Qualité Plaque ....................................................... 9

3 Présentation du sujet ...................................................................................... 10

3.1 Contexte .............................................................................................................................. 10

3.1.1 Principe d'Oricox ......................................................................................................... 12 3.1.2 Le site Oricox............................................................................................................... 13

3.2 Problématiques .................................................................................................................... 15

3.3 Cahier des charges............................................................................................................... 16

4 Mise en œuvre ............................................................................................... 17

4.1 Outils ................................................................................................................................... 17 4.2 Développement.................................................................................................................... 18

4.2.1 Préliminaire .................................................................................................................. 18

4.2.2 Fiabilisation et optimisation......................................................................................... 18 4.2.3 Ajout de mises à jour ................................................................................................... 19

4.2.4 Déployabilité et améliorations générales d‟Oricox..................................................... 19 4.2.4.1 Phase 1 .................................................................................................................. 19 4.2.4.2 Phase 2 .................................................................................................................. 23

4.2.5 Modules ajoutés ........................................................................................................... 25 4.2.5.1 Paramétrage .......................................................................................................... 25

4.2.5.2 Création de sites depuis un fichier Excel.............................................................. 26 4.2.5.3 Vérification de plan de fréquences ....................................................................... 26 4.2.5.4 Fichier de retune ................................................................................................... 26

4.3 Planning............................................................................................................................... 27 4.4 Problèmes rencontrés .......................................................................................................... 27

5 Bilan ............................................................................................................. 28

5.1 Bilan pour l‟entreprise ......................................................................................................... 28 5.2 Bilan personnel.................................................................................................................... 29

5.2.1 Techniques ................................................................................................................... 29 5.2.2 Humain......................................................................................................................... 29

5.3 Perspectives ......................................................................................................................... 30

6 Conclusion .................................................................................................... 31

7 Bibliographie ................................................................................................ 32

Table des illustrations .......................................................................................... 33

Table des matières ............................................................................................... 34

Chenevoy Stéphane - 35 - Sept. 2007 – Fév. 2008

Rapport de stage ST40 - Automne 2007

Chenevoy Stéphane Département génie Informatique

France Telecom - Orange 8, rue du Dauphiné

69424 Lyon

Résumé C'est au sein de l'Unité de Pilotage Réseau Centre-Est appartenant au groupe France

Telecom que j'ai pu découvrir le monde de la téléphonie mobile. En coulisse, les ingénieurs radio s'activent pour que la qualité des réseaux mobiles soit la meilleure possible. Pour cela l'opérateur historique s'est doté de plusieurs logiciels. Dans ce rapport nous nous intéresserons plus

particulièrement à l'outil NetAct Planner développé par Nokia dont la fonction principale est la simulation de couverture radio. Cet outil est doté d'une base de données dont le contenu doit être le

plus à jour possible par rapport aux données terrain. Au court de mon stage, il m'a été donné de reprendre le projet informatique Oricox initié un semestre auparavant par un étudiant de l'UTBM. Le rôle principal de cette application est de détecter puis mettre à jour les incohérences de la base de

données de NetAct Planner grâce à d'autres bases de références. L'objectif de ce stage fut d'ajouter diverses fonctionnalités concernant la correction des incohérences ainsi que de développer plusieurs

petits modules en relations avec les données de NetAct Planner et les bases de références. Une partie du stage fut aussi dédiée à l'amélioration du déploiement d'Oricox pour les autres Unité de Pilotage Réseau.

Mots clés Transports et télécommunications Informatique Qualité

Génie logiciel Réseau et communications

Logiciel d‟analyse de données Logiciel de gestion