2016

Dveloppement dune
plateforme pour le
suivi de la qualit de
service en LTE

CYCLE DE FORMATION
DES INGENIEURS EN
TELECOMMUNICATIONS
USER

Ralis par: ZOGHBI Zied

Encadr par: ZGHAL Hamdi
Priode du stage: de 01/07/2016
27/08/2016
Anne universitaire : 2015/2016
4
 Remerciements

Avant tout dveloppement sur cette exprience professionnelle, il apparat opportun de

commencer ce rapport de stage par des remerciements, ceux qui mont beaucoup
appris au cours de ce stage.

En hommage leur sympathie, je tiens remercier vivement tous les responsables de

GET Wireless de leur chaleureux accueil et de leurs multitudes daides avec une grande
sincrit et gratitude. Je tiens remercier M. Hamdi ZGHAL, Responsable Unit de
Mesures et Interventions qui a assur avec bienveillance lencadrement de ce projet.
Jadresse aussi mes remerciements

M. Aymen HENTATI et M. Nadhmi HELALI.

De ma part, j'espre que ma conduite et mon apprentissage ont laiss une bonne
impression de SUPCOM.

5
 Rsum

La qualit de service des rseaux mobiles prsente un facteur majeur de

diffrenciation entre les oprateurs.

Les travaux mens dans le cadre de ce projet consistent la conception et

l'implmentation de deux applications :
Une application mobile qui permet de mesurer la qualit de service du rseau
mobile 4G. Cette application permet de vrifier le bon fonctionnement du rseau
tout endroit. Cet outil sert galement grer la qualit de service grce des
mesures envoyes par lapplication mobile vers loprateur.
Une application web pour la visualisation des diffrentes mesures envoyes
loprateur.

Mots-cls : QoS, RSRP, RSRQ, SNR, DL, UL.

6
7
Table des matires

Introduction gnrale ............................................................................................................................ 9

Chapitre1: Prsentation de GET Wireless et du cadre du projet ..................................................... 10
I. Introduction :.................................................................................................. Erreur ! Signet non dfini.
II. Prsentation de lorganisme daccueil: .................................................................................................... 10
III. Cadre du projet:................................................................................................................................................. 11
IV. Problmatique: .................................................................................................................................................. 11
V. Etude de lexistant:........................................................................................................................................... 11
VI. Solution propose: ........................................................................................................................................... 12
VII. Conclusion: .......................................................................................................................................................... 12
Chapitre 2: Qualit de Service en LTE ................................................................................................ 13
I. Introduction: ................................................................................................................................ 13
II. LTE: Architecture gnrale: ......................................................................................................................... 13
1. Rseau daccs (Access Network) : ....................................................................................... 14
2. Rseau cur (Core Network) : .............................................................................................. 14
III. Qualit de Service en LTE: ............................................................................................................................ 17
1. Dbit de linterface radio....................................................................................................... 17
2. Connexion permanente ......................................................................................................... 17
3. Latence .................................................................................................................................. 17
4. Mobilit ................................................................................................................................. 18
5. Coexistence et Interfonctionnement avec la 3G ................................................................... 18
6. Flexibilit dans lusage de la bande ....................................................................................... 18
7. Support du multicast ............................................................................................................. 18
8. Couverture de cellule importante dans les zones urbaines et rurales.................................. 18
IV. Paramtres du rseau mobile LTE: ........................................................................................................... 18
V. Conclusion: .......................................................................................................................................................... 20
Chapitre 3: Spcification et tude conceptuelle ................................................................................ 21
I. Introduction ........................................................................................................................................................ 21
II. Dtermination des besoins ........................................................................................................................... 21
1. Acteurs du systme : ............................................................................................................. 21
2. Besoins fonctionnels :............................................................................................................ 21
3. Besoins non fonctionnels : .................................................................................................... 22

5
 4. Description gnrale du fonctionnement de la plateforme : ............................................... 23
5. Diagrammes de cas dutilisation : ......................................................................................... 24
6. Diagramme de classes : ......................................................................................................... 27
7. Diagramme de squences : ................................................................................................... 28
8. Outils de conception :............................................................................................................ 33
III. Conclusion: .......................................................................................................................................................... 33
Chapitre 4: Ralisation ........................................................................................................................ 34
I. Introduction:....................................................................................................................................................... 34
II. Framework et langages de programmation utiliss: ......................................................................... 34
1. Java : ...................................................................................................................................... 34
2. Java 2 Entreprise Edition (J2EE) : ........................................................................................... 34
III. Protocoles utiliss: ........................................................................................................................................... 37
IV. Environnement logiciel: ................................................................................................................................. 37
1. Android studio : ..................................................................................................................... 37
2. Netbeans : ............................................................................................................................. 37
3. Le SGBD MySQL : ................................................................................................................... 38
4. Glassfish : .............................................................................................................................. 38
V. Application mobile: .......................................................................................................................................... 38
1. Prsentation de lapplication mobile : .................................................................................. 38
2. Etude dun parcours rel: ...................................................................................................... 41
VI. Application web: ............................................................................................................................................... 45
1. Prsentation de lapplication web :....................................................................................... 45
2. Statistiques : .......................................................................................................................... 47
3. Map :...................................................................................................................................... 50
VII. Conclusion: .......................................................................................................................................................... 50
Conclusion gnrale et perspectives .................................................................................................. 51
Bibliographie ........................................................................................................................................ 52

6
Liste des figures

Figure 1 : Architecture Gnrale du LTE ..................................................................................................................................... 13

Figure 2: Architecture de lE-UTRAN ............................................................................................................................................ 14
Figure 3: Vue Globale du Rseau Cur EPC ............................................................................................................................... 15
Figure 4: Latence pour chaque multiplexage ............................................................................................................................ 17
Figure 5: Architecture gnrale de la plateforme ................................................................................................................... 23
Figure 6: Parts de march mondiale des OS de smartphones de 2012 2016 (%) ................................................. 23
Figure 7: Diagramme de cas dutilisation de lapplication mobile ................................................................................... 24
Figure 8: Cas dutilisation : Envoyer rclamation ................................................................................................................... 25
Figure 9: Cas dutilisation : Tester le dbit en Downlink et/ou en Uplink ................................................................... 25
Figure 10: Cas dutilisation : Afficher les mesures dj effectues .................................................................................. 26
Figure 11: Diagramme de cas dutilisation de lapplication web ...................................................................................... 27
Figure 12: Diagramme des classes gnral ................................................................................................................................ 27
Figure 13: Diagramme de squences du scnario mesure et enregistrement des indicateurs de rseau ..... 29
Figure 14: Diagramme de squences du scnario denvoie de rclamation ............................................................... 29
Figure 15: Diagramme de squences du scnario de test de dbit en Uplink ............................................................ 30
Figure 16: Diagramme de squences du scnario analyse thmatique partir de lapplication mobile ....... 31
Figure 17: Diagramme de squences du scnario analyse statistique ........................................................................... 31
Figure 18: Diagramme de squences du scnario analyse thmatique partir de lapplication web ............. 32
Figure 19: Diagramme de squences du scnario analyse statistique partir de lapplication web ............... 32
Figure 20: Logo de lapplication mobile ...................................................................................................................................... 38
Figure 21: Interface daccueil de lapplication mobile........................................................................................................... 38
Figure 22: Menu de lapplication mobile. .................................................................................................................................... 39
Figure 23: Interface Cell info Figure 24: Interface Signal Strength .......................................... 39
Figure 25: Interface Throughput ............................................................................................................................................. 40
Figure 26: Interface Claim ........................................................................................................................................................... 40
Figure 27: Interface KPI ............................................................................................................................................................... 41
Figure 28: Parcours dtude .............................................................................................................................................................. 41
Figure 29: Etalement des mesures du RSRP sur une carte Map ....................................................................................... 42
Figure 30: Analyse statistique des mesures du RSRP ............................................................................................................ 42
Figure 31: Etalement des mesures du RSRQ sur une carte Map ....................................................................................... 43
Figure 32: Analyse statistique des mesures du RSRQ ........................................................................................................... 43
Figure 33: Etalement des mesures du SNR sur une carte Map .......................................................................................... 44
Figure 34: Analyse statistique des mesures du SNR .............................................................................................................. 45
Figure 35: Interfaces daccueil de lapplication web .............................................................................................................. 46
Figure 36: Menu de lapplication web .......................................................................................................................................... 46
Figure 37: Choix des paramtres partir de lapplication web ........................................................................................ 46
Figure 38: Camembert RSRP Figure 39: Histogramme RSRP .............................................................. 47
Figure 40: Camembert RSRQ Figure 41: Histogramme RSRQ ............................................................ 47
Figure 42: Camembert SNR Figure 43: Histogramme SNR .......................................................... 48
Figure 44: Camembert Download Speed Test Figure 45: Camembert Upload Speed Test ............................... 48
Figure 46: Histogramme Download Speed Test Figure 47: Histogramme Upload Speed Test ................... 48
Figure 48: Statistiques des rclamations de la mauvaise qualit de service .............................................................. 49
Figure 49: Etalement des paramtres radio sur une carte Map ....................................................................................... 50

7
Liste des tableaux

Tableau 1: Valeurs du RSRP ................................................................................................................ 19

Tableau 2: Correspondance entre Les Resource Blocks et la Bandwidth ....................................... 20
Tableau 3: Valeurs du RSRQ................................................................................................................ 20

8
 Introduction gnrale

La qualit de service QoS (Quality Of Service) prsente un lment majeur dans les
rseaux mobiles. Cette notion de QoS agit directement sur les clients de l'operateur. Plus
que l'oprateur veille sur sa qualit du rseau, plus que le client est satisfait. La QoS dans
les rseaux cellulaires est dfinie comme la capacit des oprateurs tlphoniques pour
fournir un service satisfaisant ses abonnes. La qualit de service comprend la qualit
de la voix, la force du signal, le taux de blocage d'appel, les dbits levs pour les
applications multimdia et le succs de l'acheminement des diffrents services, ce qui
est en relation directe avec le dbit propos par l'oprateur.

