sauvegarde et restauration de mib ss7topalpinisme.free.fr/memoires/hargoaa_olivier_ir3_2007.pdf ·...

Mémoire d’ingénieur : 3ème année Soutenu le 13 septembre 2007

SAUVEGARDE ET RESTAURATION DE

MIB SS7

Olivier HARGOAA

Promotion 2007, filière Informatique et Réseaux, école Ingénieurs 2000

Composition du jury :

• Président : M. Dominique Revuz (Ingénieurs 2000)

• Tuteur entreprise : M. Jean François Mattern (Alcatel - Lucent)

• Responsable de projet : M. Serge Viallefond (Alcatel - Lucent)

• Tuteur académique : M. Pierre Doyen (UVSQ)

• Ingénieur expert : M. Ali Salehabadi (ADP)

Python ©

Olivier Hargoaa MEMOIRE D’INGENIEUR – MIB SS7 3/78

Ecole Ingénieurs 2000

All rights reserved. Parsing on and copying of this document, use and communication of its contents not permitted without

written authorization from Alcatel-Lucent

Soutenu le 13/09/2007

Remerciements






REMERCIEMENTS Je tiens en premier lieu à remercier M Franck Jouenne, Directeur de l’ensemble des plate-formes de téléphonie mobile pour m’avoir accueilli dans son service. Je remercie particulièrement M. Jean-François Mattern qui est à l’origine de mon projet de 3ème année et qui me suit en tant que tuteur depuis 2 ans. J’adresse tous mes remerciements à Serge Viallefond, qui est chargé de contrôler le bon déroulement de mon projet et qui est mon principal support technique. Je remercie également les principaux clients de mon projet pour leur confiance et leur dynamisme afin de participer à l’élaboration du cahier des charges avec notamment monsieur Alain Giordanna (TOMIX) et monsieur Christian Gouret (HLR). Je remercie aussi l’ensemble des membres du service TOMAS et particulièrement M Jean-Paul Cloarec pour les connaissances qu’il m’a apportées sur le logiciel de gestion de projet Clearcase, ainsi que M. Eric Duhautois pour la mise à disposition rapide des outils nécessaires. Je remercie aussi l’ensemble du corps professoral de l’école Ingénieur 2000 pour m’avoir apporté les capacités de réflexion nécessaire pour avancer dans le projet qu’Alcatel-Lucent m’a confié.

Table des matières






TABLE DES MATIERES

INTRODUCTION .................................................................................................................................................................... 6

1 DE L’ORGANISATION GENERALE D’ALCATEL JUSQU’AU SERVI CE DE FIABILISATION TOMAS.... 7

1.1. L‘ ENTREPRISE ALCATEL-LUCENT ............................................................................................................................ 7 1.1.1 Les origines d’Alcatel. ........................................................................................................................................ 7 1.1.2 Les origines de Lucent. ....................................................................................................................................... 7 1.1.3 La fusion entre Alcatel et Lucent. .......................................................................................................................8 1.1.4 Quelques données clés. ....................................................................................................................................... 8 1.1.5 L’équipe de direction. ......................................................................................................................................... 9 1.1.6 La découpe par régions géographique................................................................................................................ 9 1.1.7 La découpe en business groups......................................................................................................................... 10

1.2 LE PROJET TOMAS : UN ROLE ESSENTIEL DANS LA FIABILITE DES RESEAUX MOBILES. ......................................... 12 1.2.1 La plate-forme TOMAS : Support matériel et logiciel pour applications de téléphonie mobile. ...................... 12 1.2.2 TOMAS fiabilise plusieurs éléments clé du réseau mobile. .............................................................................. 14 1.2.3 Ma place dans le service TOMAS. .................................................................................................................... 15

2 PRESENTATION DU PROJET.................................................................................................................................. 17

2.1 CONTEXTE DU PROJET............................................................................................................................................ 17 2.1.1 Expression du besoin : multiples sources de commandes. ................................................................................ 17 2.1.2 Quelques contraintes......................................................................................................................................... 18 2.1.3 Les solutions existantes et proposées. ............................................................................................................... 19 2.1.4 Une problématique de souplesse : interface Python ......................................................................................... 20 2.1.5 Une ébauche de serveur à exploiter (OmniORBPy). ........................................................................................ 21 2.1.6 Un domaine de connaissance très pointu (MIB SS7 sur TOMIX). .................................................................... 21

2.2 ORGANISATION ET PREPARATION DU PROJET.......................................................................................................... 21 2.2.1 Définition du cahier des charges. ..................................................................................................................... 21 2.2.2 Architecture fonctionnelle................................................................................................................................. 21 2.2.3 Analyse de faisabilité. ....................................................................................................................................... 21 2.2.4 Déduction du planning prévisionnel. ................................................................................................................ 21 2.2.5 Méthodologie de développement....................................................................................................................... 21

3 DEROULEMENT DU PROJET ET GESTION DES PROBLEMES RENC ONTRES. ........................................ 21

3.1 CONCEPTS TECHNIQUES MIS EN ŒUVRE DANS LE PROJET........................................................................................ 21 3.1.1 Le compilateur de compilateur. ........................................................................................................................ 21 3.1.2 Le compilateur généré (librairie python).......................................................................................................... 21 3.1.3 Manipulation de code dynamique. .................................................................................................................... 21 3.1.4 Résolution des cas particuliers. ........................................................................................................................ 21

3.2 MANIPULATION ET INTEGRATION DU PROJET.......................................................................................................... 21 3.2.1 Clearcase. ......................................................................................................................................................... 21 3.2.2 Le makefile. ....................................................................................................................................................... 21 3.2.3 La phase d’intégration. ..................................................................................................................................... 21

3.3 TESTS DU PROJET.................................................................................................................................................... 21 3.3.1 Les FQM (Fonction Qualité Mesure)................................................................................................................ 21 3.3.2 Automatisation de la procédure. ....................................................................................................................... 21 3.3.3 Les différents états testables du projet. ............................................................................................................. 21

3.4 RESULTATS DU PROJET. .......................................................................................................................................... 21 3.4.1 Rétro compatibilité............................................................................................................................................ 21 3.4.2 Fonctionnalités dont le niveau de fiabilité est satisfaisant. .............................................................................. 21 3.4.3 Propositions d’améliorations............................................................................................................................ 21

Table des matières






4 BILAN DE L’ANNEE DE FORMATION ET DU CYCLE D’INGENIE UR. ......................................................... 21

4.1 MES CRAINTES APRES UNE GRANDE ABSENCE. ....................................................................................................... 21 4.2 UN RETOUR RAPIDE DANS LE VIF DU SUJET. ............................................................................................................ 21 4.3 UNE ORGANISATION DELICATE. .............................................................................................................................. 21 4.4 LA SATISFACTION D’UN CONTRAT REMPLI. ............................................................................................................. 21 4.5 MON EVOLUTION VERS LE METIER D’ INGENIEUR. ................................................................................................... 21

CONCLUSION ....................................................................................................................................................................... 21

GLOSSAIRE ........................................................................................................................................................................... 21

BIBLIOGRAPHIE.................................................................................................................................................................. 21

TABLE DES ILLUSTRATIONS .......................................................................................................................................... 21

TABLE DES ANNEXES ........................................................................................................................................................ 21

Intro duction






INTRODUCTION Objet : Le présent document est le mémoire d’ingénieur clôturant une période de trois ans d’apprentissage entre l’école Ingénieurs 2000 et l’entreprise Alcatel-Lucent. Il présente mes travaux effectués en entreprise lors de ma troisième année du cycle d’ingénieur.

La société Alcatel-Lucent qui m’a accueilli pour mes trois années de formation d’ingénieur en informatique et réseaux, développe des produits dans le domaine des télécommunications et réseaux. La mission qui m’a été confiée en 3ème année consiste en un développement logiciel précédé d’une phase d’études ayant pour but d’assurer des sauvegardes et restaurations fiables des configurations du réseau de signalisation SS7. Dans une première partie, je présenterai le groupe Alcatel-Lucent dans son ensemble et plus particulièrement le service pour lequel je travaille afin de situer mon activité dans celui-ci. Ensuite viendra la description du projet, cœur du sujet de l'apprentissage cette dernière année, dont j’expliquerai le choix des lignes directrices. Enfin, avant de conclure, je présenterai une réflexion personnelle sur les six mois de travail vécus au sein d’Alcatel-Lucent, puis plus généralement sur les 3 ans.

Le groupe ALCATEL -LUCENT






1 De l’organisation générale d’Alcatel-Lucent jusqu’au service de fiabilisation TOMAS

1.1. L‘entreprise Alcatel-Lucent

1.1.1 Les origines d’Alcatelt. Les origines d’Alcatel-Lucent remontent à l’année 1898, lorsque l’ingénieur français Pierre Azaria a créé la Compagnie Générale d'Electricité (CGE) opérant dans divers secteurs tels que l’électricité, l’électronique et les télécommunications. Non seulement, la CGE deviendra un leader en communications numériques mais elle sera également connue pour la fabrication du TGV en France (trains à grande vitesse). Au milieu des années 1980, la CGE renforce sa place de leader dans le domaine des communications numériques en se portant acquéreur des activités de télécommunications internationales d’ITT Corporation. La CGE devient alors Alcatel Alsthom. Par ailleurs, mesurant l’énorme potentiel du marché en Asie Pacifique, Alcatel est la première entreprise française à s’implanter en Chine dès 1983. En 1995, Serge Tchuruk est nommé Président et Président-directeur général d’Alcatel. Il recentre l’activité du groupe sur le marché des télécommunications, en séparant les activités Alsthom. Le Groupe Alcatel Alsthom est rebaptisé et devient alors Alcatel. A la fin des années 1990, Alcatel réalise d’importantes acquisitions en Amérique du Nord, et en 2002, elle prend le contrôle de sa filiale chinoise Alcatel Shanghai Bell (ASB), dont une partie appartient au gouvernement chinois. ASB permet à Alcatel d’occuper une place prépondérante sur un marché en très forte croissance et où les opportunités sont nombreuses.

1.1.2 Les origines de Lucent. Lucent Technologies a été créé par AT&T le 30 septembre 1996 mais il faut remonter à l’année 1869 pour avoir la constitution de cette entreprise, date à laquelle Elisha Gray et Enos N. Barton ouvrent une petite usine de production à Cleveland. Trois ans plus tard, cette entreprise, alors installée à Chicago, est rebaptisée Western Electric Manufacturing Company. En 1880, la société était devenue le plus gros fabricant de produits électriques des Etats-Unis, réputée pour la production d’équipements électriques divers. En 1881, American Bell prend le contrôle de la Western Electric et fait d’elle le développeur et fabriquant exclusif d’équipements pour les entreprises de téléphone Bell. En 1925, les laboratoires Bell Téléphone sont créés par le regroupement des laboratoires Western Electric Research, fondés en 1907, et d’une partie des départements techniques d’AT&T. Les laboratoires Bell Labs ont par la suite été à l’origine de certaines des plus grandes découvertes scientifiques et technologiques du XXe siècle, telles que le transistor, le laser, les batteries à énergie







solaire, la puce de processeur de signaux numériques et le concept cellulaire des services téléphoniques mobiles. Le 1er janvier 1984, AT&T accepte de céder ses compagnies Bell locales. Dans le cadre de cette cession, une nouvelle unité baptisée AT&T Technologies reprend les activités de Western Electric. En 1989, AT&T Technologies intègre plusieurs divisions qui se regrouperont par la suite avec Bell Labs pour former Lucent Technologies.

1.1.3 La fusion entre Alcatel et Lucent. En 2006, alors que les opérateurs se regroupent et que la concurrence devient de plus en plus intense, Alcatel annonce son intention de fusionner avec Lucent Technologies. Parallèlement, le groupe dévoile un accord qui lui permettra de monter au capital de Thalès, acteur majeur sur le marché français de la Défense. Dans le cadre de cet accord, Alcatel céderait ses activités satellite, signalisation ferroviaire ainsi que celles dédiées aux systèmes critiques de sécurité. Alcatel annonce également son intention d’acquérir l’activité Accès radio UMTS de Nortel pour asseoir son leadership dans ce domaine. Ces accords s’inscrivent dans le cadre d’une stratégie de long terme visant à faire d’Alcatel-Lucent, le leader référent du marché en pleine croissance des télécommunications.

1.1.4 Quelques données clés. Alcatel-Lucent fournit des solutions de communication permettant aux opérateurs de télécoms, aux fournisseurs d'accès Internet et aux administrations du monde entier d’offrir des services voix, données et vidéo. Leader dans les réseaux haut débit fixes, mobiles et convergents, les services et les applications IP, Alcatel-Lucent propose des solutions de bout en bout permettant des services de communications innovants pour les utilisateurs, qu'ils soient à la maison, au travail ou en déplacement. L’entreprise dispose de la meilleure offre globale du marché et de l’une des plus grandes capacités en recherche-développement du secteur des télécommunications. Directrice Générale Patricia Russo Président non exécutif Serge Tchuruk Siège social 54 rue la Boétie, 75008 Paris, France Sièges sociaux régionaux Europe & Sud: Vélizy, France Europe & Nord: Anvers, Belgique Amérique du Nord : Murray Hill, NJ, USA Asie-Pacifique: Shanghai, Chine Nombre de salariés 80 000 Présence mondiale 130 pays Chiffre d'affaires 18,6 milliards €

Répartition des ventes 1/3 Europe, 1/3 Amérique du nord, 1/3 Reste du Monde Positions clés: n°1 dans le fixe n°3 dans le mobile Parmi les trois premiers dans les services n°1 en Europe pour les systèmes de communication IP en entreprises Actions émises et en circulation (Ordinaires) 2,3 milliards Recherche & Innovation 2,7 milliards € en dépense R&D(Recherche et Développement) 23 000 salariés en R&D 25 000 brevets 6 Prix Nobel en Physique(partagés par 11 scientifiques)







1.1.5 L’équipe de direction.

Figure 1 – Organigramme de l’équipe de direction.

CEO: Chief Executive Officer CTO: Chief Technology Officer CAO: Chief Administrative Officer IS/IT : Information System/Information Technology CFO: Chief Financial Officer HR/Com: Human Ressources/Communication CMO : Chief Marketing Officer

1.1.6 La découpe par régions géographique.

La région « Asie-Pacifique » apporte son expertise aux fournisseurs de services et aux entreprises de Chine, du nord-est et du sud-est asiatique et de l’Australie. Elle est dirigée par Frédéric Rose.







La région « Europe et Nord » comprend le Royaume-Uni, les pays nordiques, le Benelux, l’Allemagne, la Russie et les pays d’Europe de l’Est de l’Europe. Dans plus de 40 pays, elle intervient et apporte son expertise aux principaux fournisseurs de services télécoms et aux entreprises. Cette région est dirigée par Christian Reinaudo.

La région « Europe et Sud » comprend la France, l’Italie, l’Espagne et les autres pays d’Europe du Sud, l’Afrique, le Moyen-Orient, l’Inde et l’Amérique latine. Dans plus de 120 pays, elle fournit assistance et savoir-faire aux principaux fournisseurs de services télécoms et aux entreprises. Cette région est dirigée par Olivier Picard.

La région « Amérique du Nord » est dédiée aux fournisseurs de services et aux entreprises des Etats-Unis et du Canada. Elle est dirigée par Cindy Christy.

1.1.7 La découpe en business groups. Trois segments d’activités (Carrier Business Groups) ont pour objectif de répondre aux besoins des fournisseurs de service de communication. Sous la direction d’Etienne Fouques, ils développent des solutions destinées aux fournisseurs, aux entreprises et aux administrations du monde entier pour leur permettre de lancer de nouveaux services de communication innovants pour les clients. Parallèlement, ces segments d’activité contribuent à simplifier les coûts générés par les évolutions des réseaux et à réduire leur gestion.

Le groupe Convergence (Convergence Business Group) s’occupe de trouver des solutions de communication innovantes. Simples, intégrées, personnelles et sécurisées, elles servent à transformer la manière dont les gens communiquent. Dirigée par Marc Rouanne, l’activité Convergence propose aux fournisseurs de services des solutions de cœur de réseau et multimédias complètes qui combinent des services voix, données, vidéo fixes et radio sur les réseaux IP de prochaine génération.

Le groupe Mobile (Wireless Business Group) s’occupe lui des solutions de communications mobiles. Dirigée par Mary Chan, l’activité Mobile dispose d’un large portefeuille de technologies mobiles incluant notamment le WiMAX. Il dispose également des atouts et du savoir-faire pour faire évoluer toutes les technologies vers la 3G et au-delà.







Le groupe Fixe (Wireline Business Group) travaille dans toutes les activités de communication fixe tant sur le haut débit, le Triple Play, les réseaux IPTV que sur les réseaux optiques, et le marché des routeurs IP. Dirigée par Michel Rahier, elle dispose, tant pour les fournisseurs de services que les grandes entreprises, d’une offre de produits très étendue.

Le groupe Entreprise (Enterprise Business Group) travaille sur les solutions de communications pour les entreprises telles que les logiciels de centre de contact, de gestion d’adresses IP et la téléphonie pour PME. Dirigé par Hubert de Pesquidoux, le groupe apporte un réel avantage aux entreprises de toute taille en les aidant à augmenter la satisfaction de leurs clients et la productivité de leurs salariés. Son offre réunit des produits, logiciels et services conçus pour que le personnel puisse échanger plus facilement des informations multimédia.

