II. Conception
II.1. Architecture cible de la plateforme
L'objectif de la plateforme de monitoring de la QoS des
réseaux radio 2G/3G est de permettre aux opérateurs mobiles de
fournir un tableau de bord journalier sur l'expérience de ses
clients sur l'utilisation de ses services data offerts. En effet, cette
plateforme consiste à reproduire l'expérience client en
collectant les informations du réseau radio et les transmet aux
ingénieurs de l'opérateur afin diagnostiquer les problèmes
liés à la qualité de service offerte.
La figure suivante présente une vue générale
des composantes de la plateforme et leurs connectivités.
Figure 9:Présentation de l'Architecture de la
plateforme
On présente clairement et de manière un peu plus
détaillé les différentes composantes de la plateforme dans
la figure ci-dessous.
Figure 10:Présentation Détaillée
des composantes de l'Architecture
|
Groupe Tunisie Télécom |PFE#177;Jallali
Mourad#177; 2011/2012
|
19
|
a) Au niveau de l'application cliente, on va collecter les
informations concernant la clé data, le réseau, et la carte Sim
par l'intermédiaire des commandes spécifiques appelées des
commandes AT (voir Annexe A). Ces derniers ont pour rôle
d'assurer la communication avec la clé data. En effet, on envoie une
commande AT à la clé 3G, et on récupère la
réponse, puis on enregistre toutes ces données dans un fichier
local et on les envoie vers un serveur FTP chez l'opérateur. Au niveau
du serveur central, on va créer et enregistrer les données dans
une base de données locale. Ces données vont être mises
à jour dès qu'une une nouvelle connexion s'établie.
b) L'application opérateur permet la
présentation et l'analyse des KPIs data sous plusieurs formes de filtre
et formes graphiques ce qui donne l'occasion de diagnostiquer les
problèmes d'utilisation des clés 3G.
On a exploité le langage UML (Unified Modelin
Language)comme étant langage de modélisation pour concevoir
tout d'abord l'application cliente, puis l'application de mise à jour
au niveau du serveur central, et enfin l'application opérateur en
présentant les diagrammes des cas d'utilisation, des classes et de
séquences relatives à chaque module de chaque application
déjà traitée.
L'UML s'impose comme un standard lorsqu'il s'agit de
modéliser de tels systèmes en suivant une démarche
orientée objets. Il est devenu un langage de modélisation
très répondu, grâce à sa richesse
sémantique.
II.2. Conception Détaillée
II.2.1.Application cliente
L'application cliente a pour rôle principale :
· La collecte d'informations.
· L'enregistrement des données collectées
dans un fichier local.
· L'envoi des fichiers enregistrés de la session
précédente vers un serveur FTP. On présente à
chaque fois les trois diagrammes (diagramme de cas d'utilisation, des classes,
et de séquence).
a) Diagramme de Cas d'Utilisation (Application
Cliente)
Mode de Fonctionnement
On présente dans la figure ci-dessous le mode de
fonctionnement de l'application cliente.
Figure 11:Mode de fonctionnement (Application
Clientèle)
Une fois installé sur l'ordinateur d'un client,
l'application cliente s'exécute automatiquement avec chaque
démarrage du PC ainsi détecte la connexion internet par une
clé 3G++. Avant que l'application commence à collecter et
enregistrer les informations demandées dans un fichier local, elle tente
à envoyer les fichiers déjà enregistrés pendant une
session de connexion précédente puisque que l'action de
déconnexion par le client est imprévisible par l'application. Les
fichiers ainsi générés doivent comprendre les informations
:
· Les Informations de la carte SIM :
- Numéro
SIM
- IMSI
· Les informations de la clé data : - IMEI
- Fabricant
· Les informations du réseau : - Niveau du signal
Min, Avergae et Max.
- CIs enregistrés, LAC
- Mode de technologie radio (GPRS/WCDMA/HSPA+) (%
OPtilisEtiRQU
- Bande passante du lien radio (Débit Max en lien
descendant et montant)
· Les informations de la session de connexion :
- Date de la session.
- Durée de connexion, temps de début et temps de
fin de connexion - Débits utilisateurs Max, Average.
9 )EDI lEPEillDRIMIiFhieIVEMSIIitE le MP SVITIvRinHE
EuMiBITUrp1 FR0aMM n'EuaE SEs d'iP SEF\MN leMRnFtiRns SIinFiSEleMa
l'ESSliFEIiRQ UIfiQ OQIIRis leiliFhieMIvR pIil \HEAuSSriP p
[SEUlIESSliFEtiRn.
Diagramme de cas d'utilisation
associé
La figure ci-GHARWSIpAKA IlMEiEIIEP P IR5HFEN VNIilisEtiRQKH
l'ESSliFEtiRn cliente.
Figure 12:Diagramme de cas d'utilisation (Application
clientèle)
/'utilisEteur dRit d'EERrd se FRnneFter viE une
clé 3G.Une fois connecté, il pourra avoir leATiQRIP EtiRW
IidentifiFEtiRWEinsi11,11l'ensemble des KPIs data. En effet, lIESSliFEtiRQ
clientèle enregistre ces informations dans un fichier local. Dès
que l1[1re1i1161P Ht des données SIBTETiQ l'ESSliFEIiRWMnte
à MR H FH IiFKiRTEKIIH/eur F7 3 FIFKE-] IlIRSpIEteur. Le processus se
termine par la suppression de fichier de la session précédente,
et l1HTFIisAUP MEHIRONIEuGdpEiVEinsiMITles nouvelles valeurs des
KPIs.
b) Diagramme des Classes (Application
Cliente)
La figure ci-dessous présente le diagramme de cas
d'utilisation de l'application cliente.
Figure 13:Diagramme des Classes (Application
Cliente)
Le digramme de classe est utilisé pour présenter
les classes et les interfaces du système ainsi que les
différentes relations entre celles #177;ci. En effet, on a
utilisé les classes suivantes :
· Classe Clé 3G : Cette classe
permet d'identifier et récupérer les données (fabriquant,
le modèle du clé data et l'IMEI « International Mobile
Equipement Identity ») à partir des commandes AT bien
spécifiques.
· Classe Carte Sim : Cette classe
permet de récupérer les données (IMSI «
International Mobile Subscriber Identity » et MSISDN «
Mobile Station ISDN Number ») jà l'aide des commandes AT
bien définies.
· Classe Réseau : Cette classe
donne la possibilité d'avoir toutes les informations à propos le
réseau tel que LAC « Local Area Cell »,CI «
Cell ID »,RSSI « Received Signal Strength Indication
», BER « Bit Error Rate » et le mode de connexion
utilisé(WCDMA,EDGE )à partir aussi des commandes AT bien
déterminées.
· Classe Session Connexion : Cette
classe donne l'idée à ce qui concerne un établissement
d'une session de connexion .En effet, on détermine la date, l'heure de
début et de la fin de connexion, de plus elle calcule la durée de
connexion tout en
identifiant aussi de débit de transfert de
données (débit maximum DL/UL) pendant cette session.
· Classe FileInfos : Cette classe
est destinée pour enregistrer toutes les données
déjà traités (LAC, CI, RSSI, BER, MSI, IMEI, Constructeur,
Mode de connexion (la technologie utilisée), débit max DL,
débit max UL) dans un fichier local puis el(Yo II YI1111e011YHr F73 EK]
IIIRSpIDtAK.
c) Diagramme de Séquence (Application
cliente)
Les diagrammes de séquences permettent de
représenter la collaboration entre les objets selon un point de vue
temporel. On représente dans un premier lieu le diagramme de
séquence (cas système), puis on le présente avec plus de
détails.
Cas Système (Cas
Généralisé)
La figure ci-dessous présente le diagramme de
séquence (cas système) qui évoque 4RTHI TERIR(RatIMEGs
pYq(eP I(tM:'u(eIP DjqIIIIp(p1Dl3.
Figure 14:Diagramme de Séquence (Cas
Système)
Groupe Tunisie Télécom |PFE#177;Jallali
Mourad#177; 2011/2012
|
24
|
|
+ Description détaillée
Ce diagramme présente les différentes interactions
selon un point de vue temporel avec plus de détails. La figure
ci-dessous illustre bien ce déroulement.
Figure 15:Diagramme de Séquence (Description
détaillée) II.2.2. Application Serveur Central
Le serveur central est composé de trois
éléments différents à savoir un serveur FTP, une
base de données et une application qui sert à la mise à
jour de la base de données. Dans notre cas, le serveur FTP sert comme
intermédiaire entre les applications clients qui sont responsables de
générer des fichiers d'informations et la base de données
qui va contenir ces informations. Pour bien gérer les fichiers
reçus depuis les applications clientes et les fichiers sortants
destinés aux mises à jour de la base de données, deux
répertoires seront créés : Un répertoire
appelé IN qui rassemble les fichiers issus des applications clientes et
un autre répertoire OUT qui contient les fichiers dont leurs contenus
ont été ajouté à la base de données.
La figure ci-dessous montre clairement les
éléments intervenant dans cette application.
Figure 16:Présentationde l'application du
Serveur Central
L'application de mise à jour a pour objectif de
récupérer les données des fichiers dans le
répertoire « IN » du serveur FTP, mettre à jour la base
de données et transférer ces fichiers aux répertoires
« OUT » du serveur FTP comme c'est déjà
présenté dans la figure suivante.
Figure 17:Mode de fonctionnement (Application mise
à jour de la base de données)
a) Diagramme de Cas d'Utilisation (Serveur
Central)
Cote Application
Le diagramme suivant présente les interactions entre le
responsable QOS d'une part et le serveur FTP d'une autre part.
Figure 18:Interactions avec Serveur FTP
Le responsable QOS poursuit un procédé bien
déterminé pour avoir une information du fichier
déjà envoyé au serveur FTP. D'abord, il doit se connecter
au serveur FTP, puis il formule la requête SQL et l'envoie à la
base de données. Au retour il y aura la réponse à cette
requête SQL pour pouvoir, enfin, récupérer l'information
à chercher.
Cote Serveur
Le diagramme suivant présente les interactions entre le
serveur FTP d'une part et base de données d'une autre part.
Figure 19:Interactions avec Base de
Données
Le diagramme ci-dessus montre l'interaction entre le serveur
et la base des données. En effet,
le serveur commence d'abord par
envoyer les requêtes une par une. Ces derniers seront
traités
immédiatement par la base. Enfin, la base envoie les
réponses vers le serveur qui les
transmettra vers le répertoire « OUT »,
là oil on enregistre les données qui passeront par la base de
données pour une mise à jour continue.
b) Diagramme des Classes (Serveur Central)
La figure ci-dessous présente le diagramme des classes de
l'application serveur central.
Figure 20:Diagramme des Classes (Serveur
Central)
Le diagramme présente les interactions entre les
différentes classes utilisées afin de mieux présenter et
expliquer le fonctionnement de l'application serveur central. En effet on a
fait recours aux classes suivantes :
· Classe Fichierinfos : Cette classe a
pour rôle de créer le fichier (.XML) pour l'enregistrement des
données déjà collectées et l'envoyer au serveur
FTP. Une fois envoyé, ce fichier sera supprimé.
· Classe RepertoireIN : Cette classe
permet de récupérer toutes les fichiers qui proviennent des
applications clientes.
· Classe RepertoireOUT : Cette classe
contient les fichiers déjà générés par les
applications clientes mais avec mise à jour de la base de
données.
c) Diagramme de Séquence (Serveur
Central)
La figure ci-dessous présente le diagramme de
séquence de l'application serveur central.
Figure 21:Diagramme de Séquence (Serveur
Central)
| 