C'est dans ce cadre que se situe ce projet de stage dingnieur intitul "
Dveloppement dune plateforme pour le suivi de QoS en LTE ". Cette plateforme est
compose d'une application CEM sous Android qui permet de mesurer les paramtres
de la QoS et qui fourni aussi aux abonns un moyen de rclamer les problmes du rseau
mobile. La plateforme est aussi compose dun dashbord web application pour la
visualisation des diffrentes mesures. L'objectif de ce projet est de concevoir une
application appele "LTE Quality of Service" ddie aux tlphones mobiles dots de la
plateforme Android. Cette application permet un abonn 4G de pouvoir mesurer les
diffrents indicateurs des services du rseau mobile. Cette application peut tre un outil
pour le golocalisation des problmes du rseau par les oprateurs.

Ainsi, un utilisateur disposant d'un terminal Android pourrait dclencher un test

selon sa position et de consulter les analyses des divers indicateurs : la couverture, la
qualit de signal, le dbit de tlchargement et de transfert dun fichier. Ces analyses
sont faites soit en temps rel partir du test en cours, soit partir dun test fait
prcdemment. A la fin de chaque test, les mesures seront enregistres dans la mmoire
interne du terminal. Cette application permet aussi denvoyer les mesures vers un
serveur install chez loprateur.

Le prsent projet est compos de quatre chapitres. Le premier chapitre comporte

une tude sur l'environnement dans lequel sinscrit notre projet. Le deuxime chapitre
comporte une tude sur ltat de lart de la QoS dans le rseau mobile 4G. Le troisime
chapitre prsente la spcification des besoins tout en essayant de recenser tous les
acteurs et la nature des interactions avec le systme et de prciser les besoins
fonctionnels et non fonctionnels. Ainsi, que la conception de l'application. Dans le
quatrime chapitre, on va exposer l'environnement utilis pour le dveloppement de
notre plateforme et prsenter les interfaces dcrivant les principales fonctionnalits
implmentes dans nos applications web et mobile.

On clture la fin par une conclusion gnrale avec quelques perspectives pour
l'amlioration de cette plateforme.

9
 Chapitre1: Prsentation de GET Wireless et du
cadre du projet

I. Introduction:

Dans ce chapitre, on va mettre notre projet dans son cadre gnral. En premier lieu,
il y aura une prsentation de la socit GET Wireless. En deuxime lieu, on va noncer la
problmatique, et on prsentera notre solution aprs l'tude de quelques solutions
prtablies. Ensuite, on prsente une tude gnrale sur la qualit du service dans le
rseau mobile 4G.

II. Prsentation de lorganisme daccueil:

1. Prsentation gnrale de lentreprise :

GET WIRELESS (Global Expertise Telecom Wireless) est ne en 2001 pour

rpondre des challenges dinnovation dans un environnement technologique volutif
et rvolutionnaire. GET Wireless a dvelopp une expertise technique reconnue dans les
diffrentes phases de conception, dploiement, optimisation et exploitation des rseaux
radio. Elle se place en tant que socit de conseils en ingnierie, et daccompagnement
dans la mise en place de solutions pour le compte des oprateurs tlcoms. Grce ses
alliances avec les meilleurs acteurs dans le domaine, GET Wireless se positionne en tant
que leader sur le march tunisien des technologies mobiles. Elle offre aux entreprises
des services de contenus valeurs ajoutes et dveloppe des technologies dans le
domaine du marketing mobile. [1]

2. Domaines dactivits :

GET Wireless est dot dun dpartement SAV (Services valeurs ajoutes) trs
performant rpondant aux exigences de communication sur le march des technologies
de linformation et de la communication (TICs).
Un dpartement technique Rseaux mobiles de GET WIRELESS intervient sur les
systmes suivants :

Les rseaux cellulaires comme le GSM 900, PCS 1900, DCS 1800, CDMA, TETRA,
LTE.
Les rseaux sans fils fixes (Rseaux de Boucle Locale Radio).
Les rseaux de nouvelles gnrations permettant notamment laccs internet
mobile comme le GPRS, lUMTS et le LTE.

10
III. Cadre du projet:

Le domaine de tlcommunications est un secteur trs concurrentiel. Il touche

essentiellement le besoin du client cible, ce qui a fait en comptition tous les oprateurs
amliorer la qualit de leur service. On peut dfinir la QoS comme laptitude dun
service rpondre adquatement des exigences qui visent satisfaire ses usagers. Le
suivi et le maintien de cette qualit ncessite un contrle continu de ltat de
fonctionnement du rseau.
La QoS joue un rle important dans les rseaux mobiles, surtout durant le progrs
technologique de ces dernires annes. La QoS sest impos comme tant une politique
qui arrangera les problmes rencontrs. Ce mcanisme sappuie sur des indicateurs de
performance qui sont obtenus partir dune ou plusieurs mesures. Ces indicateurs
permettent de localiser les anomalies du rseau et les zones en manque de QoS.
Avec les diffrentes exigences pour le LTE qui est rcemment planifi et dimensionn
en Tunisie, il est ncessaire de dvelopper des mthodes de mesure et de vrification
des paramtres de la qualit de service dans ce rseau.

IV. Problmatique:

Limportance de la QoS dans les rseaux mobiles nest plus dmontrer, mais la
mesure et la vrification de cette qualit de service restent encore le souci important des
oprateurs. A cet gard, les outils danalyses de QoS classiques sont dun ct trs cher,
devant une application mobile, et dautre cot prennent beaucoup de temps et les
conditions dutilisation des matires sont contraignantes : matriels fragiles,
encombrants, ncessitant de formation, des outils de formation.

Grce au systme dexploitation Android et ses fortes capacits en terme de

dveloppement et de son aptitude calculer les diffrents indicateurs de la qualit de
service aussi bien lexploitation de son service de golocalisation et la mobilit des
terminaux Android. Dans ce contexte, notre projet a pour objectif de mettre en place une
application professionnelle pour tester le rseau mobile LTE en tant quutilisateur final,
permettant aux oprateurs de mesurer les paramtres rseau et visualiser les analyses
en temps rel. Ainsi que pour les clients peuvent vrifier chaque jour la qualit du
rseau et vrifier lequel oprateur est le meilleur son endroit.

V. Etude de lexistant:

Plusieurs applications mobiles qui traitent la qualit de service existent sur le

march, certaines sont payantes et dautres sous licence libre et chacune offre des
fonctionnalits bien spcifiques.

11
 G-NeTracK

Cest un outil open source qui permet de dterminer quelques indicateurs de la qualit
de service. [2]
Il est capable de :
Afficher quelques paramtres du rseau.
Etaler ces paramtres sur une carte Map.
Enregistrer les indicateurs du rseau dans un tableau, une fois lapplication est
ferm touts les donnes seront perdus.

Cependant, cette application ne peut pas assurer lenregistrement des mesures.

QualiPoc Android
Cest une application payante qui permet de tester tous les services proposes par un tel
oprateur. [3]
Elle est capable de :
Dterminer les diffrents indicateurs du rseau en diffrents technologie 2G,
3G et 4G.
Raliser des analyses statistiques des indicateurs mesurs.
Etaler les mesures enregistres sur une carte Map.

Mais, avec cet outil on ne peut pas envoyer les mesures vers loprateur.

VI. Solution propose:

Parmi toutes ces solutions prsentes aucune ne reprsente une solution optimale
qui satisfait les besoins de GET Wirelesss pour le suivi de la QoS en LTE. En effet, il ny a
pas un outil qui englobe toutes les fonctionnalits demandes. Chacun de ces outils est
destin offrir des fonctionnalits bien spcifiques. De plus que les produits gratuits
posent un problme au niveau danalyse des rsultats obtenus. Do la solution propose
pour ce projet consiste dvelopper un outil qui donne la possibilit de :

Afficher et enregistrer les paramtres du rseau mobile LTE dans la mmoire

interne du terminal.
Prsenter un service contenu et en temps rel pour le suivi de la qualit de
service en LTE
Prsenter les analyses statistiques et cartographiques de mesures enregistres.
Transfrer les mesures vers un serveur.
Tester les services proposs tel que : tlchargement et envoie dun fichier,

VII. Conclusion:

Ce chapitre tait rserv la prsentation de lorganisme daccueil GET Wireless ,

la prsentation du cadre gnrale du projet ainsi que la solution propose. Au cours du
chapitre suivant on dtaillera davantage la qualit de service en LTE ainsi que ses
diffrentes exigences.

12
 Chapitre 2: Qualit de Service en LTE

I. Introduction:
LTE : Long Terme Evolution (connu sous le nom de la 4G), est la dernire technologie
sans fil apparu. La 3GPP a dfini cette technologie comme R8 suite au succs quont
connu les rseaux UMTS/HSPA. Elle est base sur des techniques radios telles que
lOFDMA et le MIMO permettant le transfert de donnes trs haut dbit, avec une porte
plus importante, un nombre dappels par cellule suprieur et une latence plus faible.

II. LTE: Architecture gnrale:

La figure ci-dessous dcrit larchitecture globale du rseau, en incluant non
seulement le rseau Cur et le rseau daccs, mais aussi dautres blocs, et cela dans
le but de montrer la relation entre eux. Pour une simplification, la figure montre
seulement les interfaces de signalisation. Dans des cas, les deux (signalisation et DATA)
sont supports par les interfaces (comme S1, s2 ou 3G PS Gi interfaces) mais, dans
dautres cas les interfaces sont ddis pour les plans de contrle, et ne supportent que la
signalisation (comme les interfaces S6 et la S7).Les nouveaux blocs spcifis pour le LTE,
connu aussi sous le nom dEPS (Evolved Packet System), sont lEPC (Evolved Packet
Core) et lE-UTRAN (Evolved UTRAN).
Dautres blocs sont galement affichs, comme lUTRAN (le rseau daccs de
lUMTS), les deux parties PS et CS du rseau cur, relis respectivement, au rseau dIP
public (ou priv) et au rseau du tlphone. LIMS (IP Multimedia Subsystem) est
localis au sommeil de la parties cur et fournit laccs aux rseaux IP publique et
priv, et le rseau public du tlphone via les entits du rseau Media Gateway [4] et [5]