Le groupe Services (Services Business Group) dirigé par John Meyer, regroupe plus de 20 000 experts réseau qui ont pour mission d’assister les plus importants fournisseurs de services du monde à travers un choix de services professionnels couvrant tout le cycle de vie des réseaux : conseil et conception, intégration et déploiement, exploitation et maintenance. En aidant les clients à trouver le juste équilibre entre leurs activités internes et les avantages liés à une solution de partenariat adaptée à leurs besoins, Alcatel-Lucent peut accélérer la réalisation des bénéfices issus des projets d’intégration de grande envergure.







1.2 Le projet TOMAS : Un rôle essentiel dans la fiabilité des réseaux mobiles. Le groupe Convergence d’Alcatel-Lucent travaille sur un environnement sécurisé pouvant accueillir des applications téléphoniques fixes et mobiles. Il faut comprendre le terme sécurisé dans le sens d’une minimisation des pannes. Cet environnement (projet TOMAS Telecom Os M iddleware Application Server) est utilisé dans de nombreuses parties des réseaux téléphoniques actuels. Nous verrons tout d’abord ce qu’est la plate-forme TOMAS, puis sa place dans les réseaux de téléphonie mobile.

1.2.1 La plate-forme TOMAS : Support matériel et logiciel pour applications de téléphonie mobile. Les réseaux téléphoniques ont besoin d’assurer un service ininterrompu en cas de panne d’un élément. Cette sécurisation s’obtient par des redondances (duplications). Le principe de TOMAS est de dupliquer tous ses services et de mettre en place un moyen de communication pour relier les activités parallèles. Ainsi, lors d’un problème sur une activité en cours de traitement, un basculement s’effectue et la tâche commencée se poursuit sur l’équipement parallèle. La grosse difficulté de TOMAS est qu’il doit être capable de réagir très vite (en temps réel) car les applications basées sur cette plate-forme mettent en jeu beaucoup d’argent puisqu’il s’agit de services pour la téléphonie mobile devant être facturés à l’utilisateur. Le concept de TOMAS est de réaliser, à partir de composants non sécurisés (cartes processeurs, coupleurs, OS Linux, switch Ethernet), une plate-forme résistant aux pannes et offrant une grande souplesse d’utilisation (continuité de service en cas de mise à jour ou d’extension de capacité). Cette plate-forme peut accueillir diverses applications télécom par une interface standardisée (API TOMAS).

Figure 2 - TOMAS un système complet







Composition matérielle d’un serveur TOMAS : Une plate-forme TOMAS est basée sur un rack de type ATCA qui comprend un double réseau interne (LAN Ethernet). Dans ce rack, on équipera des cartes qui seront chacune reliées aux deux réseaux. Une configuration minimale comprendra au moins :

• Deux stations pilote (cartes équipées de deux accès LAN chacune) dont l’une est active et l’autre en réserve « standby ».

• Deux jeux de disques (les deux contenant les mêmes informations « disk mirroring »).

Optionnellement, on y ajoutera des cartes non-pilote pour augmenter la puissance de traitement, faire du partage de charge ainsi que des cartes coupleur télécom reliées au monde extérieur.

Figure 3 - Disk mirroring

L’ensemble TOMAS présente donc toute une partie matérielle équipée d’un système d’exploitation (Operating System), basé sur un OS Linux, permettant d’utiliser un environnement entièrement sécurisé. Le projet TOMAS fournit aussi la possibilité de gérer la plate-forme grâce à la proposition de services de management pour la partie matérielle (HW Hardware Management) et logicielle (SW Software Management). Une fois cet environnement stable, le projet TOMAS est livré aux développeurs d’applications qui produiront des solutions télécoms performantes comme pour le SGSN (Serving GPRS Support Node). Les équipes qui développent des applications pour la plate-forme TOMAS nécessitent un environnement stable. C’est pour cela que les développeurs et testeurs de TOMAS travaillent conjointement. Je fais partie intégrante de ces deux équipes.

Figure 4 - Un exemple de configuration TOMAS







1.2.2 TOMAS fiabilise plusieurs éléments clé du réseau mobile. Certains services supportés par un réseau mobile sont très critiques pour un opérateur de télécommunication. Entre autre le domaine de la taxation. Une défaillance dans le système de mesure de la durée des appels téléphoniques, peut faire perdre les informations sur tous les appels commencés avant la panne. Grâce à un système fiable se basant sur du TOMAS, une panne du serveur de taxation (billing server pour la 2G) sera immédiatement contrée par le basculement de la plate-forme TOMAS sur le service parallèle. Il ne faut cependant pas croire que seule la taxation est prise au sérieux par les opérateurs de téléphonie. S’ils veulent rester compétitifs, les opérateurs doivent fournir un service de qualité. C’est pourquoi le routage des appels (MSC) est lui aussi basé sur une plate-forme TOMAS. Le MSC est, rappelons le, l’organe principal d’un réseau de télécommunication mobile. On trouve aussi TOMAS dans le sous ensemble radio de la 2G (Base Sub System BSS), dans le routeur qui fait transiter les paquets de données multimédia du réseau GPRS (2.5 G) avec le SGSN (Serving GPRS Support Node). Les année 2005 et 2006 sont une très bonne période pour TOMAS avec un déploiement dans plus de 200 sites (Chine, Malaisie, Algérie, USA).

Figure 5 - Place de TOMAS dans un réseau mobile.

NSS







Il existe actuellement un courant tendant à modifier l’architecture des réseaux classiques vers une nouvelle génération de réseaux (New Generation Network NGN). L’objectif du concept NGN est de pouvoir traiter plus d’abonnés pour un moindre coût de revient et de faciliter la maintenance des réseaux en les rendant plus évolutifs et plus rapidement opérationnels. Le NGN sera un bon prétexte pour pousser les opérateurs téléphoniques à investir dans du nouveau matériel. A cette occasion, les MSC actuels seront divisés en deux machines (Call Servers et Media Gateway) et les serveurs de la base de donnée des abonnés (HLR) seront améliorés (New Generation HLR = NGHLR). Le marché des NGHLR est déjà partiellement conquis ainsi que celui des Media Gateway. Pour rester leader dans ce domaine, TOMAS va devoir prouver que sa plate-forme est la plus fiable du marché.

1.2.3 Ma place dans le service TOMAS. Le service TOMAS appartient à la division Solutions Mobiles de la branche Convergence. Ce service composé d’une centaine d’ingénieurs se sub-divise en plusieurs équipes. Parmi elles, une équipe de tests composée d’une vingtaine de personnes, et une équipe de développement du projet « mainstream ». Pour cette dernière année, j’ai évolué du service de tests vers une activité dédiée à l’amélioration des processus. Je travaille à la fois pour le service de tests (service dans lequel j’ai effectué mes deux premières années d’apprentissage) et pour le service de développement.

Figure 6 - Organigramme général de la branche de solutions mobiles.







Le service de tests est d’une très grande importance puisqu’il se situe en bout de chaîne du projet TOMAS. De nombreuses équipes d’Alcatel-Lucent vont développer des applications Télécom sur la plate-forme TOMAS. Il est donc indispensable que les versions de TOMAS livrées aux différentes équipes soient complètement stables. Le service de test a pour mission de valider toutes les versions de TOMAS. Un test sur une plate-forme comme TOMAS, consiste en l’envoi d’une suite de sollicitations (messages, signaux, appels de primitives…) en entrée puis on analyse les réponses lues sur la sortie. La branche communications mobiles d’Alcatel-Lucent est actuellement en cours de réorganisation. Les nouvelles directives qui en découlent demandent d’accroître la rapidité de production. Le service TOMAS doit donc livrer des nouvelles versions de manière de plus en plus fréquente, il faut donc accélérer le temps de validation de la plate-forme TOMAS, et un des axes de cette accélération est l’automatisation du passage de tests.

FiabilisationD. Tardy

A. Le Moenner

Charge et endurance

Amélioration des processusJ.F. Mattern - (S.Viallefond, O.Hargoaa, ...)

C. Colin

O.HargoaaS.Viallefond

Projet PommardD. Tardy

Projet Sauternes

J.P. Marcon

Projet Pauillac

Projets réguliers

Tests et validation

Developpement Maintenance Hotline

M. Blinot C. Colin F. Tourlonnias

Developpement Systeme TestS. Chichportich H. Mantoan A. Giordana

Fiabilité VNR Automatique

Projet en cours de développement

Projet à l'étude

Automatisation : J.F. Mattern

J.C. Vavasseur

O. Hargoaa…

Projet Main Stream

Projet terminé : en cours d'intégration dans le projet Mainstream

Figure 7 - Organisation matricielle du service TOMAS

L’organisation du service TOMAS repose sur la mise en parallèle de plusieurs projets décalés dans le temps dont un englobant les autres selon les périodes. Actuellement le projet maître est le Mainstream. Dans chacun de ces projets il existe des branches transversales par domaines d’activités. Le carrefour entre une branche transversale et un projet donne lieu à la mise en place d’une équipe. Les ingénieurs ne sont pas affiliés à un projet mais à un domaine d’activité. Ils peuvent changer de projet selon les besoins du projet meneur.

MIB SS7






2 Présentation du projet Dans la suite de ce document, vous rencontrerez le nom de « backup restore » ou encore de « 7MBR » (SS7 MIB backup restore) pour caractériser le projet.

2.1 Contexte du projet Ce projet se déroule uniquement sur ma troisième année d’apprentissage, tout en utilisant des pratiques déjà vues aux cours des deux premières années.

2.1.1 Expression du besoin : multiples sources de commandes.

a Origine du besoin.

La plate-forme de télécommunications TOMIX offre des services de base pour la partie cœur de réseau mobile. Des exemples sont donnés dans la partie traitant de la présentation du projet TOMIX. Pour maintenir et administrer ces services, TOMIX propose pour sa plate-forme des mécanismes génériques, dont un permettant d’effectuer des sauvegardes et restaurations des environnements de configuration. Suite à diverses demandes, le service TOMAS a recensé le besoin de conserver la maîtrise de son mécanisme de « backup restore » pour le domaine de la configuration SS7. Ce besoin existe depuis plus d’un an, et le service s’est engagé à proposer une solution pour fin août, début septembre 2007, date de mon départ d’Alcatel–Lucent. Mes supérieurs m’ont donc proposé de travailler dessus avant même que commence ma troisième période d’alternance.

b Les différents clients.

Pour ce projet, on peut identifier trois familles de clients :

• Les clients les plus demandeurs sont ce qu’on appelle les « applications ». Ce sont les services qui développent des couches logicielles au dessus des couches et services offerts par la plate-forme TOMIX. Le client majoritaire est celui qui travaille sur le NGHLR. C’est une application de HLR au dessus de SIGTRAN. Le support de SIGTRAN est fourni avec les mêmes interfaces d’administration que le reste du SS7 sur la plate-forme TOMIX.

• Un autre besoin va être exprimé conjointement par les branches de développement, tests et

maintenance du service TOMIX. Pour différents besoins sur la plate-forme TOMIX, ces équipes sont amenées à effectuer de nombreuses installations et configurations souvent répétitives. Ils expriment le besoin de pouvoir adapter d’une maquette à une autre les configurations SS7 déjà effectuées. Ils souhaitent aussi pouvoir élargir ces possibilités de transfert entre des plate-formes TOMIX de différentes versions.

• Pour finir, nous rencontrons un besoin parallèle au projet, prononcé par l’équipe de test de

TOMIX : utiliser le futur mécanisme de sauvegarde et restauration de la MIB SS7 afin de créer un test d’endurance sur la configuration de MIB SS7/SIGTRAN de TOMIX.

MIB SS7






c Problématique.

A l’issue de la présentation des besoins des différents clients, j’ai pu élaborer une problématique. Comment permettre à un utilisateur de TOMIX (interne ou externe) de manipuler (sauvegarder, restaurer, modifier, exploiter sur différentes version de TOMIX) les configurations SS7/SIGTRAN en étant capable de se limiter à son seul rayon d’action, tout en étant en mesure de fournir une méthode fiable l’empêchant de laisser la MIB dans un état instable ? Quelques explications :

• « se limiter à son seul rayon d’action » : le modèle SS7/SIGTRAN est organisé en couches. On peut comparer cette famille d’architectures à celle du modèle OSI qui décrit les réseaux IP. On entend donc pour une configuration SS7, que les experts de chaque domaine soient en mesure de se limiter à leur seul domaine de connaissance. Ainsi un expert travaillant sur une couche haute du modèle SS7 devra pouvoir sauvegarder ou restaurer ou encore modifier seulement son domaine.

• « fournir une méthode fiable l’empêchant de laisser la MIB dans un état instable » : Une MIB

SS7 minimaliste contient déjà plus d’une centaine d’objets, chacun composé d’une dizaine d’attributs. Sur un environnement en exploitation, le nombre de ces objets atteint le millier. Les configurations de MIB SS7 valides sont définies par des organismes de normalisations (ANSI et ITU) La plate-forme TOMIX respecte ces standards internationaux. Au niveau d’une MIB, cela se caractérise pour chaque attribut, une description des plages de valeurs autorisées, puis pour les objets, les attributs qui doivent les composer en fonction de différents paramètres. L’application de « backup restore » doit être en mesure de certifier le bon respect de ces normes, faute de quoi la plate-forme TOMIX deviendrait instable, car les objets non valides ne peuvent y être créés.

La demande telle que formalisée officiellement :

• Provide a way to backup/restore only SS7 MIB and reduce the outage during the restore procedure.

• Fournir une méthode pour sauvegarder/restaurer une MIB SS7, tout en réduisant la durée pendant laquelle la MIB n’est plus capable de permettre le transfert des messages de signalisation SS7 (ceci est le cas pendant la période de restauration).

2.1.2 Quelques contraintes.

a Contrainte temporelle.

Aujourd’hui, la procédure de restauration de MIB SS7 conduit à une interruption de service d’au minimum 15 minutes. Avec la nouvelle procédure, le cluster ne sera pas redémarré et le réapprovisionnement de la MIB se fera en 3 ou 4 minutes. Pendant la durée de restauration, seul le réseau SS7 sera perturbé, pas de redémarrage des stations.

b Contrainte technique.

TOMIX est une plate-forme en constante évolution. Le service produit une version majeure par an. La difficulté vient principalement du fait du grand nombre de stations TOMIX présentes sur le marché. Notre principal client (ngHLR) possède la moitié de son parc avec des TOMIX MD5 (2004/2005) et

MIB SS7






l’autre moitié avec des TOMIX MD7 SP1 (mi-2006). Aujourd’hui la prochaine livraison de TOMIX sera une MD7 SP3. Pour des raisons dimenssionnement, le projet doit être disponible pour MD7 SP1, parti pris que le ngHLR fera évoluer son parc MD5 vers une version supérieur d’ici peu. Le projet backup/restore doit être livrable via une mise à jour de type “minor”. Chez TOMIX le type “minor” signifie que la modification doit être livrée sous forme d’un package installable (RPM) ne nécessitant pas modification des packages en fonctionnement. Un aspect plus particulier lié à ce projet, est qu’il traite de la configuration SS7 et SIGTRAN. Ces protocoles répondent à des normes, et régulièrement des évolutions y sont apportées. Le projet 7MBR doit être auto-adaptable aux évolutions voulues par la norme, ainsi qu’à l’éventuelle création de protocoles réseaux (évolutions que pourra succiter l’apparition de la 4G de la téléphonie mobile).

2.1.3 Les solutions existantes et proposées.

a Méthodes actuelles de configuration SS7.

On recense actuellement deux méthodes permettant de manipuler les configurations SS7/SIGTRAN contenues dans les MIBs.

• L’utilisation de commandes BUI (Basic User Interface). Ces commandes permettent d’effectuer des actions sur les MIB avec un jeu de commande propriétaire défini par TOMIX. Le traitement des commandes se fait de manière unaire. On ne traite pas ici tout ou partie d’une MIB, mais on travaille sur chaque objet de la MIB individuellement.

• L’interface graphique GUI (Graphical User Interface), applet JAVA. Elle permet les mêmes fonctionnalités que les commandes BUI, mais en offrant des contrôles plus poussés pour éviter de laisser une MIB dans un état instable après travail.

b Propositions de méthode de backup/restore.

• Solution proposée par les clients du ngHLR : Porter pour le ngHLR la solution actuellement

existante pour le service du SGSN (Serving GPRS Support Node – 2.5G – basé SS7). Le ngHLR étant basé à la fois sur SIGTRAN et SS7, il faut re-concevoir l’application existante et y décrire tous les aspects de la configuration SIGTRAN. Cette procédure est celle que privilégie le service ngHLR ainsi qu’une partie de l’équipe TOMIX. (prévoir 4000 lignes de PERL et 1000 lignes de shell script et 300 heures – 9 semaines pour une personne connaissant les MIB et ayant travaillé sur la version précédente).

• Solution proposée par TOMIX – équipe décisionnelle : Utiliser le mécanisme de backup/retore

de TOMIX (TOMIXBR) pour sauvegarder les MIBs SS7 et SIGTRAN. Cette solution sera proposée sous forme d’une notice explicative, elle ne nécessite pas à priori de développement mais ne peut en aucun cas couvrir l’ensemble des besoins exprimés par les différents clients. Stratégie : l’utiliser en attendant de trouver une solution plus complète.

• Solution proposée par TOMIX – équipe développement : Développer une nouvelle application la

plus proche possible des besoins des clients, capable de s’affranchir des interfaces de communications standard présentes sur TOMIX. Cette solution doit être générique et adaptable aux futures versions de TOMIX avec le moins de maintenance possible. Nom : 7MBR.

MIB SS7






c Récapitulatif.

Figure 8 - Comparaison des solutions capables de modifications sur les MIBs SS7.

