TRAFFIC TRACKER : UN SYSTEME DE CONTROLE DES VOLUMES DES FLUX DES RESEAUX CELLULAIRES
La solution TRAFFIC TRACKER comporte une partie matérielle (serveurs, ordinateurs,...) et une partie logicielle (Application de transfert des fichiers CDR, Application de traitement des CDR et Application de Reporting et tableau de bord). Elle nécessite une intégration pour la personnalisation par rapport aux usages souhaités par le Client ainsi qu'une adaptation par rapport aux réseaux, leurs interfaces et formats de CDR associés. En effet, TRAFFIC TRACKER comporte deux niveaux : 1. Niveau opérateur : Un serveur de collecte de données sera mis en place pour chaque opérateur, contenant un serveur FTP en assurant le maximum de sécurité pour l'opérateur à travers des connexions sécurisés et des transferts de fichiers en utilisant des protocoles spécifiques pour le cryptage des données transmises. 2. Niveau Régulateur : Au niveau du régulateur, nous installerons une application de transfert de données sous un serveur de données, un serveur de base de données et un serveur Backup ainsi que des ordinateurs pour l'administration des serveurs. Nous détaillons dans ce qui suit les architectures et les fonctionnalités de ces deux niveaux. a. Niveau Opérateur Au niveau des cinq opérateurs dans les salles OMC, nous installerons des serveurs FTP qui communiqueront en temps réel à partir du système de facturation et qui sera connecté en amont du système de médiation. Pour assurer la sécurité des accès aux systèmes des opérateurs, les serveurs seront en mode de connexion asynchrone, c'est à dire que dès qu'ils terminent l'importation des données, la communication sera coupée, pour ouvrir la connexion au serveur de données chez le régulateur en mode pooling. La connexion entre les opérateurs et le régulateur sera assurée par des faisceaux hertziens. La figure ciaprès présente à titre d'exemple l'architecture simplifiée de l'application.
MSC1 Serveur Airtel MSCi Lien FH MSC1 Serveur Opérateur 1 MSCi Lien FH MSC1 Serveurs du Régulateur Serveur Opérateur 2 Lien FH MSCi Lien FH MSC1 Serveur Opérateur 3 Lien FH Niveau Régulateur MSCi MSC1 Serveur Opérateur 4 Lien FH MSCi Niveau Opérateurs Figure 1 : Les deux niveaux de fonctionnement de Traffic Tracker Les données collectées seront transmises au moyen des équipements faisceaux hertziens vers le dispositif de stockage et de traitement installé dans les locaux du Régulateur.
b. Niveau Régulateur Au niveau régulateur, nous mettrons en place : 1 serveur de collecte de données ; 1 serveur de base de données ; 1 serveur Backup ; 3 postes d'administration. Serveur de base de données Serveur de backup Serveur de données du Régulateur Lien FH Niveau Régulateur Figure 2 : Schématisation du niveau régulateur Serveur de collecte de données Ce serveur permettra de collecter les données des serveurs installés chez les opérateurs moyennant des faisceaux hertziens. La fréquence de récupération des données sera définie par le régulateur (5min, 10min,...). Ces données brutes seront converties et importées vers une base de données.
Figure 3 : Exemple de fichier CDR Serveur de base de données lié à un serveur de backup Ce serveur permettra de stocker les données sous formats tableaux afin de permettre l'exploitation des différentes informations ainsi que la consultation des différents reporting (ex : rapport hebdomadaire, mensuel, annuel,...) et tableaux de bord qui auront été générés par le système. Une copie des données sera enregistrée sur le serveur de backup pour garantir la continuité de service en cas de panne. Figure 4 : Exemple de tables créées
3 postes Client Ces postes, sont des postes d'administration qui seront utilisés pour le lancement des requêtes d'analyse et le contrôle du trafic ainsi que le reporting. Liste des pré-requis pour la mise en place de la plateforme matérielle Pour la mise en place de la solution dans les brefs délais, SFM TECHNOLOGIES proposera que o L'aménagement du centre de supervision (Climatisation, Alimentation électrique de 220V énergie, éclairage, transmission, réseau local, tables et chaises utilisateurs, contrôle d'accès,...) sera à la charge de le RÉGULATEUR; o L'aménagement des espaces dans les OMC de chaque opérateur (Energie, transmission, climatisation, éclairage, contrôle d'accès,..) sera à la charge de le RÉGULATEUR; o Allocation d'un espace de 15m² pour le centre de supervision et un espace de 2m² chez les opérateurs. o Les opérateurs doivent prévoir que l'acheminement de l'ensemble des CDR sera en un point unique OMC de l'opérateur.
Description détaillée de la partserveur de collecte de données niveau opérateur Nous proposons de mettre en place cinq (5) serveurs NX58-4RD pour les cinq opérateurs dont les caractéristiques sont détaillées en Annexe 2.d. Figure 5 : Serveur NX58-4RD Serveur de collecte données niveau régulateur Nous proposons de mettre en place un (1) serveur NX58-4RD dont les caractéristiques sont détaillées en Annexe 2.d. Serveur de base de données niveau régulateur Nous proposons de mettre en place un (1) serveur NX58-4RD lié d'un serveur de backup dont les caractéristiques sont détaillées en Annexe 2.c. Poste Administrateur Nous proposons de mettre en place Un (1) poste d'administration NX-2102M dont les caractéristiques sont détaillées en Annexe 1. Figure 6 : Poste d'administration
Ecran de Monitoring - Centre de Supervision Nous proposons de mettre en place cinq (5) Ecrans de monitoring. Imprimante Laser Couleur pour édition des rapports - Centre de Supervision Nous aurons besoin d'une (1) imprimante laser pour le tirage des rapports PDF. Onduleur La mise en place d'un (1) onduleur sera indispensable pour garantir la continuité de service.
Dans cette partie, nous présentons les outils à mettre en œuvre pour le contrôle de flux. La plateforme logicielle comporte 3 modules essentiels : Module 1 : Transfert de fichiers CDR des serveurs des opérateurs vers le serveur du RÉGULATEUR; Module 2 : Application de traitement des CDR sur le serveur du RÉGULATEUR; Module 3 : Application de Reporting et de tableau de bord. En effet, les 3 modules constituent une chaine de fonctionnement : Module 1 Module 2 Module 3 Figure 7 : Interfonctionnement des 3 modules Ainsi, TRAFFIC TRACKER constitue une suite de logiciels intégrés permettant une plus grande flexibilité dans la gestion et optimisation de fonctionnement avec l'utilisation d'outils middleware. Nous détaillons après pour chaque module les fonctionnalités illustrées par des imprimes écran.
a. Module 1 : Application de collecte des CDR L application doit fonctionner dans un environnement Windows coté RÉGULATEUR et coté serveurs des cinq opérateurs. Un serveur Cerberus FTP Server est installé au niveau des cinq opérateurs. Il permet de mieux manipuler les fichiers et de supporter une variété des méthodes d authentification. Figure 8 : Interface du Cerberus FTP Server Pour accéder à l'application, l'utilisateur doit s'authentifier à travers l'application de traitement (Module 2) CDR Engine, intégré à la suite TRAFFIC TRACKER. Figure 9 : Interface d'authentification
Figure 10 : Interface d'accueil de l'application Pour des raisons de sécurité, l'administrateur doit s'authentifier soit en utilisant échangeant des clés d'authentification ou par envoie d un certificat x.509. Pour générer une paire de clé asymétrique, l administrateur est demandé de taper le type de clé, que ce soit RSA ou DSA, ainsi l application génère une clé privée et une clé publique de 512 bits et calcule l empreinte numérique des clés. Figure 11 : Générer une paire de clé asymétrique
Pour la deuxième méthode d'authentification, l administrateur est demandé de remplir un formulaire qui contient les informations nécessaires à la création du certificat. En cliquant sur le bouton «sendrequest», un canal shell interactive est initialisé via une session SSH pour communiquer avec la machine linux à travers le serveur OPENSSH. Une fois que la session est initialisée, et après le succès d authentification, l application envoie des commandes vers la machine linux, précisément vers le serveur OPENSSL pour créer un certificat x.509. Figure 12 : Formulaire de demande de certificat L application récupère le certificat x.509 qui sera ensuite envoyé vers le serveur SFTP. Ce certificat est utilisé comme un conteneur de clé publique. La clé privée va être utilisée au niveau de l application qui s exécute sur le serveur du RÉGULATEUR. La clé publique de l autorité de certification sera utilisée pour vérifier l intégrité de certificat.
Figure 13 : Exemple de Certificat x.509 L'administrateur insérera les adresses IP des serveurs distants. Il doit sélectionner le nombre des serveurs d opérateurs avec lesquelles l application doit communiquer et établir des sessions SFTP. Figure 14 : Interfaces de configuration des adresses des serveurs des opérateurs
Les interfaces qui suivent sont des interfaces dynamiques dont leur apparence dépend du nombre de serveur d opérateur sélectionné par l administrateur. L administrateur doit définir le type d authentification pour initialiser une session SSH. Figure 15 : interface d authentification de client SFTP L administrateur choisit le chemin d un dossier d enregistrement pour chaque serveur. L application lors de téléchargement de fichier CDR filtre le trafic et enregistre les fichiers de chaque serveur dans son répertoire. L Administrateur doit remplir ces informations seulement lors de la première connexion. Les données entrées sont enregistrées en mémoire interne de l application dans des fichiers, ce qui permet d éviter l accès à une base de données, alléger l application et maintenir le bon fonctionnement de l application même en cas de défaillance de la base de données.
Figure 16 : Répertoire d enregistrement Ensuite, l'administrateur est demandé de sélectionner le/les serveur d opérateur et de saisir la date de fichier CDR. Figure 17 : Interface de téléchargement de fichier CDR
En appuyant sur le bouton «Download file from server» une session SFTP est initialisée entre le régulateur et le serveur d opérateur. Trois réponses sont possibles suivant le cas : Echec de téléchargement dû à l impossibilité d ouvrir une session SFTP avec le serveur; Le fichier n existe pas encore au niveau de serveur d opérateur Succès de téléchargement. Figure 18 :Arborescence des fichiers disponibles sur le serveur d operateur Le bouton «advanced option» permet de parcourir l arborescence du serveur d opérateur et visualiser la liste des fichiers CDR disponible, suivant la date. Clic droite sur le nom fichier et une liste d option s apparaisse pour télécharger, renommer ou supprimer le fichier. Pour voir les détails des requêtes échangées en arrière-plan entre l application et le serveur d opérateur, un fichier LOG est disponible pour visualiser les étapes et les informations nécessaires à l établissement d une session SSH.
Figure 19 : Fichier Log Une autre possibilité est offerte par notre application qui permet à l administrateur de sélectionner le/ les serveurs d opérateurs et insérer l heure d exécution (hh :mm). Une fois la commande de récupérations des fichiers lancée, une fenêtre animée qui apparait tout en bas de l écran pour indiquer que l application est en cours d exécution.
Figure 20 : Exécution automatique de l'application Chaque jour à une heure précise l application se lance sans l intervention de l administrateur, initialise des sessions SFTP via des tunnels SSH avec les serveurs d opérateurs, et récupère les fichiers CDR ayant comme date le jour qui précède la date de lancement de l application. Si le fichier CDR est récupéré l application l enregistre dans un dossier local dans le régulateur puis ferme la connexion avec le serveur d opérateur, et se déclenche de nouveau toute les 24 heures. Si le fichier CDR n a pas pu être récupéré, l application ferme la session SSH et essayera de contacter à nouveau le serveur d opérateur pour récupérer ce fichier chaque heure jusqu'à ce qu il soit récupéré.
b. Module 2 : Application de traitement des CDR sur le serveur du Régulateur Une application de traitement des CDR bruts sera installée sur le serveur du régulateur. Cette application permettra de convertir les données d'un format spécifique vers un format lisible pour les enregistrer ensuite dans une base de données. Le temps de traitement des CDR est optimisé afin d'assurer l'enregistrement des données en temps réel. Dès la réception du fichier, l'application sera lancée automatiquement, le fichier CDR est désarchivé ensuite converti en un format lisible. Fichier.ZIP Fichier désarchivé Données Lisibles Figure 21 : Fonction de traitement de CDR Engine Les données seront ensuite enregistrées dans la table correspondante (Originating, Terminating, Roaming,...) de la base de données.
Figure 22 : Exemple de base de données Figure 23 : Extrait de la table contenant les CDR de Transit
La conversion des fichiers CDR brut diffère d'un équipementier à un autre (Ericsson, Huawei, ZTE,...), d'où SFM TECHNOLOGIES aura besoin de la liste des formats CDR avec leurs syntaxes de conversion. Nous présentons dans ce qui suit un exemple de syntaxe de ZTE : Figure 24 : Extrait du fichier de syntaxe - ZTE
c. Module 3 : Application de Reporting et de tableau de bord Le troisième module de la plateforme Traffic Tracker est CDR Analyzer qui permet d'afficher les détails du trafic par opérateur que ce soit en temps réel ou à la demande de l'utilisateur. CDR Analyzer est un outil puissant de supervisons permettant la surveillance 24h sur 24h d'un réseau téléphonique. C'est un outil pratique qui donne tous les détails sur un réseau pendant un temps bien déterminé. CDR Analyzer permettra d'effectuer le contrôle du trafic national et du trafic international. Figure 25 : Choisir entre trafic national et international
Le suivi du trafic national Chaque heure, il fournit toutes les informations sur l'heure passée, permettant ainsi la détection de tous les trafics (roaming, originating, terminating,...) écoulés sur le réseau. Figure 26 : Trafic Temps Réel Vu la valeur de l'information qu'elle traite, CDR Analyzer, ne permettra l'accès seulement si on s'authentifie avec succès.
Figure 27 : Interface d'authentification Conformément au cahier des charges, CDR Analyzer pourra réaliser les extractions suivantes (liste non exhaustive) : Figure 28 :Nombre et Total en minutes des appels (hors roaming)
Figure 29 :Nombre total de SMS Figure 30 :Nombre total de SMS MO
Figure 31 : Nombre total de SMS MT Figure 32 :Liste d'appels d'un MSISDN (SIM)
Le suivi du trafic international De même pour le trafic international, nous pourrons réaliser plusieurs types de statistiques. Figure 33 : Communications Internationales Sortantes Figure 34 : Communications Internationales Entrantes
Figure 35 : Trafic International Temps Réel Ces données pourront être extraites vers un document PDF. Figure 36 : Possibilité de génération d'un rapport PDF
2. Description des accessoires NX-2102M Screen Size Resolution Display Type CPU Memory Hard Drive Network Wireless All-In-One PC 21.5" Wide FHD 1080p (1920x1080) LED Intel G530 2.40GHz 4 GB DDR3 system memory 1 x SATA2 2.5" 500GB HDD On board 100 NIC 54Mbps WIFI Graphics Intel HD Graphics 1000 Web Camara Audio Optical Drive Built-in 1.3M pixels camera On Board Audio None Dimensions Height : Width : Depth : Color Material Aprx Weight Buttons USB Video LAN Audio Power AC Input Silver Magnalium 12.8 Lbs. Power On/Off 4 x USB 2.0 ports 1 x D-Sub VGA port 1 x RJ45 LAN ports ICH4 integrated audio Full-range 100-240V,50/60 Hz,1.5A Max
Product SKUs NX58-2RD Motherboard Supermicro Chipset Processor Socket Supported CPU Series System Bus Memory Memory Capacity Memory Type DIMM Sizes On-Board Devices SATA SAS (Option) 1U Rackmount Server 2 x Hot Swap SATA or SAS HDD X8STi - Default X8STi-LN4-4 NIC on Board X8STi-3F - SAS HDD Support Intel X58 Express chipset ICH10R LGA 1366 Socket Intel Core i7 / i7-965 Extreme Intel Xeon 5500 / 3500 series QPI (up to 6.4 GT/s) Up to 24 GB of system memory Three Channel memory bus 6 DIMM sockets DDR3 1333 / 1066 / 800MHz ECC / non-ecc Un-Buffered 256MB, 512MB, 1GB, 2GB, 4GB 6 x SATA ports Intel ICH10R SATA (3.0Gbps) Controller RAID 0, 1, 5, 10 support 8 x SAS / SATA 6 x SATA ports
IPMI Network Controllers Graphics System BIOS BIOS Type BIOS Features Chassis Form Factor Dimensions Aprx Weight Drive Bays Internal External Buttons LEDs USB Rear I/O Ports VGA LAN USB Keyboard / Mouse Buttons LSI SAS1068E RAID 0, 1, 10 support (Optional : AOC-IButton68) RAID 5 support Support for Intelligent Platform Management Interface v.2.0 IPMI 2.0 with virtual media over LAN and KVM-over-LAN support Winbond WPCM450 BMC 2x Intel 82574L Gigabit Ethernet Controllers Supports 10BASE-T, 100BASE-TX, and 1000BASE-T, RJ45 output 1x Realtek RTL8201N PHY (dedicated IPMI) Matrox G200eW 8 MB DDR2 32Mb SPI Flash EEPROM with AMI BIOS DMI 2.3 PCI 2.2 ACPI 1.0/2.0 USB Keyboard support SMBIOS 2.3 1U Rackmount Height : 1.75" - 44.4 mm Widht : 16.9" - 430 mm Depth : 22.4" - 569mm 45 Lbs 4 x 3.5" SATA/SAS Hot-swap drive bay Slim-type DVD-ROM Slim-type Floppy Drive Power On/Off System Reset Alarm Mute Power Status Hard Drive activity Network actitvity Fan Failure System Overheat Warning 2 x USB ports 1 x D-Sub 15-pin port 2 x RJ45 LAN ports (X8STi-F / 3F) 4 x RJ45 LAN ports (X8STi-LN4) 1 x USB ports PS/2 keyboard and mouse ports Power On/Off System Reset Alarm Mute
LEDs Serial Port Audio Expansion Slots PCI-Express Profile System Cooling Fans Power Supply Output Watts Power Status Hard Drive activity Network actitvity Fan Failure System Overheat Warning 1 x Fast UART 16550 serial port n/a 1 x PCI-e (x16) 2.0 slot (via raiser card) Standard Profile 5 x 40mm fans mid chassis 1 x 40mm fan rear chassis CPU heatsink and fan 400 Watts
d. Serveur Central au niveau du régulateur
e. Serveurs Data
MySQL est un système de gestion de base de données (SGBD). Il est distribué sous une double licence GPL et propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde1, autant par le grand public (applications web principalement) que par des professionnels, en concurrence avec Oracle, Informix et Microsoft SQL Server. MySQL Enterprise Edition inclut l'ensemble de fonctionnalités avancées, d'outils de gestion et de support technique le plus complet pour atteindre les niveaux d'évolutivité, de fiabilité et de disponibilité les plus élevés de MySQL. Il réduit les risques, les coûts et la complexité pour développer, déployer et gérer des applications MySQL critiques pour les entreprises. (Voir plus de détails en Annexe). Ce système de base de données interagit avec l'application de traitement des CDR d'une part et avec l'application de traitement des données et de reporting d'une autre part.
Le serveur sftp a été réalisé en fonction de deux objectifs majeurs : o Répondre aux préoccupations de sécurité inhérent au opérateurs : Lorsque le serveur du régulateur envoie une commande pour accéder au serveur FTP des opérateurs, il devra au préalable avoir été défini dans l annuaire du serveur sous un nom logique qui portera un code user et un mot de passe différents de ceux dont il se sert pour accéder aux serveurs des autres opérateurs. Ainsi, son profil réel d accès aux serveurs des opérateurs ne circulera jamais en clair sur les lignes ce qui évitera tout risque de piratage. Le domaine de son identification étant limitée à l accès au serveur FTP, il ne pourra agir que sur les fichiers qui auront été mis à disposition pour son compte par l administrateur du serveur FTP de l'opérateur. L utilisateur client pourra récupérer un fichier mis à disposition mais en aucun cas ne pourra physiquement le supprimer du système. Les répertoires sont crées dans la même manière dans les différents serveurs. Lorsqu'on importe les données des serveurs des opérateurs, on enregistre en mémoire tampon le nom du dernier fichier importé. o Automatiser le fonctionnement de l'application de traitement des CDR.
Figure 37 :Spécification du serveur FTP à mettre en place