Figure 1 : Architecture Gnrale du LTE

13
 1. Rseau daccs (Access Network) :

La seule entit prsente dans laccs est leNodeB qui peut tre assimil un NodeB+ RNC.
LeNodeB est le responsable de la transmission et de la rception radio avec lUE.

A la diffrence de lUTRAN 3G o sont prsentes les entits NodeB et RNC, larchitecture e-

UTRAN ne prsente que des eNodeB. Les fonctions supportes par le RNC ont t
rparties entre leNodeB et les entits du rseau cur MME/SGW. LeNodeB dispose
dune interface S1 avec le rseau cur. Linterface S1 consiste en S1-C (S1-Contrle)
entre leNodeB et la MME et S1-U (S1-Usager) entre leNodeB et la SGW. Une
nouvelle interface X2 a t dfinie entre les eNodeBs adjacents. Son rle est de
minimiser la perte de paquets lors de la mobilit de lusager en mode ACTIF (Handover).
Lorsque lusager se dplace en mode ACTIF dun eNodeB un autre eNodeB,
de nouvelles ressources sont alloues sur le nouvel eNodeB pour lUE, or le rseau
continu transfrer les paquets entrants vers lancien eNodeB tant que le nouvel
eNodeB na pas inform le rseau quil sagit de lui relayer les paquets entrants pour cet
UE. Pendant ce temps lancien eNodeB relaie les paquets entrants sur linterface X2 au
nouvel eNodeB qui les remet lUE. [4] ,[5] et [6].

Figure 2: Architecture de lE-UTRAN

2. Rseau cur (Core Network) :

En effet, la SAE est le nom dune tude o la 3GPP industrie dveloppe une structure
pour une volution et migration des systmes courants un systme qui supporte des
technologies d'accs multiples, avec un plus haut taux de donnes et bas sur la
commutation de paquets. Alors que lEPC (Evolved Packet Core) ou le CPE est le nom
du rseau cur volu. [6], [7] et [8].
la diffrence des rseaux 2G et 3G o lon distinguait les domaines de commutation de
circuit (CS, Circuit Switched) et de commutation de paquet (PS, Packet Switched) dans
le rseau cur, ce nouveau rseau quant lui ne possde quun domaine paquet appel
EPC. Ainsi, tous les services devront tre offerts sur IP y compris ceux qui taient
auparavant offerts par le domaine circuit tels que la voix, la visiophonie, le SMS, etc.

14
 Il est possible de faire acheminer le trafic de lEPC vers laccs LTE, CDMA-2000
(paquet), 2G (paquet) et 3G (paquet) et ainsi garantir le handover entre ces technologies
daccs.
LEPC supporte les Default bearers et les Dedicated bearers, cest--dire lorsque
lusager se rattache au rseau EPC, ce dernier lui cre un dfaut bearer qui reprsente une
connectivit permanente tant que lusager est rattach au rseau mais sans dbit garanti. Quand
lusager souhaitera tablir un appel qui requiert une certaine qualit de service telle que
lappel voix ou visiophonie, le rseau pourra tablir pour la dure de lappel un
dedicated bearer qui supporte la qualit de service exige par le flux de services et
surtout qui dispose dun dbit garanti afin dmuler le mode circuit.

Figure 3: Vue Globale du Rseau Cur EPC

Le rseau cur volu EPS consiste comme le montre la figure en les cinq principales
entits numres ci-dessous :

Mobility Management Entity

Entit de gestion de mobilit, MME : la MME est le nud principal de contrle du

rseau d'accs LTE/SAE. Elle manipule un certain nombre de fonctionnalits telles que :
Le suivi des UE Mode Inactif (idle).
Lactivation / dsactivation du Bearer.
Le choix du SGW pour un UE.
Le handover Intra-LTE impliquant la location du nud du rseau daccs.
Linteraction avec le HSS pour authentifier un utilisateur en attachement
et implmentation des restrictions d'itinrance.
Elle agit comme un licenciement pour la Non-Access Stratum (NAS).
Elle Fournit des identits temporaires pour les UEs.
La SAE/MME agit en point de terminaison pour le chiffrement de protection des
NAS de signalisation. Dans le cadre de cela, il s'occupe galement de la gestion de
la cl de scurit. En consquence, la MME est le point o l'interception lgale de
signalisation peut tre effectue.

15
 La procdure de Paging.
L'interface S3 se terminant dans la MME fournit ainsi la fonction de plan
de contrle de mobilit entre les rseaux d'accs LTE et 2G/3G.
Le MME/SAE termine galement l'interface S6 pour le HSS pour l'itinrance UEs.
La MME/SAE fournit un niveau considrable de fonctionnalits de contrle
global.

Serving Gateway (SGW)

La passerelle de service SGW, est un lment plan de donnes au sein de la LTE/SAE.

Son objectif principal est de grer la mobilit du plan utilisateur, elle agit galement
comme une frontire principale entre le Radio Access Network, RAN et le rseau cur.
La SGW maintient galement les chemins de donnes entre les eNodeBs et les
passerelles PDN. De cette faon le SGW forme une interface pour le rseau de donnes
par paquets l'E-UTRAN. Aussi quand les UEs se dplacent dans les rgions des servies
par des eNodeBs diffrentes, la SGW sert de point d'ancrage de mobilit veillant ce que
le chemin de donnes soit maintenu.

PDN Gateway (PGW)

La passerelle LTE/SAE PDN assure la connectivit pour l'UE des rseaux de paquets
de donnes externes, remplissant la fonction d'entre et de sortie pour les donnes UE.
L'UE peut disposer d'une connectivit avec plus d'un PGW pour laccs des PDNs
multiples.

Home Subscriber Server (HSS)

Avec la technologie LTE, le HLR est rutilis et renomm HSS. Le HSS est donc un
HLR volu qui contient linformation de souscription pour les rseaux GSM, GPRS,
3G, LTE et IMS. A la diffrence de la 2G et de la 3G o linterface vers le HLR est
supporte par le protocole du monde SS7, MAP, linterface S6 sappuie sur le protocole
du monde IP, DIAMETER. Le HSS est une base de donnes qui est utilise simultanment
par les rseaux 2G, 3G, LTE/SAE et IMS appartenant au mme oprateur. Il supporte
donc les protocoles MAP (2G, 3G) et DIAMETER (LTE/SAE, IMS).

Policy and Charging Rules Function (PCRF)

La PCRF est le nom gnrique de l'entit au sein de la LTE SAE/EPC qui dtecte les flux de services
et applique la politique de tarification. Pour les applications qui ncessitent une
politique dynamique de tarification ou de contrle, un lment du rseau intitul
Applications Function, AF est utilise.

16
 III. Qualit de Service en LTE:

1. Dbit de linterface radio

Linterface radio E-UTRAN doit pouvoir supporter un dbit maximum instantan de
100 Mbit/s en considrant une allocation de bande de frquence de 20 MHz pour le sens
descendant et un dbit maximum instantan de 50 Mbit/s en considrant aussi une
allocation de bande de frquence de 20MHz pour le sens montant. Les technologies
utilises sont OFDMA (Orthogonal Frequency Division Multiple Access) pour le sens
descendant et SC-FDMA (Single Carrier - Frequency Division Multiple Access) pour le
sens montant. Cela correspond une efficacit du spectre de 5 bit/s/Hz pour le sens
descendant et 2,5 bit/s/Hz pour le sens montant.
Il faut aussi que le LTE en Tunisie est oprationnel sur des bandes des frquences
de 10MHz.

2. Connexion permanente
Principe des accs haut dbit o la connectivit est permanente pour laccs Internet.
Mais mme si la connexion est permanente au niveau du rseau, il est ncessaire pour le
terminal de passer de ltat IDLE ltat ACTIF lorsquil sagira denvoyer ou recevoir du
trafic. Ce changement dtat sopre en moins de 100 ms. Le rseau pourra recevoir le
trafic de tout terminal rattach puisque ce dernier dispose dune adresse IP, mettre en
mmoire ce trafic, raliser lopration de paging afin de localiser le terminal et lui
demander de rserver des ressources afin de pouvoir lui relayer son trafic.

3. Latence
Latence du plan de contrle
Lobjectif fix pour le LTE est damliorer la latence du plan de contrle par rapport
lUMTS, via un temps de transition infrieur 100 ms entre un tat de veille de lUE et
un tat actif autorisant ltablissement du plan usager.
Latence du plan usager
La latence du plan usager est dfinie par le temps de transmission dun paquet entre la
couche IP de lUE et la couche IP dun nud du rseau daccs ou inversement. En
dautres termes, la latence du plan usager correspond au dlai de transmission dun
paquet IP au sein du rseau daccs. Le LTE vise une latence du plan usager infrieure
5 ms dans des conditions de faible charge du rseau et pour des paquets IP de petite
taille. Le tableau 2.1 prsente les deux types de latence existante dans le rseau LTE,
ainsi que leurs diffrences dans les domaines de duplexage (FDD et TDD).

Figure 4: Latence pour chaque multiplexage

17
 4. Mobilit
Assure des vitesses comprises entre 120 et 350 km/h. Le handover pourra
seffectuer (la LTE ne permet que le hard handover et non pas le soft handover) dans des
conditions o lusager se dplace grande vitesse.

5. Coexistence et Interfonctionnement avec la 3G