Après analyse préalable, on retiendra la solution de présenter dans une même documentation les projets TOMIXBR et 7MBR afin d’englober la majorité des besoins liés aux configurations SS7 et SIGTRAN. En effet le projet 7MBR nécessite un serveur TOMIX en fonctionnement pour effectuer ses opérations de nettoyage de MIB. Il ne peut donc fonctionner en cas de crash exceptionnel. Dans ces cas précis la solution TOMIXBR lui sera préférable. Le projet 7MBR me sera confié dans son intégralité des phases de spécifications jusqu’aux livraisons finales.

2.1.4 Une problématique de souplesse : interface Python

a Politique générale.

Initialement prévu pour les équipes de test, le service TOMIX a manifesté sa volonté d’harmoniser ses procédures de tests. La demande faisait état d’une nécessité de recentrer les compétences des testeurs sur leur cœur de métier : le test, et non sur l’apprentissage d’un grand nombre de formats de fiches de tests venues de tous horizons. Cette politique a été amorcée alors que je me trouvais en première année d’alternance chez Alcatel-Lucent. Ma mission avait alors été d’introduire le langage Python auprès des équipes de testeurs. Puis plus largement ensuite le promouvoir aux développeurs également. Cela s’est fait notamment avec le développement de mon projet de première et deuxième année en Python. Ce projet avait le double intérêt de cibler les deux équipes puisqu’il s’agissait de réaliser une application pour l’équipe de test, en s’intégrant dans l’équipe de développement.

b Exploiter les compétences.

Fort de cette première expérience de mes deux précédentes années, j’ai aujourd’hui complètement évolué vers le service de conception et développement. Ma connaissance de Python me désigne tout naturellement vers ce nouveau projet. Il est vu par l’équipe comme l’aboutissement de mon apprentissage. Je vais donc pouvoir me servir de mes compétences acquises mais aussi de celles des testeurs et développeurs qui ont continué la mise en place de Python pendant mon absence.

MIB SS7






c Le python c’est maniable.

Bien que souhaité pour ce nouveau projet, le python ne sera en aucun cas imposé. Pour ce projet une analyse de faisabilité aura lieu tout en conservant l’idée que le Python est souhaitable. Il faudra procéder pour cela à une évaluation du surcoût engendré par Python en lieu et place d’un langage plus adapté, si on en trouve un pour ce projet. On note toutefois que cette demande n’intervient pas au hasard par pure volonté d’homogénéisation, mais elle s’appuie sur la présence en standard sur toutes les machines TOMIX d’une machine virtuelle Python embarquée. L’utilisation d’une technologie telle que python facilite la réalisation d’une des contraintes client, ce langage étant interprété, on pourra facilement envisager une livraison du nouveau projet avec une livraison de type « minor ».

2.1.5 Une ébauche de serveur à exploiter (OmniORBPy).

a Les acquis des deux premières années.

Nous avons vu précédemment qu’une des possibilités de configurer le SS7 était de passer par le BUI afin d’y passer des commandes ciblant les MIBs. Durant mes précédentes années d’apprentissage, je suis intervenu sur un projet : BULtoPy (Basic User Language to Python). Ce langage : le BUL, est celui utilisé par le BUI. Lors de la volonté d’uniformisation de l’environnement des testeurs, nous avions décidé de convertir tous les scripts BUL en scripts Python. Mon rôle s’était alors limité à travailler sur un script python destiné à convertir les scripts BUL en scripts Python. Pour utiliser ces scripts Python, l’équipe de développement a créé un client CORBA (Comon Object Request Architecture) en python capable de faire exécuter les anciennes commandes BUL sur les serveurs de MIB embarqués dans TOMIX. Il semble donc intéressant d’utiliser ces anciens travaux pour le futur projet.

b Fonctionnement du client/serveur CORBA pour OmniORB.

Le serveur est capable de faire exécuter des commandes équivalentes aux différentes commandes BUI disponibles. Il existe cinq types de commandes définies par une interface IDL. Cette interface est commune aux BUI et au serveur Python. On retrouve des commandes qui peuvent faire penser à une gestion de base de données : « create, set, get, delete, action ». Le nouveau format des commandes Python a été défini le plus proche possible des anciennes commandes BUI pour minimiser le temps d’adaptation des testeurs. Le client python va parser les commandes une à une puis les envoyer via CORBA au serveur python, qui lui les enverra via CORBA sur les différents serveurs de MIB en fonction du domaine visé. Les commandes sont envoyées de manière asynchrone. (cf A 4 1 )

c Architecture TOMIX.

Afin de situer les applications de gestion des MIBs sur TOMIX, voici un schéma partiel de l’architecture de blocs TOMIX. On peut notamment situer le BUI, ainsi que le GUI permettant de configurer les MIBs de manière unaire. L’ORB (Object Request Broker – c’est le bus de CORBA) interne cache la présence de sous serveurs internes. On peut dès lors mentionner que la pile de protocole SS7/SIGTRAN possède autant de serveurs de configuration qu’elle possède de couches.

MIB SS7






Figure 9 – Architecture de CORBA sur TOMIX

2.1.6 Un domaine de connaissance très pointu (MIB SS7 sur TOMIX).

a Le SS7.

Le réseau SS7 (Signaling System n°7 défini par les normes ITU-T Q70x) est en charge de la signalisation nécessaire au contrôle d’une communication via les réseaux télécom. Elle est en charge de l’établissement, du contrôle de rupture, de la facturation, de la maintenance et d’autres services tels que les réseaux intelligents IN (présentés en première partie). Initialement prévue dans un réseau physique dédié, cette méthode de signalisation s’est ensuite étendue en surcouches de réseaux ATM (Asynchronous Transfer Mode), puis plus récemment adaptée au dessus de IP(Internet Protocol), sous le nom de SIGTRAN (SIGnaling TRANsport - RFC 2719). La plateforme TOMIX propose des composants matériels pour les couches basses du protocole, et des couches logicielles pour les couches plus élevées. Par comparaison au modèle OSI, seul l’équivalent de la couche 2 (liaison), possède une architecture matérielle sur TOMIX. Les différents éléments de ces réseaux de contrôle doivent être configurés avant d’entrer en fonctionnement. Il existe le même besoin pour les routeurs et switchs du modèle IP/OSI.

b Les MIBs.

Les MIBs (Management Information Base), sont en charge de la configuration des réseaux, dans notre cas des réseaux SS7 et SIGTRAN. Nous avons vu en amont comment les administrer. Voyons maintenant ce qu’elles contiennent. Elles sont composées d’objets décrivant la configuration du réseau. Elles permettent au réseau de se reconstruire et de maintenir son état.

MIB SS7






On trouve deux familles d’objets. Les objets de configuration, et les objets de descriptions d’état. Cette constatation soulève une première interrogation : comment faire un backup/restore d’un état ? Pour les objets de configurations il n’y a pas de problème si ce n’est de respecter la norme. Pour les objets d’état prenons un exemple : soit un canal de communication inactif au moment du backup. Pour pouvoir le détruire il faudra d’abord le verrouiller, puis ensuite le détruire. Mais lors de sa reconstruction, on ne pourra le reconstruire qu’avec un état d’initialisation. Ensuite il passera automatiquement à un état soit actif, soit inactif, et cela au bout du temps d’initialisation. Par la suite comment tester si la MIB restaurée est identique à celle sauvegardée ? On ne le pourra pas. Il faudra tester si la MIB est équivalente. La gestion de ces cas particuliers va imposer une réelle difficulté lors de la conception de l’application. On sait désormais que cela risque d’être le point clé lors de l’analyse de faisabilité.

c Des concepts pour informaticiens.

La lecture des paragraphes sur le SS7 et sur les MIBs SS7 pourrait faire penser qu’un ingénieur télécom serait mieux placé qu’un ingénieur informaticien. Mais TOMIX a pris soin de convertir les normes de configurations SS7 dans une batterie de fichiers de description au format XML. L’approche de la plateforme TOMIX, elle aussi a été simplifiée grâce à nos travaux de l’année dernière sur la réalisation d’un serveur CORBA pour passer des commandes sur les MIBs SS7. Les concepts qu’il va falloir manipuler se résument finalement à des fichiers XML avec leur fichier de définition XSD. A cela il faut ajouter la compréhension de CORBA, et le projet pourra démarrer. Mais des compétences de télécom sont tout de même requises. Elles seront indispensables pour connaître les gestions particulières des objets des descriptions des états du réseau SS7. Il faut aussi des compétences spécifiques TOMIX pour manipuler la plateforme TOMIX, y créer des jeux de configurations et être en mesure de les restituer au fur et à mesure du développement. Le mélange des deux compétences sera requis pour l’élaboration de scénarios de tests.

2.2 Organisation et préparation du projet.

2.2.1 Définition du cahier des charges. L’élaboration du cahier des charges correspond à la première opération sur ce projet. Il faut pour cela réunir les besoins de chacune des trois familles de clients présentées dans la partie « expression du besoin ».

a Schéma de principe.

Ce schéma a pour rôle de servir de support à la discussion pour les phases qui précèderont la réalisation.

MIB SS7






b Les acteurs.

Pour ce projet, on identifie deux acteurs qui possèdent chacun les mêmes droits. L'utilisateur peut être :

• Soit un humain connecté directement sur le serveur TOMIX, ou sur une autre machine, depuis laquelle l'ORB CORBA est accessible sur le port choisi par TOMIX.

• Soit un process Linux tournant sur la machine elle-même

c Les objets du domaine.

Quelques nouveaux concepts : nous avions vu précédemment qu’une MIB est composée d’objets, eux même composés d’attributs. Ces objets sont en fait des instances de MOC. MOC (MIB Object Component) Ils sont caractérisés par un MOC, un nom d’instance, des paramètres leur donnant des droits, puis leurs attributs. Ces attributs peuvent être soit des attributs classiques soit des compositions d’attributs (Composite).

MIB MIB

Serveur SS7

Interface IDL create, get, set,

delete

Description des classes

SS7 nxx_mdl.xml

Backup Restore Contrôle de validité du contenu

CORBA

Format interprétable et modifiable par un

utilisateur final

Figure 10 – Schéma fonctionnel de haut niveau de 7MBR

MIB SS7






Figure 11 – Objets du domaine.

.

d Les use case.

Figure 12 - Diagramme des uses case.

Les use cases principaux sont « backup » et « restore ». Seul ces deux là sont détaillés dans ce document.

MIB SS7






Use-case : Backup : Ce use-case est un use-case principal. Une fois connectable, l'utilisateur choisi de sauvegarder sa MIB SS7. Il récupère le contenu de sa MIB dans un format lisible sans nécessité d'utilisation d'un logiciel particulier.

Pré-requis : La plateforme TOMIX doit être démarrée. Les MIBs activées. Déroulement standard : Le programme lit la MIB. Il en enregistre une copie sur la machine du client (utilisateur) ou directement sur TOMIX. Scénario alternatif : Une erreur intervient pendant la récupération. Le programme se déconnecte, l'utilisateur est informé. Une erreur se produit pendant la copie sur disque. Le programme se déconnecte, l'utilisateur est informé. Post-traitement : Les données concernant la MIB SS7 sauvegardées sont disponibles en un ou plusieurs fichiers sur la machine du client. En principe : - Un fichier script qui permet de mettre la MIB dans un état « Deletable« (exemple : tous les links d’un Link Set doivent être lockés pour pouvoir détruire le Link Set) . - Un fichier script qui permet de détruire la MIB - Un fichier script qui permet de créer la MIB - Un fichier script qui permet de retrouver l’état d’origine de la MIB au moment du backup (éventuellement unlock des links etc…)

Use-case : Restore :

Pré-requis : L'utilisateur possède des fichiers produits avec la méthode de backup, accessibles par son exécutable de restauration, éventuellement modifiés. Déroulement standard : Le programme valide la configuration du client, ainsi que tout le contenu de sa MIB SS7 locale, qu'il veut exporter. Le programme restaure la MIB sur la machine cible TOMIX.

MIB SS7






Scénario alternatif : Si la MIB n'est pas valide, le programme de restaure rien. Si une erreur intervient pendant la restauration (panne réseau), le serveur TOMIX sera instable. L'utilisateur sera prévenu et pourra recommencer. Post-traitement : La MIB SS7 locale est exportée sur le serveur et fonctionne. De nouveau, le trafic SS7 transite normalement si il transitait déjà au moment du backup.

2.2.2 Architecture fonctionnelle La détermination de l’architecture fonctionnelle est la première étape permettant de donner un aperçu du projet. Elle a un rôle très important dans l’analyse de faisabilité. En effet, chaque bloc fonctionnel identifié va faire l’objet d’une analyse. On pourra ensuite déterminer approximativement le coût de réalisation de chacun des modules.

a Découpe de haut niveau.

Figure 13 – Architecture fonctionnelle de haut niveau.

MIB SS7






Ce premier diagramme montre les fonctionnalités de 7MBR, pour une utilisation en fonctionnement.

b Découpe bas niveau.

7MBR ne doit pas se contenter d’interagir sur les MIBs, cette application doit être aussi capable de se générer automatiquement en fonction de la version de TOMIX sur laquelle elle doit fonctionner. Voici un second diagramme fonctionnel qui permet de renter davantage dans les détails de conception.

Figure 14 – Schéma fonctionnel détaillé.

On peut également visualiser les interactions entre les différents modules pour les traitements principaux.

MIB SS7






2.2.3 Analyse de faisabilité. Pour déterminer si une telle application est réalisable en respectant l’ensemble des contraintes données, j’ai opté pour la réalisation d’un prototype réduit. La méthode consiste en la détermination des différentes phases de réalisation logicielle et pour chacune de ces phases, j’ai réalisé en Python la prise en charge d’un cas simple. Nous allons maintenant détailler la réalisation du prototype de certains blocs logiciels.

a Adaptateur pour types de bases.

Pour le prototype de ce module, j’ai choisi d’utiliser le type Enum. Il s’agit d’un élément pouvant prendre une valeur parmi une liste de valeurs données. <xs:complexType name="Enum"> <xs:complexContent> <xs:extension base="typeType"> <xs:attribute name="name" type="xs:IDREF" use ="required"/> </xs:extension> </xs:complexContent> </xs:complexType>

Voici ce que contient le fichier de définition mdl.xsd à son sujet. On va maintenant la convertir en une classe Python. class Enum : def __init__(self, liste, value): self.admissible=liste if not self.__admissible(value): raise Error("Element \"%s\" not in %s in clas s %s" %(value, repr(liste), self.__class__.__name__)) def __admissible(self, value): return value in self.admissible

Pour notre utilisation particulière, il faut être capable de fabriquer automatiquement une telle classe. Il faut donc écrire un squelette capable de fabriquer ce type de classe. class EnumSkeleton : def __init__(self, name, liste): … def toPythonClass(self): return """from generation.generic.Enum import E num class %sEnum(Enum) : def __init__(self, value): Enum.__init__(self, %s, value) """ %(self.name, repr(self.liste))

On crée donc une classe capable d’écrire une classe qui hérite de celle du type de base Enum. Pour déterminer la méthodologie de réalisation de ce module, j’ai réfléchi à son utilisation finale. La fréquence d’appel à la réalisation de ce module est très faible. A priori le fichier xsd est figé et ne dois pas bouger, même entre différentes versions de TOMIX. Partant de ce constat, on peut en déduire qu’il n’est pas nécessaire d’automatiser cette procédure. Le dimensionnement a aussi sa part d’importance avant de prendre une décision finale. En parcourant le fichier xsd on constate qu’il existe une vingtaine de types de base. Une implémentation manuelle est donc justifiable et sera la plus rapide pour ce module.

MIB SS7






b Adaptateur de types réels.

Fréquence : à chaque évolution de TOMIX entrainant un changement de version. (Au pire tous les mois – nominal : deux fois par an). Dimensionnement : il existe environ un millier de classes et d’attributs à prendre en compte. Conclusion : ce traitement doit être automatisé. Pour commencer il faut être en mesure de garantir que le modèle xml que nous souhaitons intégrer est compatible avec les types de base précédemment définis. Pour cela on valide le fichier xml avec la feuille de style mdl.xsd utilisée pour la génération des types de base. # XML validation : from lxml import etree xmlDoc = open("../xml/n73_mdl.xml") xsdSchema = open("../xml/mdl.xsd") xmlDocTree = etree.parse(xmlDoc) xsdSchemaTree = etree.parse(xsdSchema) xmlSchema = etree.XMLSchema(xsdSchemaTree) isValid = xmlSchema.validate(xmlDocTree)

Maintenant nous allons fabriquer les classes décrivant toutes les Enum contenues dans le fichier xml choisi pour le prototype. Pour cela nous faisons appel aux classes de génération proposées en exemple dans la partie « adaptateur de types de base ». # XML parse import sys import lxml.etree as etree sys.path.append("../generation/skeleton") EnumSkeleton = __import__("EnumSkeleton") xmlDoc = open("../xml/n73_mdl.xml") tree = etree.ElementTree(file=xmlDoc) enumNodes = tree.findall('Enum') for enumNode in enumNodes : name = enumNode.get("name") liste = tuple([valueNode.text for valueNode in en umNode.findall("Value")]) print EnumSkeleton.EnumSkeleton(name, liste)

Prenons en exemple une Enum adm_state dans le fichier XML. # XML input : <Enum name="adm_state"> <Value>locked</Value> <Valu e>unlocked</Value> </Enum>

Voici le résultat python obtenu. # Result from generation.generic.Enum import Enum class adm_stateEnum(Enum) : def __init__(self, value): Enum.__init__(self, ('locked', 'unlocked'), val ue)