Le handover entre E-UTRAN (LTE) et UTRAN (3G) doit tre ralis en moins de 300
ms pour les services temps-rel et 500 ms pour les services non temps-rel. Il est clair
quau dbut du dploiement de la LTE peu de zones seront couvertes. Il sagira pour loprateur
de sassurer que le handover entre la LTE et la 2G/3G est toujours possible. Le handover
pourra aussi seffectuer entre la LTE et les rseaux CDMA-2000. Les oprateurs CDMA
volueront aussi vers la LTE qui devient le vrai standard de communication mobile de
4me gnration.

6. Flexibilit dans lusage de la bande

E-UTRAN doit pouvoir oprer dans des allocations de bande de frquence de
diffrentes tailles incluant 1.25, 2.5, 5, 10, 15 et 20MHz.

7. Support du multicast
Notamment pour les applications multimdia telles que la tlvision en broadcast.

8. Couverture de cellule importante dans les zones urbaines et

rurales
Comme la LTE pourra oprer sur des bandes de frquences diverses et notamment
basses comme celle des 700 MHz, il sera possible de considrer des cellules qui pourront
couvrir un large diamtre.

Tout au long de cette section ddie ltude de la qualit de service en LTE, on a

consult les rfrences suivantes : [4], [7], [8] et [9].

IV. Paramtres du rseau mobile LTE:

Aprs la phase de dploiement du rseau cellulaire intervient la phase dexploitation
et de maintenance. Dans cette phase lajustement des paramtres de travail est une
tche essentielle. Cette tche permet lactivation ou la dsactivation de certaines
fonctionnalits pour assurer le maintien de la qualit et loptimisation du rseau.

18
 Il y a deux types de paramtres :

Les paramtres constructeurs (ou fournisseur dquipement) : Ce sont des

paramtres systme (activation de certaines fonctionnalits tel que le contrle de
puissance, le chiffrement) prconiss par le constructeur et sont aussi, lis
lquipement (version de logiciel).
Les paramtres ingnierie : Ce sont des paramtres linitiative des oprateurs et
ils sont modifis au niveau de lOMC. Loptimisation des paramtres du rseau est
un processus dlicat mais une tche essentielle. Pour maintenir une qualit de
service acceptable suite des modifications de certaines fonctionnalits ou des
services de loprateur.

Loptimisation des paramtres du rseau est un processus dlicat mais une tche
essentielle. Pour maintenir une qualit de service acceptable suite des modifications de
certaines fonctionnalits ou des services de loprateur.

Il existe plusieurs paramtres logiques en LTE, mais les plus important parmi eux et
qui agissent directement sur la QoS sont :

Signal to Interference plus Noise Ratio (SINR) : est mesur par UE sur la base
des Resource Blocks (RB). LUE calcule les SINRs sur chaque RB, les convertit
en CQI Channel Quality Indicator et les rapporte leNodeB o il est utilis
pour slectionner le MCS le plus appropri pour la transmission de donnes
d'utilisateur en un RB particulier. La valeur SINR dfinit le MCS qui doit tre
utilis pour un RB cest--dire le nombre de bits par symbole de modulation
transmettre cest -dire le dbit atteindre pour un RB particulier, ainsi que le
nombre de RB allouer par eNodeB l'utilisateur. SINR peut tre dfini comme
tant le rapport de la puissance du signal la somme de la puissance
d'interfrence moyenne des autres cellules et le bruit.

Reference Signal Received Power (RSRP) : est une mtrique lie la puissance
de signal reu partir dune cellule et qui est utilise comme entre pour la
slection de la cellule et les dcisions du handover. Pour une cellule particulire,
RSRP est dfinie comme tant la puissance moyenne (en watts) des Resource
Elements (RE) qui transportent les signaux de rfrence (RSs) spcifiques des
cellules dans la bande passante considre. Les mesures de RSRP, normalement
exprim en dBm, sont utilises principalement pour faire le classement entre les
diffrentes cellules candidates en fonction de leurs forces de signal.

Tableau 1: Valeurs du RSRP

19
 Reference Signal Received Quality (RSRQ) : une mesure de qualit de signal
spcifique la cellule. Semblable la mesure de RSRP, cette mtrique est utilise
principalement pour fournir le classement entre les diffrentes cellules
candidates en fonction de leur qualit de signal. Cette mesure peut tre utilise
comme une entre pour la slection de cellules et des dcisions du Handover
dans des scnarios (par exemple) dans lesquels les mesures de RSRP ne sont pas
suffisantes pour prendre des dcisions fiables dans la slection de cellule et le
Handover intercellulaire.

RSRQ = (N x RSRP) / (LTE carrier RSSI) (1)

O N est le nombre des Physical Resource Blocks (PRBs) sur lesquels est
mesur le RSSI, typiquement gale la bande passante du systme.

Tableau 2: Correspondance entre Les Resource Blocks et la Bandwidth

Tableau 3: Valeurs du RSRQ

Received Signal Strength Indicator (RSSI) : est la moyenne linaire de la

puissance totale reue de toutes les sources, y compris les cellules servantes et
les cellules, l'interfrence de canal adjacent et le bruit thermique, dans la bande
passante de mesure sur N RB. RSSI est utilis comme entre pour calculer la
mesure LTE RSRQ dcrit ci-dessus.
A partir de l'quation ci-dessus. (1), on voit qu'en raison de l'inclusion de RSSI,
RSRQ prend en considration l'effet combin de la force du signal et les
interfrences. Il peut galement tre observ que mathmatiquement RSRQ est
proportionnelle RSRP.

V. Conclusion:

Au cours de ce chapitre, on a donn une vue globale sur larchitecture du le rseau

mobile LTE ainsi que la qualit de service en prcisant les paramtres logiques
mesurer. La prochaine tape est de se focaliser sur les besoins fonctionnels et non
fonctionnels de la plateforme ainsi que la conception.

20
 Chapitre 3: Spcification et tude conceptuelle

I. Introduction
Etant donn que lanalyse des besoins est une tape dterminante, il faut avoir une
vue claire des diffrents besoins escompts de notre projet. La premire partie de ce
chapitre prsente l'ensemble des besoins fonctionnels et non fonctionnels que notre
plateforme doit fournir. La deuxime partie portera sur les diffrents cas d'utilisations
dans notre systme, et on finit par l'tude conceptuelle de l'application.

II. Dtermination des besoins

1. Acteurs du systme :

Un acteur dsigne le rle jou par une personne ou une entit externe au systme qui
interagit avec celui-ci. Pour notre systme on a identifi les acteurs suivants :

Un utilisateur de lapplication android est celui qui va lancer les tests : les tests
sont les mesures des paramtres radio RSRP, RSRQ, SNR, ou des tests de dbits
(en Downlink et/ou en Uplink). Cet utilisateur peut galement faire des
rclamations de la mauvaise qualit de service.
Le rseau mobile : c'est une entit indispensable pour notre application,
l'existence de cette entit permet de bien calculer les diffrents indicateurs du
rseau.
Un utilisateur de lapplication web est celui qui va visualiser les diffrents
paramtres de la qualit de service envoys partie de lapplication android.

2. Besoins fonctionnels :

Pour lister les diffrentes fonctionnalits que devrait offrir la plateforme

dvelopper, on dcrit ci-aprs les scnarios d'utilisation. La plateforme est compose
dune application android et une application web. Lapplication android concevoir et
dvelopper permettra l'utilisateur de pouvoir tout voir et tout contrler partir de son
Smartphone Android tout moment et tout endroit. Un utilisateur pourra lancer le test
qui comportera :

21
 Affichage des paramtres du rseau suivants :

Nom de loprateur auquel lutilisateur est connect.

Si lutilisateur est connect au rseau LTE.
Le dbit de tlchargement en Mbps.
Le dbit de transfert en Mbps.
La position actuelle : longitude et latitude.
Code de rseau mobile (MNC) : cest un code spcifique de chaque oprateur.
Code mobile de pays (MCC) : un code spcifique de chaque pays.
Lidentifiant de la cellule serveuse (CID).
Code de la zone de routage (TAC).
Niveau du signal (RSRP).
Qualit de signal (RSRQ).

Enregistrement des paramtres du rseau dans une base de donnes interne.

Analyse statistique des paramtres rseau partir des mesures enregistr dans
la base de donnes interne.
Etaler les paramtres sur une carte Map partir des mesures enregistres dans la
base de donnes interne.
Visualiser quelques KPI sur les paramtres rseau sous forme de camembert et
dhistogramme partir des mesures enregistr dans la base de donnes interne.
Tlcharger un fichier afin de tester le dbit de tlchargement.
Envoyer un fichier vers un serveur pour tester le dbit de transfert.
Reporting en temps rel (transfert des mesures vers le serveur).
Envoyer des rclamations de la mauvaise qualit de service vers le serveur.

La plateforme est aussi compose dune application web qui permettra

lutilisateur visualiser les mesures et les paramtres, reus partir des terminaux des
abonns LTE qui ont install lapplication android, et sauvegards dans la base de
donnes centrale. Lutilisateur peut soit taler les mesures sur une carte Map soit
afficher quelques KPIs sous la forme de camemberts et de histogrammes.

3. Besoins non fonctionnels :

Contrainte ergonomique : les deux applications doivent prsenter des interfaces

simples et conviviales pour que l'utilisateur ait une manipulation aise.
Contrainte sur la fiabilit des applications : les applications ne doivent pas
prsenter des bugs.
Contrainte dvolution : les applications doivent permettre une maintenance
facile, et tre volutives.

22
 4. Description gnrale du fonctionnement de la plateforme :

Notre plateforme est constitue de deux applications (une application android et une
application web), un serveur et une base de donnes comme le montre la figure ci-
dessous.

Figure 5: Architecture gnrale de la plateforme

L'application android comporte cinq principaux scnarios pour chaque service :

La mesure des indicateurs de rseau si lutilisateur est connect un rseau LTE.

La consultation des analyses des diffrents indicateurs.
Lutilisateur peut envoyer les mesures vers un serveur en temps rel (Reporting).
Envoyer des rclamations au serveur en cas de mauvaise qualit de service.
Tlcharger ou envoyer un fichier du tlphone vers un serveur et enregistrer le
dbit de tlchargement et transfrer les mesures vers le serveur.

Un Smartphone est un tlphone mobile construit sur un systme d'exploitation

mobile, avec des capacits de calcul plus avances et une connectivit d'un tlphone
simple. Il peut supporter des applications mobiles construites avec des langages de
programmation spcifique.
Le march des systmes d'exploitation des Smartphones est divis en plusieurs OS.
Comme le montre la figure ci-dessous, Android est leader dans le march, suivi de l'iOS.

Figure 6: Parts de march mondial des OS de smartphones de 2012 2016 (%)

23
 Daprs cette figure prcdente, on peut dduire que 86,2% des Smartphone en 2016
utilise lAndroid comme systme dexploitation. C'est pour cette raison on a opt pour le
dveloppement de notre application sur l'OS Android.

Lapplication web comporte deux principales fonctionnalits :

Etalement des diffrentes mesures et des rclamations effectues par les

utilisateurs, qui ont install lapplication android sur leurs terminaux, sur une
carte Map.
Consultation des analyses des diffrents indicateurs et Affichage de ces analyses
sous la forme de camemberts et dhistogrammes.

5. Diagrammes de cas dutilisation :

Un diagramme de cas d'utilisation permet de dcrire l'interaction entre le l'acteur et

le systme en dterminant les besoins de l'utilisateur et tout ce que doit faire le systme
pour l'acteur.

Le diagramme reprsent dans la figure suivante dcrit le diagramme de cas

d'utilisation gnral de lapplication mobile.

Figure 7: Diagramme de cas dutilisation de lapplication mobile

24
 En procdant l'application mobile, le client LTE doit choisir un des services qu'il
veut tester et quon peut les rsumer ainsi :

Un des services offert lutilisateur est denvoyer des rclamations en cas de

mauvaise qualit de service o il doit identifier le type de rclamation et ajouter
une description du problme.

Figure 8: Cas dutilisation : Envoyer rclamation

Si l'utilisateur choisit de le service Download il doit entrer lURL du fichier

tlcharger. Pour le service Upload lutilisateur doit imprativement indiquer le
fichier transfrer, Ladresse du serveur distant, le login et le password. Pour les
services des rclamations et des tests de throughput, le client LTE a le choix de
sauvegarder les paramtres de ces services dans la mmoire interne du terminal
ou de les envoyer vers le serveur et par la suite sauvegarder dans la base de
donnes centrale.

Figure 9: Cas dutilisation : Tester le dbit en Downlink et/ou en Uplink

25
 Un autre service qui sera effectu en arrire plan est de tester les paramtres
radio (RSRP, RSRQ, SNR). partir de ce dernier service lapplication offre
lutilisateur un suivi en temps rel lorsquil y a un changement de ces paramtres.
Chaque mesure de ses paramtres sera automatiquement sauvegarde dans la
base de donnes interne dans le terminal du client LTE et envoye vers le serveur
et par la suite sauvegarder dans la base de donnes centrale.
Lapplication offre au client LTE la possibilit danalyser les mesures dj
effectues et enregistres et dafficher le rsultat de lanalyse sous la forme de
camemberts ou dhistogrammes. Pour ce faire le client LTE doit identifier le
paramtre (pour le throughput : en downlink ou en uplink, pour les
rclamations : le type de rclamation et pour les paramtres radio : RSRP, RSRQ,
SNR) analyser et le type daffichage.
Lapplication offre galement au client LTE la possibilit dtaler les mesures dj
effectues et enregistres sur une carte Map. Pour ce faire le client doit
uniquement identifier le paramtre (pour le throughput : en downlink ou en
uplink, pour les rclamations : le type de rclamation et pour les paramtres
radio : RSRP, RSRQ, SNR).

Figure 10: Cas dutilisation : Afficher les mesures dj effectues

En procdant l'application web, lutilisateur effectue le suivi de la qualit de

service en LTE partir des mesures effectues par les clients LTE et sauvegardes dans
la base de donnes centrale. Pour ce faire lutilisateur doit identifier le paramtre (pour
le throughput : en downlink ou en uplink, pour les rclamations : le type de rclamation
et pour les paramtres radio : RSRP, RSRQ, SNR) et choisir le type daffichage
(camemberts ou histogrammes si lutilisateur veut effectuer des analyses sur ce
paramtre ou Map sil veut ltaler sur une carte Map)

26
 Figure 11: Diagramme de cas dutilisation de lapplication web

6. Diagramme de classes :

Le diagramme de classes sert pour dfinir la structure statique du systme en

montrant les objets dans le systme, les relations entre les objets, les attributs et les
oprations qui caractrisent chaque classe d'objets. La figure ci-dessous dcrit le
diagramme de classes gnral de la plateforme.

Figure 12: Diagramme des classes gnral

27
 Le diagramme des classes de la plateforme est compos de cinq principales classes.
En effet jai implment les classes suivantes :

Classe SIM Subscriber Identity Module : cette classe permet de rcuprer les
donnes (MSISDN Mobile Station ISDN Number : est le numro connu du
public de l'usager , IMSI International Mobile Subscriber Identity : est un
numro unique, qui permet un rseau mobile d'identifier un usager, ICCID
Integrated Circuit Card Identifier est unique et correspond au numro de
srie de la Carte SIM, MCC Mobile Country Code est un code pays sur
trois chiffres, standardis par l'Union internationale des tlcommunications
(UIT)pour les rseaux de tlphonie mobile, MNC Mobile Network Code est
utilis en combinaison avec le MCC pour l'identification univoque
du rseau d'un oprateur de tlphonie mobile ainsi que le SIM Operator
Name et SIM Serial Number). tant connect un rseau mobile LTE dun
oprateur et partir de cette carte SIM, on peut effectuer plusieurs mesures des
paramtres radio. On peut galement lancer plusieurs tests de dbits et envoyer
des rclamations en cas de mauvaise qualit de service.
Classe Mesure : cette classe permet de rcuprer les paramtres radio (RSRP,
RSRQ, SNR, ). Une mesure est effectue une position et une date bien
dtermine. Les paramtres de la position sont la latitude et la longitude ainsi
que leNodeB auquel le client LTE est connect.
Classe Rclamation : partir de cette classe le client LTE peut rclamer la
mauvaise qualit de service. Une rclamation est identifie par une identit, un
type de rclamation et une description de la rclamation en question. Une
rclamation est effectue une position et une date bien dtermine. Les
paramtres de la position sont la latitude et la longitude ainsi que leNodeB
auquel le client LTE est connect.
Classe Dbit : partir de cette classe le client LTE peut lancer des tests de dbit
en downlink et/ou en uplink. Un test de dbit est identifi par une identit et les
valeurs du test de dbit (download et upload). Un test de dbit est effectu une
position et une date bien dtermine. Les paramtres de la position sont la
latitude et la longitude ainsi que leNodeB auquel le client LTE est connect.
Classe eNodeB : cette classe permet didentifier les eNodeBs. Les attributs de
cette classe sont : Cell ID est une valeur qui permet didentifier de faon unique
un eNodeB, PCI Physical Cell Identity et TAC Tracking Code Area.

7. Diagramme de squences :

Les diagrammes de squences sont les reprsentations graphiques des interactions

entre les acteurs et le systme selon un ordre chronologique dans la formulation UML.
Dans ce qui suit, on prsente le diagramme de squence pour quelques scnarios.

28
 a. Application mobile : diagrammes de squences

Lapplication mobile offre un client LTE plusieurs services. Un des principaux

services de lapplication est la mesure des paramtres radio. La figure ci-dessous dcrit
le diagramme de squences du scnario de mesure des indicateurs de rseau.

Figure 13: Diagramme de squences du scnario mesure et enregistrement des indicateurs

de rseau

Ds que le client lance lapplication, le service de mesure des paramtres radio sera
lancer en arrire plan. En cas de changement de ces paramtres, l'utilisateur aura un
affichage instantan de la valeur de chaque indicateur. Ensuite, lapplication les
sauvegarde dans la base de donnes locale et affiche un message lutilisateur. Une fois
les indicateurs sont sauvegards dans la base de donnes locale, lapplication procde
lenvoie de ces mesures au serveur qui se charge de leurs enregistrement dans la base de
donnes centrale.

Un deuxime service offert au client LTE est le reporting en cas de mauvaise qualit
de service. La figure ci-dessous dcrit le diagramme de squences du scnario dun
envoie de rclamation.

Figure 14: Diagramme de squences du scnario denvoie de rclamation

29
 Le client LTE commence par identifier le type de rclamation et le problme en
question. Ensuite, il a le choix entre la sauvegarde de la rclamation dans la base de
donnes locale et lenvoie de cette rclamation vers le serveur. Le premier cas est trs
utile lorsque le client na pas accs linternet cet instant. Dans le deuxime cas, le
serveur se charge de lenregistrement de cette rclamation dans la base de donnes
centrale.

Un autre service est offert au client travers lapplication : il sagit du test de dbit
en downlink ou en uplink. La figure ci-dessous dcrit le diagramme de squences du
scnario de test de dbit en uplink.

Figure 15: Diagramme de squences du scnario de test de dbit en Uplink

Le client commence par choisir un fichier envoyer depuis la carte SD de son

smartphone. Il doit galement saisir ladresse du serveur distant ainsi que son login et
son mot de passe. Ensuite, ds que le test est lanc par le client et Si ces paramtres sont
correctes, un message indiquant que la connexion avec le serveur est tablie et
lapplication procde lenvoie du fichier. Une fois lenvoie du fichier est achev,
lapplication calcule de dbit en uplink et affiche le rsultat du test au client. Le client a
toujours le choix entre lenregistrement du rsultat du test dans la base de donnes
locale et lenvoie du rsultat vers le serveur pour le sauvegarder dans la base de donnes
centrale.