c Validateur de MIB (niveau logique – analyse sémantique).

Les classes générées sont de telle sorte que la validation sémantique soit incluse dans le constructeur de la classe de base. Le point important pour l’analyse de faisabilité est de tester les opportunités du langage python à intégrer dynamiquement des classes dont à un instant « t », on ne connaît que le nom.

MIB SS7






# class extern in file external.py in PYTHONPATH if not : add it on the fly : # sys.path.append(pathname) after import of modul e sys class external : def __init__(self, v="I am the external class"): self.v=v def __repr__(self): return repr(self.v) # class internal in the main file class internal : def __init__(self, v="I am the internal class"): self.v=v def __repr__(self): return repr(self.v) def main(): print internal() # affiche : "I am the interna l class" print globals()["internal"]() # affiche : "I am the internal class" external = __import__("external") MyClass = getattr(external, "external") print MyClass() # affiche : "I am the externa l class"

d Module de sauvegarde (utilisé par le module de lecture de résultats et le module de génération des scripts de restauration).

Pour le module de sauvegarde, l’idée est de proposer un format identique à celui que connaissent déjà les testeurs. On va donc s’orienter vers la rédaction automatisée de scripts capables de fonctionner avec le module de communication TOMIX en python qui envoi des commandes visant les différentes MIBs SS7. Ces commandes sont représentées par deux classes python : Command et Attributes . L’idée est d’utiliser une des particularités du langage python, pour tous les objets python, il existe une méthode __repr__() capable de rendre sous format texte du code source python permettant de reconstruire l’objet représenté. Apres avoir redéfini cette méthode pour les classes Command et Attributes , nous disposerons d’un format de sauvegarde identique aux scripts python existants pour configurer les MIBs. Exemple : print "ss7.cmdExeList_=%s\n" %(ss7.cmdExeList_) ss7.cmdExeList_=[SS7Common.Command("create", "pcmc_ fe", "pcmcI", 0, [SS7Common.Attribute("hostname", "STATION_I"), SS7 Common.Attribute("period", 30)]), …

e Messages d’erreurs.

Les messages d’erreurs doivent être parlant et suggérer une correction. A chaque message, on saura quelle commande pose problème, puis plus précisément quel attribut et enfin nous verrons les valeurs possibles de l’attribut. Exemple : Error, message : Element "activated" not in ('locke d', 'unlocked') in class adm_stateEnum

f Module de communication.

Le module de connexion sera le module existant. Son code ne sera pas retouché. La récupération des valeurs renvoyées par les commandes « get » n’étant pas prise en compte, j’ai développé un « handler »

MIB SS7






dédié à 7MBR capable de reconstruire des objets Attribute et Command avec le résultat des commandes « get ». Au moment de l’analyse de faisabilité, certaines parties ne seront pas inclues dans le prototype à cause de leur manque de maturité. Il s’agit de la partie permettant de gérer le cas des objets de MIB nécessitant un traitement particulier inclus dans le module « adaptateur de types réels », ainsi que la partie exploration des liens dynamiques entre les objets de la MIB. Cette fonctionnalité se situera dans le module « génération des scripts de restauration » (édition de liens). La validation des points mentionnés permet de démarrer la phase de réalisation du projet.

2.2.4 Déduction du planning prévisionnel.

Figure 15 – Planning prévisionnel avec avancement à la mi-juillet.

Le planning ci-dessus mentionne la livraison de base du projet. Parallèlement à cette version, il existe une version spécifique (pour TOMIX MD7 SP1), qui s’adapte régulièrement à la version de base, et contient en plus la gestion des cas particuliers. Les cas particuliers demandant les apports spécifiques d’experts SS7, il est difficile de les planifier. Ils évoluent au fur et à mesure en fonction des besoins de chaque couche SS7. Les tests planifiés ici sont les tests officiels. Chaque version possède en amont ses propres scénarios de tests. Plus de détails sont données dans la partie « Méthodologie de développement ».

2.2.5 Méthodologie de développement. La méthode de développement que j’ai choisie est itérative (cycle en spirale). Chaque étape du développement est découpée en plusieurs itérations. Le but étant de faire converger l’ensemble des itérations vers un produit fiable et abouti. Pour la première livraison, chaque fonctionnalité a été découpée en un cycle en V de courte durée. (ex : génération de la librairie : 1 mois ; réalisation du module de backup : 3 semaines). L’ensemble des modules une fois traités et assemblés puis replacés dans le contexte du cycle en V général à la première version, on peut passer à la seconde itération générale.

MIB SS7






Figure 16 - Cycle V

La seconde itération comprend en plus la gestion des cas particuliers. Cette gestion a été découpée en autant de sous versions que le SS7 comporte de couches. Chaque couche du SS7 comporte ses propres cas particuliers. (entre zéro et trois avec une moyenne de 1).

Figure 17 – Développement itératif en spirale.

Figure 18 – Les itérations des deux branches de 7MBR

D’autres itérations succéderont à ces deux premières, mais plus sous ma responsabilité. Le projet passera en effet en branche de maintenance.

MIB SS7






3 Déroulement du projet et gestion des problèmes rencontrés.

3.1 Concepts techniques mis en œuvre dans le projet.

3.1.1 Le compilateur de compilateur. On décrira sous ce nom la partie capable de générer les fichiers python constituant la librairie SS7. Une analogie est faite avec un compilateur de compilateur pour sa finalité. En effet le code généré est capable de prendre en charge un langage de commandes ss7 pour le transformer en une MIB SS7 exécutable. Cette partie étant celle qui détermine le plus l’architecture globale du projet, nous verrons ici le diagramme des packages du projet.

Figure 19 – Diagramme des packages de 7MBR.

MIB SS7






On remarque sur le schéma trois catégories de package. Le package permanent est celui qui va contenir entre autre le compilateur de compilateur. La librairie produite par le compilateur de compilateur est qualifiée de package auto – généré. Seule la partie mdltopy::generated concerne la librairie. Regardons maintenant un extrait de fichier xml à partir desquels nous générerons la librairie. <Moc Title="PCM coupler device" name="pcmc_fe"> <Container name="root"/> <Inheritance name="generic"/> <ConfigurationAttributes> <Attribute Title="Host Name" UsageProfile="stand ard" name="hostname"> <Type xsi:type="String"> <Max>31</Max> </Type> <Access>get</Access> <Use>mandatory</Use> </Attribute> <Attribute Title="Observation period" name="peri od"> <Type xsi:type="Integer"> <Range> <Min>1</Min> <Max>10000</Max> </Range> </Type> <Access>get</Access> <Use>optional</Use> <Default>30</Default> </Attribute> </ConfigurationAttributes> <ResourceStates> <Attribute Title="L2 session reference" name="ic s_ref_l2"> <Type xsi:type="Integer"/> <Access>none</Access> <Use>forbidden</Use> </Attribute> <Attribute Title="Obs session reference" name="i cs_ref_obs"> <Type xsi:type="Integer"/> <Access>none</Access> <Use>forbidden</Use> </Attribute> </ResourceStates> </Moc>

Le Moc est l’unité de base pour la génération de la librairie. Lors d’une commande ss7, les Moc sont les objets manipulés. Une MIB contient des instances de Moc. Ce sont en fait des containers d’attributs pouvant être récursif. A l’intérieur d’un Moc on rencontre une balise Container qui indique le niveau de récursivité de la structure. On trouve ensuite une balise Inheritance , qui renvoie à des attributs définis communément pour plusieurs Moc. Ensuite on trouve les attributs spécifiques du Moc séparés en deux catégories : les attributs de configuration (ConfigurationAttributes ), puis ceux de description de l’état des ressources (RessourceStates ).

MIB SS7






Dans les Attribute , on rencontre des balises définissant le type de base tel que décrit dans le fichier de définition xsd, des valeurs signifiant des contraintes supplémentaires telles qu’une plage de valeurs autorisées ou encore un nombre d’occurrences pour lequel cet attribut doit être présent à l’intérieur du Moc. On trouve aussi des restrictions d’accès qui indiquent la visibilité, les périodes d’existence des Attribute , ainsi que les opérations qu’il est possible d’effectuer dessus. Le rôle de la partie compilateur de compilateur de 7MBR est donc de convertir l’ensemble des types définis par la structure des fichiers xml en une librairie de types personnalisés en Python. Si je parle de compilateur de compilateur et non de simple compilateur, c’est parce que la librairie produite en sortie aura quant à elle le rôle d’un compilateur. Il ne s’agit pas ici de générer un byte code ou autre langage machine, mais de générer un jeu de commandes valides pour une MIB SS7 donnée. Afin de ne pas prendre en charge la partie analyse syntaxique d’un compilateur ordinaire, j’ai choisi d’exploiter la capacité de python à charger du code dynamiquement. Ainsi si python est capable de charger un code source, c’est que ce code est syntaxiquement correct. Une des principales difficultés de ce module est la présence parmi les attributs d’un type particulier. Le type lien vers un autre attribut (LinkTo ). La difficulté a été résolue en intégrant pour ce type une nouvelle couche d’héritage. J’ai retrouvé une difficulté comparable pour les objets de type Composite qui sont des pointeurs sur des collections d’objets.

3.1.2 Le compilateur généré (librairie python). La particularité de cette librairie, c’est que chacun des objets qui la composent est auto validant. Chacun de ses objets a pour responsabilité la validation de l’ensemble des paramètres d’entrée. Ils sont également en charge de la génération de messages d’erreurs pertinents offrant la possibilité de localiser rapidement le lieu de l’erreur dans le fichier de commande en cours de compilation. Cette librairie prise dans son ensemble est responsable de la phase analyse sémantique. Elle est aussi responsable de la possibilité pour chaque Moc de se représenter sous forme de commandes ss7 en fonction de l’action choisie, à savoir prepareDelete , delete , create ou encore afterCreate . Exemple de message d’erreur produit. CompileError exception raised in class "creation_da te" while parsing "SS7Common.Command("set", "l2prof_fe", "L2P1", 0, [ SS7Common.Attribute("creation_date", '1186 579493fgh'), ..... SS7Common.Attribute("trans_cong_abat", 30) , SS7Common.Attribute("max_msu_retrans_n1", 64), SS7Common.Attribute("max_koct_retrans_n2", 16)])" unmatching value is '1186579493fgh' message : Your value '1186579493fgh' is not in 0 - 2147483647 range

Pour comprendre l’architecture du compilateur, voici un diagramme de classe partiel. Il montre l’architecture globale appliquée à un exemple. L’exemple choisi concerne le domaine n73 . Ce domaine contient plusieurs Moc, je vous montre à titre d’exemple le Moc loadshare . Ce Moc ce compose également de multiples attributs. Au niveau architectural, les plus complexes sont les attributs de type Composite. Sur le diagramme vous avez donc seulement l’attribut choice qui est un Composite .

MIB SS7






Figure 20 – Diagramme de classes partiel du compilateur.

MIB SS7






3.1.3 Manipulation de code dynamique. Si l’on poursuit l’analogie entre 7MBR et un compilateur, on a vu jusque ici que l’analyse lexicale était effectuée directement par python, l’analyse sémantique est prise en charge par la librairie. Nous n’avons pas encore abordé la question de l’édition de liens. Si la librairie est capable de générer pour chaque Moc le jeu de commandes qui lui correspond en fonction de l’action choisie, il n’a pour l’instant été mentionné de problème d’ordonnancement. Nous avions vu précédemment qu’un des types d’attributs possible est un lien. Ces liens sont en fait des pointeurs sur d’autres instances de Moc. Dans une MIB SS7, les Moc instanciés doivent être valides aux yeux de la norme, mais les Moc vers lesquels ils pointent doivent exister, et inversement, il est impossible de détruire un Moc si il y a d’autres Moc qui pointent sur lui (cf C 2 ). Une première idée a été de prendre la norme pour regarder les relations possibles entre les différents Moc. Mais cette approche n’est pas réalisable car la structure des MIB permet des relations récursives et non ordonnées au niveau des Moc. La solution fut donc de travailler dynamiquement au rang des instances et non des classes. Pour mettre en place cet ordonnanceur, une petite étude algorithmique s’est imposée. Algorithme : Pour chaque Moc du domaine et de l’ifap donné : Préparer liste des dépendances Liste ordonnée = tous les Mocs n’ayant pas de dépen dances Pour chaque Moc restant : Si toutes ses dépendances sont dans la liste ordo nnée : Alors l’ajouter à la fin de la liste ordonnée, le retirer de la liste initiale Répéter tant que l’algorithme trouve des mocs à ajo uter Les mocs restants sont ajoutés à la fin de la liste (dépendances inter domaines)

La première opération de recherche de dépendances est coûteuse. On l’effectue donc une seule fois en travail préparatoire. Ainsi on limite sa complexité à un O(n). Ensuite on initialise la liste ordonnée avec tous les cas évidents (un parcours de tous les moc suffit pour les détecter) – O(n) également. L’algorithme de recherche commence. On peut le comparer à celui du tri à bulles. Au pire cas seul un moc est trouvé à chaque itération. La liste diminue alors de la sorte : n + (n-1) + (n-2) + … + 2 + 1, ce qui est le résultat connu de n(n+1)/2 soit O(n²) pour la complexité pire cas. Dans la pratique on peut approximer la complexité nominale sous un autre angle. L’ordre des moc est prédéterminé lors de la configuration de 7MBR. Ainsi les cas connus de dépendances entre les mocs sont positionnés de telle sorte que le moins de liens possibles restent croisés. En prenant en compte cette aide technique on remarque donc qu’à chaque itération, la moitié des mocs en attente arrivent à être classés. La liste diminue ainsi : n + n/2 + n/4 + n/8 + … soit une complexité en moyenne de O(n log2 n). Cette complexité est globalement mauvaise mais est atténuée par une excellente complexité spatiale en O(n). En effet, on ne manipule que des pointeurs, pas de duplications des objets. En revanche les études pratiques ont montré que l’algorithme était bien suffisant pour le nombre d’objets à traiter. Pour le plus gros domaine testé, nous avons 68 mocs en entrée pour un total de 170 itérations, ce qui reste

MIB SS7






parfaitement contenu par O(n log2 n). Nul besoin d’améliorer cet algorithme au risque de le rendre illisible, ce qui compliquerait le travail de maintenance par la suite. Voici un exemple pour le domaine s7s. Les traces sont obtenues avec le mode verbeux du compilateur 7MBR – BuildRestoreFiles.py MOC : SCCP/RAP1_10_SSN10 --> ['SCCP/LINKAGE1_10', ' SCCP'] MOC : SCCP/LINKAGE1_21 --> ['SCCP'] MOC : SCCP/RAP1_14_SSN10 --> ['SCCP/LINKAGE1_14', ' SCCP'] MOC : SCCP/LINKAGE1_14 --> ['SCCP'] MOC : SCCP --> [] MOC : SCCP/LINKAGE1_10 --> ['SCCP'] MOC : SCCP/LAP50 --> ['SCCP'] totalTransfert : 3 parmi une liste de 6 totalTransfert : 2 parmi une liste de 3 totalTransfert : 1 parmi une liste de 1 totalTransfert : 0 parmi une liste de 0

Nous avons ici 6 mocs à trier, et un total de 10 itérations (6 + 3 + 1). On reste encore majoré par O(n log2 n). On retrouve ci-dessous l’ordre trouvé pour la destruction des Mocs u domaine n7s (extrait du fichier de delete généré). # n7s\ SS7Common.Command("delete", "sccpaccesspoint", "SCC P/RAP1_10_SSN10", 0, []), \ SS7Common.Command("delete", "sccpaccesspoint", "SCC P/LAP50", 0, []), \ SS7Common.Command("delete", "sccplinkage", "SCCP/LI NKAGE1_10", 0, []), \ SS7Common.Command("delete", "sccpaccesspoint", "SCC P/RAP1_14_SSN10", 0, []), \ SS7Common.Command("delete", "sccplinkage", "SCCP/LI NKAGE1_14", 0, []), \ SS7Common.Command("delete", "sccplinkage", "SCCP/LI NKAGE1_21", 0, []), \ SS7Common.Command("delete", "sccp", "SCCP", 0, []), \

3.1.4 Résolution des cas particuliers. Comme vu dans la partie traitant de la méthodologie de développement, la gestion des Moc nécessitant une gestion individualisée est traitée de manière indépendante sur un concept simplifié au maximum. Vous avez pu jusqu’ici voir en détail le fonctionnement de la librairie générée, contenue dans le package mdltopy::generated . Pour gérer les cas particuliers, il faut créer manuellement une architecture équivalente dans le package mdltopy::overrided . A l’intérieur de ce package on recrée des classes Moc portant le même nom que les classes Moc que l’on veut surcharger. Ces nouvelles classes héritent des Moc pour lesquels on souhaite une gestion particulière. Dans les nouvelles classes, il suffit de surcharger les méthodes issues de l’interface mdltopy::base::action .

MIB SS7






Figure 21 – Diagramme de classe du mécanisme de gestion des cas particuliers.

Grâce aux technologies d’import dynamique offertes par python, on importe si elles existent les classes contenues dans le package mdltopy::overrided . Si elle n’existent pas on utilise directement les classes équivalentes du package mdltopy::generated . Les classes surchargées doivent jouer sur les méthodes de l’interface action pour modifier le comportement des MIBs en vue de l’obtention de commandes SS7. import mdltopy.generated.n7s.sccp.sccp import mdltopy.base.Access import ss7.utils.SS7CommonSource import mdltopy.base.AttributeDescriptor class sccp(mdltopy.generated.n7s.sccp.sccp.sccp): def getAfterCreateCommand(self): defaultCreateCommand = mdltopy.generated.n7s.sccp.sccp.sccp.ge tCreateCommand(self)[0] tmpAttrList=[]

MIB SS7






for attr in defaultCreateCommand.attrList : if self.knownAttributes[attr.name].acce s == mdltopy.base.Access.set: tmpAttrList.append(attr) return [ss7.utils.SS7CommonSource.Command(" set", d efaultCreateCommand.classe, d efaultCreateCommand.objName, d efaultCreateCommand.ifap, t mpAttrList)]

Voici l’exemple de la classe sccp . Cette classe sccp se trouve dans le package mdltopy::overrided::n7s::sccp et elle hérite de la classe sccp du package mdltopy::generated::n7s::sccp . Ici le problème technique se rencontre au moment de la re-création du Moc sccp dans la MIB SS7. Cet objet présente la particularité d’être indestructible. Si il existait dans l’ancienne MIB, la commande create sur cet objet échouera systématiquement. La seule possibilité pour modifier et ajouter des attributs est de passer par une commande set en deuxième passe après la création de la MIB. Ici, on limite les attributs du Moc pour la commande set à ceux qui possèdent l’autorisation : leur paramètre Acces doit valoir « set ».

3.2 Manipulation et intégration du projet. Nous allons voir dans cette rubrique, les pratiques indispensables à mettre en œuvre pour la réalisation de ce projet.

3.2.1 Clearcase. Clearcase est un outil dit de gestion de configurations. Dans son utilisation primitive, c’est un outil de gestion de code source semblable à un serveur CVS ou SVN. Son plus est la possibilité de créer des configurations pour l’édition de projets versionés. Cela ce fait grâce à un utilitaire de makefile : clearmake et à des outils de création de configuration que l’on peut intégrer. J’ai déjà dû me familiariser avec clearcase au cours de mes deux premières années, mais uniquement pour une utilisation basique (gestion itérative de fichiers de code source). Cette année, je suis également en charge de l’intégration de mon projet dans les branches de développement et maintenance TOMIX. Cette différence vient du fait que le projet de cette année est livrable sous forme directement intégrée à la plateforme TOMIX. Les années précédentes, mon projet était externe à TOMIX, dans le sens où il fonctionnait sur une machine différente de TOMIX, puis se connectait à un serveur qui lui savait se connecter à TOMIX ; pas de liaison directe avec TOMIX ; pas d’évolution contrainte par celles de TOMIX ; le projet était totalement indépendant. Politique de développement : il existe pour l’équipe TOMIX des règles liées au développement de la plateforme TOMIX. En tout temps, TOMIX possède une branche de projet portant le nom de main_stream. Cette branche est le passage obligatoire pour tout nouveau développement visant à terme la plateforme TOMIX. Parallèlement à cette branche il existe en ce moment deux projets particuliers en cours de développement. Ces deux projets récupèrent les développements en fonction de leurs besoins dans la branche main_stream. Les développements particuliers visant uniquement ces projets sont quant à eux effectués dans la branche de projet correspondante. Parallèlement à ces branches de développement, TOMIX conserve les branches des projets déjà en cours d’exploitation. Dans ces branches on pourra y développer des correctifs, où y faire fusionner des nouveaux développements issus

MIB SS7






de la branche main_stream. Parmi ces projets déjà livrés, on note le projet RL42 MD7 SP1 pour lequel 7MBR doit fonctionner.

Figure 22 – Branches de développement clearcase.

3.2.2 Le makefile. Le makefile a pour rôle de générer les binaires qui seront par la suite exportés sur TOMIX durant la phase d’intégration. Il sera appelé par le makefile global de TOMIX via la commande clearmake fournie par clearcase. Dans le cas d’une application python, il n’existe pas de fichiers binaires. Les fichiers sources pourront directement être interprétés par TOMIX. En revanche une partie de 7MBR étant dynamique, il faut générer la librairie et les propriétés au moment du make. properties: cd ../properties && python createMibProperties.py @mkdir -p $(LOCAL_SRC)/ss7/properties @mv $(LOCAL_PROPERTIES)/mib_properties.py $(LOCAL_SRC)/ss7/properties/mib_properties.py @chmod +x $(LOCAL_SRC)/ss7/properties/mib_propertie s.py @mv $(LOCAL_PROPERTIES)/domain_properties.py $(LOCAL_SRC)/ss7/properties/domain_properties.p y @chmod +x $(LOCAL_SRC)/ss7/properties/domain_proper ties.py @touch $(LOCAL_SRC)/ss7/properties/__init__.py

La cible properties traduit la configuration 7MBR entrée par l’utilisateur en un module python.

MIB SS7






build_directories: cleartool startview $(XMLVIEW) && \ cleartool setview -exec "python $(LOCAL_SRC)/genera teLibrary.py -v --xml-directory $(XMLDIR) --properties-directory $(LOCAL_SRC)/ss7/propert ies --generated-directory $(LOCAL_SRC)/mdltopy/gene rated" $(PROJECT_VIEW)

La cible build_directories prépare les packages python qui vont accueillir la librairie. generate_all: cleartool startview $(XMLVIEW) && \ cleartool setview -exec "python $(LOCAL_SRC)/genera te_all_library.py --verbose --xml-directory $(XMLDIR) --generated-directory $(LOCAL_SRC)/mdltopy/gene rated" $(PROJECT_VIEW)

La cible generate_all fabrique les fichiers python de la librairie. Pour la phase de développement, afin de faciliter le transfert des fichiers générés vers TOMIX, j’ai ajouté une directive install : RSYNC_OPTS = -v --recursive --delete --rsh=ssh --ti mes upload_src: @rsync $(RSYNC_OPTS) $(LOCAL_SRC)/ $(USER)@$(FTP) /$(PROJECT)/src upload_doc: @rsync $(RSYNC_OPTS) $(LOCAL_DOC)/ $(USER)@$(FTP) /$(PROJECT)/doc upload_properties: @rsync $(RSYNC_OPTS) $(LOCAL_PROPERTIES)/ $(USER) @$(FTP)/$(PROJECT)/properties

Cette directive permet d’optimiser le transfert de la machine de conception vers les maquettes TOMIX.

3.2.3 La phase d’intégration. La phase d’intégration consiste en la fabrication de package TOMIX installables sur la plate-forme. La première étape consiste en la rédaction d’un fichier xml (Developpement Descriptor) qui décrit pour chaque répertoire produit par le makefile la position des binaires sur la plateforme TOMIX. Ensuite la commande tpkg (tomix package) fabrique le fichier installable (rpm). /* Fabrication du package à partir d’un descripteu r */ cd /oam_ss7/DeveloppementDescriptor tpkg –b /local/ohargoaa/tsttpkg –version ta06a.005. 0000 –release 00 –package toam-ss7-python –des `pwd`/tomas-oam-ss7-server.xml /* lister le contenu du rpm */ rpm –qpil toam-ss7-python-ta06a.005.0000.x86_pentiu m3.rpm /* installation sur la machine */ rpm –i -nodeps toam-ss7-python-ta06a.005.0000.x86_p entium3.rpm

MIB SS7






3.3 Tests du projet.

3.3.1 Les FQM (Fonction Qualité Mesure). Ces spécifications sont utilisées pour définir le niveau de qualité du projet.

a Backup.

• Lisibilité : Un habitué des commandes BUI, en possession d’un fichier de backup, ne doit pas avoir besoin d’explication pour interpréter le fichier comme il l’aurait fait avec des commandes BUI.

• Rapidité : Le temps d’exécution doit être inférieure à 4 minutes. • Simplicité : pour démarrer le backup, l’utilisateur doit pouvoir se contenter de l’aide fournie.

b Modify.

• Simplicité : La qualité simplicité de la fonction modify évolue avec la qualité lisibilité de la fonction backup.

c Compile backup.

• Messages d’erreur explicites : Le problème doit toujours pouvoir être localisé avec les informations du mode verbeux de l’outil python qui assure la fonction fabrique des fichiers de restauration.

d Restore.

• Rapidité : Le cahier des charges demande un temps de blocage inférieur à 4 minutes. Le passage des 4 scripts générés par compile backup doit donc durer moins de 4 minutes.

• Qualité des messages d’erreur : on doit retrouver les mêmes messages que lors de l’utilisation du BUI.

e Update source code.

• Accessibilité : La méthode de gestion des cas particuliers doit être compréhensible d’un programmeur habitué à un environnement objet, à condition qu’il s’inspire des exemples et qu’il ait eu par lui-même ou par une entité extérieure, l’équivalent d’un cours de programmation python d’environ 2 heures. La lecture d’un tutoriel d’introduction doit être suffisante.

3.3.2 Automatisation de la procédure. La procédure de test consiste en une analyse de deux backups consécutifs avec une phase de restore complète. La difficulté de l’automatisation de cette procédure est de se limiter à comparer ce qui est comparable. Une première barrière technologique, est liée au langage python lui-même. Tout étant objet, on ne sait pas forcément les méthodes utilisées pour effectuer les comparaisons. Par exemple pour comparer deux tableaux, python compte le nombre d’éléments, puis les compare deux à deux. Le fichier de backup est composé en majorité de traitements issus de tables de hachages. L’ordre d’apparition des éléments n’est pas garanti. Pour comparer les Moc entre eux, on doit être capable de les trier pour les présenter deux à

MIB SS7






deux. Pour ce faire nous devons trouver un algorithme de tri selon trois critères : le nom de la classe, le nom d’instance et l’ifap. Pour garder une complexité correcte O(n log2 n), on juxtapose bout à bout les trois critères de comparaison et l’on compare ce critère composé. Une fois cette difficulté franchie, il faut éliminer de la comparaison les attributs automatiquement générés, tels que les dates de création. Pour les attributs de configuration, pas de problèmes particuliers, mais la gestion des attributs d’état des ressources doit être prise en compte. N’étant pas en mesure de connaître la liste des attributs comparables, j’ai choisi de laisser à la libre interprétation des testeurs ces attributs. Si un testeur constate ce type de différences, il devra dire si il considère cette différence comme un échec ou comme un cas normal.

Figure 23 – Méthode de test

3.3.3 Les différents états testables du projet.

a Test de l’application de test.

Pour tester l’application de test, on effectue un backup puis, on clone le fichier de backup. La comparaison de ces deux fichiers ne doit pas remonter de différences. Une fois cette étape franchie, sur une machine à trafic SS7 constant, effectuer deux backups successifs. La comparaison ne doit en aucun cas manifester d’erreurs sur les attributs de configuration. Pour les attributs d’état, il faudra une fois de plus en juger au cas par cas. Le nombre d’erreur doit être faible.

b Test du backup seul.

Le test du backup peut reprendre le test de l’application de test. Sinon si l’application de test n’est pas disponible il est possible d’utiliser le GUI ou le BUI . Mais la quantité de travail devient trop importante. On peut alors choisir de ne comparer que certains attributs de certains Moc.

MIB SS7






c Test du backup restore.

Pour ce test, il faut utiliser la procédure automatique telle que présentée dans la section précédente.

d Test du modify.

Procéder de la même manière que pour le backup restore, puis localiser manuellement les différences souhaitées.

3.4 Résultats du projet.

3.4.1 Rétro compatibilité. Dans la partie présentation du projet, j’ai introduit les différents clients. Notre client majoritaire est celui qui développe le ngHLR au dessus de la plate-forme TOMIX. Pour satisfaire sa demande, 7MBR prend en charge les différentes versions TOMIX à partir de la version RL42 – MD7 SP1, version de TOMIX qui équipe la moitié des stations du ngHLR. Son souhait de faire fonctionner 7MBR sur des versions antérieures de TOMIX n’a pas pu être réalisé. Nous avons jugé que les mises à jour nécessaires sur ces versions étaient trop importantes pour ne pas justifier un changement de version complet. Le support de python n’était pas encore disponible sur les anciennes plateformes. Afin d’assurer la rétro compatibilité MD7 SP1, les parties exécutables du projet, ont été développées pour la version 2.0 de python. Cette contrainte m’a été assez déroutante, puisque je possède une pratique de python dans ses versions plus récentes. En effet cette version 2.0 présente de nombreux comportements assez surprenants dont certains proches d’être définis comme bugs. On peut noter notamment une mauvaise gestion de la portée des variables ainsi qu’un comportement atypique du mot clé global .

3.4.2 Fonctionnalités dont le niveau de fiabilité est satisfaisant. En date de rédaction de ce document (mi-aout 2007), l’état d’avancement de 7MBR est concluant. Dans son ensemble le projet fonctionne et répond au cahier des charges. Le projet est capable de générer une librairie python de description SS7 pour les versions MD7 SP1 et supérieur, sous réserve de non modification de la feuille de style XSD de description des types de base rencontrés dans les MIB SS7. Le projet est capable d’effectuer une sauvegarde et restauration pour tous domaines du SS7 et de SIGTRAN. A ce jour il a été testé sur des plateformes TOMIX 2 et 4 stations (cf B 3 ). La procédure de test utilisée est celle utilisant le transfert manuel des fichiers vers TOMIX. La partie packaging et intégration n’a pas encore été soumise à test. Le bilan sur l’ensemble du projet est d’ores et déjà très positif, à un mois de la fin officielle du projet.

MIB SS7






3.4.3 Propositions d’améliorations. Voici quelques propositions d’évolution pour 7MBR. TOMIX évoluant, des solutions impossibles aujourd’hui deviendront envisageables dans les futures version. En effet de version en version, TOMIX tente de simplifier les procédures de création et destructions des MIB

• Partie compilation : Au niveau du contrôleur d’admission des objets Moc, il serait envisageable d’ajouter une gestion du trop perçu d’attributs. Il s’agit d’un traitement techniquement simple à réaliser en python, mais aujourd’hui il existe une inconnue, peut-il y avoir plusieurs attributs d’un même type passés successivement les uns après les autres.

• Partie utilitaire de test : Il faut au niveau de l’application de test être capable de faire un

traitement particulier à l’instar de celui effectué sur certains Moc. L’idée étant de définir des configurations testables, en étant capable d’écarter du test dynamiquement les attributs qui selon l’état d’activité de la machine cible, sont forcément différents après une phase de restauration.

• Evolution générale : Les futures versions de TOMIX posséderont en standard une livraison

python 2.4. Le code actuel fonctionnera sans difficulté sur une telle version, puisque python assure la compatibilité ascendante. Mais il pourrait être utile de formater le code de 7MBR aux conventions de codage python 2.4, pour y gagner en lisibilité, et ainsi faciliter la maintenance.

Bilan et résultats personnels






4 Bilan de l’année de formation et du cycle d’ingénieur.

4.1 Mes craintes après une grande absence. Dans le cadre de la formation dispensée dans l’école Ingénieurs 2000, le rythme de l'alternance est de six mois de cours suivis de six mois en entreprise, le tout répété pendant trois années. Cela suppose donc des absences d'un semestre dans l'entreprise qui nous accueille. Or, le marché des Télécom évolue de plus en plus vite. Pour être compétitif, le groupe Alcatel-Lucent ne cesse d’innover ce qui lui permet de rester à la pointe de la technologie. Ainsi, pour le service TOMAS, la durée de vie des projets généraux, est volontairement fixée à six mois. Il devient donc difficile de se projeter sur des périodes de longue durée. Amorcée en avril 2006, la fusion avec l’équipementier américain Lucent, devait se produire pendent mon absence. Cette fusion devait être l’occasion d’un renouveau et d’une réorganisation au sein des équipes d’Alcatel-Lucent. Un doute planait sur la composition de l’équipe TOMIX. Par chance, le projet 7MBR m’avait été réservé dès décembre 2006. Ce projet étant nouveau, la composition de l’équipe TOMIX au moment de mon retour de séquence académique ne devait pas influencer sa réalisation. Il se trouve que l’équipe TOMIX ne perdra pas d’effectifs avec le plan social et que je retrouverai l’ensemble de mes repères dès mon retour. Ceci étant bien effectivement un gain de temps considérable, ce qui me permet pour chaque besoin de connaître directement mon interlocuteur, situation favorisant les échanges rapides et efficaces.

4.2 Un retour rapide dans le vif du sujet. Cette troisième année professionnelle se place sous le signe de l’action. Le projet de cette année est l’objet d’une demande extérieure. Je ne développe plus uniquement pour le service de R&D TOMIX, mais pour des clients de la plateforme TOMIX. Ce projet s’inscrit donc dans une véritable politique commerciale et managériale. Cette fois-ci, la date de rendu de projet est directement prévue par les managers ce qui instaure une pression réelle. Mais les deux années précédentes ont été formatrices : elles m’ont appris à ne pas me précipiter. Une partie importante de ce nouveau projet sera l’écoute. Le délai étant court, l’étape du cahier des charges sera extrêmement sensible. En effet, on ne pourra se permettre aucune erreur à ce niveau, car nous n’aurions pas le temps de rectifier le tir une fois le problème détecté, sans entraîner un report sur la livraison. Il faut donc que je m’organise efficacement en travaillant sur les phases d’analyse afin de prévoir les points techniquement délicats, pour trouver des solutions sans tomber dans des impasses technologiques. Bien que l’effectif n’ait pas été réduit dans le service TOMIX, il faudra assurer un rendement maximal malgré des contraintes extérieures liées à un climat social déstabilisant et un déménagement de site causant une désorganisation du service.







4.3 Une organisation délicate. Le service TOMIX dispose actuellement d’une organisation matricielle. Ceci présente l’intérêt de se partager les ressources humaines par technologies plutôt qu’uniquement par projets. Ainsi une ressource convoitée peut être disponible par plusieurs chefs de projet. Notre période d’alternance fait que nous sommes en entreprise sur des périodes très utilisées pour la pose de congés (mai et juillet-août). Cette organisation va permettre de contrer le manque de ressources de ces moments creux. Il se trouve que pour un projet comme le mien visant un domaine très précis, les ressources sont rares. J’ai été directement affecté par le manque de ressources dans le service. Il m’a sans cesse fallu réévaluer mon planning en fonction des absences des différentes personnes. Ceci m’a parfois imposé d’effectuer des travaux préparatoires à des taches devant commencer une fois d’autres terminées. Ces artifices m’ont permis de tenir un avancement global dans les temps, en jouant sur l’agencement entre les tâches.

4.4 La satisfaction d’un contrat rempli. Le projet qui m’a été confié est très complet. Les phases d’analyse, de développement et de tests sont sous ma responsabilité. Au cours de cette dernière année, mon responsable m'a beaucoup moins guidé, ce qui m’a permis plus de libertés. J’ai donc dû être davantage acteur de ma gestion du temps sur mon propre projet. A quelques semaines de la fin de mon apprentissage, je sais que ce dernier projet est réussi et sera utilisé. Cela à été rendu possible grâce aux méthodes de génie logiciel enseignées lors de la dernière séquence académique, ainsi qu’à ma connaissance du service TOMIX, aussi bien sur le plan technique que sur le plan humain. Finalement, après quelques périodes de doutes, j’ai réussi à combler les retards pris sur mon planning personnel, pour arriver à tenir les objectifs fixés en début de période.

4.5 Mon évolution vers le métier d’ingénieur. Au fil de mes trois années d’apprentissage, mon regard sur le métier d’ingénieur a pris du recul. Je suis arrivé dans cette branche d’étude avec un diplôme de technicien supérieur qui me procurait une expérience technique me permettant d’évoluer aisément dès mon arrivée chez Alcatel-Lucent. Peu à peu mes préoccupations se sont orientées davantage vers la gestion de projet, ainsi que la prise en considération des différentes demandes. Petit à petit, j’ai appris à synthétiser les besoins, à devenir capable de déterminer précisément les durées de chaque tâche, à m’intégrer dans des équipes d’ingénieurs pour mettre en commun nos travaux, à être capable de déterminer les limites de mon activité pour optimiser les temps de réalisation de chaque tâche, tout ceci grâce à la connaissance du rôle de chaque ingénieur de l’équipe. Sur le plan technique, mes qualités d’ingénieur ont été mises à l’épreuve en nécessitant une grande adaptabilité. En effet, cet emploi requiert des aptitudes liées au domaine de la télécommunication, ainsi que des aptitudes à travailler sur des grands systèmes. Ces aptitudes ne sont pas enseignées dans le cadre de la séquence académique, et ce qui fait qu’aujourd’hui sur le plan technique mes compétences se rapprochent de celles d’un véritable ingénieur, c’est que j’ai réussi à m’adapter rapidement à un







environnement technique très complet, aptitudes que je conserverai pour m’intégrer éventuellement à d’autres secteurs d’activités que les télécommunications. Sur le plan de la communication, j’ai eu en trois ans deux projets différents, ce qui m’a contraint à une adaptation dans deux équipes d’ingénieurs différentes. Mais ces projets ont également demandé une part importante de gestion, notamment de détermination de planning prévisionnel tout en conservant l’idée que ces plannings seraient susceptibles d’être modifiés dynamiquement en fonction de paramètres externes. Il m’a également fallu connaître les techniques de reporting d’activités et ce, en particulier lors des réunions d’avancement. J’ai eu aussi à gérer des clients différents pour un même projet et à déterminer l’ensemble des besoins une solution réalisable dans les délais impartis satisfaisant les besoins de chacun. C’est grâce à l’utilisation de l’ensemble de mes connaissances techniques, ainsi qu’à la mise en pratique d’une gestion complète de projet, que je prouve mon évolution du stade de technicien supérieur à celui d’ingénieur.

Conclusions






CONCLUSION A l’issue de cette dernière année d’apprentissage, j’ai encore beaucoup appris. Tout d’abord, l’environnement technique était nouveau pour moi. J’ai pu alors découvrir les techniques de configurations SS7, et continuer mon apprentissage des cycles de vie de projets logiciels. La formation académique m’a offert les connaissances de base que j’ai régulièrement mises en pratique lors des séquences en entreprise. Ainsi grâce à ce double apprentissage (scolaire + professionnel), j’ai pu mener à bien les projets qui m’ont été confiés, ce qui m’a permis d’acquérir une maturité professionnelle. Le domaine d’application du projet : le monde des télécommunications est très éloigné de ce qui est vu dans la séquence académique. Grâce à l’adaptabilité que j’ai su développer, je me sens désormais prêt à aborder sereinement des domaines d’activités variés. Les deux plus grandes notions que j’ai développé ces 3 années durant, sont l’autonomie et l’adaptabilité, critères importants pour un poste d’ingénieur. Aujourd’hui je n’ai pas peur de dire que ces 3 ans m’ont fait évoluer de la fonction de technicien supérieur vers celle d’ingénieur, à laquelle je prétends répondre fonctionnellement.

Glossaire






GLOSSAIRE 2G / 3G Deuxième génération / Troisième génération du téléphone mobile.

2G = GSM 3G = UMTS Telecom

7MBR SS7 M IB Backup Restore Nom donné à mon projet de 3ème année.

Alcatel

API Application Programming Interface Interface de programmation qui définit la manière dont un composant informatique peut communiquer avec un autre.

Info

ATM Asynchronous Transfert Mode Système de transmission par paquets courts de taille fixe.

Telecom

BEP Back End Processor Processeur applicatif sur la plateforme TOMIX.

Alcatel

BSS Base Station Sub_System Infrastructure supportant les cellules radio GSM. Ce terme désigne l’ensemble constitué de la BSC (Base Station Controller) et du BTS (Base Transceiver Station). Cet ensemble communique avec le MSC par une interface normalisée pour le GSM. Chaque BSS gère une zone du réseau mobile.

Telecom

DSL Digital Subscriber L ine Ligne d’abonné fixe permettant la transmission de données numériques.

Telecom

DTD Définition de Type de Document Une DTD décrit un document XML à l’aide de règles déclaratives, de manière formelle afin de restreindre le vocabulaire utilisable et de contrôler la grammaire des éléments du fichier XML.

Info

FEP Front End Processor Coupleur SS7 TOMIX (par opposition à BEP).

Alcatel

GGSN GPRS Gateway Support Node Passerelle d’interconnexion ente le réseau GPRS maillant les SGSN et les autres réseaux de données par paquets extérieurs au réseau GSM.

Telecom

GPRS General Packet Radio Service (2.5 G) Extension du protocole GSM auquel on a ajouté une transmission par paquet pour augmenter le débit des données numériques. Se situe à mi-chemin entre le GSM (2G) et l’UMTS (3G).

Telecom

GSM Global System for Mobile Communications Norme numérique de seconde génération pour la téléphonie mobile.

Telecom

GTK GIMP Tool K it Bibliothèques logicielles pour le développement d’interfaces graphiques.

Info

HLR Home Location Register Base de donnée pour gérer les abonnés à la téléphonie mobile.

Telecom

IMS Internet Multimedia Subsystem Accès Internet pour les abonnés mobiles

Telecom

IN Intelligent Network Réseau intelligent (concept Télécom séparant les services de la communication)

Telecom

ITU International Telecom Union Organisme mondial de normalisation pour les Télécoms

Telecom

MIB Management Information Base Base de configuration pour le SS7

Info

MMC Man Machine Communication Relations entre l’homme et la machine, terme générique désignant les protocoles de que l’on va utiliser pour communiquer avec une machine cible.

Info

MOC M IB Object Component Objet de description de configuration dans les MIBs SS7. (Unité de base)

Alcatel

MSC Mobile Switching Center Autocommutateur pour les appels mobile/mobile et fixe/mobile.

Telecom

Glossaire






MSD Mobile Solution Division Division interne à Alcatel regroupant notamment le service TOMAS.

Alcatel

NGHLR New Generation HLR HLR de nouvelle génération qui se déploieront avec les réseaux NGN.

Telecom

NGN New Generation Network Concept Télécom séparant le transport (user plane) et le contrôle (control plane).

Telecom

NSS Network Sub System Partie centrale du réseau GSM (complémentaire au BSS).

Telecom

SCP Service Control Point Serveur dans l’architecture IN.

Telecom

SGSN Serving GPRS Support Node Equivalent MSC pour le traffic paquet 2.5 G

Telecom

SS7 Signaling System n°7 Système de signalisation téléphonique définit par l’ITU.

Telecom

SUT System Under Test Nom générique utilisé pour designer l’ensemble des composants sur lesquels portent les tests. Dans ce document, il s’agit de la plate-forme TOMAS.

Telecom

TDM Time Division Multiplexing Multiplexage par tranche de temps de plusieurs canaux d’information sur un même circuit physique.

Telecom

TAT2 Test Automation Tool 2 Nom donné à mon projet de 1ère et 2ème année.

Alcatel

TOMAS Telecom OS M iddleware Application Server Plate-forme et API fabriquée par Alcatel pour la téléphonie mobile.

Alcatel

TOMIX Nouveau nom de TOMAS. Alcatel UMTS Universal Mobile Terrestrial Service (3G)

L’UMTS ou 3GSM est la norme de téléphonie mobile de troisième génération. Telecom

UTRAN UMTS Terrestrial Radio Access Network. C’est l’équivalent du BSS de la 2G adapté pour la 3G. Il regroupe le Node B et le RNC.

Telecom

Vittam 2 Validation Test Tools And Methods Outil pour le passage des tests automatiques.

Alcatel

WIFI Wi reless Fidelity Nom pour les réseaux locaux sans fils (Wireless Local Area Network, WLAN), correspondant à la norme IEEE 802.11.

Telecom Info

WIMAX World Interoperability for M icrowave Access. WIFI haute performance.

Telecom

XML eXtensible Markup Language Format de stockage de donnée standardisé pour une lecture facilitée par les humains et les machines.

Info

Glossaire SS7 :

AAL5 ATM Adaptation Layer 5

ANSI American National Standards Institute

AS Application Server

ATM Asynchronous Transfer Mode

BB Broad Band

Glossaire






E1 PCM link : 2 048 kbps digital signal, Europe

IP Internet Protocol

ITU International Telecommunications Union

M2UA MTP Level 2 User Adaptation Layer

M3UA MTP Level 3 User Adaptation Layer

MAC Media Access Control

MTP1 Message Transfer Part level 1 (Narrow-band)



MTP3b Message Transfer Part level 3 (Broad-band)

NB Narrow Band

NIF Nodal Interworking Function

NNI Network to Node Interface

PCM Pulse Code Modulation

SCCP Signalling Connection Control Part

SCTP Stream Control Transmission Protocol

SDH Synchronous Digital Hierarchy

SG Signalling Gateway

SIGTRAN SIGnalling TRANsport

SS7 Semaphore Signalling number 7.

SS7oIP SS7 Signalling over IP

SSCF Service Specific Coordination Function

SSCOP Service Specific Connection Oriented Protocol

T1 PCM link : 1 544 kbps digital signal USA

STM1 Synchronous Transmission Module 1

Bibliographie






BIBLIOGRAPHIE

Livres : Introduction à XML. Par Erik T.Ray O’REILLY, édition Août 2003 ; 352 pages. Le réseau GSM, l’évolution GPRS : une étape vers UMTS. Par Joachim Tisal. DUNOD, édition Octobre 1999; 179 pages. UMTS Signaling (chapitre 1, UMTS basics). Par R. Kreher et T. Rüdebusch. WILEY, édition 2005; 438 pages. . Documents internet : Tutoriel Python. Par Jérôme Tschanz. Edition du 02/11/2000; 98 pages. Disponible sur http://www.ceramiko.ch/python/download/jt_python.pdf. Initiation à Python par l’exemple. Par Raphael Marvie. 102 pages. Disponible sur http://www.lifl.fr/~marvie/cours/initiation_python.pdf. Documentation sur XML et sur XML en Python (Utilisé surtout pour le chapitre 6 DOM: The Document Object Model). http://pyxml.sourceforge.net/topics/howto/xml-howto.html. Normes de l’ITU-T Q700 – Q70x Spécifications du SS7. Mécanismes classiques de la signalisation de connexion par C.Rigault Présentation – Janvier 2003 – 248 pages. ENST OmniORBpy user’s guide version 3 – par Duncan Grisby. Avril 2006 – 67 pages. Documents intranet : Nombreux documents sur le site web du projet TOMAS avec en particulier : Tomas overview (.ppt). Décembre 2004, 34 pages. Présentation : ClearCase NT Développeur, par Alcatel University ; octobre 2002, 286 pages. TOMIX-SS7-SIGTRAN_ConfigurationGuide 63 pages. Pour chaque couche du SS7 : Functional_and_Administrative_API_specification TOMIX_SIGNALLING_Stacks_Offer BUI API Specification – 23 février 2001 – 17 pages

Table des illustrations






Table des illustrations Figure 1 – Organigramme de l’équipe de direction.................................................................................... 9 Figure 2 - TOMAS un système complet.................................................................................................. 12 Figure 3 - Disk mirroring ......................................................................................................................... 13 Figure 4 - Un exemple de configuration TOMAS.................................................................................... 13 Figure 5 - Place de TOMAS dans un réseau mobile. ............................................................................... 14 Figure 6 - Organigramme général de la branche de solutions mobiles. ................................................... 15 Figure 7 - Organisation matricielle du service TOMAS .......................................................................... 16 Figure 8 - Comparaison des solutions capables de modifications sur les MIBs SS7............................... 20 Figure 9 – Architecture de CORBA sur TOMIX ..................................................................................... 21 Figure 11 – Objets du domaine. ............................................................................................................... 21 Figure 12 - Diagramme des uses case. ..................................................................................................... 21 Figure 13 – Architecture fonctionnelle de haut niveau. ........................................................................... 21 Figure 14 – Schéma fonctionnel détaillé. ................................................................................................. 21 Figure 15 – Planning prévisionnel avec avancement à la mi-juillet......................................................... 21 Figure 16 - Cycle V .................................................................................................................................. 21 Figure 17 – Développement itératif en spirale. ........................................................................................ 21 Figure 18 – Les itérations des deux branches de 7MBR.......................................................................... 21 Figure 19 – Diagramme des packages de 7MBR. .................................................................................... 21 Figure 20 – Diagramme de classes partiel du compilateur....................................................................... 21 Figure 21 – Diagramme de classe du mécanisme de gestion des cas particuliers.................................... 21 Figure 22 – Branches de développement clearcase.................................................................................. 21 Figure 23 – Méthode de test ..................................................................................................................... 21 Figure 24 – Pile de protocole SS7 et SIGTRAN...................................................................................... 21 Figure 25 – Aperçu du GUI de configuration SS7. .................................................................................. 21 Figure 26 – Configuration de TOMIX en Serveur d’application. ............................................................ 21 Figure 27 – Configuration de TOMIX en passerelle de réseau de signalisation...................................... 21 Figure 28 - AS: configuration quadri-stations avec 2 FEP NB-BB-IP (exemple pour vmware). ............ 21 Figure 29 – Relation entre les objets de management du MTP2 - NB..................................................... 21 Figure 30 - Relation entre les objets de management du MTP2 - BB...................................................... 21 Figure 31 – Relation entre les objets de management du MTP3.............................................................. 21 Figure 32 – Relation entre les objets de management du SCCP. ............................................................. 21 Figure 33 – Exemple de programmation objet. ........................................................................................ 21

Annexes






ANNEXES

Annexes






Table des annexes

ANNEXE A LES RESEAUX DE CONTROLE................................................................................................................... 21

A 1 OBJECTIFS...................................................................................................................................................................... 21 A 2 SS7................................................................................................................................................................................. 21 A 3 SIGTRAN...................................................................................................................................................................... 21 A 4 CONFIGURATION SUR TOMIX........................................................................................................................................ 21

A 4 1 Les commandes BUI .............................................................................................................................................. 21 A 4 2 Le GUI Java........................................................................................................................................................... 21

ANNEXE B CONFIGURATIONS DE TOMIX................................................................................................................... 21

B 1 APPLICATION SERVER (AS)............................................................................................................................................ 21 B 2 SIGNALLING GATEWAY (SG).......................................................................................................................................... 21 B 3 EXEMPLE DE CONFIGURATION EN ENVIRONNEMENT VMWARE ...................................................................................... 21

ANNEXE C LES OBJETS DES MIBS SS7 ET SIGTRAN ................................................................................................ 21

C 1 LES XML ....................................................................................................................................................................... 21 C 2 SCHEMAS DES RELATIONS ENTRE OBJETS. ...................................................................................................................... 21

C 2 1 MTP2 - NB............................................................................................................................................................. 21 C 2 2 MTP2 - BB............................................................................................................................................................. 21 C 2 3 MTP3 ..................................................................................................................................................................... 21 C 2 4 SCCP ..................................................................................................................................................................... 21

ANNEXE D DOCUMENTATION DE MAINTENANCE .............. .................................................................................... 21

D 1 NOTIONS DE PROGRAMMATION OBJET............................................................................................................................ 21 D 2 CONNAISSANCE DE PYTHON. .......................................................................................................................................... 21 D 3 FREQUENCE DE MISE A JOUR MAJEURE. .......................................................................................................................... 21 D 4 LOCALISATION DE BUGS................................................................................................................................................. 21 D 5 LES MOCS DEMANDANT UN TRAITEMENT PARTICULIER (MD7 SP1). ............................................................................. 21

ANNEXE E DOCUMENTATION DU TESTEUR.............................................................................................................. 21

E 1 RECUPERATION DU PROJET............................................................................................................................................. 21 E 1 1 Depuis les sources ................................................................................................................................................. 21 E 1 2 Depuis les rpm TOMIX.......................................................................................................................................... 21

E 2 MISE EN PLACE DU BANC DE TEST. .................................................................................................................................. 21 E 3 COMPILATION ET EXPORTATION DU PROJET. ................................................................................................................... 21 E 4 LANCEMENT DE L’APPLICATION DE TEST. ....................................................................................................................... 21

ANNEXE F DOCUMENTATION UTILISATEUR ................. ........................................................................................... 21

F 1 METHODOLOGIE DU BACKUP RESTORE............................................................................................................................ 21 F 2 METHODOLOGIE DU CHANGEMENT DE VERSION.............................................................................................................. 21 F 3 METHODOLOGIE DU PORTAGE DE MIB. .......................................................................................................................... 21 F 4 LES REPERTOIRES SUR TOMIX. ...................................................................................................................................... 21 F 5 L’ ACTION « BACKUP ». ................................................................................................................................................... 21 F 6 LA GENERATION DES FICHIERS DE MANIPULATION DE MIB............................................................................................. 21 F 7 UTILISATION DES SCRIPTS GENERES. ............................................................................................................................... 21

F 7 1 Prepare delete........................................................................................................................................................ 21 F 7 2 Delete..................................................................................................................................................................... 21 F 7 3 Create. ................................................................................................................................................................... 21 F 7 4 After create. ........................................................................................................................................................... 21

Annexes






Annexe A Les réseaux de contrôle

A 1 Objectifs Le réseau SS7/SIGTRAN est en charge du transport des messages de signalisation du réseau télécom. Il s’agit d’un réseau numérique transportant des messages de supervision et gestion du réseau via des canaux sémaphores. Ces messages sont transportés dans des trames sémaphores. Ces réseaux sont utilisés pour transférer des informations de contrôle entre les différents éléments du réseau, et ont permis l’introduction des services de télécommunication à valeur ajoutée, telle que le transport des SMS, la gestion des numéros spéciaux (les réseaux intelligents).

A 2 SS7 Le protocole MTP (Message Transfert Part) se compose de 3 couches équivalentes aux 3 premières du modèle ISO/OSI. Ce protocole est à la base du SS7. MTP est responsable du transport des messages SS7 au travers le réseau SS7. Il s’assure de l’ordonnancement des messages et de la non duplication de ceux-ci. Par-dessus, on trouve la couche SCCP (Signaling Connection and Control Part). SCCP fournit des extensions de protocole de routage, assure la segmentation des paquets, corrige les erreurs liées au transport. Il offre au réseau la possibilité de travailler en mode connecté ou non connecté et est responsable de la traduction des numéros spéciaux en numéros réels. Il fournit une classe de base en mode sans connexion utilisée pour transporter les messages TCAP (Transactions Capabilities Applications Part). TCAP fournit un protocole de transactions entre différentes applications. Les applications ne sont pas développées par le service TOMIX. Le schéma ci dessous présente les parties du SS7 supportées par TOMIX.

ISO

SSCOPAAL5

MTP1 MTP1 ATM MTP1E1(64kb/s) E1(2Mb) STM1 T1(56kb/s) T1(1,5Mb) STM1

Physical Type PCM PCM SDH PCM PCM SDH

Data link MTP2

SS7 Signalling SS7oIPITU ANSI SIGTRAN

Application TCAP TCAP

Presentation

Session

Transport SCCP SCCP

MTP3 MTP3b MTP3 MTP3bNetwork

MTP2SCCF-NNI

MTP2

AAL5SSCOP

SSCF-NNI

PhysicalATM MAC

PHYEthernet

802.3...

M2UA

SCTPIP

M3UA

Figure 24 – Pile de protocole SS7 et SIGTRAN

Annexes






Pile Logiciel

Firmware

embarqué ou partie purement

matérielle

ITU/ETSI

ANSI

ATM

SIGTRAN

Communication entre les différentes couches de la pile de protocole.

A 3 SIGTRAN Il s’agit d’une adaptation des couches basses du SS7, pour transférer les messages sémaphores au-dessus du réseau IP. Les anciennes couches hautes du SS7 sont compatibles avec les services proposés par SIGTRAN. SCTP (Stream Control Transmission Protocol) : fournit des services analogues à TCP et UDP mais SCTP est capable de transporter plusieurs flux de données en parallèle et d’assurer l’ordonnancement des paquets. M2UA (MTP2 User Adaptation layer) : Adaptation MTP2 (voir SS7). M3UA (MTP3 User Adaptation layer) : Adaptation MTP3 (voir SS7).

A 4 Configuration sur TOMIX

A 4 1 Les commandes BUI Extraits de la documentation officielle pour les commandes utilisées par 7MBR. BUL commands comply with the following scheme : <service> < Class > [ < InstanceName > ] < Paramete rArea > < AttributeArea > ; <service > := create | delete | get | getwhen | s et | action <InstanceName > := < Word > | < Word >< Separator >< InstanceName > <ParameterArea > := NULL | { < ParameterList > } <ParameterList> := < Parameter > | <Parameter > < Comma > < ParameterList > <Parameter > := < ParameterName > = < String > <ParameterName > := version | userinfo <AttributeArea > := NULL | < NotEmptyAttrArea > <NotEmptyAttrArea> := ( < AttributeList> | < Attr ibuteValueList> |< ActionArea> )

create < Class > [ < InstanceName > ] ( < AttributeValueList > ); < InstanceName > := < Word > | < Word >< Separato r >< InstanceName > < AttributeValueList > := < AttributeValue > | < AttributeValue > < Comma > < AttributeValueList > | < CompositeValue> | < CompositeValue > < Comma > < AttributeValueList > < AttributeValue > := < AttributeName > = < Value > < AttributeName > := < Word > < CompositeValue > := < CompositeName > [ < PosInt > ] ( < AttributeValueList > ) < CompositeName > := < Word >

Annexes






delete < Class > [ < InstanceName > ] ( ); < InstanceName > := < Word > | < Word >< Separator >< InstanceName >

get < Class > [ < InstanceName > ] < Version > ( < Att ributeList > ); < InstanceName > := * | * < Separator >< Instance Name > | < Word > | < Word > < Separator > < InstanceName > < Version > = NULL | { version = ” < VersionName > ” } < VersionName > := * | < Word > < AttributeList > := * | NULL | < AttributeNameLi st > < AttributeNameList > := < AttributeName > | < AttributeName > < Comma > < AttributeNameList > | < Composite > | < Composite > < Comma > < AttributeNameList > < AttributeName > := < Word > < Composite > := < CompositeName > [ < Index > ] ( < AttributeList > ) < ComposieName > := < Word > < Index > := * | < PosInt >

set < Class > [ < InstanceName > ] < Version > ( < Att ributValueList > ) ; < InstanceName > := < Word > | < Word >< Separato r >< InstanceName > < Version > = NULL | { version = ” < VersionName > ” } < VersionName > := < Word > < AttributeValueList > := < AttributeValue > | < AttributeValue > < Comma > < AttributeValueList > | < CompositeValue> | < AttributeValue > := < AttributeName > = < Value > < AttributeName > := < Word > < CompositeValue > := < CompositeName > [ < PosIn t > ] ( < AttributeValueList > ) < CompositeName > := < Word >

action <Class> [ <InstanceName> ] <Version> ( < ActionNam e >< ArgumentPackage > ); < InstanceName > := < Word > | < Word >< Separato r >< InstanceName > < Version > = NULL | { version = ” < VersionName > ” } < VersionName > := < Word > < ActionName > := < Word > < ArgumentPackage > := ( NULL | < ArgumentValueLi st > ) < ArgumentValueList > := < ArgumentValue > | < ArgumentValue ><Comma>< ArgumentValueList > < ArgumentValue > := < ArgumentName > = < Value > < ArgumentName > := < Word >

A 4 2 Le GUI Java Le GUI Java est une application disponible via le protocole JNLP (Java Networking Launching Protocol), directement depuis la racine du serveur web de TOMIX.

Annexes






Figure 25 – Aperçu du GUI de configuration SS7.

Annexes






Annexe B Configurations de TOMIX

B 1 Application Server (AS)

Figure 26 – Configuration de TOMIX en Serveur d’application.

B 2 Signalling Gateway (SG)

Figure 27 – Configuration de TOMIX en passerelle de réseau de signalisation.

TOMIX N.E.

M3UA LN=14, NA=-1

SCTP

SG SG

IP

AS AS

SS7

PC=1

PC=1

SG NA=-1

SCCP

TOMIX N.E.

NIF

M3UA LN=14, NA=-1

MTP2 SCTP

AS AS

IP

SG SG

SS7

PC=1 PC=1 AS0 PC=20, NA=-1

MTP3 PC=20, LN = 0

Annexes






B 3 Exemple de configuration en environnement VmWare

Pilot station A (active)

GTCAP

GSCCP

Pilot station B (standby)

FEP-NB-BB-IP

LSN network

Mirroring disks

GSS7

SCCPL

Station C FEP-NB-BB-IP Station D

SCCPL

Dist TCAP:SSN3

Dist TCAP:SSN4

Dist SCCP:SSN10

Dist SCCP:SSN20

Dist TCAP:SSN3

Dist TCAP:SSN4

Dist SCCP:SSN10

Dist SCCP:SSN20

G3-NB-N1 G3-BB-N2

G2-BB

G3-NB-N0

G2-NB

G3UA

GSCTP

L3-N0 L3UAL3-N1 L3-N2

SCCPL

L2-NB

SS7 NB access


L2-BB

SS7 BB access

LSCTP

IP access

L2-NB


L2-BB LSCTP

SS7 NB access

SS7 BB access

SCCP appli

TCAP appli

GTCAP

GSCCP

GSS7

G3-NB-N1 G3-BB-N2

G2-BB

G3-NB-N0

G2-NB

G3UA

GSCTP


SCCPL

SCCP appli

TCAP appli

Figure 28 - AS: configuration quadri-stations avec 2 FEP NB-BB-IP (exemple pour vmware).

Annexes






Annexe C Les objets des MIBs SS7 et SIGTRAN

C 1 Les XML Chaque couche de configuration de la MIB SS7 est définie dans un fichier xml utilisé par 7MBR pour générer la librairie python ss7. Chaque fichier correspond à la configuration d’une couche de la pile de protocoles SS7. Voici les équivalences SS7 XML pour les XML utilisés par 7MBR:

• MTP2 NB (Narrow Band) : nfe_mdl.xml – ifap = 0 • MTP2 BB (Broad Band) : nfe_mdl.xml – ifap = 1 • MTP3 Nx : n73_mdl.xml – ifap = [0..15] • MTP3 Nef : ns7_mdl.xml • SCCP : n7s_mdl.xml

• M3UA : nua_mdl.xml • NIF : nif_mdl.xml

Il existe d’autres fichiers xml de description des MIBs SS7, mais ils ne correspondent pas à des domaines éditables. On trouve par exemple des fichiers décrivant les couches matérielles du réseau. Pour ces couches on ne peut qu’observer des valeurs mais pas les restaurer, donc il n’y a pas d’utilité pour 7MBR. Ces couches sont celles implémentées de manière matérielle ou par firmware.

C 2 Schémas des relations entre objets. Ces schémas montrent les interactions envisageables entre les différentes instances de Moc.

C 2 1 MTP2 - NB

Figure 29 – Relation entre les objets de management du MTP2 - NB

pcmc_fe pcm_fe pcmprof_fe datalink_fe l2prof_fe

ROOT

contains

n n n

Annexes






C 2 2 MTP2 - BB

contains

n

1ROOT

aal_cnx_fe

atm_link_fe

n

prof_sscf_nni_fe

atm_device_fe

n

prof_cpcs_cv_fesccf_uni_prof_fe

contains1

obs_cv_fe

n

n n

Figure 30 - Relation entre les objets de management du MTP2 - BB

Annexes






C 2 3 MTP3

Figure 31 – Relation entre les objets de management du MTP3

ANSI

ITU

loadshare lstimers

route

sltimers

lnk

n n

root

signpoint

sptimers

routeset

n n

0..16

0,1 0,1

0,1

linkset

Annexes






C 2 4 SCCP

sccpEntitySet

sccpAccesspoint

sccpLinkage

sccp

root

scoc TranslatorSelector gtTranslator

gtRule

gtConversionRule

callingPartyAddress

concernedArea

1-16

remote

translationTest

1-16

local

localremote

congestion

local

Figure 32 – Relation entre les objets de management du SCCP.

Annexes






Annexe D Documentation de maintenance Ce projet comporte la particularité de nécessiter une maintenance régulière liée aux évolutions de TOMIX, en plus des phases de maintenance classique. Il est probable que les tâches de maintenance évolutive soient iniquement constituées en la suppression de code source dans le package mdltopy::overrided . En effet TOMIX s’efforce de simplifier régulièrement les interactions avec les objets des MIBs, à tel point qu’on espère qu’à terme l’ensemble des cas particuliers gérés aujourd’hui par 7MBR adoptera les procédures génériques. En cas d’évolution du fichier de définition mdl.xsd se reporter au fichier generate_all_library.py du package src . En cas d’évolution de TOMIX sur les fichiers nxx_mdl.xml ou sur les objets qui s’y réfèrent, se reporter à cette documentation.

D 1 Notions de programmation objet Pour assurer la maintenance et la prise en charge par 7MBR de nouveaux MOC (MIB Objects Component), vous avez besoin de comprendre les bases de la programmation orientée objet. Vous pouvez vous contenter des notions de bases. Vous devrez savoir ce que sont une classe, ses attributs et ses méthodes. Vous devez faire la différence entre une classe et une instance de classe (objet). Vous devez également comprendre les principes de l’héritage (héritage, généralisation, super classe, surcharge de méthode). Une classe est une description d’un concept réel ou non. Dans cette petite introduction à la programmation objet, nous prendrons pour exemple des véhicules. Pour décrire avec le paradigme objet un concept réel nous avons besoin de deux choses :

• Savoir décrire l’objet que nous voulons représenter de manière statique, pour cela nous utilisons des attributs.

• Savoir décrire des comportements associés aux objets décrits, pour cela nous utilisons des méthodes.

Les attributs vont donc servir à se donner une idée de la représentation de l’objet à décrire. Pour un véhicule on pourra trouver comme attributs : le nombre de roues, le poids, y a t-il un moteur ?, localisation. Les méthodes pour un véhicule pourront par exemple être : avancer( ), reculer( ). Une classe sera donc la description générale applicable à tous les véhicules. Puis à partir de cette classe, nous pourrons avoir des objets (instance de classe). Une instance de la classe véhicule pourra être un véhicule à 3 roues, de 400kg, équipé d’un moteur, se trouvant sur la N6 et actuellement en train de reculer. On peut imaginer que beaucoup d’autres objets peuvent instancier cette classe. Voyons maintenant le concept de l’héritage. Nous avons vu qu’un véhicule pouvait avancer. La question est : comment un véhicule fait-il pour avancer ? S’il s’agit d’une voiture, il faut appuyer sur l’accélérateur. S’il s’agit d’un vélo, il faut pédaler. On va alors créer une classe vélo et une classe voiture. On va spécifier que la classe vélo hérite de la classe véhicule (un vélo est bien un véhicule : il

Annexes






peut avancer, reculer, possède deux roues, pèse 10kg et n’a pas de moteur). Ensuite nous ferons de même pour la classe voiture.

Figure 33 – Exemple de programmation objet.

On dit que la classe Vélo hérite de la classe véhicule. Si dans la classe Vélo on a redéfini la méthode avancer( ), alors si on veut faire avancer un véhicule qui est un vélo, on utilisera la méthode avancer de la classe vélo à la place de celle de la classe véhicule.

D 2 Connaissance de python. Vous devez connaitre les bases de python : listes, tuples, dictionnaires, ainsi que les classes. Vous pouvez lire le tutoriel officiel disponible sur le site web de python.

D 3 Fréquence de mise à jour majeure. Ce type de mise à jour se produit à peu près deux fois par an. Lors d’une mise à jour majeure de TOMIX, il est conseillé de re-générer la librairie.

D 4 Localisation de bugs Si le bug est prévu par 7MBR, alors vous aurez sur la sortie d’erreur standard la commande SS7 qui est à l’origine du bug. Sinon, si le bug intervient dans la phase de génération de la librairie, vous pouvez tenter de reproduire le bug sur un PC, à partir d’un débugger. (Pour le projet, j’ai utilisé celui de PyDev). Pour les autres bug, la solution reste de faire des affichages réguliers si le message d’erreur ne vous permet pas de le localiser. Si l’erreur se produit à partir d’un objet qui vous est inconnu, afficher ce que la fonction dir( ) vous renvoie sur lui. dir( ), vous indique les attributs et méthodes de l’objet interrogé.

D 5 Les Mocs demandant un traitement particulier (MD7 SP1).

• ns7 : fsm (prepare delete, create, after create) • n7s : sccp (after create) • n7s : scoc (after create) • nua : association (prepare delete)

Annexes






Annexe E Documentation du testeur

E 1 Récupération du projet

E 1 1 Depuis les sources Les sources sont disponibles sous clearcase dans la vob /oam_ss7/backup-restore Dans ce répertoire on trouve les sous répertoires suivants :

• build, qui contient le makefile. • src, qui contient les sources python. • properties, qui contient ce qui peut être modifié avant la compilation. • test, contient des tests unitaires de code. • doc, contient la présente documentation.

E 1 2 Depuis les rpm TOMIX

Contacter la branche d’intégration pour savoir si ils disposent d’un rpm déjà prêt pour la version de TOMIX désirée (rappel : pas de distribution antérieure à RL42 MD7 SP1)

E 2 Mise en place du banc de test. Il vous faut récupérer une image TOMIX pour VmWare. Elle peut ou non contenir le projet 7MBR. Si 7MBR est inclut, ne pas passer par la phase compilation et exportation. Pour voir si 7MBR est installé : démarrez vos stations, puis sur une des stations démarrées, regardez dans le répertoire /usr/nectar/oam/python. Assurez vous de la présence du répertoire backup-restore. Vous devez avoir une MIB SS7 pré chargée. Pour le vérifier, démarrez vos stations, connectez vous sur la machine active et ouvrez une session BUI en tapant buii. Là, passez des commandes get sur les objets de votre choix.

E 3 Compilation et exportation du projet. Si vous n’avez pas de rpm, je vous conseille de suivre la procédure ssh indiquée en haut du makefile.

• Sans rpm : Faites un checkout –unreserved sur le makefile pour le configurer. Puis make && make install

• Avec rpm : Utilisez la procédure classique d’installation de package TOMIX.

E 4 Lancement de l’application de test.

Utilisez la documentation utilisateur pour effectuer des procédures de backup et restore. Ensuite reportez vous à la section test du mémoire d’ingénieur MIB SS7 (cf 3.3).

Annexes






L’utilitaire de test est cmpBackup.py . vm21:/usr/nectar/oam/python(0)# ./run.sh backup-res tore/src/cmpBackup.py -h cmpBackup.py NAME cmpBackup.py -- compare backup files SYNOPSIS : cmpBackup.py [-hv] [--help] [--verbose] file1 file2 DESCRIPTION The following options are available: -h display this help -v verbose mode file1 file2 the two files to compare

Annexes






Annexe F Documentation utilisateur

F 1 Méthodologie du backup restore. Une utilisation de 7MBR en mode backup-restore consiste en un backup quotidien. Au moment du restore, vous devez commencer par effectuer une procédure de backup. Avec le backup acquis au moment de la volonté de faire un restore, il faut générer les scripts de suppression de MIB. Puis avec le backup correspondant à la version de MIB que vous souhaitez restaurer, il faut générer les scripts d’écriture dans la MIB. Une fois les générations de scripts accomplies, vous pouvez démarrer la procédure de restauration en commençant par détruire la MIB avec les tous derniers scripts, puis ensuite en exécutant les scripts d’écriture générés par la version à restaurer.

F 2 Méthodologie du changement de version. 7MBR n’est pas en mesure de garantir la compatibilité entre les MIB SS7 des différentes versions de TOMIX. Cependant vous pouvez tenter l’opération. Si 7MBR trouve une incompatibilité, vous le saurez avant d’effectuer un traitement pouvant avoir des répercussions sur la MIB. La raison de cette incertitude est due à la possibilité par TOMIX d’ajouter ou de supprimer des objets entre ses différentes versions. Réalisez un backup sur la machine de départ. Prenez ensuite le fichier issu du backup et exportez le sur la nouvelle machine. Utilisez 7MBR pour générer les scripts de traitement sur la MIB. Si les scripts sont générés, c’est que les MIB sont compatibles. Si vous connaissez la raison de l’erreur, par exemple un attribut nouvellement inséré, vous pouvez modifier le fichier issu du backup à la main. Sa syntaxe est proche de celle des scripts BUL. Une fois le fichier de backup modifié, recommencez l’opération de génération des scripts. Attention : il est conseillé de ne jamais modifier les scripts générés pour le traitement des MIB. Faites toujours vos modifications dans les fichiers issus du backup. Les travaux protégeant les MIBs SS7 proposés par 7MBR se limitent à la génération des scripts de restauration. Lorsque vous exécutez ces scripts, il n’y a plus aucun contrôle avant les serveurs de MIB TOMIX. Vous risquez de vous retrouver avec des MIBs partiellement détruites ou partiellement créées. Une fois que vous avez réussi à générer vos fichiers de restauration, n’oubliez pas de commencer par une procédure de delete sur la machine sur laquelle vous voulez importer la MIB.

F 3 Méthodologie du portage de MIB. Cette pratique est la même que celle expliquée pour le changement de version, sauf que vous n’avez pas besoin de modifier le fichier issu du backup. Si vous ne souhaitez exporter qu’une partie de la MIB, vous pouvez le faire en générant des fichiers de restauration uniques par domaine. Par exemple si vous partez d’une TOMIX avec SIGTRAN, vers une TOMIX avec seulement du SS7, vous devrez éliminer les domaines nif et nua des fichiers de restauration.

Annexes






F 4 Les répertoires sur TOMIX. L’application se trouve dans /usr/nectar/oam/python/backup-restore. Les sources exécutables sont dans /usr/nectar/oam/python/backup-restore/src (Les noms des exécutables sont communiqués dans les 2 prochaines sous parties). Par défaut, les scripts sont fabriqués dans /usr/nectar/oam/python/result.

F 5 L’action « backup ». Voici l’aide disponible : vm21:/usr/nectar/oam/python(0)# ./run.sh backup-res tore/src/backup.py –h backup.py NAME backup.py -- Backup the SS7 MIB SYNOPSIS : backup.py [-h] [-t hostname] [-l login] [-p passwor d] [--help] [--target hostname] [--login login] [--password password] DESCRIPTION The following options are available: -h --help display this help -t --target hostname (vm10) of TOMIX platform -l --login login (admin_root) of TOMIX platfo rm -p --password password (admin_root) of TOMIX pla tform

Voici un exemple d’utilisation : vm21:/usr/nectar/oam/python(0)# ./run.sh backup-res tore/src/backup.py --target vm21 … … save set file as : /usr/nectar/oam/python/result/20 07-08-14_08-39-54_setSS7Mib.py

F 6 La génération des fichiers de manipulation de MIB.

Voici l’aide disponible : vm21:/usr/nectar/oam/python(0)# ./run.sh backup-res tore/src/BuildRestoreFiles.py –h BuildRestoreFiles.py NAME BuildRestoreFiles.py -- build delete - create files SYNOPSIS : BuildRestoreFiles.py [-hvqg] [-o directory] [-s prefix] [-t hostname] [-l lo gin] [-p password] -f input-file [--help] [--verbose] [--quiet] [--global] [--output=directory] [--prefix=prefix] [--targe t hostname] [--login login] [--password password] --input-file=input-file domain.. . DESCRIPTION The following options are available: -h --help display this help -v --verbose verbose mode

Annexes






-q --quiet disable error messages -g --global make global output files for all g iven domains -s --prefix customize output filename, default prefix (start of name) is system clock : y-m-d_h-m-s -t --target hostname (vm10) of TOMIX platform -l --login login (admin_root) of TOMIX platfo rm -p --password password (admin_root) of TOMIX pla tform

Voici un exemple d’utilisation : vm21:/usr/nectar/oam/python(0)# ./run.sh backup-res tore/src/BuildRestoreFiles.py

-v -s latest -t vm21 -f /usr/nectar/oam/python/result/2007-08-14_08-39-5 4_setSS7Mib.py

Voici les fichiers générés : vm21:/usr/nectar/oam/python(0)# ls result/ 2007-08-14_08-39-54_setSS7Mib.py latest_delete.py latest_delete_n73.py latest_delete_n7s.py latest_afterCreate.py latest_delete_nfe.py latest_afterCreate_n73.py latest_delete_nif.py latest_afterCreate_n7s.py latest_delete_ns7.py latest_afterCreate_nfe.py latest_delete_nua.py latest_afterCreate_nif.py latest_prepareDelete.py latest_afterCreate_ns7.py latest_prepareDelete_n73 .py latest_afterCreate_nua.py latest_prepareDelete_n7s .py latest_create.py latest_prepareDelete_nfe .py latest_create_n73.py latest_prepareDelete_nif .py latest_create_n7s.py latest_prepareDelete_ns7 .py latest_create_nfe.py latest_prepareDelete_nua .py latest_create_nif.py latest_create_ns7.py

Les fichiers dont le nom ne se termine pas par celui d’un domaine sont ceux générés avec l’option –g.

F 7 Utilisation des scripts générés. Pour la suite, nous allons prendre l’exemple du domaine n7s : il ne possède que très peu d’objets. Pour exécuter une procédure de backup restore il faut passer dans l’ordre : prepareDelete qui positionne les liens dans un état suppressible. delete qui détruit les objets de la MIB. Ensuite on part des fichiers générés avec le précédent backup, et on passe le create qui reconstruit les objets, puis le afterCreate qui réactive les liens. Lancement (exemple) : vm21:/usr/nectar/oam/python(0)# ./run.sh result/lat est_delete_n7s.py

Voici maintenant le contenu des fichiers générés pour le n7s.

F 7 1 Prepare delete # Generated by BuildRestoreFiles.py # on 2007/08/14 08:45:13 import SS7Common

Annexes






import SS7ExecCommand cmdList = [ \ \ ] if __name__ == "__main__": host = 'vm21' SS7ExecCommand.start(cmdList, host, 'admin_root ', 'admin_root')

F 7 2 Delete.

# Generated by BuildRestoreFiles.py # on 2007/08/14 08:45:13 import SS7Common import SS7ExecCommand cmdList = [ \ SS7Common.Command("delete", "sccpaccesspoint", "SCC P/RAP1_10_SSN10", 0, []), \ SS7Common.Command("delete", "sccpaccesspoint", "SCC P/LAP50", 0, []), \ SS7Common.Command("delete", "sccplinkage", "SCCP/LI NKAGE1_10", 0, []), \ SS7Common.Command("delete", "sccpaccesspoint", "SCC P/RAP1_14_SSN10", 0, []), \ SS7Common.Command("delete", "sccplinkage", "SCCP/LI NKAGE1_14", 0, []), \ SS7Common.Command("delete", "sccplinkage", "SCCP/LI NKAGE1_21", 0, []), \ SS7Common.Command("delete", "sccp", "SCCP", 0, []), \ \ ] if __name__ == "__main__": host = 'vm21' SS7ExecCommand.start(cmdList, host, 'admin_root ', 'admin_root')

F 7 3 Create. # Generated by BuildRestoreFiles.py # on 2007/08/14 08:45:13 import SS7Common import SS7ExecCommand cmdList = [ \ SS7Common.Command("create", "sccp", "SCCP", 0, [SS7Common.Attribute("maxstatinfotimer", 5), SS7Com mon.Attribute("systemtypes", 'es'), SS7Common.Attribute("initialvaluereasstimer" , 10)]), \ SS7Common.Command("create", "sccplinkage", "SCCP/LI NKAGE1_21", 0, [SS7Common.Attribute("mtpaccesspointtype", 'local') , SS7Common.Attribute("network", 1), SS7Common.Attribute("pointcode", 21), SS7Common .Attribute("pclength", 'pc14'), SS7Common.Attribute("concernedareapointer", '<>'), SS7Common.Attribute("version", 'itu96'), SS7Common.Attribute("ludtsupportindicator ", 0), SS7Common.Attribute("forcedata", 'sendudt'), SS7Common.Attribute("lowerlimitforsegmentation", 16 0), SS7Common.Attribute("upperlimitforsegmentation", 25 4), SS7Common.Attribute("congestionpointer", '<>')]), \ SS7Common.Command("create", "sccplinkage", "SCCP/LI NKAGE1_14", 0, [SS7Common.Attribute("mtpaccesspointtype", 'remote' ),

Annexes






SS7Common.Attribute("network", 1), SS7Common.Attrib ute("pointcode", 14), SS7Common.Attribute("pclength", 'pc14'), SS7Common.Attribute("concernedareapointer", '<>'), SS7Common.Attribute("version", 'itu96'), SS7Common.Attribute("ludtsupportindicator ", 0), SS7Common.Attribute("forcedata", 'sendudt'), SS7Common.Attribute("lowerlimitforsegmentation", 16 0), SS7Common.Attribute("upperlimitforsegmentation", 25 4), SS7Common.Attribute("congestionpointer", '<>')]), \ SS7Common.Command("create", "sccpaccesspoint", "SCC P/RAP1_14_SSN10", 0, [SS7Common.Attribute("ssn", 10), SS7Common.Attribut e("sccplinkagepointer", 'SCCP/LINKAGE1_14'), SS7Common.Attribute("ssavailab leaftersprestart", 1), SS7Common.Attribute("concernedareapointer", '<>'), SS7Common.Attribute("administrativestate", 'unlocke d')]), \ SS7Common.Command("create", "sccplinkage", "SCCP/LI NKAGE1_10", 0, [SS7Common.Attribute("mtpaccesspointtype", 'remote' ), SS7Common.Attribute("network", 1), SS7Common.Attrib ute("pointcode", 10), SS7Common.Attribute("pclength", 'pc14'), SS7Common.Attribute("concernedareapointer", '<>'), SS7Common.Attribute("version", 'itu96'), SS7Common.Attribute("ludtsupportindicator ", 0), SS7Common.Attribute("forcedata", 'sendudt'), SS7Common.Attribute("lowerlimitforsegmentation", 16 0), SS7Common.Attribute("upperlimitforsegmentation", 25 4), SS7Common.Attribute("congestionpointer", '<>')]), \ SS7Common.Command("create", "sccpaccesspoint", "SCC P/LAP50", 0, [SS7Common.Attribute("ssn", 50), SS7Common.Attribut e("sccplinkagepointer", '<>'), SS7Common.Attribute("ssavailableaftersprestart", 1) , SS7Common.Attribute("concernedareapointer", '<>'), SS7Common.Attribute("administrativestate", 'unlocke d')]), \ SS7Common.Command("create", "sccpaccesspoint", "SCC P/RAP1_10_SSN10", 0, [SS7Common.Attribute("ssn", 10), SS7Common.Attribut e("sccplinkagepointer", 'SCCP/LINKAGE1_10'), SS7Common.Attribute("ssavailab leaftersprestart", 1), SS7Common.Attribute("concernedareapointer", '<>'), SS7Common.Attribute("administrativestate", 'unlocke d')]), \ \ ] if __name__ == "__main__": host = 'vm21' SS7ExecCommand.start(cmdList, host, 'admin_root ', 'admin_root')