On prsente maintenant le diagramme de squences du scnario analyse thmatique

dans la premire figure de la page suivante. Il sagit de ltalement des diffrentes
mesures effectues par le client sur une carte Map.

30
 Figure 16: Diagramme de squences du scnario analyse thmatique partir de
lapplication mobile

Pour taler les indicateurs de rseau ou les rclamations enregistres dans la base de
donnes locale, lutilisateur doit en premier temps identifier lindicateur taler, puis
ds que le client demande ltalement de cet indicateur, les donnes seront rcupres.
La valeur et la position de chaque indicateur seront envoyes vers une carte pour les
afficher.

On prsent dans la figure suivante le diagramme de squence du scnario analyse

statistique dans la figure ci-dessous. Il sagit dune analyse des diffrentes mesures
effectues par le client reprsente sous la forme de camembert ou dhistogramme selon
le choix du client.

Figure 17: Diagramme de squences du scnario analyse statistique

Pour analyser les indicateurs de rseau ou les rclamations enregistres dans la

base de donnes locale, lutilisateur doit en premier temps identifier lindicateur
analyser ainsi que le type daffichage (camembert ou histogramme), puis ds que le
client demande lanalyse de cet indicateur, les donnes seront rcupres. La valeur et la
position de chaque indicateur seront envoyes vers un web view pour les afficher.

31
 b. Application web : diagrammes de squences

Lapplication web offre essentiellement lutilisateur deux services. Un des deux

services de lapplication est lanalyse thmatique des paramtres radio et des
rclamations de la mauvaise qualit de service en les talant sur une carte Map. La figure
ci-dessous dcrit le diagramme de squences du scnario de cette analyse thmatique.

Figure 18: Diagramme de squences du scnario analyse thmatique partir de

lapplication web

Pour taler les indicateurs de rseau ou les rclamations enregistres dans la base de
donnes centrale, lutilisateur doit en premier temps identifier lindicateur taler, puis
ds que le client demande ltalement de cet indicateur, les donnes seront rcupres.
La valeur et la position de chaque indicateur seront envoyes vers une carte pour les
afficher.

Le deuxime service de lapplication web est lanalyse statistique des diffrents

paramtres radio et des rclamations de la mauvaise qualit de service en les
reprsentant sous la forme de camemberts ou histogrammes. La figure ci-dessous dcrit
le diagramme de squences du scnario de cette analyse statistique.

Figure 19: Diagramme de squences du scnario analyse statistique partir de

lapplication web

32
 Pour analyser les indicateurs de rseau ou les rclamations enregistres dans la
base de donnes centrale, lutilisateur doit en premier temps identifier lindicateur
analyser ainsi que le type daffichage (camembert ou histogramme), puis ds que
lutilisateur demande lanalyse de cet indicateur, les donnes seront rcupres. La
valeur et la position de chaque indicateur seront envoyes vers un web view pour les
afficher.

8. Outils de conception :

a. StarUML :
Le langage de modlisation unifi, de l'anglais Unified Modeling Language (UML),
est un langage de modlisation graphique base de pictogrammes conu pour fournir
une mthode normalise pour visualiser la conception d'un systme. Il est couramment
utilis en dveloppement logiciel et en conception oriente objet.

StarUML est un logiciel de modlisation UML, cd comme open source par son
diteur, la fin de son exploitation commerciale, sous une licence modifie de GNU GPL.
L'objectif de la reprise de ce projet tait de se substituer des solutions commerciales
comme IBM Rational Rose ou Borland Together. StarUML gre la plupart des diagrammes
spcifis dans la norme UML 2.0.

b. Power AMC :
PowerAMC est un logiciel de conception qui permet de modliser les traitements
informatiques et leurs bases de donnes associes. Il se destine aux architectures de
donnes, aux architectures dinformations et aux architectures dentreprise.
Avec PowerAMC, offrez enfin, votre entreprise, des mthodes efficaces danalyse
dimpact, de gestion des changements et des techniques avances de gestion des
mtadonnes. Dot de fonctions uniques bases sur les techniques de modlisation et de
la gestion des donnes, PowerAMC prend en charge tous les environnements
architecturaux.

PowerAMC a t lun des premiers outils qui permet dlaborer des modles de
donnes de manire graphique et de les implmenter quel que soit le SGBD et ce de
manire automatique. De mme, loutil permet de modliser les processus mtiers.
PowerAMC permet de raliser tous les types de modles informatiques. Il reste un
des seuls qui permet de travailler avec la mthode Merise permettant damliorer la
modlisation, les processus, le cot et la production dapplications.

III. Conclusion:

Dans ce chapitre, on a spcifi les fonctionnalits de notre plateforme, ce qui a

permis de distinguer le rle de chaque acteur dans ce processus. Aprs cette phase de
spcification, on a entam l'tude conceptuelle qui a permis de faire le tour de
diffrentes vues du systme et de construire les modles de faon faciliter la phase de
ralisation.

33
 Chapitre 4: Ralisation

I. Introduction:

Avant de passer l'tape de l'implmentation, on va dcrire l'environnement du

travail qui a permis de mettre en ouvre la conception aborde dans le chapitre
prcdent. Cette partie constitue le dernier volet de ce rapport, elle a pour objet de
prsenter le travail achev lors de ce projet.

II. Framework et langages de programmation utiliss:

1. Java :

Android est un systme d'exploitation conu pour les tlphones mobiles dvelopps
par Google, qui a mis disposition un kit de dveloppement logiciel SDK (Software
Development Kit) bas sur le langage Java. On rappelle que Java est la fois un langage
de programmation informatique orient objet et un environnement d'excution
informatique portable. Java permet de dvelopper des applications autonomes mais
aussi, et surtout, des applications client-serveur. Ct client, les applets sont l'origine
de la notorit du langage. C'est surtout ct serveur que Java s'est impos dans le
milieu de l'entreprise grce aux servlets, le pendant serveur des applets, et plus
rcemment les JSP (JavaServer Pages) qui peuvent se substituer PHP, ASP et ASP.NET.

2. Java 2 Entreprise Edition (J2EE) :

Java 2 Enterprise Edition, destin un usage professionnel avec la mise en uvre des
serveurs dapplications. Chaque dition prsente un environnement complet pour le
dveloppement et l'excution d'applications bases essentiellement sur Java et contient
notamment une machine virtuelle Java (Java Virtual Machine) ainsi qu'un ensemble de
classes. J2EE s'appuie entirement sur le Java, il bnficie de ses avantages ainsi que ses
inconvnients. Gnralement, on parle de plate-forme J2EE pour dsigner l'ensemble
constitu des services (API) offerts et de l'infrastructure d'excution.

On utilise J2EE pour prsenter lapplication web de notre plateforme. En effet, les
ingnieurs de loprateur doivent consulter cette application pour suivre les
performances des services offertes en les talant sur des cartes Map ou partir des
camemberts ou des histogrammes qui vont tre affichs. Ainsi, on donne loccasion
lquipe de diagnostiquer les problmes de la QoS et proposer enfin des solutions pour
rendre la fonctionnalit normale du systme

34
Les spcifications JEE portent sur trois lments particuliers :

Les Servlets. Il sagit dapplications ou de fragments dapplication qui sexcutent

au sein dun serveur HTTP (plus prcisment dans un conteneur de servlets).
Elles peuvent traiter les requtes HTTP reues par le serveur et retransmettre
des donnes dans les rponses HTTP. Etant donn quil sagit du langage Java, les
servlets peuvent exploiter toutes les API fournies en standard.
Les JSP (Java Server Pages). Il sagit dune technologie destine gnrer
dynamiquement des pages web (HTML, XML, etc.). Ces pages se prsentent sous
la forme dun document web classique dans lequel il est possible dintgrer des
portions de code Java qui seront traites par le serveur avant lenvoi vers le
client.
Les Enterprise JavaBeans (EJB). Il sagit de composants logiciels distribus (i.e.
pouvant tre dploys sur des serveurs distants) dont la logique de
communication (RMI, CORBA, RPC) est laisse au serveur dapplications (et plus
spcifiquement un conteneur dEJB). On distingue trois sortes dEJB :
Les EJB Entit, qui permettent de reprsenter des donnes et sur lesquels un
langage de requte proche du SQL (EJBQL) permet deffectuer des oprations.
Les EJB Session, qui permettent de proposer des services et peuvent tre
convertis rapidement en service web. Ils peuvent aussi enregistrer des tats
(Stateful).
Les EJB Message, qui permettent daccomplir des tches de manire asynchrone
(nouveau processus ct serveur).
Donc, tout le projet est bas sur Java/J2ee comme tant un environnement de
dveloppement, mais cet environnement est li dautres technologies quon doit les
signaler tel que :

Javascript :

JavaScript est un langage de programmation de scripts principalement utilis pour

les pages Web interactives. C'est un langage orient objets prototype, c'est dire que
les bases du langage et ses principales interfaces sont fournies par des objects qui ne
sont pas instancis au sein de classes mais qui sont chacun quips de constructeurs
permettant de gnrer leurs proprits, et notamment une proprit de prototypage qui
permet d'en gnrer des objets hritiers personnaliss.

html5, css3 :

LHyperText Markup Language, gnralement abrg HTML, est le format de

donnes conu pour reprsenter les pages web. Cest un langage de balisage permettant
dcrire de lhypertexte, do son nom. HTML permet galement de structurer
smantiquement et de mettre en forme le contenu des pages, dinclure
des ressources multimdias dont des images, des formulaires de saisie, et des
programmes informatiques. Il permet de crer des documents interoprables avec des
quipements trs varis de manire conforme aux exigences de laccessibilit du web.

35
 Le terme CSS est l'acronyme anglais de Cascading Style Sheets qui peut se traduire par
"feuilles de style en cascade". Le CSS est un langage informatique utilis sur l'internet
pour mettre en forme les fichiers HTML ou XML. Ainsi, les feuilles de style, aussi appel
les fichiers CSS, comprennent du code qui permet de grer le design d'une page
en HTML.

Android :

Android est un systme d'exploitation ouvert bas sur le noyau Linux et le langage
de programmation Java, destin pour les terminaux mobiles (tlphones portables,
tablettes tactiles, etc.). Sur le domaine applicatif, Android intgre plusieurs services de
Google pour accder rapidement aux services Internet tels que Gmail, You-Tube, Google
Talk et Google Maps. Android dispose d'un SDK (Software Development Kit) offrant une
panoplie d'APIs pour dvelopper une application mobile sur son systme et bnficier
d'une documentation exhaustive et des outils de dveloppement prts l'emploi.

On cite ici les principales qualits d'Android qui on a encourages choisir ce

systme :
- L'interaction avec les services Google est plus aise et offre plus de fonctionnalits.
- Les interfaces utilisateur sont dynamiques.
- Android est gratuit et open source.

SQL :

SQL (Structured Query Language) est un langage utilis pour effectuer des
diffrentes oprations sur la base de donnes tel que la mise jour de la base, la
modification des donnes dans une table (ajout, suppression)etc.

SQLite :

SQLite est un systme de base de donnes qui a la particularit de fonctionner sans

serveur, on dit aussi "standalone" ou "base de donnes embarque". On peut l'utiliser
avec beaucoup de langages : PHP, Python, C# (.NET), Java, C/C++, Delphi, Ruby... Ce
systme a t utilis pour lenregistrement des mesures effectues dans une base de
donnes interne cre sur le smartphone du client LTE et pour viter lenregistrement
dans des fichiers (texte, Excel, ).

JSON :

JSON (JavaScript Object Notation Notation Objet issue de JavaScript) est un format
lger d'change de donnes. Il est facile lire ou crire pour des humains. Ce format
est utilis pour lchange de donnes entre le Smartphone et le serveur.

36
 III. Protocoles utiliss:

Dans ce projet, on a utilis plusieurs protocoles pour garantir la communication

entre le Smartphone et le rseau. Le protocole HTTP est utilis pour assurer l'change
des donnes du tlchargement des pages web. Ce protocole est utilis pour lchange
de donnes entre le Smartphone et le serveur. Le protocole FTP est un protocole du
rseau standard utilis pour transfrer des fichiers d'un hte un autre hte sur un
rseau bas sur TCP, tel que l'Internet, ce protocole assure le fonctionnement du service
du transfert de fichier. Ce protocole est utilis pour le test de dbit en downlink ou en
uplink lors du download ou de lupload dun fichier.

IV. Environnement logiciel:

Dans cette section, il sagit de prsenter les programmes quon a utiliss.

1. Android studio :

Android Studio est lenvironnement de dveloppement officiel de Google qui

remplace lIDE dEclipse (avec donc exactement les mmes fonctionnalits) depuis le 8
dcembre 2014. Cet environnement est ddi pour de dveloppement des applications
android.

Comparaison entre Android Studio et Eclipse

2. Netbeans :

NetBeans IDE est un environnement de dveloppement open source soutenus par

Sun. Il fournit une interface complte permettant de dvelopper des applications Java ou
JSP, des outils destins la gestion de projets, au contrle des versions et au dbogage. Il
offre tous les outils ncessaires la mise en place de pages JSP : coloration syntaxique,
auto-compltion, mais aussi un dbuggeur permettant lexcution pas pas des pages
JSP.

37
 3. Le SGBD MySQL :
MySQL est un systme de Gestion de Base de Donnes(SGBD) qui a pour rle de
grer laccs aux bases de donnes. Le serveur de base de donns MYSQL est trs rapide,
facile utiliser et fiable. Il fonctionne sous la plupart des systmes dexploitation. Ce
logiciel a lavantage dtre gratuit et hautement adapt au web. Lun des points fort de
MySQL est quil est un SGBD de type relationnel comme Microsoft SQL Server et Oracle,
cest--dire quil organise les donnes selon des tables comportant des champs
attributs simples et monovalus.

4. Glassfish :
Glassfish est un serveur dapplication trs utilis dans le processus de
dveloppement dapplications, cre par Sun Microsystems en 2005. En effet, il permet le
dveloppement dapplications distribues en utilisant les technologies comme : EJB, JPA,
JSF et dautres.

V. Application mobile:

1. Prsentation de lapplication mobile :

On a choisit comme nom pour notre application "LTE Quality Of Service" la figure
suivante illustre le logo de lapplication.

Figure 20: Logo de lapplication mobile

Linterface daccueil de lapplication prsente lapplication, le cadre du projet ainsi que

lidentit du SIM et du Smartphone partir duquel les mesures seront effectues.

Figure 21: Interface daccueil de lapplication mobile

38
 Notre application mobile LTE
Quality Of Service prsente un
menu partir duquel le client a
laccs plusieurs interfaces.

Figure 22: Menu de lapplication mobile.

Interfaces Cell Info et Signal Strength :

Figure 23: Interface Cell info Figure 24: Interface Signal Strength

Ces deux interfaces permettent dafficher les paramtres du rseau comme

indique les deux figures prcdentes. Linterface Cell info permet dafficher
les paramtres didentit de la cellule 4G laquelle labonn LTE est associ :
Cell ID et TAC ainsi que les identits de la carte SIM et le smartphone.
Pour linterface Signal Strength , ds que cette interface est lance par le
client, une mesure des paramtres radio sera effectue. Cette mesure comprend
essentiellement les paramtres radio suivant : RSRP, RSRQ, SNR, . partir de
cette dernire interface, le client a le choix entre lenregistrement de cette
mesure dans la base de donnes locale et lenvoie de cette mesure vers le
serveur pour la sauvegarder dans la base de donnes centrale.

39
 Interface Throughput :

Figure 25: Interface

Throughput

partir de linterface Throughput , on effectue une vrification du type du rseau

auquel le client est associ, une vrification daccs linternet et une vrification des
coordonnes GPS du client. Ensuite, lutilisateur peut tlcharger ou envoyer un
fichier vers un serveur en slectionnant soit "Download", soit "Upload". Une fois
lutilisateur a choisie de tlcharger un fichier, il doit entrer le lien de
tlchargement. Aprs de le download de fichier, on calcule le dbit en downlink et
on sauvegarde le fichier dans la SD carte du terminal. Sil a choisie de transfrer un
fichier il doit choisir un fichier partir de la mmoire interne du terminal. Aussi,
lutilisateur est appel a entrer les paramtres du serveur vers lequel il va envoyer le
fichier tel que, ladresse du serveur, login et le mot de passe. En cas derreur par
exemple le serveur nest pas accessible un message derreur sera affich. Une fois
lupload est achev, on calcule le dbit en uplink. Lutilisateur aussi le choix entre
lenregistrement ou lenvoie des valeurs des dbits ainsi testes dans la mmoire
interne du terminal ou vers le serveur.

Interface Claim :

partir de notre application

LTE Quality Of Service , notre
client a la possibilit denvoyer
des rclamations sur la
mauvaise qualit de service.

Figure 26: Interface Claim

40
 Figure 27: Interface KPI

partir de linterface KPI et des diffrentes mesures et des rclamations

sauvegardes dans la base de donnes locale, lutilisateur a la possibilit deffectuer
une tude statistique sous forme de camembert ou dhistogramme. Lutilisateur doit
en premier lieu identifier le paramtre tudier : dbit en downlink ou en uplink, les
rclamations de la mauvaise qualit de service ainsi que les paramtres radio (RSRP,
RSRQ, SNR). Lutilisateur a galement la possibilit dtaler ses paramtres sur une
carte Map pour localiser les problmes.

2. Etude dun parcours rel:

Pour valider les algorithmes de

capture des paramtres radio (RSRP,
RSRQ, SNR,..), on a effectu des
mesures de ces paramtres tout au
long le lavenue de la bourse (Lac II),
lavenue principale lac II et cit
Taieb El Mhiri El Aouina. Les
rsultats des ces tests sont tals sur
une carte Map prsente ci-contre.

Donc, dans la section suivante, on

va prsenter les deux analyses
statistiques et thmatiques de ces
mesures pour tous les indicateurs
tels que le niveau (RSRP) et qualit
de signal (RSRQ, SNR).

Figure 28: Parcours dtude

41
 Figure 29: Etalement des mesures du RSRP sur une carte Map

Figure 30: Analyse statistique des mesures du RSRP

On remarque daprs les figures ci dessus que 50.3% des points de mesures
(marqus en jaune sur la carte Map) prsentent un niveau de signal entre -100 dBm et -
80dBm ce qui implique une couverture moyenne. Alors que 6.9 % des points de mesures
(marqus en orange sur la carte Map) ont une valeur de niveau de signal infrieur -
100dBm, donc une mauvaise couverture, do il faut taler ce paramtre sur une carte
afin de localiser le problme de couverture. Pour le reste, le niveau de signal est
suprieur -80dBm, donc une couverture acceptable. On a prsent lanalyse mentionn
si dessus sous forme de camembert et histogramme. Les trois premires figures
prsentent une imprime dcran de ltalement de niveau de signal RSRP sur une carte.
On remarque que la plupart de cette trajectoire (50.3 + 6.9 = 57.2% des points) prsente
une mauvaise ou une moyenne couverture.

42
 Daprs les trois premires figures, on remarque que les points autour de leNodeB (le
triangle en bleu) prsentent une mauvaise ou une moyenne couverture. Cela est d au
fait que lantenne de leNodeB est un peu tilt vers le haut. Ceci se manifeste aussi
partir des points situs une distance de quelques kilomtres de leNodeB notamment
autour de Ooredoo et qui prsentent une bonne couverture.

Figure 31: Etalement des mesures du RSRQ sur une carte Map

Figure 32: Analyse statistique des mesures du RSRQ