F 7 4 After create.

# Generated by BuildRestoreFiles.py # on 2007/08/14 08:45:14 import SS7Common import SS7ExecCommand cmdList = [ \ SS7Common.Command("set", "sccp", "SCCP", 0, [SS7Common.Attribute("maxstatinfotimer", 5), SS7Com mon.Attribute("systemtypes", 'es'), SS7Common.Attribute("initialvaluereasstimer" , 10)]), \ \ ] if __name__ == "__main__": host = 'vm21' SS7ExecCommand.start(cmdList, host, 'admin_root ', 'admin_root')

Olivier HARGOAA 2007 IR-3

Résumé :

La plate-forme télécom TOMAS d’Alcatel-Lucent offre une gestion de l’ensemble des couches du réseau SS7. Mon projet (7MBR) consiste en la création en langage Python d’un outil permettant d’en extraire les configurations afin de les restaurer ultérieurement, en prenant soin de valider les sauvegardes avant de créer dynamiquement les scripts de restauration.

Expression générale :

Création d’une application de sauvegarde et restauration de configurations pour le réseau SS7.

Mots clés :

• Configuration SS7 • Plate-forme Télécom • Sauvegardes et restaurations • Langage Python

Olivier Hargoaa

Fiche de synthèse mémoire d’ingénieur / Alcatel-Lucent