43
 On remarque daprs les figures de la page prcdente que 60.2% des points de
mesures (marqus en jaune sur la carte Map) prsentent un RSRQ entre -10 dB et -5dB
ce qui implique une qualit du signal moyenne. Alors que 13 % des points de mesures
(marqus en orange sur la carte Map) ont une valeur de RSRQ entre -15dB et -10dB,
donc une mauvaise qualit de signal, do il faut taler ce paramtre sur une carte afin
de localiser le problme de la qualit. Pour le reste, le RSRQ est suprieur -5dB, donc
une qualit de signal acceptable. On a prsent lanalyse mentionn si dessus sous forme
de camembert et histogramme. Les trois premires figures prsentent une imprime
dcran de ltalement de la qualit du signal sur une carte. On remarque que la plupart
de cette trajectoire (60.2 + 13 = 73.2% des points) prsente une mauvaise ou une
moyenne qualit.

Figure 33: Etalement des mesures du SNR sur une carte Map

44
 Figure 34: Analyse statistique des mesures du SNR
On remarque daprs les figures ci-dessus que 54.3% des points de mesures
(marqus en jaune sur la carte Map de la page prcdente) prsentent un SNR entre 5
dB et 15dB ce qui implique un rapport de signal sur bruit acceptable. Alors que 6.1 %
des points de mesures (marqus en orange sur la carte Map de la page prcdente) ont
une valeur de SNR entre 0dB et 5dB, donc un rapport signal sur bruit faible, do il faut
taler ce paramtre sur une carte afin de localiser le problme de la qualit. Pour le
reste, le SNR est suprieur 15dB, donc un bon rapport signal sur bruit. On a prsent
lanalyse mentionn si dessus sous forme de camembert et histogramme. Les trois
premires figures prsentent une imprime dcran de ltalement de la qualit du signal
sur une carte. On remarque que la plupart de cette trajectoire (54.3 + 6.1 = 60.4% des
points) prsente un rapport signal sur bruit faible.

VI. Application web:

1. Prsentation de lapplication web :

Lapplication web permet aux ingnieurs de loprateur de suivre les performances

de la qualit de service offert. En effet, partir dune analyse dun ensemble des
camemberts et des histogrammes ou en talant les paramtres sur une carte Map, ils
doivent prciser la cause dun tel problme qui touche la qualit de service chez le client.
Les problmes majeurs qui se posent la couverture et le dbit de transfert de donnes
chez un client. Les ingnieurs de loprateur peuvent aussi suivre les rclamations sur la
mauvaise qualit de service.

La figure suivante prsente les interfaces daccueil de lapplication web et partir de

ces interfaces, lutilisateur peut accder au menu de lapplication.

45
 Figure 35: Interfaces daccueil de lapplication web

La figure suivante prsente le menu de lapplication web et partir de ce menu

lutilisateur a le choix entre la visualisation des paramtres de la qualit de service sur
une carte Map ou davoir des statistiques sous forme de camembert ou dhistogramme
de ces paramtres.

Figure 36: Menu de lapplication web

Ensuite lutilisateur procde au choix du paramtre de qualit de service taler ses

mesures sur une carte Map ou en tudier les statistiques sous forme de camembert ou
dhistogramme.

Figure 37: Choix des paramtres partir de lapplication web

46
 2. Statistiques :

Pour arriver faire une diagnostique des problmes lis la qualit de service, il faut
avoir prsent les KPIs dans des camemberts et des histogrammes qui facilitent
linterprtation, et donc savoir la cause du problme dj signal. Pour cela, on doit
rcuprer les diffrentes donnes issues de la base de donnes pour construire les
camemberts et les histogrammes.

Figure 38: Camembert RSRP Figure 39: Histogramme RSRP

On remarque daprs le camembert ci-contre que 100% des tests des

mesures de RSRP sont entre -120 dbm et -100dbm ce qui permet de
conclure que la puissance de signal reu dans la zone de mesure est assez
faible et par consquent un problme de couverture dans cette zone. Il taler
ce paramtre sur une carte Map pour localiser ce problme.

Figure 40: Camembert RSRQ Figure 41: Histogramme RSRQ

On remarque daprs le camembert ci-contre que 5.3% des valeurs des mesures du
paramtre RSRQ entre -15db et -10db, 28% de ces valeurs sont suprieures -5db et 66.7%
entre -10db et -5db ce qui implique une qualit de signal moyenne dans la zone de mesure.

47
 Figure 42: Camembert SNR Figure 43: Histogramme SNR

On remarque daprs le camembert ci-contre que 30.7% des valeurs des mesures du
paramtre SNR entre 0dB et 5db, et 69.3% de ces valeurs sont entre 5db et 15db ce qui
implique un rapport de signal sur bruit faible dans la zone de mesure.

Lutilisateur peut effectuer des analyses sur les tests de dbits partir des
camemberts et des histogrammes.

Figure 44: Camembert Download Speed Test Figure 45: Camembert Upload Speed Test

Figure 46: Histogramme Download Speed Test Figure 47: Histogramme Upload Speed Test

48
Lutilisateur de lapplication web peut avoir accs aux statistiques sur les rclamations envoyes
loprateur sur la mauvaise qualit de service en spcifiant les problmes en question.

Figure 48: Statistiques des rclamations de la mauvaise qualit de service

49
 3. Map :

Figure 49: Etalement des paramtres radio sur une carte Map
On remarque daprs ltalement des paramtres radio sur une carte Map ci-dessus
que la valeur du RSRP est de -111dBm ce qui traduit un faible niveau de signal, la valeur
du RSRQ est de -9dB ce qui signifie une mauvaise qualit de signal et la valeur du SNR
est de 3dB ce qui signifie un faible rapport signal sur bruit. Quoique leNodeB est trs
proche (100 mtres) de la position o ces mesures ont t effectues, la qualit de
service en ces points est trs mauvaise. Cette mauvaise qualit de service sexplique par
deux raisons. La premire raison est que ces mesures ont t effectues dans le sige de
GET Wireless et plus prcisment en sous-sol ce qui traduit une faible puissance du
signal reue par le terminal. La deuxime raison est que lantenne de leNodeB est un
peu tilt vers le haut ce qui a empch davoir une bonne qualit de signal autour de
leNodeB.

VII. Conclusion:

Dans ce chapitre, on a prsent les plateformes matrielles et logicielles sur lesquelles

on a dvelopp notre projet, ainsi que les technologies employes. On a par la suite,
prsent les interfaces les plus significatives de nos applications web et mobile. On a
aussi tudi un parcours en termes de couverture et de qualit de signal.

50
 Conclusion gnrale et perspectives

La qualit de service prsente un lment majeur dans les rseaux mobiles tant
donn qu'il est en relation directe avec l'utilisateur du rseau mobile qui est le client de
l'oprateur. Pour garantir une qualit de service acceptable, des outils de mesures
doivent tre mis en place. L'organisme "GET Wireless" veille sur ce sujet. Il on a t
confi de concevoir et raliser une plateforme de mesure de la QoS dans le rseau
mobile 4G.

La richesse de ce sujet tait une occasion pour profiter tant dans l'acquisition des
connaissances que dans l'initiation au travail de groupe. Aussi, ce projet li au stage,
tait aussi une opportunit de dcouvrir le monde professionnel, ses ralits, du point
de vue adaptation et difficults.

Comme d'autres applications Android, notre application mobile peut tre aisment
amliore. Grce laspect ouvert de lAndroid qui offre l'opportunit de crer des
logiciels mobiles innovants et rvolutionnaires en encourageant les dveloppeurs
puiser dans leurs imaginations et mobiliser toutes leurs comptences pour le meilleur
de cette plateforme.

On a essay de rpondre le plus possible aux spcifications de la plateforme. Comme

travail de futur, on suggre d'amliorer notre application mobile qu'elle sera installe
dans plusieurs Smartphones. Les clients seront tous les utilisateurs des Smartphones,
qui peuvent mesurer eux mme la QoS des diffrents services et juger sur les services
proposs par leur oprateur. Lamlioration de lapplication mobile peut consister
essentiellement dans la mesure dautres paramtres radio relatifs la qualit de service
en LTE comme le RSSI, le CQI et la latence du plan usager.

51
 Bibliographie

[1] http://www.getwireless-group.com/ , consult le 20/08/2016.

[2] http://www.gyokovsolutions.com/ , consult le 07/07/2016.

[3] http://www.swissqual.com/en/products/optimization2/qualipoc-android/ , consult le

07/07/2016

[4] https://fr.wikipedia.org/wiki/LTE_(r%C3%A9seaux_mobiles) , dernirement consult le

22/08/2016

[5] http://www.eyrolles.com/Chapitres/9782212129908/Chap-3_Wolff.pdf dernire consultation

le 22/08/2016

[6] http://multimedia.fnac.com/multimedia/editorial/pdf/9782212129908.pdf dernire

consultation le 23/08/2016

[7] http://www.efort.com/r_tutoriels/LTE_SAE_EFORT.pdf dernire consultation le 24/08/2016

[8]
http://archive.org/stream/etsi_ts_123_002_v08.05.00/ts_123002v080500p#page/n3/mode/2up
dernire consultation le 24/08/2016

[9] https://cradlepoint.com/sites/default/files/Content/fr-
architectures_reseau_dentreprise_utilisant_la_4g_lte_-eu-wp-network-architectures.pdf dernire
consultation le 24/08/2016

[10] https://fr.scribd.com/document/293026837/QoS-in-LTE dernire consultation le 25/08/2016

[11] http://laroccasolutions.com/training/78-rsrp-and-rsrq-measurement-in-lte/ dernire

consultation le 25/08/2016

[12] http://www.simpletechpost.com/2015/05/rsrp-rssi-and-rsrq.html dernire consultation le

25/08/2016

[13] http://airccse.org/journal/jwmn/7415ijwmn09.pdf dernire consultation le 25/08/2016

52