Objectifs Résultats

Enjeu

Objectifs

Planning prévisionnel

Budget prévisionnel

Forme et type de résultat attendu

Démarche / moyens prévus

Suites à donner

Planning réalisé

Budget consomé

Conséquence pour l’entreprise

Résultats obtenus / écarts

Proposer une solution pour assurer la

sauvegarde et restauration des configurations

du réseau SS7.

Réaliser les phases d’études et développement

de la solution proposée pour fournir une

version fonctionnelle fin août 2007. Les

sauvegardes doivent être modifiables par les

utilisateurs afin qu’ils puissent les exporter. La

restauration doit valider les sauvegardes pour limiter les erreurs.

Non applicable Non applicable

Le court délai de réalisation force à favoriser la

partie étude afin de ne pas avoir à revenir

dessus durant la phase de développement.

Le projet sera divisé en deux parties, chacune

réalisée parallèlement.

Le résultat attendu est un projet fonctionnel. Il

doit être remis sous forme de code source sur

un serveur dédié accompagné de son makefile,

ainsi que la description permettant son

intégration dans le projet global du service.

On attend que le projet soit capable de

sauvegarder la configuration SS7, soit capable

de générer un script python permettant de

l’effacer, puis un autre pour la ré-exporter.

Le service ngHLR va pouvoir sauvegarder ses

MIB SS7 par domaine ou pour l’ensemble du

SS7/ SIGTRAN comme il le souhaitait.

Le service test de TOMIX va utiliser ce projet

pour préparer ses configurations SS7 à tester.

Le projet est fonctionnel, le service TOMIX

pourra le livrer à ses clients.

Serge Viallefond sera en charge de la

maintenance du projet et sera le principal

interlocuteur de l’ensemble des clients.

Etudes

Développement

Tests

Etudes

Développement

Tests

Aujourd'hui Aujourd'hui