UNIVERSITE LIBANAISE

FACULTE DE GENIE
BRANCHE 1
No d'ordre 68/1460/G1-EE/2013

BRANCHE 1
PROJET DE FIN DTUDES
Ralis par

Nour KOUZAYHA
Pour obtenir le

Diplme d'Ingnieur en lectricit et lectronique

Option Informatique et Tlcommunications

Evaluation des Mcanismes dAccs Alatoires

dans les Rseaux LTE pour le Support des
Applications M2M
Dirig par :
Dr. Nada CHENDEB TAHER, Liban
Pr. Yacine GHAMRI-DOUDANE, France
Soutenu devant le Jury :
Dr. Bachar EL-HASSAN
Dr. Bassem BAKHACHE
Mr. Hikmat ADHAMI
Session Juillet 2013
1

Remerciements
La ralisation de ce projet a t possible grce Dieu et au concours de plusieurs personnes
qui je voudrais tmoigner toute ma reconnaissance.
Je voudrais tout d'abord adresser toute ma gratitude la directrice de ce projet, Dr. Nada
Chendeb, pour sa patience, sa disponibilit, ses discussions et surtout ses conseils critiques, qui
m'ont bien oriente dans ce projet de recherche assez ouvert.
Je dsire aussi remercier le professeur Yacine Ghamri-Doudane, du Laboratoire dInformatique
Gaspard-Monge (UMR CNRS 8049) luniversit Paris-Est Marne la valle pour ses
orientations et son aide.
Je voudrais galement remercier les professeurs qui mont enseigne durant mon parcours
universitaire. Je remercie particulirement Dr. Bachar El Hassan, Dr. Bassem Bakhache, Dr.
Rola Naja, Dr. Ziad Naja et Mr. Hikmat Adhami pour avoir accept de faire partie de mon jury.
Un merci particulier du fond du cur Dr. Haissam Ziad, pour son aide inestimable. A lui
jadresse mes remerciements les plus sincres.
Je voudrais exprimer ma reconnaissance envers mes collgues qui mont accompagne durant
les 4 mois de ce stage et qui ont pu crer une ambiance de travail agrable. Je leur souhaite tous
le meilleur futur.
Un grand merci ma famille : mon pre, ma mre, Salam, Hoda et Houssam pour m'avoir
supporte durant ces cinq annes d'tudes. Ctait un long trajet, un trajet que je ne pourrais pas
parcourir seule.
Finalement, jadresse un immense merci mon amie intime, Ranime, pour son soutien, sa
patience et son support illimit. Je la souhaite toujours le succs et le bonheur.

Rsum
Machine-Type-Communication (MTC), galement connu par Machine to Machine
communication (M2M) est lun des sujets mergents dans les rseaux haut dbit mobiles tels que
le rseau LTE (Long Term Evolution) en tant que technologie cl pour les dcennies venir.
Les applications M2M sont des applications automatises qui impliquent des machines ou des
dispositifs communiquant travers un rseau sans intervention humaine. Jour aprs jour, ces
applications toucheront tous les domaines de notre vie (lectricit, sant, transport, etc) et
impliqueront ainsi un norme nombre de dispositifs communiquants autonomes.
Ceci dit, il est indiscutable que lactivation massive des services M2M dans les rseaux haut
dbit mobiles n'est pas une tche facile. En effet, les oprateurs des rseaux mobiles doivent
penser mettre jour leurs rseaux pour pouvoir soutenir ces nouvelles communications.
Plusieurs problmes interviennent en prsence des communications massives M2M.
Principalement, des problmes de congestion au niveau de l'accs radio peuvent se prsenter
cause des signalisations ou des messages de donnes simultans partir d'un grand nombre de
dispositifs MTC. Ce qui pnalise la fois les dispositifs MTC et non-MTC.
La congestion de la partie radio a t agressivement adresse par 3GPP comme un lment de
travail indispensable. Et pour contrler cette congestion, 3GPP a propos plusieurs solutions.
Dans ce travail de stage, nous analysons et comparons les performances de ces solutions.
L'valuation est faite thoriquement, au moyen des simulations et par des modles analytiques
que nous avons dvelopps.
Les solutions de contrle de congestion proposes par 3GPP ont t codes dans le simulateur
LTE-Sim et plusieurs scenarios ont t simuls. Alors que les modles analytiques ont t
implments sous Matlab. Les performances de ces solutions ont t mesures par le biais de
trois mtriques : probabilit de succs, probabilit de collision et dlai d'accs moyen. Les
rsultats des modles analytiques ont valid ceux des simulations et ces rsultats montrent que
chacune de ces solutions possde ses avantages et inconvnients. Finalement, une solution que
nous trouvons la meilleure a t slectionne comme candidat potentiel adopter par les
oprateurs LTE.
Mots-Cls: Machine To Machine (M2M), Long Term Evolution (LTE), Procdure daccs
alatoire (RACH), Congestion du rseau daccs, Evaluation des performances, Simulation,
Modlisation analytique.

Abstract
Machine Type Communication (MTC), also known as Machine to Machine (M2M)
communication is one of the most important emergent issues in mobile broadband networks such
as LTE 3GPP Long Term Evolution as a key technology for the near future. M2M applications
are applications that involve automated machines or devices communicating through a network
without human intervention. Day after day, these applications will be related to all our life
domains (smart energy, e-health, transport, etc) and will introduce a huge number of
communicating autonomous devices.
Knowing that, it is out of discussion that enabling massive M2M services in the mobile
broadband network is never an easy task. In fact, mobile operators must start upgrading their
networks in order to support this new type of communications.
Many problems arise from the presence of massive M2M communications. Mainly, problems of
congestion at the radio level may occur due to the excessive number of signaling messages or
simultaneous data messages from the MTC devices. This may have a significant impact on the
operations in the mobile network, which penalizes both the MTC and non-MTC devices.
The congestion in the radio part of the network has been aggressively addressed by 3GPP as an
essential working item. To solve this congestion, 3GPP have proposed multiple solutions. In this
work we study, analyze and compare the performance of the 3GPP solutions. The evaluation is
done theoretically, via simulations and analytically using analytical models we developed for
this purpose.
3GPP proposed congestion control solutions were coded and implemented in LTE-Sim simulator
and multiple scenarios were simulated, while the analytical models were implemented in Matlab.
The performance of these solutions have been measured based on three metrics: success
probability, collision probability and mean access delay. The results obtained from the
analytical models were validated by those of the simulations. These results show that each
solution provide some advantages and have some drawbacks on the global performance. Finally,
the best solution was selected as a potential candidate to be adopted by LTE operators.
Key Words: Machine To Machine (M2M), Long Term Evolution (LTE), Random Access
Procedure (RACH), Radio Access Network (RAN) Overload, Performance Evaluation,
Simulation, Analytical modeling.

Table de Matires
Table de Matires ......................................................................................................................................... 1
Table de Figures ............................................................................................................................................ 9
Liste de Tableaux........................................................................................................................................... 9
Introduction Gnrale................................................................................................................................. 10
Chapitre 1.

Communications M2M et rseaux LTE/LTE Advanced ................................................... 12

1.1

Introduction ............................................................................................................................ 12

1.2

Les communications M2M ...................................................................................................... 12

1.2.1

Les applications M2M ..................................................................................................... 12

1.2.2

Les problmes et les dfis ............................................................................................... 14

1.3

Les rseaux LTE ....................................................................................................................... 15

1.3.1

Architecture du rseau LTE ............................................................................................. 16

1.3.2

Caractristiques gnrales de la technologie LTE........................................................... 17

1.3.3

Les ressources dans LTE .................................................................................................. 18

1.3.4

Procdure daccs alatoire en LTE ................................................................................ 19

1.4

Conclusion ............................................................................................................................... 21

Chapitre 2.

M2M et 3gpp .................................................................................................................. 22

2.1

Introduction ............................................................................................................................ 22

2.2

Activits de Standardisation en M2M..................................................................................... 22

2.3

3GPP et M2M .......................................................................................................................... 23

2.3.1

Documents de standardisation ....................................................................................... 23

2.3.2

Caractristiques des communications M2M dans 3GPP ................................................ 23

2.4

Les solutions de contrle de congestion de 3GPP .................................................................. 24

2.4.1

Access Class Barring Scheme (ACB)................................................................................. 24

2.4.2

Separation of RACH ressources for MTC........................................................................ 25

2.4.3

Dynamic Allocation of RACH Resources ......................................................................... 25

2.4.4

Backoff Specific Scheme.................................................................................................. 25

2.4.5

Slotted Access ................................................................................................................. 26

2.5

Autres Solutions ...................................................................................................................... 26

6

2.6

Conclusion ............................................................................................................................... 26

Chapitre 3.

Simulations et rsultats .................................................................................................. 28

3.1

Introduction ............................................................................................................................ 28

3.2

Le choix du simulateur ............................................................................................................ 28

3.3

Le simulateur choisi : LTE-Sim ................................................................................................. 29

3.4

Problmes rencontrs ............................................................................................................. 29

3.4.1

La familiarisation avec LTE-Sim ....................................................................................... 29

3.4.2

La longue dure d'excution des simulations ................................................................. 30

3.5

Environnement de Simulation ................................................................................................ 30

3.6

Mise jour du simulateur ....................................................................................................... 31

3.6.1

Implmentation de la procdure RACH : ........................................................................ 31

3.6.2

Implmentation des solutions de 3GPP .......................................................................... 32

3.7

Simulations et rsultats .......................................................................................................... 34

3.7.1

Effet de la communication M2M sur H2H ...................................................................... 35

3.7.2

Evaluation et comparaison des solutions de 3GPP ......................................................... 36

3.7.3

Scnarios simuls ............................................................................................................ 37

3.7.4

Analyse des rsultats ...................................................................................................... 38

3.8

Conclusion ............................................................................................................................... 40

Chapitre 4.

Modlisation analytique des mcanismes daccs alatoires dans LTE ......................... 41

4.1

Introduction ............................................................................................................................ 41

4.2

Gnralits sur la modlisation analytique ............................................................................ 41

4.3

Etude de lexistant .................................................................................................................. 42

4.4

Modle analytique de la procdure RACH .............................................................................. 43

4.5

Modlisation des solutions de 3GPP....................................................................................... 45

4.5.1

Access Class Barring ........................................................................................................ 45

4.5.2

Backoff Scheme ............................................................................................................... 46

4.5.3

Resource Separation ....................................................................................................... 46

4.5.4

Slotted Access ................................................................................................................. 47

4.6

Modlisation du mcanisme daccs global ........................................................................... 47

4.6.1

Dfinition......................................................................................................................... 47

4.6.2

Calcul des probabilits et du dlai d'accs moyen ......................................................... 48

7

4.7

Rsultats et Analyses .............................................................................................................. 49

4.8

Conclusion ............................................................................................................................... 51

Conclusions et Perspective ......................................................................................................................... 52

Annexe A .................................................................................................................................................... 54
Annexe B .................................................................................................................................................... 55
BIBLIOGRAPHIE ........................................................................................................................................... 58

Table de Figures
Figure 1-1: Application M2M - Rseau lectrique intelligent...................................................... 13
Figure 1-2: Application M2M-eHealth ......................................................................................... 14
Figure 1-3: Architecture de laccs radio (eUTRAN) dun rseau LTE ...................................... 16
Figure 1-4: UMTS 3G : UTRAN et LTE : E-UTRAN ................................................................... 17
Figure 1-5: Grille de ressources en LTE ...................................................................................... 18
Figure 1-6: Resource Block en LTE ............................................................................................. 19
Figure 1-7: Procdure daccs alatoire en LTE ......................................................................... 20
Figure 1-8: Comportement de l'quipement pendant la procdure RACH .................................. 21
Figure 3-1: Algorithme dimplmentation de la procdure RACH .............................................. 32
Figure 3-2: Algorithme dimplmentation de la solution ACB .................................................... 33
Figure 3-3: Algorithme dimplmentation de la solution Backoff ................................................ 33
Figure 3-4: Algorithme dimplmentation de la solution Slotted Access ..................................... 34
Figure 3-5: Taux de perte des paquets de la communication H2H .............................................. 35
Figure 3-6: Dlai de bout en bout de la communication H2H ..................................................... 35
Figure 3-7: Probabilit de succs................................................................................................. 38
Figure 3-8: Probabilit de collision ............................................................................................. 39
Figure 3-9: Dlai daccs ............................................................................................................. 39
Figure 4-1: Probabilit de succs daccs obtenue avec le modle analytique propos ............. 50
Figure 4-2: Probabilit de collision obtenue avec le modle analytique propos ....................... 50
Figure 4-3: Dlai daccs obtenu avec le modle analytique propos ........................................ 50

Liste de Tableaux
Table 2-1: Rcapitulation des mcanismes daccs alatoires proposs par 3GPP.................... 27
Table 3-1: Rcapitulation des paramtres des 3 scnarios dvelopps ....................................... 37

Introduction Gnrale
L'observation de l'volution des technologies de communication sans fil montre un avancement
assez rapide dans les dix dernires annes. Cette volution a t oriente par le besoin croissant
de faire transmettre les donnes provenant des diffrentes applications qui naissent jour aprs
jour. De la transmission de la voix dans les rseaux cellulaires mobiles de la premire gnration,
nous nous trouvons maintenant devant des donnes de trs hauts dbits transitant dans les
rseaux mobiles de la quatrime gnration. Ces donnes peuvent reprsenter pas seulement la
voix, mais aussi la vido enregistre et temps rel, les fichiers informatiques, les applications, les
images, etc. Des dbits modestes de quelques Kb/s dans les rseaux GSM, nous arrivons
maintenant des dbits touchant les centaines de Mb/s dans les rseaux LTE (Long Term
Evolution; quatrime gnration des rseaux cellulaires). De la mobilit pitonne, les rseaux
actuels peuvent supporter des mobilits des vitesses de l'ordre de centaines de Km/s. Les
exemples chiffrs de cette volution sont trs nombreux.
Les rseaux cellulaires ne sont pas les seuls rseaux sans fil actuels. Plusieurs autres technologies
de communication sans fil existent, telles que la famille des standards sans fil IEEE 802 qui
englobe les noms suivants : Wifi, WiMAX, Zigbee et Bluetooth, etc. Ces technologies ont aussi
assez volu dans ces quelques annes passes.
Les applications et les dispositifs communiquant dans les rseaux volus d'aujourd'hui ne sont
plus limits aux ordinateurs s'changeant des fichiers informatiques et aux tlphones pour la
parole. Actuellement, tout dispositif peut tre muni d'une unit de communication pour changer
des informations avec le rseau et avec les autres dispositifs. C'est ce qu'on appelle l'Internet des
choses ou l'internet des objets. Tout objet peut donc communiquer et ceci ouvre la porte
largement vers un nombre norme d'objets communiquant et vers un trs grand panel
d'applications. Ces communications ne se font pas uniquement dans les rseaux cellulaires
mobiles mais peuvent tre aussi au sein du Wifi et d'autres. Toutes ces technologies de
communications restent complmentaires vis--vis du support de ces applications mergentes.
Dans ce travail de stage, on s'intresse plus particulirement au support des communications des
objets dans les rseaux cellulaires de quatrime gnration LTE, nommes dans ce contexte
communications Machine Machine (M2M) ou communications de type machine (MTC).

Problmatiques et objectifs de la recherche

La communication M2M (Machine To Machine) est un nouveau type de communication qui va
tre bientt introduit dans nos rseaux actuels, principalement les rseaux mobiles haut dbit
tel que le rseau LTE. La communication M2M possde ses propres caractristiques qui la
10

diffrent de la communication H2H (Human to Human) classique. On note essentiellement la

signalisation importante et la faible taille des paquets de donnes.
Nombreuxdfisvontaffronterlesoprateursdesrseauxmobilesactuelslorsdelintroduction
des applications M2M vue l'htrognit des scnarios de communication. Le problme
principalcausparlintroductiondecesapplicationsestlacongestionquiseproduit au niveau
du rseaudaccs cause du grand nombre de dispositifsquiessaientdaccdersimultanment
au rseau. Les oprateurs des rseaux cherchent une solution optimale pour rduire cette
congestion et garantir la communication H2H classique non affecte. Cest pourquoi plusieurs
organisations essaient de dvelopper une solution convenable pour rsoudre ce problme. 3GPP
a propos 5 solutions diffrentes afin de rduire la congestion.
Lobjectif de ce travail est dvaluer ces solutions proposes thoriquement, par simulation, et
par modlisation analytique afin de sortir par une orientation vers la solution, la moins complexe
et la meilleure en sens derductiondelacongestiondaccs.

Structure du rapport
La suite de ce rapport est organise comme suit :
Le chapitre 1 est ddi la prsentation de quelques lments bibliographiques ncessaires pour
lenchanement de la suite. Nous exposons les gnralits sur les communications M2M, et les
problmes quelles imposent aux rseaux hauts dbit actuels. La technologie LTE est aussi
dcriteetexposedanscechapitreeninsistantprincipalementsurlaprocduredaccsalatoire.
Dans le chapitre 2, la communication M2M dans les standards de 3GPP et les solutions
proposes pourrsoudreleproblmedecongestiondanslerseaudaccsLTE sont dtailles.
Lecurdenotretravailse trouve essentiellement dans les chapitres 3 et 4. Dans le chapitre 3,
nous dcrivons tous les dtails relatifs lvaluation des solutions de 3GPP par simulation :
simulateur choisi, problmes rencontrs, environnement de simulation, scnarios, etc. Nous
analysons les rsultats et nous indiquons la meilleure solution. Le chapitre 4, dtaille lvaluation
de ces solutions par modlisation analytique des procdures d'accs. Nous analysons les rsultats
et nous comparons les rsultats analytiques avec les rsultats des simulations.
Le rapport est cltur par les conclusions, les perspectives et les nouveaux dfis manant de ce
travail.

11

Chapitre 1.

COMMUNICATIONS M2M ET RESEAUX LTE/LTE

ADVANCED

1.1 Introduction
Dans ce chapitre, qui constitue une introduction bibliographique au rapport, nous prsentons les
dtails sur les mots cls, les concepts, et les lments bibliographiques essentiels autour desquels
tournent les contributions de ce travail.
Nous commenons par introduire les communications M2M connues aussi par communications
de type machine (MTC: Machine Type Communications). Nous donnons les caractristiques de
ces communications etnoussoulignonsplusparticulirementlesproblmeslislintroduction
de ce type de communications dans les rseaux haut dbit actuels qui motivent la recherche dans
ce domaine. Ensuite, nous prsentons quelques lments du rseau cellulaire; LTE.
NotretravailporteplusprcismentsurleffetdescommunicationsM2Msurlerseaudaccs
c..d.auniveaudelassociationdel'utilisateuraurseauavantdinitier la communication. Pour
cela, nous dcrivons en fin de ce chapitre la procduredaccsaurseauLTE.

1.2 Les communications M2M

Les applications M2M sont des applications automatises qui impliquent des machines ou des
dispositifs communiquants sans aucune intervention humaine. Une caractristique presque
commune la majorit des applications M2M est qu'elles gnrent beaucoup plus du trafic de
signalisation que du trafic de donnes. De plus, les applications M2M gnrent en gnral des
paquets de donnes de faible taille.
L'objectif essentiel pour supporter les communications M2M est dtablir les conditions qui
permettent un dispositif dchanger des informations avec une application via un rseau de
communication le plus efficacement possible. Dans cette dfinition, M2M est le synonyme de
M2(CN2)M : Machine-to-Communication Network-to-Machine.

1.2.1

Les applications M2M

Dansunelargemesure,M2Mnestpasunmarchensoi,cestpluttuneextensiondeplusieurs
marchs verticaux qui bnficient des communications M2M. Les principaux marchs o M2M
joue un rle important sont : la sant, les transports, lnergie, la scurit, la surveillance,
lautomatisation et le control industriel, etc. Les applications M2M peuvent alors tre utilises
dans presque tous les domaines de la vie quotidienne et sont classifies dans [1]. Dans ce qui
suit, nous prsentons quelque unes des applications M2M qui sont dj en activit :
a- Compteurs intelligents (Smart meters): Les applications des rseaux lectriques intelligents
bases principalement sur l'utilisation des compteurs intelligents sont dployes par le secteur
12

dnergie pour atteindre un haut degr defficacit et de fiabilit concernant la consommation

dlectricitpar les utilisateurs. La communication entre les appareils au sein de la maison sera
ralise en utilisant plusieurs technologies (Bluetooth, Zigbee, LTE, WiMAX, Wifi,.).Un
recueil des informations sera alors ralis etlenvoidespetitsjetsdinformationauserveurdela
compagnie aura lieu via un rseau tendu.Lutilisateurpeutainsi contrler la consommation de
lnergie domestique et les donnes relatives aux cots transmis partir du site web de la
compagnie via son ordinateur portable ou son tlphone mobile. [2]

Figure 1-1: Application M2M - Rseau lectrique intelligent1

b- Distributeur Automatique : Le distributeur automatique permet un client dacheter des

produitstelsquelesboissonsparexemplepartirdundistributeurautomatiqueenlibre service.
Un vendeur gre plusieurs machines distributrices. Le distributeur automatique va fournir
llmentslectionnlorsquelapicedemonnaieestinsre.Ladisponibilitdunobjetdonn
est dtermine par des capteurs spcifis. Une fois la machine dtecte quun objet n'est plus
disponible, elle va signaler un out of stock lordre du serveur de gestion qui envoie
linformationauvendeur.Ledistributeurstockeaussilesdonnesdesventesquotidiennesdans
des bases de donnes internes et envoie un message contenant le rapport de vente quotidienne au
vendeurquisauraalorsquelsproduitsonttvendusetlechiffredaffairestotalquotidien.
c- Soins et sant : La sant lectronique (E-Health) constitue un segment de march important
pour les applications M2M. Le service fait souvent appel des dispositifs M2M intgrs dans un
braceletouuncollier.Ilpermetaupatientdecontacteruncentredurgenceenappuyantsurun

ETSI TR 102 691 V1.1.1 (2010-05): Machine-to-Machine communications (M2M); Smart Metering Use Cases

13

bouton du dispositif M2M. Le serveur M2M reconnat le patient dappel et dclenche

automatiquement un appel vers le dispositif M2M du patient. Le patient est alors assist par un
technicienmdicaldurgence.Lesappareilslisl'eHealthsontdeplusenplusutilisspourdes
applications telles que la surveillance distanceetlessoinsdomicileetc..[3] Le paradigme
M2Mpermetlasurveillanceentempsreldelasantdunepopulationentire.Lesambulances
peuvent tre immdiatement dpches sur les lieux daccidents et les patients peuvent tre
surveills leurdomicileaveclammeefficacitquedansleshpitaux.Lemdecindunpatient
peut galement tre immdiatement inform si son patient souffre dune crise cardiaque, par
exemple.

Figure 1-2: Application M2M-eHealth2

1.2.2 Les problmes et les dfis

Les nouvelles gnrations de rseaux mobiles haut dbit paraissent tre les rseaux les plus
convenables supporter les applications M2M de diffrentes natures. Nanmoins, lactivation
des applicationsM2M danslerseaunest jamaisunetchefacile. Lesoprateursdesrseaux
doivent mettre jour leurs rseaux afin de soutenir ces types dapplications sans pour autant
perturber les applications classiques de type "Humain Humain" (H2H: Human to Human).
Nombreux dfis vont affronter les oprateurs des rseaux mobiles actuels vue l'htrognit des
scnarios des communications M2M. Les principaux dfis sont les suivants :
a- Le nombre massif de dispositifs M2M : Ce nombre va tre beaucoup plus grand que celui des
dispositifs H2H. Cela provoquera deux problmes principaux : dabord un problme de
congestion important pouvant causer la dgradation du service H2H. Puis un problme
d'adressage; en fait la longueur des adressesutilisesaujourdhui (MSISDN, IMSI, IPV4,etc.)

Draft ETSI TR 102 732 V0.4.1(2011-3) : Machine to Machine communications(M2M); E-Health Use Cases

14

semble insuffisante pour identifier le nombre lev des machines dans le rseau. Pour ce dernier
problme, l'adoption de l'adressage IPv6 semble tre la solution la plus convenable. Alors que
pour le premier problme, des mthodes de gestion des ressources, de contrle d'accs multiples,
et de contrle de congestion prenant en compte les services requis par les diffrentes applications
et les profils de service offerts par le rseau doivent tre mises en route.
b- Lagestiondelalimentation : Par exemple : un dispositif M2M destin dtecter les donnes
mdicales doit pouvoir maintenir son nergie pendant de longues priodes sans alimentation
externe. La batterie doit tre alors soigneusement conserve. Le rseau doit offrir une opration
optimale avec ce type de dispositifs afin de les aider au mieux conserver leur nergie.
c- La diversit des exigences QoS : Certaines applications temps rel, ont des exigences leves,
surtout en ce qui concerne la latence et la fiabilit.Alorsquedautresapplicationssonttolrables
aux dlais et ont des faibles priorits. Le rseau doit donc offrir plusieurs niveaux de QoS aux
diffrents dispositifs M2M.
d- L'htrognit des modles de trafic : Certains dispositifs M2M (par exemple les capteurs de
collision) ne transmettent aucune donne pour des mois. Alors que dautres transmettent des
donnes encontinuoupriodiquementcommelecapteurdelapressionsanguinedunpatient.
La charge de la signalisation et du protocole ne doit donc pas tre importante et par suite
surpasser la charge des donnes utiles.
e- Les diffrents profils de mobilit :CertainsdispositifsM2Msontfixestandisquedautresse
dplacent grande vitesse. Ces diffrents profils de mobilits doivent tre supports galement
par le rseau.
Aprs la prsentation des dfis qui confrontent l'activation des communications M2M dans les
rseaux mobiles de nouvelle gnration, nous passons prsenter les lments essentiels des
rseaux LTE.

1.3 Les rseaux LTE

LTE est l'volution la plus rcente des normes de la tlphonie mobile GSM/EDGE, CDMA2000
et UMTS. La norme LTE, dfinie par le consortium 3GPP (3rd Generation Partnership Project),
a d'abord t considre comme une norme de troisime gnration 3.9G (car plus proche de
la 4G), spcifie dans le cadre des technologies IMT-2000, car dans les versions 8 et 9 de la
norme, elle ne satisfaisait pas toutes les spcifications techniques imposes pour les normes 4G
de l'Union internationale des tlcommunications. La norme LTE n'est pas fige, le consortium
3GPP la fait voluer en permanence.
En octobre 2010, l'UIT a accord aux normes LTE et WiMAX dfinies avant les spcifications
IMT-Advanced et qui ne satisfaisaient pas compltement ses prrequis, la possibilit
15

commerciale d'tre considres comme des technologies 4G , du fait du niveau substantiel

d'amlioration des performances compares celles des premiers systmes 3G . Les rseaux
mobiles LTE sont maintenant commercialiss sous lappellation 4G par les oprateurs de
nombreux pays.
LTEutilisedesbandesdefrquenceshertziennesdunelargeurpouvantvarierde1,4MHz20
MHz, permettant ainsi d'obtenir (pour une bande 20 MHz) un dbit binaire thorique pouvant
atteindre 300 Mbit/s en liaison descendante ; la "vraie 4G", appele LTE-Advanced offrira un
dbit descendant pouvant atteindre 1 Gbit/s ; ce dbit ncessitera lutilisation de bandes de
frquences de 2x100 MHz de largeur qui sont dfinies dans la version 10 (3GPP release 10) de la
norme LTE-Advanced.

1.3.1 Architecture du rseau LTE

Les rseaux LTE sont des rseaux cellulaires constitus de milliers de cellules radio qui utilisent
les mmes frquences hertziennes grce aux codages radio OFDMA et SC-FDMA. Ceci permet
daffecterchaquecelluleunelargeurspectraleplusimportante,variantde320MHzetdonc
d'avoir une bande passante plus importante et plus de dbit dans chaque cellule.
Lerseauestconstitude2parties:unepartieradio(eUTRAN)etuncur de rseau EPC
(Evolved Packet Core).
a- La partie radio eUTRAN (Evolved- Universial Terrestrial Radio Access Network) :
La partie radio du rseau, appele eUTRAN est simplifie par rapport celles des rseaux 2G
et 3G parlintgrationdanslesstations de base eNodeB des fonctions de contrle qui taient
auparavant implmentes dans les RNC (Radio Network Controller) des rseaux 3G UMTS.
La partie radio dun rseau LTE (voir figure 1-3) se compose donc des eNodeBs, dantennes
locales ou distantes, de liaisons en fibres optiques vers les antennes distantes et des liens IP
reliant les eNodeBs entreeux(liensX2)etaveclecurderseau.

Figure 1-3: Architecture de laccs radio (eUTRAN) dun rseau LTE

16

b- LecurderseauEPC
Lecurderseauappel EPC (EvolvedPacket Core)utilisedestechnologies tout IP ,
c'est--dire bases sur les protocoles Internet pour la signalisation, le transport de la voix et des
donnes.Cecurde rseaupermetlinterconnexion via des routeurs avec les autres eNodeBs,
les rseaux des autres oprateurs mobiles, les rseaux de tlphonie fixe et le rseau Internet
(Figure 1-4).
LutilisationduprotocoleIPdebout-enboutdanslecurdu rseau permet des temps de latence
rduitspourlaccsinternet et les appels vocaux LTE.

Figure 1-4: UMTS 3G : UTRAN et LTE : E-UTRAN

1.3.2 Caractristiques gnrales de la technologie LTE

a- Dbit maximal en sens descendant arrivant jusqu' 299,6 Mbit/s et en sens montant jusqu'
75,4 Mbit/s en fonction de la catgorie de l'quipement de l'utilisateur. Tous les terminaux sont
capables de traiter 20 MHz de bande passante.
b- Faibles latences de transfert de donnes, faibles latences pour le "Handover" et le temps
d'tablissement de connexion en comparaison avec les technologies d'accs radio prcdentes.
c- Amlioration du support de la mobilit, illustre par le soutien des terminaux mobiles ayant
des vitesses arrivant jusqu' 350 km/h ou 500 km/h selon la bande de frquence.
d- Utilisation de la technologie OFDMA pour le sens descendant, et SC-FDMA pour le sens
montant afin de mieux conomiser l'nergie.
e- Interopration et coexistence avec les normes et les standards dj existants. Les utilisateurs
peuvent lancer un appel ou commencer le transfert des donnes dans une cellule en utilisant
LTE, et, si la couverture n'est plus disponible, continuer l'opration sans aucune action de leur
part en utilisant UMTS, W-CDMA voire aussi les rseaux GSM / GPRS.
17

f- Une interface radio commutation de paquets.

g- Support du MBSFN (Multicast-Broadcast Single Frequency Network). Cette fonctionnalit
peut fournir des services tels que la tlvision mobile en utilisant l'infrastructure LTE.
h- Support des systmes de communication FDD et TDD ainsi que half-duplex FDD avec la
mme technologie d'accs radio.
i- Une flexibilit croissante du spectre: 1,4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz et 20 MHz.
j- Diffrentes tailles des cellules allant de quelques dizaines de mtres (rayon) pour les femto et
les pico-cellules jusqu' 100 km pour les macro-cellules.
k- Prise en charge d'au moins 200 clients actifs en mme temps dans chaque cellule de 5 MHz.
l- Architecture simplifie: Le ct rseau daccs delE-UTRAN est compos uniquement des
eNodeBs. [4]

1.3.3 Les ressources dans LTE

Pour surmonter l'effet de la propagation multi-chemin qui existe en UMTS, LTE utilise la
technique Orthogonal Frequency Division Multiplexing (OFDM) en sens descendant afin de
transmettre les donnes sur plusieurs porteuses de bande troite de 180 KHz chacune au lieu de
diffuser un signal sur la bande passante complte de 5MHz. OFDM utilise un grand nombre de
sous-porteuses troites pour une transmission multi-porteuse des donnes.
OFDM rpond l'exigence LTE pour la flexibilit du spectre et permet des solutions
conomiques pour les porteuses trs larges avec des valeurs maximum leves. La ressource
physique de base pour LTE dans le sens descendant peut tre considre comme une grille
temps-frquence, comme la montre la figure 1-5 ci-dessous :

Figure 1-5: Grille de ressources en LTE

18

Les symboles OFDM sont regroups en blocs de ressources 2D (voir figure 1-6). Les blocs de
ressources ont une taille totale de 180 kHz dans le domaine de frquence et de 0,5 ms dans le
domaine temporel. Chaque intervalle de temps de transmission 1ms (TTI) est constitu de deux
slots (Tslot).

Figure 1-6: Resource Block en LTE

A chaque utilisateur est attribu un nombre de blocs dites ressources dans le rseau tempsfrquence. Plus de blocs de ressources un utilisateur obtient, plus la modulation utilise dans les
lments de ressources est leve et plus le dbit sera lev. Laffectationdesblocsderessource
aux utilisateurs un instant donn dpend des mcanismes de planification avancs utiliss. [4]

1.3.4 Procdure daccs alatoire en LTE

Une exigence fondamentale pour tout systme cellulaire est la possibilit pour le terminal de
demander ltablissement de connexion. Ceci est connu par la procdure d'accs alatoire ou
Random Access Procedure. L'accs alatoire est ralis non seulement pendant l'accs initial,
mais encore lors de passage de ltat inactif l'tat actif, aussi aprs des priodes d'inactivit
dans le sens montant. La procdure d'accs alatoire se compose de quatre tapes suivants
(Figure 1-7):
1) Etape 1: Random access preamble transmission (Msg-1): La premire tape est base sur
l'mission d'un prambule d'accs alatoire, permettant l'eNodeB de la cellule destimer le
temps de transmission du terminal. La synchronisation est ncessaire comme autrement le
terminal ne peut pas transmettre des donnes dans le sens montant. Donc, le terminal slectionne
un prambule et l'met sur le canal d'accs alatoire physique (Physical Random Access Channel
PRACH).
2) Etape 2: Random access response (Msg-2): Dans la seconde tape, l'eNodeB transmet un
message de synchronisation pour rgler la synchronisation d'mission du terminal, en fonction de
la mesure effectue dans la premire tape. En plus de la synchronisation du sens montant,
l'eNodeB attribue galement des ressources au terminal pour les utiliser dans la troisime tape
de la procdure.
19

3) Etape 3: RRC Connection Request (Msg 3) : lors de cette troisime tape, le terminal
transmet son identit vers le rseau en utilisant le canal UL-SCH (Uplink Signaling Channel). Le
contenu exact de cette signalisation dpend de l'tat du terminal, en particulier si ce terminal est
dj connu par le rseau ou non.
4) Etape 4: RRC Connection Setup (Msg 4) : La quatrime et la dernire tape est base sur
la transmission d'un message de rsolution de contention du rseau vers le terminal sur le canal
DL-SCH (Downlink Signaling Channel). Cette tape rsout galement toute contention cause
parmultiplesterminauxquiessaientdaccderausystmeenutilisantlamme ressource accs
alatoire [5].

Figure 1-7: Procdure daccs alatoire en LTE

La figure 1-8 montre la procdure d'accs alatoire sous la forme d'un algorithme. Quand le
terminal est prt transmettre le prambule, il vrifie si le slot de temps actuel est un slot d'accs
alatoire (pendant dix millisecondes, un terminal possde deux possibilits pour envoyer le
prambule). Sinon, le terminal va attendre le slot de temps daccs alatoire suivant. Aprs
l'envoi du prambule, le terminal va augmenter le nombre de fois de transmission par 1, dmarrer
le temporisateur Random access response (RAR) et puis attendre ce temps RAR. Ds qu'il reoit
la rponse d'accs alatoire dans la fentre RAR, le terminal se prpare pour envoyer la demande
de connexion RRC (c.- Msg3). D'autre part, si le terminal ne reoit pas une rponse d'accs
alatoire dans la fentre RAR (c.--d. leNodeB ne parvient pas dtecter le prambule de
l'quipement), le terminal vrifie si le nombre de fois de transmission de prambule est plus petit
que le nombre maximum d'mission de prambule. Si oui, il choisira au hasard un time slot bas
sur un indicateur de Backoff et se prparera pour la transmission du prambule suivant. Sinon, il
20

doit cesser deffectuer la procdure daccs alatoire et indiquer un problme d'accs alatoire
aux couches suprieures. [6]

Figure 1-8: Comportement de l'quipement pendant la procdure RACH

1.4 Conclusion
Nous avons prsent dans ce premier chapitre, une introduction bibliographique au projet. La
premire section a dcrit les principales applications M2M avec les problmes les plus
importants qui peuvent intervenir lors de lintroduction de ces applications dans les rseaux
actuels. Il y a donc une ncessit primordiale de rsoudre ces problmes. On sintresse
prcismentauproblmedelacongestionauniveaudaccsdanslerseauLTEetauxsolutions
proposes. Dans la deuxime partie, nous avons introduit la technologie LTE et la mthode
daccsalatoireRACH.Ceci ouvre une fentre sur les solutions et les amliorations proposes
par 3GPP sur cette procdure daccs afin de mieux supporter les communications M2M. Ces
solutions ainsi que d'autres de la littrature seront discutes en dtail dans le chapitre 2.

21

Chapitre 2.

M2M ET 3GPP

2.1 Introduction
Avec une large gamme d'applications, le support des applications M2M gagne un immense
intrt de la part des oprateurs des rseaux mobiles, des fournisseurs d'quipement, des
compagnies spcialises et des organismes de recherche. Pour faciliter la convergence entre ces
diffrents acteurs, les diffrents groupes de normalisation ont commenc travailler dans ce
domaine en essayant de trouver des standards sur lesquels tous les actionneurs dans ce domaine
doivent se baser. Ce chapitre prsente brivement quelques-unes des activits de standardisation,
en mettant l'accent sur celles qui sont traites par 3GPP. 3GPP a dfini plusieurs caractristiques
de communication des dispositifs MTC. On va dabordprsenter ces caractristiques. Parmi les
domaines tudis par 3GPP on trouve une tude dtaille sur le phnomne de congestion au
niveau de l'accs au rseau. Cette tude vise principalement faciliter lincorporation des
communications M2M dans les rseaux 3GPP tout en gardant inaffecte la communication H2H
initiale. Dans cette tude, 3GPP dcrit cinq nouvelles solutions proposes pour rsoudre le
problme de congestion dans le rseau daccs. Ces solutions sont bien sr inspires des
solutions dj adoptes dans les rseaux informatiques ou les entits communicantes sont des
ordinateurs. L'objectif dans ce chapitre est de prsenter et dtailler ces solutions. Nous
prsentons aussi quelques solutions proposes par des organisations et des chercheurs autres que
3GPP qui ont encore beaucoup travaill, beaucoup cherch afin de sortir avec une procdure,
plus exactement, afin de trouver la meilleure solution rsolvant les problmes causs par la
svrecongestionauniveaudurseaudaccs.

2.2 Activits de Standardisation en M2M

Les communications MTC incluent les communications qui se font directement entre les
dispositifs lectroniques MTC et/ou les communications inities des dispositifs MTC vers un
serveur MTC central. Les communications peuvent utiliser soit les rseaux fixes soit les rseaux
sans fil. MTC permettra un nombre infini d'applications dans une grande multitude de
domaines, touchant diffrents environnements et marchs de se relier entre eux, l'Internet et
d'autres rseaux, formant ce qu'on appelle l'Internet des objets (ou Internet of Things).
Plusieurs prvisions indiquent une croissance significative du march des applications M2M au
cours des prochaines annes. Selon ces prvisions, des milliards de machines ou d'appareils
industriels vont bnficier de la communication MTC.
Alors que certains dploiements MTC existants utilisent des technologies de
radiocommunication courte porte, des solutions MTC bases sur les technologies d'accs
mobiles sont faciles installer et sont d'une importance vitale pour soutenir un large nombre des
dispositifs MTC, y compris ceux avec des fonctionnalits de mobilit. Les solutions mobiles sont
encore adquates pour supporter les services MTC qui ncessitent une livraison immdiate et
22

fiable des donnes aux serveurs MTC distants. Prsentant un comportement diffrent des
terminauxmobilesactuels,lesdispositifsMTCncessitentdtretraits dunemanirediffrente
pour permettre aux oprateurs mobiles de supporter un grand nombre de ces dispositifs. Donc, il
existeunbesoindoptimisation des solutions, plus prcisment celles conues pour les services
MTC. Pour viter la fragmentation entre les diffrentes solutions proposes, et alors la
divergence entre les diffrents acteurs du march MTC, il est ncessaire de joindre tous les
efforts dans ce domaine pour concevoir une architecture M2M standardise de bout en bout.
3GPP et IEEE se focalisent principalement sur les MTC cellulaires, plus prcisment sur le
support de la communication MTC dans les rseaux cellulaires sans fil (Wireless) actuels.
En ce qui concerne 3GPP, la premire tude sur MTC a t prsente dans [7]. Dans la Release
10, le groupe SA2 (3GPP System Architecture Working group 2) dfinit les amliorations au
rseau proposes par 3GPP pour supporter la communication MTC en UMTS et en LTE.
Laccentestprincipalementsurloptimisationdusystme,pourempcherlacongestiondansle
rseau qui consiste un important dfi.

2.3 3GPP et M2M

2.3.1 Documents de standardisation
En 2007, un sujet dtude chez 3GPP (TR-22,868) [7] sur les communications MTC intitul
Study on Facilitating Machine to Machine Communication in 3GPP Systems a t achev.
En 2010, 3GPP a commenc le processus de dveloppement des rsultats de l'tude et est sorti
avec 2 documents importants : TS 22.368 Service Requirements for Machine-Type
Communication (MTC) Stage 1 June 2010 [8] et TR 23.888 System Improvements for MTC
July 2010 [9].
TS 22.368 dfinit les exigences gnrales et les caractristiques spcifiques des applications
M2M.
TR 23.888 identifie les principaux problmes et propose des solutions correspondantes. 3GPP
Release 10 travaille sur les changements proposs lis la congestion et le contrle de surcharge
du rseau alors que les autres lments restants sont laisss pour des versions ultrieures.

2.3.2 Caractristiques des communications M2M dans 3GPP

Il peut y avoir toute sorte d'applications dans les communications MTC. Pour faciliter
loptimisation du systme, 3GPP dfinit 14 fonctionnalits pour la communication MTC [10]
afin de caractriser toutes les applications possibles. Bien qu'il existe des caractristiques
communes entre les communications MTC et les communications H2H tels que la mobilit, la
commutation de paquets, et les connexions scurises. On peut galement voir que certaines
23

caractristiques des communications MTC peuvent tre trs diffrentes que celles des
communications H2H, telles que la faible frquence de transmissions, les transmissions des
petites rafales de donnes, le contrle du temps (les dispositifs MTC peuvent envoyer ou
recevoir des donnes uniquement dans un dlai d'accs acceptable, le rseau rejette les demandes
daccs,d'envoietderceptiondesdonnesetdessignalisationspendantlesintervallesdetemps
interdits). Notons en particulier que le spectre peut tre insuffisant pour les communications
MTC. En consquence, en plus de l'utilisation de la bande haute frquence (par exemple, 60
GHz), une solution prometteuse peut se trouver dans la technologie radio cognitive [11] qui
consiste rutiliser le spectre licenci.
Dans la littrature, peu de programmes de gestion des dispositifs MTC avec leurs
caractristiques spcifiques ont t proposs tels que dans [12, 13] o on a profit de
lexploitation des terminaux normaux (tlphones et ordinateurs par exemple) pour grer les
dispositifs MTC .Cependant, ces systmes ne sont pas compatibles avec LTE. En consquence,
les systmes de gestion des dispositifs MTC avec ces caractristiques sont encore en
dveloppement dans 3GPP.

2.4 Les solutions de contrle de congestion de 3GPP

Comme nous l'avons vu, avec le dploiement des applications M2M, le nombre de dispositifs
M2M va certainement dpasser le nombre de terminaux H2H. Plusieurs recherches dans 3GPP
[14] affirment que non seulement les dispositifs MTC mais aussi les dispositifs H2H vont
souffrir des collisions continues dans le canal d'accs alatoire (RACH : Random Access
Channel) quand un grand nombre de dispositifs MTC est introduit. Ces points essentiels ont reu
une attention considrable et cinq solutions possibles ont t tudies dans 3GPP [15] afin de
rsoudre ce problme de congestion. Dans ce qui suit, nous discutons, analysons et valuons
thoriquement ces solutions.

2.4.1 Access Class Barring Scheme (ACB)

En UTRAN / E-UTRAN, l'Access Barring est un moyen efficace pour contrler l'accs des
dispositifs MTC surtout lorsque le rseau est surcharg. LACB est initialement conu pour le
contrle d'accs des terminaux H2H normaux (User Equipment). Dans ACB, il existe 16 classes
diffrentes : AC = 0-9 reprsentent les terminaux normaux, AC = 10 reprsente un cas urgent,
AC = 11-15 reprsente certains services spcifiques haute priorit.
Le phnomne ACB est ralis par la diffusion d'une probabilit d'accs "p" et un dlai appel
AC Barring Time par l'eNodeB vers les terminaux correspondant AC = 0-9. Le terminal
choisit au hasard une valeur q, avec 0 q 1. Si q p, le terminal procde la procdure
RACH. Si q > p leterminalestbloqupendantlACBarringTime,ensuiteleterminalessaie
nouveau d'accder au rseau. Ce phnomne est galement propos pour contrler l'accs des
dispositifs MTC [14].
24

Le systme bas sur lACB peut rsoudre le problme de la congestion en utilisant des trs
faibles valeurs de p. Cependant, cela va entraner des valeurs leves de retard d'accs. Compar
d'autres approches qui visent rsoudre la surcharge au niveau RAN, ACB pourrait
effectivement viter/rduire la congestion au niveau du canal RACH. En outre, une classe
d'accs spcifique aux dispositifs MTC pourrait tre introduite pour contrler la probabilit
d'accs des dispositifs MTC, ce qui permet alors une meilleure granularit pour le contrle du
rseau [16].

2.4.2 Separate RACH resources for MTC

Lorsque les dispositifs MTC utilisent les mmes ressources RACH que les terminaux normaux,
cela va certainement provoquer un problme de congestion et affecter les communications
classiques. Donc, la sparation des ressources RACH entre les dispositifs H2H et les dispositifs
MTC peut diminuer cette congestion et retirer l'effet des communications MTC sur les
communications H2H. Dans LTE, la sparation de ressources peut tre ralise soit en sparant
les prambules en deux groupes: l'un pour les appareils MTC et l'autre pour les appareils H2H,
soit en sparant les ressources temps-frquence du canal RACH (RBs du RACH entre les
dispositifs H2H et les dispositifs MTC). Une tude dtaille concernant cette solution a t faite
dans [17]. On propose 2 mthodes:
Une mthode, appele Mthode 1 consiste sparer compltement l'ensemble des prambules
disponibles en deux sous-ensembles disjoints. L'autre mthode, appele Mthode 2, est aussi
de diviser l'ensemble en deux sous-ensembles, mais dans ce cas un ensemble est ddi pour les
clients H2H seulement, tandis que l'autre est la fois pour les clients H2H et les clients MTC.
Toutefois, le partage dterministe des ressources RACH en 2 groupes ne semble pas tre efficace
[16]. Par exemple, s'il n'y a pas un trafic excessif de type MTC, les ressources RACH ddis la
communication H2H seront puises, alors que les ressources RACH de la communication MTC
sont encore libres. Comme exemple de ce type d'applications, nous pouvons trouver les
communications des compteurs intelligents, o les donnes sont transmises sur des longues
priodes de temps.

2.4.3 Dynamic Allocation of RACH Resources

Dans cette solution, le rseau peut prdire l'avance si le rseau surcharge cause des essais
daccs excessifs causs par le grand nombre des dispositifs MTC. Ainsi, le rseau alloue
dynamiquement des ressources supplmentaires pour la procdure RACH. Lallocation
dynamique des ressources RACH peut tre efficace dans certains cas. Toutefois, cette mthode
restera limite par la disponibilit des ressources supplmentaires.

2.4.4 Backoff Specific Scheme

25

Dans ce schma, on choisit une dure de temporisation pour les terminaux H2H infrieure la
dure de temporisation des dispositifs MTC [18]. Il est donc clair que cela va rduire la collision
et la congestion dans le rseau d'accs. Malheureusement, cette mthode entranera un retard
considrable qui a un impact ngatif sur les applications haute priorit non tolrables au dlai.
Bien que cette mthode base sur le backoff, puisse fournir des amliorations sur la performance
avec un faible niveau de congestion sur le canal RACH, elle ne peut pas rsoudre un niveau de
congestion lev lorsque le canal RACH est surcharg [18].

2.4.5 Slotted Access

Aveccetteapproche,lesslotsdaccssontdfinispourlesappareilsMTC,d'unemanirequun
dispositif MTC peut accder au rseau uniquement au dbut de son slot de temps ddi. Cela
signifie qu'un dispositif MTC est empch d'accder au rseau chaque fois qu'il veut, mais
seulement pendant son slot de temps prdfini. Cette solution permettra galement de rduire la
congestion au niveau d'accs.
Dans le tableau 2-1, nous donnons une comparaison thorique rapide entre ces solutions base
sur notre analyse de leurs principales caractristiques.

2.5 Autres Solutions

Beaucoup d'autres travaux [18-21] ont vis trouver une solution parfaite pour le problme de
congestion et ont propos alors de nombreuses solutions bases essentiellement sur celles
proposes par 3GPP. Nous trouvons essentiellement le travail de [19] qui propose le concept de
l'allocation des ressources par groupes et celui de [20] qui propose une modification l'ACB de
faon ce qu'elle soit cooprative entre plusieurs eNodeBs et par suite plus adapte
l'architecture LTE-Advanced. Nous nous contentons de donner ces simples ides sur ces
propositions car nous sommes uniquement intresss aux solutions de 3GPP dans ce travail.
Nanmoins, ces tudes nous paraissent trs intressantes pour une continuation sur ce sujet de
recherche.

2.6 Conclusion
Le rseau mobile actuel est optimis pour les modles de trafic H2H et ne tient pas compte de
l'introduction d'un grand nombre de communications M2M. Les amliorations et les
optimisations sont alors ncessaires quand on introduit ce nouveau type dans les rseaux actuels
afin de traiter des questions telles que l'volutivit, la taille des adresses, la protection contre la
surcharge du trafic de contrle, la diffrenciation entre les applications MTC qui ont des
caractristiques diffrentes.
Dans ce chapitre, nous avons dtaill sur les solutions proposes par 3GPP pour surmonter le
problmedecongestionauniveaudaccs.La tche suivante consiste dvelopper ces solutions
26

ainsi que la procdure RACH et les intgrer dans un simulateur nomm LTE-Sim. Ce travail de
simulation avec les rsultats obtenus constitue l'objet du chapitre suivant.
Table 2-1: Rcapitulation des mcanismes daccs alatoires proposs par 3GPP

Solution de contrle
de congestion

Points positifs

Points ngatifs

Access Class Barring

Scheme

Facile implmenter

Le choix et l'adaptation de p n'est

pas vident

Granularit possible pour

les diffrentes classes de
service

Les faibles valeurs de p entranent

des retards supplmentaires

Separate RACH
resources for MTC

La communication H2H
est totalement protge de
la communication M2M

Faible efficacitsiilnyapasun
trafic M2M excessif, mais un
trafic H2H excessif

Dynamic allocation
of RACH resources

Bonne adaptation avec

ltatdurseau

Limite par les ressources

disponibles

Utilisation efficace des

ressources

Le haut niveau de congestion ne

peut pas tre rsolu
Complexe implmenter car elle
ncessite une adaptation continue

MTC Specific
Backoff scheme

Facile implmenter
Charge de calcul moyenne
Plus facile rsoudre le
problme de congestion
quelACB

Slotted access

L'approche la plus
efficace en thorie

Similaire a l'ACB mais avec plus

de retard
Efficacedanslecasdunefaible
congestion mais non pas au cas
duneimportante congestion
Ncessite un algorithme
complexe de distribution
L'quit est une question
importante dans la distribution
des slots

27

Chapitre 3.

SIMULATIONS ET RESULTATS

3.1 Introduction
Il est maintenant le temps de commencer prsenter notre travail proprement dit. Ce chapitre est
consacr lvaluation des solutions de contrle de congestion proposes par 3GPP par
lintermdiairedessimulations.Au niveau de notre connaissance, il n'y a ce jour aucune tude
dtaille portant sur lvaluation de ces mthodes par simulation dans des environnements
htrognes. Dans ce qui suit, le travail consiste implmenter ces solutions dans un simulateur
adquat et essayer de les valuer et les comparer.
Dans la premire partie de ce chapitre, nous donnons un aperu sur le simulateur choisi ainsi que
la justification de ce choix. Dans la partie 2, nous discutons les problmes et les limitations que
nous avons rencontrs pendant les simulations. Dans la partie 3, nous prsentons les scnarios
des simulations que nous avons ralises. La partie 4 sera consacre la prsentation et
lanalysedesrsultats.Finalement,onterminelechapitrepardes recommandations sur le choix
de la meilleure solution en se basant sur les rsultats de la simulation.

3.2 Le choix du simulateur

Avant de commencer les simulations, il fallait choisir un simulateur adquat capable de nous
aider atteindre les objectifs de ce stage. Nous tions indcis entre plusieurs choix possibles
parmi lesquels nous citons le simulateur LTE-Sim, le simulateur ns3, les simulateurs dvelopps
sous Matlab. Une recherche a t effectue pour savoir les simulateurs utiliss par les chercheurs
qui ont publi des travaux en relation avec ce stage. Malheureusement, les auteurs de la majorit
des publications ne donnent aucune prcision sur le simulateur utilis. Pour choisir le meilleur
simulateur, nous avons contact plusieurs chercheurs parmi lesquels Shao Yu Lien; un expert
dans le domaine des communications M2M et un auteur de plusieurs articles sur ce sujet comme
par exemple [18], [19], [20], etc. Il nous a conseill dimplmenter notre propre simulateur
parce que le but principal des simulateurs adopts par les entreprises dans 3GPP est la
comptition. Pour cela, chaque entreprise met en place son propre simulateur bas sur ses
exigences.
Notre recherche nous a guids vers Giuseppe Piro qui est un assistant principal dans
limplmentationdusimulateurLTE-Sim et le module LTE dans le simulateur ns3.Nouslavons
encore contact. Il nous a dit que les deux simulateurs LTE-Sim et ns3 peuvent tre utiliss dans
notre tude mais il faut les adapter afin de supporter les caractristiques des communications
M2M. LTE-Sim est uniquement ddi LTE, alors que ns3 est beaucoup plus vaste dont LTE
est l'un de ses modules.
Une recherche rapide nous a permis de savoir que l'adaptation de LTE-Sim pour rpondre aux
objectifs du stage est plus ralisable que celle de ns3 vu la dure limite du stage. Notre choix est
alors tomb sur LTE-Sim comme outil pour implmenter les solutions 3GPP et les valuer.
28

3.3 Le simulateur choisi : LTE-Sim

Actuellement, l'optimisation de tous les aspects LTE est un objet de recherche pour l'industrie et
les quipes derechercheuniversitaires.Ilestimportantderemarquerque,jusqumaintenant,un
simulateur complet niveau systme n'est pas disponible pour ces communauts. En fait, les
fournisseurs les plus importants d'quipements de communication mobile ont mis en place leurs
propres simulateurs. Par ailleurs, d'autres simulateurs [22] - [25], dvelopps par la coopration
entrelesuniversitsetlindustrie,peuventtreachetsl'aided'unelicencecommercialeetleurs
codes sources ne sont pas accessibles au public.
Pour combler cette lacune, Giuseppe Piro et al. prsentent un cadre open source pour simuler les
rseaux LTE, nomm LTE-Sim, capable de fournir une vrification complte de la performance
du LTE. LTE-Sim englobe plusieurs aspects des rseaux LTE, y compris la fois L'E-UTRAN
etlEvolvedPacketSystem(EPS).[26].
Afin d'assurer la modularit, le polymorphisme, la flexibilit et la haute performance, LTE-Sim a
t crit en C++, comme un simulateur base dvnements. Actuellement, le logiciel se
compose de 90 classes, 220 fichiers, et environ 23.000 lignes de code. Pour plus d'informations
sur ce simulateur, l'annexe "A" contient le diagramme UML des classes les plus importantes
misesenuvre,ensoulignantleursmthodesetlesvariableslesplus importantes.

3.4 Problmes rencontrs

Dans ce qui prcde, nous avons prsent le simulator LTE-Sim. Certainement cela ne suffit pas
pour bien comprendre et se familiariser avec ce simulateur. Le document [27] expose une bonne
explication sur ce simulateur et peut tre considr un point de dpart poursapprofondirdans
les spcifications et les dtails de ce simulateur.
Durant ce stage nous avons affront plusieurs problmes. Les problmes les plus importants qui
ont affect principalement notre avancement sont essentiellement la familiarisation avec LTESim et la longue dure d'excution des simulations.

3.4.1 La familiarisation avec LTE-Sim

Avant de commencer les simulations avec LTE-Sim nous tions obligs de nous familiariser
aveccesimulateur.Ilntaitpas facile de comprendre un simulateur de bout en bout form de 90
classes et 23,000 lignes de code. C'tait un dfi, et nous avons russi le gagner en comprenant
l'architecture gnrale et en dcouvrant les outils ncessaires le modifier et insrer notre propre
code l o il faut.
Aprs un plongement dans le code du simulateur, nous avons dcouvert que les mcanismes
daccsRANnesontpasimplmentsdanscesimulateur.Nousentendonsparcelalaprocdure
RACHlorsqueleterminalessaiedaccder le rseau. Il fallait implmenter la procdure RACH
avantdimplmenterlessolutionsde3GPP.
29

3.4.2 La longue dure d'excution des simulations

Durant les simulations, nous avons affront un grand problme. En effet la congestion sur le
rseaudaccsLTEquon dsire atteindre ne seralisepasquelorsquon introduit un trs grand
nombre de dispositifs M2M. Nous avons remarqu qu' chaque fois quon augmente le nombre
de dispositifs M2M, les dures d'excution deviennent trs longues et l'ordinateur s'implante. A
titre d'exemple, nous tions obligs de laisser quelques simulations trois jours sur un ordinateur
"Intel Core i5, 4GB DDR3 Memory". Nous avons alors excut les simulations sur deux
ordinateurs pour acclrer le travail mais toujours sans aucun gain important. Ceci nous a
beaucoup limits et plusieurs scenarios planifis dans des environnements htrognes de trafic
et de mobilit taient impossibles raliser avec ces contraintes de ressources informatiques. Il
fallait utiliser des serveurs ayant des performances hautes afin de raliser ces simulations, ce qui
n'tait pas disponible.
Nous avons cherch plusieurs solutions pour rsoudre ce problme. En premier lieu, nous avons
essayderduirelabandepassantedanslacelluleafindarriverlacongestion plus rapidement.
Nous avons aussi essay de rduire le temps des simulations mais toujours en vain.
Cest ce stade l que nous avons contact Mr. Piro une deuxime fois pour lui demander
conseil pour rduire cette longue dure d'excution. Il nous a dit quil est avec son quipe de
recherche en train de finir limplmentation dun nouvel algorithme nomm Multi-Master
Scheduler qui va rduire la dure des simulations en adoptant une excution en parallle [28].
Cependant, cet algorithme nest pas encore termin et nous ne sommes pas srs quil puisse
rsoudre radicalement le problme dans le cas des M2M.
Nous avons alors pass au simulateur ns3 et surtout le module LTE dans ce simulateur. Mais,
nous a trouv qu'avec ce simulateur, nous allons affronter toujours lemmeproblmepuisquil
est un simulateur base dvnements discrets tout comme LTE-Sim. Ces deux simulateurs
adoptent un scheduler quiordonnancelesvnementsetlesfaitprocderunaprsunjusqula
fin de la simulation. Ce principe de simulation prend gnralement un temps trs long en
prsencedun trs grand nombre d'vnements (un trs grand nombre de dispositifs M2M vont
tre crs et vont accder au rseau) et ncessite des processeurs assez performants.
Pour combler les limites des simulations nous avons pens raliser une modlisation analytique
desmcanismesdaccsalatoires.Ctaituntravailnon prvu au dbut du stage, mais il tait
ncessaire pour atteindre les objectifs viss. La modlisation analytique est dveloppe et
dtaille dans le dernier chapitre de ce rapport.

3.5 Environnement de Simulation

Dans cette partie, nous dtaillons le dveloppement et la programmation des solutions proposs
par 3GPP et de la procdure RACH dans le simulateur LTE-Sim.

30

Nous commenonsdabordexpliquerunscnario LTE juste pour introduire la programmation

dans le simulateur LTE-Sim.
Avec LTE-Sim, un scnario LTE peut tre cr comme une fonction statique dans un fichier
entte C++ et doit tre stock dans le rpertoire Simulation/Scnarios. Une rfrence pour cette
fonction doit tre introduite dans le programme principal.
Un scnario de base peut tre cr en utilisant les instructions suivantes :
a- Crer une instance pour les composants: Simulator, NetworkManager, FlowsManager,
FrameManager.
b- Crer des objets de type Cell, ENodeB et UE en utilisant les mthodes de la classe
NetworkManager. Pour chacun de ces objets, plusieurs paramtres peuvent tre assigns
directement avec le constructeur de la classe.
c- Crer les applications,etdfinirpourchacunedelles,letypedudataRadiobearer(GBRou
non GBR), les paramtres de classification IP, le temps de dbut, le temps de fin et les
paramtres de QoS.
d- Dfinir la dure de la simulation, et finalement appeler la fonction Simulator::Run

3.6 Mise jour du simulateur

Pour pouvoir commencer les simulations, il a fallu mettre jour le simulateur par
l'implmentation des solutions des procdures d'accs dans LTE. Dans ce qui suit, nous
dtaillons cela.

3.6.1 Implmentation de la procdure RACH :

La procdure RACH nest pas dveloppe dans le simulateur LTE-Sim. Do la ncessit
dimplmenter cetteprocdureetlintgrerjustelorsqueleterminal essaiedaccder au rseau
avant de transmettre ses donnes. Nous avons donc introduit un code reprsentant la procdure
RACH dans le code du simulateur LTE-Sim juste lors de la cration de lapplication, avant la
transmission du premier paquet. La procdure RACH est base sur le choix dun prambule
alatoire entre 0 et 55 et la transmission de ceprambuleverslENodeB.Si leterminal reoit
une rponse de lENodeB, dans un temps limit, bien dfini, alors la procdure RACH est
suppose russie. Sinon, on aura alors une retransmission dun nouveau prambule jusqu
arriver au nombre maximal de retransmission.
Le code reprsentant la procdure RACH est introduit dans le code initial du simulateur LTESim, prcisment au dbut de la mthode Application::Start(), c..d. la procdure RACH est
ralise juste la premire fois le terminal accde au rseau.

31

Figure 3-1: Algorithme dimplmentation de la procdure RACH

3.6.2 Implmentation des solutions de 3GPP

La deuxime tape du travail consiste dvelopper les solutions proposes par 3GPP. Ces
solutions sont dj expliques dans le chapitre prcdent. Nous avons dvelopp quatre solutions
parmi cinq : L Access Class Barring , Resource Separation , Backoff Scheme et
Slotted Access . La solution Dynamic Allocation of RACH Resources nest pas
compltement dveloppe suite aux complexits de la programmation de celle-ci.
a- Access Class Barring
A la cration de chaque dispositif M2M, on lassocie une classe daccs spcifique. Cette
association est ralise dune faon alatoire, en dautres termes, on dfinit 10 classes daccs
pour les dispositifs [16].Achaqueclassedaccsonspcifieunevaleurdiffrentedep.Lorsde
la cration de chaque dispositif, on tire un nombre alatoire entre 0 et 9 et ce nombre spcifie la
classe daccs laquelle appartient le dispositif. Notons que cette solution doit prcder la
procdure RACH, c..d. si la solution ACB russit on passe la procdure RACH. Sinon, le
dispositif est bloqu. Voil le schma de lalgorithme prsentant la solution Access Class
Barring et introduit dans le simulateur LTE-Sim juste avant le code de la procdure RACH.

32

Figure 3-2: Algorithme dimplmentation de la solution ACB

b- Backoff Scheme
Dansceschma,suitelchec pendantlessaidaccsaurseau,ledispositifM2Mestretard
pendant un temps de backoff pour essayer de retransmettre. Dans la programmation, cela est
ralis par le fait de retarder lvnement event de laccs de cet dispositif M2M dans le
calendrier des vnements, c..d. on retarde lintroduction de lvnement dans le calendrier
jusquletempstir du Backoff.

Figure 3-3: Algorithme dimplmentation de la solution Backoff

33

c- Separate RACH resources for MTC

Danscettesolution,ongroupelesressourcesdisponiblesen2groupeslunspcifiquepourles
terminaux normauxetlautrepourles dispositifs M2M.
Dans notre simulation, on considre que les ressources disponibles sont les prambules existants.
Alors on groupe lensemble des prambules en 2 groupes : les prambules de 0 27 sont
spcifis pour les terminaux normaux alors que les prambules de 28 54 sont spcifis pour les
dispositifs M2M.
d- Slotted Access
Cette solution est la dernire solution implmente. Dans cette solution, on permet au dispositif
M2Mdaccderau rseau juste des moments bien dfinis. Dans la programmation, on a choisi
que le dispositif M2M pouvait accder au rseau (commencer la procdure RACH) des instants
de temps multiples de 3 de l'instant initial (cette valeur est choisie alatoirement). On peut
choisir la valeur correspondante aux applications existantes. L'algorithme de distribution des
slots de temps n'est pas implment bien sr car nous ne disposons pas d'un algorithme
spcifique.

Figure 3-4: Algorithme dimplmentation de la solution Slotted Access

Notons finalement pour clturer cette partie que des extraits de codes relatifs l'implmentation
de ces solutions dans LTE-Sim se trouvent dans l'annexe B.

3.7 Simulations et rsultats

Dans ce qui suit, nous donnons les caractristiques gnrales des scnarios de simulations. Nous
choisissons de simuler une cellule unique avec un seul ENodeB et 2 types de terminaux : les
terminaux normaux (communication H2H) et les dispositifs M2M. Dans la programmation, on a
le mme code pour les deux types des terminaux, mais la diffrence et la particularit rsident
34

dansletypedesapplicationsdfiniespources2types.Onassimilelapplicationspcifieaux
dispositifs M2M celle des compteurs lectriques intelligents. CestalorsuneapplicationCBR
(Constant bit Rate) avec un intervalle de temps et une taille de paquet bien spcifis. Pour
lapplicationH2Honpeutchoisirnimportequelleapplicationdjexistantedansle simulateur.
Comme on vise lvaluation des mcanismes daccs, on na pas besoin de crer plusieurs
cellules dans les scnarios,ilsuffitdavoirunecelluleuniqueettouslesdispositifs essaient de
transmettredesdonnesverslENodeB de cette cellule.

3.7.1 Effet de la communication M2M sur H2H

Avant de comparer les performances des solutions de 3GPP nous avons effectu une simulation
pourmontrerleffetdelintroductiondesapplicationsM2MsurlacommunicationH2H.
Pour valuer les rsultats obtenus nous avons utiliss deux critres : Le taux de perte des paquets
et le dlai de bout en bout.
On travaille toujours avec une seule cellule et dans le sens montant : bande passante = 5MHz, 1
ENodeB, 10 terminaux normaux H2H, et un nombre croissant des dispositifs M2M allant de 0
1500. On considre le mme type dapplication pour les terminaux normaux et les dispositifs
M2M (CBR, taille= 100 octets), et en supposant aussi que les dispositifs H2H sont mobiles alors
que les dispositifs M2M sont fixes, nous avons alors obtenu les rsultats suivants :
Taux de perte des communications H2H

Taux de perte

0.15
0.1
0.05
0
0

500

1000

1500

2000

Nombre de dispositifs M2M

Figure 3-5: Taux de perte des paquets de la communication H2H

Delai (s)

Delai des communications H2H

0.003
0.0025
0.002
0.0015
0.001
0.0005
0
0

500

1000

1500

2000

Nombre de dispositifs M2M

Figure 3-6: Dlai de bout en bout de la communication H2H

35

Cesrsultatsmontrenttrsclairementleffetngatifdelintroduction des applications M2M sur

lacommunicationH2Hdjexistante.AveclaugmentationdunombredesdispositifsM2M(ce
quiestlecasrelcausedelaugmentationrapidedanslemarchdesapplicationsM2Mactuel),
on va avoir une dgradation de performance de la communication H2H.
On a besoin alors certainement des nouvelles solutions afin de rsoudre cet effet ngatif des
communications MTC. Cela donne une preuve pour la recherche et la focalisation des
organisations et des chercheurs sur la congestion produite par les dispositifs M2M et les
meilleures solutions rsolvant cette congestion.

3.7.2 Evaluation et comparaison des solutions de 3GPP

On a choisi pour cette valuation les 3 mtriques dj dfinis dans les standards de 3GPP [29] :
la probabilitdesuccsdaccs,laprobabilitdecollisionetledlaidaccs.Daprs[29] :
Probabilit de succs daccs : dfinie comme la probabilit de complter avec succs la
procdure RACH en respectant le nombre maximal de retransmission.
Probabilit de Collision : dfinie comme la probabilit que 2 ou plusieurs dispositifs M2M
ralisent un essai daccs alatoire en utilisant exactement le mme prambule pendant la
priode de temps dfinie.
Dlai daccs : dfini comme la moyenne de dlai pour chaque procdure RACH entre le
premieressaidaccsetlafin de la procdure RACH pour les dispositifs M2M qui ont russi
accder le rseau.
Pour calculer ces mtriques il fallait dvelopper un code que nous avons introduit au sein du
simulateur. A chaque choix dun nouveau prambule, on a introduit une ligne dans le fichier
tracedesrsultats,indiquantliddu dispositif courant, le prambule choisietlinstantauquelce
prambule a t transmis.
Ensuite, nous avons dvelopp un code pour compter le nombre de fois o deux prambules
identiques ont t slectionns en mme temps. Cela traduit le phnomne de collision. La
probabilit de collision sera alors calcule par le rapport entre ce nombre de collision trouv et le
nombre total des prambules transmis.
Pour le calcul de la probabilit de succs, nous avons dvelopp un code similaire. A chaque fois
quun utilisateur russit accder au rseau avec un certain prambule, on introduit une ligne
dans le fichier trace indiquant lid de cet utilisateur, son prambule russi et linstant de
transmission du prambule. Nous avons pu alors compter le nombre des prambules qui ont
russi et le diviser par le nombre total des prambules transmis pour trouver la probabilit de
succs.
Enfin en ce qui concerne le dlai daccs au rseau, nous avons calcul la diffrence entre
linstant o lutilisateur essaie la premire fois daccder le rseau, et linstant o lutilisateur
36

accde vraiment au rseau, et nous avons obtenuledlaidaccsparlasoustractionde ces deux

valeurs.

3.7.3 Scnarios simuls

Pour bien valuer et comparer ces quatre solutions, nous avons simul 2 scnarios diffrents.
Chaque paramtre de performance est la moyenne des valeurs calcules suite x excutions de la
simulation. Toujours nous avons considr le fameux scnario du sens montant avec une cellule
unique, un eNodeB et plusieurs dispositifs M2M et H2H quiessaientdaccder au rseau.
Dans les 2 scnarios considrs, nous avons choisi un nombre fixe des terminaux H2H = 30
terminaux, mais un nombre croissant de dispositifs M2M allant de 0 1200 dans le scnario 1 et
de 0 2000 dans le scnario 2. 2000 tait le nombre maximal que nous avons pu atteindre, et
celantaitpaspossiblequenlaissantlasimulation3jourscomplets sur 2 ordinateurs portables
distincts.
Pour les 2 scnarios on a considr que les terminaux H2H sont mobiles avec une vitesse =
3Km/h, alors que les dispositifs M2M sont fixes. De plus on a pris un temps de simulation court,
juste gal 5s comme nous valuons seulementlaccsaurseau. Pour les deux cas considrs
nous avons fix la bande passante 3MHz.
Enfin,encequiconcerneletypedapplicationchoisi,onpeutnoterquecesscnariostraitent2
cas distincts : le premier est celui regroupant les scnarios 1 o on considre un seul type
dapplicationpourlesterminauxH2HetlesdispositifsM2M (CBR).
Le deuxime cas est celui du scnario 2, pour ce scnario on a considr un rseau htrogne :
PourlesterminauxH2Honaadopt2typesdiffrentsdapplication (CBR et VOIP), alors que
pour les dispositifs MTC, on a adopt 3 flux de donns diffrents (mme application de type
M2M mais avec des intervalles de temps et tailles des paquets diffrents). Le tableau rcapitule
les caractristiques de ces 2 scnarios.
Nous notons finalement qu'il a t prvu de faire plus de scenarios htrognes mais la limitation
des dures d'excution nous a freins.
Table 3-1: Rcapitulation des paramtres des 2 scnarios dvelopps

Paramtres
Nombre des terminaux H2H
Nombre des dispositifs M2M
TypedapplicationH2H
Type dapplicationM2M

Scnario 1
30
0 1300
CBR
M2M

Temps de simulation (s)

Vitesse H2H (Km/h)
Vitesse M2M (Km/h)

5
3
0

Scnario 2
30
0 2000
CBR + VOIP
M2M (3 tailles diffrentes, 3
intervalles de temps diffrents)
5
3
0
37

3.7.4 Analyse des rsultats

Les figures 3-7, 3-8 et 3-9 reprsentent les rsultats obtenus du scnario 2. Nous navons pas
donn les rsultats du scnario 1 car ces rsultats sont similaires et entrainent la mme
interprtation (le scnario 2 inclut le scnario 1).
A partir des graphes, nous pouvons vrifierquelaprobabilitdesuccsdaccsestdcroissante
pourlesquatresolutions.Mmeaveclintroductiondecessolutionspourrsoudreleproblme
de congestion, la probabilit de succs daccs va diminuer cause du grand nombre des
dispositifs M2M. Les solutions 3GPP ne peuvent pas rsoudre le problme compltement mais
peuvent rduire cette congestion et son effet ngatif sur la communication H2H originale.

Probabilit de Succs (s)

Probabilit de Succs
0.4
0.3
Access Barring

0.2

Backoff Scheme

0.1

Ressources Separation

Slotted Access
0

500

1000

1500

2000

2500

Nombre des dispositifs M2M

Figure 3-7: Probabilit de succs

Pour choisir la meilleure solution, il faut comparer ces mthodes. La mthode Backoff
possde la plus grande valeur de la probabilit de succs, en comparaison avec les autres
mthodes, la mthode Slotted Access possde la valeur la plus faible, la mthode Access
Barring et Resource Separation possdentdesprobabilitsdesuccsdaccsproches,mais
la mthode Resource Separation possde une valeur plus importante. Cela peut tre
interprt. En effet, les deux mthodes Access Class Barring et Slotted Access
empchentledispositifM2Mdaccderlerseausilaconditiondelasolutionnestpasvrifie.
Alors quon na pas un phnomne dempchement dans les 2 autres solutions, seulement un
retard de temps pour la solution Backoff .
On peut conclure quen se basant sur la probabilit de succs daccs, on peut dire que la
solution Backoff est la meilleure solution alors que la solution Slotted Access est la
moins performante.

38

Probabilit de Collision

Probabilit de Collision
0.08
0.06
Access Barring

0.04

Backoff Scheme

0.02

Ressources Separation

0
0

500

1000

1500

2000

2500

Slotted Access

Nombre des dispositifs M2M

Figure 3-8: Probabilit de collision

En considrant la probabilit de collision, nous pouvons remarquer que la solution Resource

Separation possde la valeur maximale, suivie par la solution Backoff , ensuite on peut
trouver la solution Access Class Barring , et enfin la solution Slotted Access . Le fait que
la solution Resource Separation aura la valeur maximale de la probabilit de collision est
expliqu par le fait que dans cette mthode on a spar les prambules de la procdure RACH en
2 groupes : Le premier pour les terminaux normaux H2H, et le second pour les dispositifs M2M.
Donc on va avoir plus de collisions, plus particulirement dans le groupe M2M. Ensuite, comme
nous avons trouvdanslanalysedelaprobabilitdesuccsquungrandnombrededispositifs
peut accder au rseau dans les solutions Backoff et Resource Separation puisquilnya
pas un phnomne de blocage comme dans les solutions Access Barring et Slotted
Access , les deux solutions Backoff et Resource Separation doivent avoir des valeurs de
la probabilit de collision plus grandes que celles des solutions Access Barring et Slotted
Access . La solution Slotted Access peut tre considre la meilleure suivie par la solution
Access Barring en ce qui concerne la probabilit de collision.

Dlai d'accs (s)

Dlai d'accs
0.006
0.005
0.004
0.003
0.002
0.001
0

Access Barring
Backoff Scheme
Ressources Separation
0

500

1000

1500

2000

2500

Nombre des dispositifs M2M

Figure 3-9: Dlai daccs

39

Slotted Access

Il nous reste enfin la comparaison ces solutions en considrant le dlai daccs. Pour le dlai
daccsonpeutvrifierquelasolution Backoff possde la valeur maximale. Cela peut tre
simplement expliqu : La solution Backoff est principalement base sur le retardement de la
procduredaccspourdiminuerlacongestion.Lasolutionqui suit Backoff est la solution
Access Barring ,cettesolutionencoreretardelaprocduredaccsaurseausisacondition
nest pas vrifie mais la valeur du temps de dlai dans cette solution est toujours infrieur
celui de la solution Backoff . Les deux solutions Backoff et Access Barring ont des
valeursdedlaidaccsplusgrandesquecellesdesautressolutions.
La solution Slotted Access qui possdait la plus faible valeur de la probabilit de succs, la
plus faible valeurdelaprobabilitdecollision,etlaplusfaiblevaleurdudlaidaccspeuttre
considre donc, la fin de cette comparaison, la solution optimale pour rsoudre le problme de
congestionauniveaudaccsdanslesrseaux LTE. Par contre, cette solution est base sur un
algorithme de distribution de l'accs efficace, ce qui n'est pas du tout vident avec des
communications M2M htrognes.

3.8 Conclusion
Dans ce chapitre, nous avons prsent le dveloppement des solutions de 3GPP et les simulations
dans LTE-Sim. Nous avons analys les rsultats et nous avons compar ces solutions en nous
basant sur trois mtriques de performance. Nous avons trouv que la solution Slotted Access
est la meilleure solution, introduisant leminimumdlaidaccs,etayantlaprobabilitdaccset
la probabilit de collision minimale. Les scnarios de simulations htrognes n'taient pas
possibles suite aux limitations dtailles dans ce chapitre. Dans le chapitre suivant, on va tablir
une modlisation analytique des mcanismesdaccsalatoire.Ondsirevrifiersilesrsultats
analytiques correspondent et corrlent bien avec les rsultats trouvs dans les simulations.

40

Chapitre 4.

MODELISATION ANALYTIQUE DES MECANISMES

DACCES ALEATOIRES DANS LTE

4.1 Introduction
L'objectif principal de cestageestdvaluerles performances des mcanismesdaccsalatoires
proposs pour le rseau LTE en prsence des communications M2M. Dans le chapitre 3, nous
avons effectu cette valuation en se basant sur les rsultats obtenus de plusieurs simulations
ralises dans l'environnement de simulation LTE-Sim. Malheureusement, les rsultats de ces
simulationsntaientpasobtenus facilement et rapidement ( titre d'exemple, des simulations ont
t laisses trois jours pour l'obtention des rsultats et d'autres ont caus l'implantation de
l'ordinateur). En plus, plusieurs scnarios comportant des modles de trafics htrognes, des
modles de mobilit diffrents et un plus grand nombre de dispositifs, que nous avons voulu faire
n'ont pas eu la chance d'tre excuts cause de plusieurs contraintes et limitations expliques
dans le chapitre prcdent, principalement le problme des longues dures de simulation et de
l'implantation de l'ordinateur.
Nous savons d'un autre ct qu' part les atouts offerts par la modlisation analytique des
phnomnes physiques, celle-ci permet d'valuer les performances et par suite surmonter les
limitations des simulations. Ceci nous a pousss dvelopper des modles analytiques pour les
mcanismesdaccs alatoires proposs etdessayerdvaluercesmcanismesen analysant les
rsultats analytiques obtenus.
Ce chapitre est organis comme suit : dans la premire partie, nous prsentons une analyse
dtaille de notre approche de modlisation analytique. Cette modlisation se base
principalement sur deux parties complmentaires : Le modle de la procdure RACH tendu par
le modle de la solution 3GPP. Dans la deuxime partie, une comparaison analytique entre les
solutions de 3GPP est ralise. Pour finir, le modle propos est valid en comparant ses
rsultats aux rsultats de la simulation.

4.2 Gnralits sur la modlisation analytique

Danslesannesrcentes,ungrandnombredtudesont t raliss dans la littrature dans le but
dvalueretdanalyserlaperformance de la procdure RACH. Cette analyse de performance a
tralisenonseulementparlintermdiairedessimulations,maisaussipardesmodlisations
analytiques de la procdure RACH.
Gnralement, nous pouvons classifier ces modles analytiques en deux groupes. Le premier
englobelesmodlesbasssurlutilisationdeschanesdeMarkovdiscrtes,alorsquelesecond
grouperegroupeceuxbasssurlanalysedesvaleursmoyennesetdesformulesstatistiques.Au
mieuxdenotreconnaissance,ilnexiste pasdtudecomparativeentrecesdeuxapprochesence
41

qui concerne la validit et la fidlit de prdiction. Cependant, il apparat que la deuxime

approche est plus simple mme quelle nglige beaucoup de dtails du systme et impose un
certain nombre dhypothses.
Notons que notre objectif pour le moment n'est pas d'avoir un modle analytique du systme tout
entier; c..d. un modle englobant le modle d'entre du trafic et celui du comportement du
rseau LTE dans sa procdure d'accs. En fait si c'est le cas, les modles bass sur les chanes de
Markov seront la solution la plus approprie. Notre objectif est d'valuer le comportement des
solutions proposes pour une variation des taux de demande d'accs. Pour cela, nous pensons que
la deuxime approche est compltement suffisante pour atteindre les objectifs du travail.
Nous ajoutons aussi que la modlisation analytique totale du systme avec le dveloppement du
trafic provenant des applications M2M est vraiment du rve. Les applications M2M sont assez
diverses provoquant toujours une htrognit des types de trafic : Nous pouvons trouver par
exemple les compteurs lectriques intelligents qui transmettent des temps bien prcis et
priodiques, mais nous pouvons de mme trouver les camras de scurit, qui transmettent des
larges quantits de donnes seulement lors de l'apparition d'un vnement anormal. Cette
htrognit est encore prsente lors de la mobilit o nous pouvons trouver plusieurs modles
diffrents : les applications V2V (Vhicule to Vhicule) imposent une mobilit importante alors
que les compteurs intelligents sont mobilit en gnral nulle.
Dans ce qui suit, nous allons prsenter donc une modlisation analytique base sur le
raisonnement probabiliste des mcanismes daccs alatoires au rseau, plus prcisment de la
procdure RACH dj explique couple a lune des solutions 3GPP et formant ainsi le
mcanismedaccstotalaurseauLTEpar les dispositifs M2M.

4.3 Etude de lexistant

La procdure RACH a t propose depuis longtemps. Dans la technologie cellulaire UMTS,
nous pouvons trouver cette procdure comme dans LTE. Alors, certainement il va y avoir
beaucoup de travail pour sortir avec un modle pour cette procdure. Le document [30] portant le
nom LTE Random-access capacity and collision probability est un travail effectu par 3GPP
qui a pour but l'approximation de la probabilit de collision de la procdure RACH. A partir de
cetteprobabilit,laprobabilitdesuccsdetransmissionetlaprobabilitdchecpeuventtre
dduites.
La procdure RACH est approche au mcanisme Slotted ALOHA 3 parcequelleestralise
des slots de temps bien dtermins : Si un terminal essaie daccder au rseau un slot de

Slotted Aloha est un systme TDMA (Time Division Multiple Access). Le temps est divis en des intervalles de
temps. Un utilisateur disposant de donnes peut transmettre seulement au dbut du slot de temps suivante.

42

temps non spcifi pour la procdure RACH, Il sera empch. Donc, le calcul de la probabilit
de collision est similaire celui du mcanisme SlottedALOHA.Daprs[31], la probabilit de
collision = 1- e-/L avec = Intensit daccs alatoire (nombre des essais daccs
alatoires/sec/cellule) et L = Nombre total des opportunits RACH /sec.
Dans larticle[31], l'auteur rsume les 2 dfinitions proposes par 3GPP pour la probabilit de
collision dans le document TR 37.868 [30]. Cet article prsente en outre un modle analytique
pourdriverlaprobabilitdecollision,laprobabilitdesuccsetlaprobabilitdinactiviten
fonction de ces deux dfinitions.
Danslarticle[32] Revak R.Tyagi et al. visent tudier la transmission des paquets de donnes
de faible taille provenant des applications "e-healthcare" dans les rseaux LTE-Advanced en
supposant que chaque paquet de donnes transmises doit tre prcde par la procdure RACH.
Dans cet article, lauteur analyse mathmatiquement le dlai de la procdure RACH, les
probabilitsdesuccs,dchec,toutensebasantsurladfinitiondelaprobabilitdecollision
donne par 3GPP et vrifie enfin cet analyse avec les simulations.
Nous allons prsenter notre approche de modlisation en deux tapes : dans la premire tape,
nous prsentons le modle de la procdure RACH et dans la deuxime tape nous modlisons
l'extension du modle par la solution 3GPP. Le modle de la procdure RACH est bas sur les
rsultats obtenus dans [32] alors que les modles des diffrentes solutions de 3GPP sont
dvelopps par nous-mmes. Dans ce qui suit nous prsentons le modle RACH ainsi que notre
modlisation analytique des solutions proposes par 3GPP.

4.4 Modle analytique de la procdure RACH

Considrons un systme cellulaire contenant un grand nombre de dispositifs communicants dans
une cellule unique. Le choix dune seule cellule nest pas une limitation du travail comme la
procdure RACH est une interaction entre le terminal et leNodeB de la cellule laquelle il
appartient. En plus, ce choix est impos par les objectifs de cette tude.
Soit les variables principales du modle :
:letauxdarrivedesnouvellesdemandesdaccspendantunepriodeTs (slot de temps)
x : la population des nouvelles demandes et des demandes de retransmission
f : fraction de transmissions russies
: fraction de transmissions choues (aprs W essais de transmission)
o :nombredesprambulesutilissdansltude

43

A ltatdquilibre, le taux de nouvelles demandes balancent celui des demandes choues .

et celui des demandes russies.Do :
= . + x.f

(1)

x.f = .

(2)

Daprs[31]la probabilit de collision P[collision] = 1-e-/L, avec et L dj dfinis.

Dans ce cas = x et L=o, doP[collision] = 1-e-x/o
Celanousdonnelaprobabilitdesuccsdunetransmissionquiseragale : 1 - P[collision] =
e-x/o. Donc f sera gal e-x/o et = (1-f)W c..d.cestlchecdetransmissionaprsW essais.Do
f = e-x/o

(3)

= (1- e-x/o)W

(4)

Introduisons ces formules dans la formule initiale on trouve :

x.e-x/o = (1-(1-e-x/o)W)

(5)

O est nombre de nouvelles demandes qui arrivent pendant un intervalle de temps prcis,
x reprsente le nombre total des demandes d'accs reuesparleNodeBpendantun intervalle de
temps prcis, ce dernier comprend les nouvelles demandes et les demandes de retransmission. Le
nombre total des prambules disponibles dans la cellule est reprsent par o et finalement W est
le nombre de fois une demande d'accs est essaye avantdtrebloque.
Laprobabilitdavoirexactementncollisionsavantunsuccspeuttremodlise par :
P[n collisions] = (1-f)n . f

(6)

Donclaprobabilitquundispositif subisse ncollisionssachantquiltransmetestalors :

P[n collisions/transmission] =

(7)

Avec n=0, 1, 2, W-1.

DolenombredecollisionsE[C] est donn par :
E[C] =

(8)

Finalement,ensupposantqueladuredelintervallesurlequeloneffectuenotretudeestTs,le
dlai E[D] sera :
44

E[D] =

(9)

Cette quation donne le dlai pour les accs survenus aprs collisions seulement. Pour exprimer
le dlai moyen en tenant compte du dlai d'accs direct sanscollision,lexpressiondudlaisera :

E[D] =
=

(10)

(11)

En utilisant les 2 quations suivantes avec 0 < y < 1 :

(12)

(13)

Et en supposant que = (1 - f), ontrouvelquationdudlai :

E[D] =

(14)

4.5 Modlisation des solutions de 3GPP

Ltudequiprcdenousapermisde modliserlaprobabilitdesuccs,decollision,dchec,et
le dlai moyen de la procdure RACH. Cette tude nest pas suffisante. Notre but est de bien
valuer les solutions 3GPP dans un environnement o il y a un grand nombre de demandes
daccs des dispositifs M2M. Dans ce qui suit, nous essayons de donner une modlisation
analytique de ces solutions assez raliste et simple que possible afin dobtenir une bonne
valuation et une bonne comparaison entre ces solutions.
4.5.1 Access Class Barring
Cette solution consiste choisir un nombre q appartenant lintervalle [0, 1] et comparer ce
nombre avec un nombre p (valeur caractrisant la classe daccs laquelle appartient le
dispositif), p est encore entre 0 et 1. Si q < p le dispositif procde la RACH. Sinon il est arrt
duntemps=ac-barring time avant de ressayer de nouveau.
En utilisant le principe de la probabilit gomtrique :
0

1
P

la probabilit de tirer un nombre alatoire entre a et b plus petit

que x avec x appartient [a, b] est :

Lapplicationdeceprincipeicinousdonnequelaprobabilit que (q < p) =

45

Do :
P[succs ACB] = p

(15)

P[chec ACB] = 1-p

(16)

En ce qui concerne le dlai pos par cette mthode :

Dlai[ACB] = (1-p)* ac-Barring-time + p*0 = (1-p)* ac-Barring-time

(17)

4.5.2 Backoff Scheme

Le principe de la mthode de "backoff" en LTE est le suivant: si un dispositif M2M choue
accder au rseau, il doit choisir un nombre alatoire u entre 0 et U o U est la fentre du
Backoffetdoitalorsattendreuntempsgalutimesslotsavantdessayer de nouveau.
DolavaleurmoyennedudlaiposparcettesolutionestgaltailledelafentreBackoff
=

* Ts = Backoff time

DolquationdudlaidelasolutionBackoffsera :
Dlai [Backoff] = Backoff time

(18)

Cette valeur dpend seulement de la taille de la fentre Backoff.

4.5.3 Resource Separation
Cette mthode consiste sparer les ressources disponibles entre les dispositifs M2M et les
dispositifs H2H (les terminaux normaux). Les ressources dans notre tude sont les prambules.
Commenons par le calcul de la probabilit de succs P[succs RACH] = e-x/o = f
Soit o = o1 + o2
O o1 : le nombre des prambules propres
o2 : le nombre de prambules propres la communication M2M

la

communication

DoP[succs RACH] = P[succs RACH M2M] = e-x/o2

f = e-x/o2

(19)

De mme la probabilit de collision sera = 1 e-x/o2 et

= (1 e-x/o2 )W

(20)

Le dlai de la procdure RACH sera :

46

H2H

Dlai [RACH] =

(21)

4.5.4 Slotted Access

Dans ce schma, chaque terminal M2M est seulement autoris transmettre le prambule des
slots spcifiques dans les trames radio. d'autres moments, les terminaux M2M sont en mode de
veille. Le mcanisme, qui est utilis par le dispositif M2M pour calculer les slots sur lesquels il
peuttransmettreestbassurlidentitdecedispositifetdesparamtrestransmisparleNodeB.
Onconsidredanstoutenotretude analytique quelaccsse faitparslot( : cest lenombre
darrivs des demandes RACH par slot). Nous ne pouvons pas savoir chaque slot si cette
demandeestoriginedunterminalH2HoudundispositifM2M.Donccettesolutionnepeuttre
modlise analytiquement dans les conditions de cette tude. La solution Slotted Access a un
effet direct dediminuer laprobabilitdaccsaurseaudesdispositifs M2M. Doncjustepour
avoir une ide sur leffet de cette solution, nous pouvons considrer le mme cas pris dans la
simulation o nous avonsconsidrquun dispositif M2M peut accder le rseau une fois parmi
chaque3demandesdaccsRACH.
Donc la probabilit de succs de cette solution sera gal :
P[succs Slotted Access] = 1/3

(22)

4.6 Modlisation du mcanisme daccs global

4.6.1 Dfinition
Dans les parties qui prcdent nous avons modlis la procdure RACH ainsi que les extensions
ncessaires pour chaque solution 3GPP. En effet, lemcanismedaccsaurseaudesdispositifs
M2M est une combinaison de ces 2 phnomnes. Donc dans cette section on va essayer de
modliser le systme en total reprsent par la solution 3GPP suivi par la procdure RACH.
Modle analytique de la procdure
RACH

Modle analytique de la solution de

3GPP

Nous adoptons dans cette section la reprsentation suivante Ps[], Pe[] et Pc[] pour reprsenter la
probabilitdesuccs,dchecetdecollisiondechaquemcanismedaccs.Onnoteencorepar :

1 : le mcanisme daccs 1 constituant de l Access Class Barring suivi de la

procdure RACH
2: Backoff Sheme + Procdure RACH
3: Resource Separation + Procdure RACH
4: Slotted Access + Procdure RACH

47

4.6.2 Calcul des probabilits et du dlai d'acces moyen

Laprobabilitquunmcanismerussitestgallaprobabilitderussitedelasolution3GPP
et la procdure RACH ensemble, alors :
Ps=Ps[3GPP et RACH]=Ps[3GPP].Ps[RACH]

(23)

De mmelaprobabilitdchecseralaprobabilitque la solution de 3GPP choue ou bien la

solutionde3GPPrussitmaislaprocdureRACHchoue.Onobtientlaprobabilitdchecdu
mcanisme global qui sera :
Pe = Pe[3GPP] + Ps [3GPP] . Pe[RACH]

(24)

La probabilit de collision est la probabilit que la solution 3GPP russit mais avec une collision
pendant la procdure RACH
Pc = Ps[3GPP] . Pc[RACH]

(25)

Le dlai D sera gal :

D = D[3GPP] + D[RACH]

(26)

Il nous reste enfin de calculer ces valeurs pour les 4 solutions.

Ps[1] = Ps[ACB] . Ps[RACH] = p . f = p . e-x/o

(27)

Pe[1] = Pe[ACB] + Ps[ACB] . Pe[RACH] = (1-p) + p . (1-f)W = (1-p) + p . (1- e-x/o)W

(28)

Pc[1] = Ps[ACB] . Pc[RACH] = p . (1-f ) = p. (1- e-x/o)

(30)

D[1] = D[ACB] + D[RACH] = (1-p)*ac-Barringtime +

= (1-p)* ac-Barringtime +

D[1] = (1-p)*ac-Barringtime +

Ps[2] = Ps[Backoff] . Ps[RACH] = e-x/o

(31)
(32)

Pe[2] = Pe[Backoff] + Ps[Backoff] . Pe[RACH] = (1- e-x/o)W

Pc[2] = 1- e-x/o

(33)
(34)

48

D[2]= D[Backoff] +D[RACH] = Backoff +

(35)
Ps[3] = Ps[Resource Separation] . Ps[RACH] = e-x/o2

(36)

Pe[3] = Pe[Resource Separation] + Ps[Resource Separation] . Pe[RACH] = Pe[RACH] =

(1 - e-x/o2)W

(37)

Pc[3] = 1 - e-x/o2

(38)

D[3] = D[Resource Separation] + Dlai [RACH] =

(39)
Ps[4] = Ps[Slotted Access] . Ps[RACH] = 1/3 . e-x/o

(40)

Pe[4] = Pe[Slotted Access] + Ps[Slotted Access] . Pe[RACH] =(1- 1/3) + 1/3 * (1- e-x/o)W
(41)
Pc[4] = 1/3 . (1- e-x/o)

(42)

D[4] = D[Slotted Access] + D[RACH] =

(43)

4.7 Rsultats et Analyses

Les quations prcdentes ont t implmentes dans Matlab afin dvaluer les solutions de
3GPP en utilisant les mme mtriques de performance utiliss dans les simulations sous LTESim. Rappelons que les mtriques utilises dans les simulations taient la probabilit de succs
daccs, la probabilit de collision et le dlai daccs. Les rsultats obtenus sont prsents cidessous :

49

Figure 4-1: Probabilit de succs daccs obtenue avec le modle analytique propos

Figure 4-2: Probabilit de collision obtenue avec le modle analytique propos

Figure 4-3: Dlai daccs obtenu avec le modle analytique propos

50

A partir des rsultats obtenus, nous pouvons vrifier que la solution Backoff possde la plus
grande probabilit de succsdaccs,alorsquelasolution Slotted Access possde la valeur
minimale.Cestlemmersultatobtenudanslessimulations.Demme,pourlaprobabilitde
collision, la solution Resource Separation possde la valeur maximale suivie par la solution
Backoff , alors que la solution Slotted Access possde la valeur minimale. Ce rsultat est
encorelemmequeceluiobtenudanslessimulations.Enfin,encequiconcerneledlaidaccs,
nous pouvons noter que la solution Backoff provoque le dlai maximal avant daccder au
rseau, alors que la solution Slotted Access donne le dlai minimal. Toujours, mme rsultat
que la simulation.
Les rsultats obtenus par le modle analytique sont valids par les rsultats de la simulation. La
solution Slotted Access parat tre la solution optimale pour rduire la congestion dans le
rseaudaccs.Cependant, cettesolution ncessiteunalgorithmededistributioncomplexe.Ce
quevapousserleschercheursencasdabsencedecetalgorithme penser adopter une autre
solution, tel que par exemple la solution Access Class Barring qui est la plus simple
implmenter. La solution Access Class Barring peut tre amliore afin de surmonter ses
limites.

4.8 Conclusion
Dans ce chapitre, nousavonsprsentlesmodlesanalytiquesdesmcanismesdaccsalatoire
au rseau LTE. L'approche consiste intgrer deux modles complmentaires pour le mcanisme
d'accs : celui de la procdure RACH et le modle de la solution 3GPP. Le modle de la
procdure RACH est pris de la littrature mais nous avons tendu ce modle pour l'adapter aux
solutions proposes par 3GPP. Nous avons implment ces modles et nous avons enfin valid
les rsultats analytiques obtenus avec les rsultats de la simulation.

51

Conclusions et Perspective
L'volution rapide des technologies de communication sans fil avec l'mergence des applications
de natures diffrentes impose des contraintes additionnelles aux oprateurs des rseaux mobiles
d'aujourd'hui. Ces derniers doivent anticiper et mettre jour leur rseau pour subsister et
continuer offrir les services aux clients.
L'internet des choses commence devenir maintenant une ralit. Tout ce qui nous entoure va
communiquer dans le futur proche. Dans ce contexte les communications M2M vont sans doute
rgner. Nous aimons toujours parler des applications killer pour les rseaux cellulaires.
Beaucoup de gens pensent que la prochaine application Killer est le streaming vido, qui est
estim reprsenter jusqu' 60 % du volume des donnes. Aujourd'hui, M2M pourrait ne pas tre
peru comme une application killer . Cependant, mme si M2M devrait avoir des applications
principalement avec des donnes de tailles faibles (certains pourraient gnrer un trafic plus
lev dans le cas de la vidosurveillance), le nombre des terminaux qui se connecteront au rseau
est important. Les prvisions actuelles indiquent quon va avoir un grand march pour les
applications M2M. Et donc il ne doit pas tre tonnant la classification des applications M2M
comme les applications Killer les plus terrifiants du futur proche.
Des solutions efficaces pour le support de ces applications est donc primordial. Le problme
majeur rside dans la congestion au niveau du rseau d'accs. Dans ce stage nous avons adress
ce problme et nous avons analys les solutions proposes par 3GPP LTE. Cette analyse et cette
comparaison de performance a t faite thoriquement, par simulation et par modlisation
analytique. Les solutions tudies sont principalement 1) la sparation des ressources entre les
communications M2M et H2H, 2) la distribution d'accs sur les slots de temps (Slotted Access),
3) l'utilisation du mcanisme de backoff et finalement 4) le retard alatoire en fonction de la
classe du trafic (Access Class Barring).
Cette tude a conclu que les solutions 2 et 4 sont les plus performantes. Par contre la premire
ncessite un algorithme de distribution efficace de l'accs aux slots de temps. La conception de
cet algorithme n'est pas du tout vident vue l'htrognit du trafic M2M dans les diffrentes
cellules, ce qui rend cette solution irralisable. L'Access Class Barring parait tre la solution la
plus russie vue la simplicit d'implmentation et la granularit et la diffrentiation de service
qu'elle peut offrir diffrentes classes de trafic. La performance de cette solution peut tre
ajuste en fonction des classes de services offertes par l'oprateur. Ainsi l'oprateur peut ajuster
les paramtres de cette solution de faon statique pour assurer la performance requise par les
applications M2M qu'il supporte. Un ajustement dynamique de ses paramtres est aussi possible
pour une meilleure efficacit d'utilisation des ressources.

52

Notons que ce travail nous a mis sur le chantier dans ce domaine de recherche assez ouvert.
L'expertise que nous avons eue dans les simulations et dans la modlisation analytique est
exploiter pour amliorer et tendre ce travail qui ne constitue en fait qu'une entre vers un sujet
de thse plus labore. Les perspectives principales rsultantes de ce travail sont les suivantes:
1- Simulations plus excessives introduisant des types bien spcifis d'applications dans le
domaine nergtique, sant et transport. Les trois domaines les plus rpandues
actuellement
2- Amlioration des modles analytiques par l'introduction du modle de trafic pour les trois
applications cites ci-dessus et l'utilisation des chanes de Markov permettant une
valuation plus correcte.
3- Analyse de chaque solution part en fonction de ses paramtres et en prsence des trois
applications avec les communications H2H pour savoir comment peut-on l'amliorer.
4- Proposition d'une solution plus complte avec les dtails sur l'ajustement de ses
paramtres dans les objectifs suivants: Simplicit d'implmentation, efficacit et
performance dans le support d'un grand panel d'applications M2M.

53

Annexe A
Diagramme UML du simulateur LTE-Sim

54

Annexe B
Quelques Lignes du code dvelopp
1- Procdure RACH
void
Application::Start ()
{
//RACH Procedure
for(int j=0 ; j<10 ; j++ )
{
int preamble=(int)rand()% 55;
std::cout << "preamble " << preamble << " at " <<
Simulator::Init()->Now()*100 << endl;
double noise=(double)rand()/(RAND_MAX);
double preamble_=preamble + noise;
double diff= preamble_-preamble;
if(diff <= 0.5)
{
std::cout << "NBpreamble_retransmis " <<
NBpreamble_retransmis << endl;
std::cout << "preamblesucceed " << preamble << " at " <<
Simulator::Init()->Now()*100 << endl;
NBpreamble_retransmis=0;//slotted Access
.
.
.
.
.
.
.
break;
}
else
{
NBpreamble_retransmis++;
if(NBpreamble_retransmis==11)
{
std::cout << "NBpreamble_retransmis " <<
NBpreamble_retransmis << endl;
NBpreamble_retransmis=0;
}
}
55

}
}

2- Access Class Barring:

UserEquipment* ue = (UserEquipment*) GetSource ();
ENodeB* enb= (ENodeB*) GetDestination ();
double p_;
double q;
std::cout << ue->GetTypeUE() << " User avec id " << ue>GetIDNetworkNode() << std::endl;
if (ue->GetTypeUE()=="M2M")
{
double* p=enb->SetP();
p_= p[ue->GetACfactor()];
q=(double)rand()/RAND_MAX;
if ((q < p_))
{
std::cout << "ue id " << ue->GetIDNetworkNode () << "
avec q " << q << " Ok" << endl;
}
else
{
std::cout << "Oops id ue " << ue->GetIDNetworkNode () <<
" avec q " << q << endl;
}
}
else
{
p_=1;
q=0;
}
int NBpreamble_retransmis=0;
if (q < p_)
{

3- Resource Separation:
if (ue->GetTypeUE()=="M2M")
{
preamble=27+(int)rand()% 28;
}
else
{
preamble=(int)rand()% 28;
}
56

4- Slotted Access:
UserEquipment* ue= (UserEquipment*) GetSource();
std::cout << ue->GetTypeUE() << " User avec id " << ue>GetIDNetworkNode() << std::endl;
int NBpreamble_retransmis=0;
double t;
int r;
if (ue->GetTypeUE()=="M2M")
{
t=(double)Simulator::Init()->Now();
std::cout << "time now " << t << endl;
r= ((int)(t*100)) % 3;
std::cout << "reste " << r << endl;
if(r!=0)
{
std::cout << "Not my turn ue " << GetSource ()>GetIDNetworkNode () << endl;
}
}
else
{
r=0;
}
if(r==0){

Backoff Scheme:
M2M::DoStart (void)
{
UserEquipment* ue=(UserEquipment*) GetSource();
double j=(int)ue->Getj()/10;
std::cout << "At " << j << std::endl;
Simulator::Init()->Schedule(j, &M2M::Send, this);
}

57

BIBLIOGRAPHIE
[1] ETSI TS 102 689 v1.1.1 (2010-08) : Machine-to-Machine communications ; M2M service
requirements. Aug. 2010
[2] Z. Fan, G. Kalogridis, C. Efthymiou, M. Sooriyabandara, M. serizawa, J. McGeehan, "The
new frontier of communication research: Smart Grid and smart metering", e-Energy, pp 115-118,
2010
[3] D. Boswarthick, O. Elloumi, and O. Hersent,M2MCommunicationASystemsApproach,
John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ,
United Kingdom, 2012.
[4]www.tutorialspoint.com/lte/lte_ofdm_technology.htm,
[5] Erik Dahlman, Stefan Parkvall, Johan SkldandPerBeming,3GEvolutionHSPAandLTE
forMobileBroadband,ElsevierLtd.,Firstedition2007.
[6] 3GPP TS 36.912 V10.0.0 (2011-03): Feasibility study for Further Advancements for EUTRA. Mar. 2011.
[7]3GPPTR22.868,FacilitatingMachineto MachineCommunicationin3GPPSystems,
Mar. 2007.
[8] 3GPP TS 22.368, Service Requirements for Machine-Type Communication (MTC) ,
Stage 1, June 2010.
[9]3GPPTR23.888SystemImprovementsforMTC,July2010
[10]3GPPTS22.368V11.0.0,ServiceRequirements for Machine-TypeCommunications,
Dec. 2010
[11] S.-Y. Lien, C.-C. Tseng, and K.-C.Chen,CarrierSensingbasedMultipleAccessProtocols
forCognitiveRadioNetworks,Proc. IEEE ICC, 2008.
[12] L. Popova et al.,CooperativeMobile-to-Mobile File Dissemination in Cellular Networks
WithinAUnifiedRadioInterface,Computer Networks, vol. 52, no. 6, Apr. 2008, pp. 115365.
[13]R.Y.Kim,SnoopBasedGroupCommunicationSchemeinCellularMachine-to-Machine
Communications,Proc. ICTC, 2010.
[14] CATT, R2-100182: Access Control of MTC Devices, 3GPP TSG RAN WG2 Meeting
68bis, Jan. 2010.
[15] ZTE, R2-104662: MTC Simulations Results with Specific Solutions, 3GPP TSG RAN
WG2 Meeting 71, Aug 2010.
58

[16] 3GPP R2-112071,EvaluationonpushbasedRANoverloadcontrolschemes,Huaweiand

HiSilicon, RAN2#73bis, April 2011.
[17] K.-D. Lee, S. Kim, and B. Yi, Throughput Comparison of Random Access Methods for
M2MServiceoverLTENetworks,in2011 GLOBECOM Workshops (GC Wkshps), Dec., pp.
373 377.
[18] S.-Y. Lien, K.-C. Chen, and Y. Lin, Toward ubiquitous massive accesses in 3GPP
machine-to-machinecommunications,IEEE Communications Magazine, vol. 49, no. 4, pp. 66
74, April 2011.
[19] S.-Y. Lien and K.-C. Chen, Massive Access Management for QoS Guarantees in 3GPP
Machine-to-MachineCommunications,IEEE Communications Letters, vol. 15, no. 3, pp. 311
313, March 2011.
[20]K.Zheng,F.Hu,W.Wang,W.Xiang,andM.Dohler,CooperativeAccessClassBarring
for Machine-to-Machine Communications, IEEE Transactions on Wireless Communications,
vol. 11, no. 1, pp. 27-32, January 2012.
[21] G. Wang, X. Zhong, S. Mei, and J. Wang, An Adaptive Medium Access Control
Mechanism for Cellular Based Machine to Machine(M2M) Communication, in 2010 IEEE
International Conference on Wireless Information Technology and Systems (ICWITS), Sept., pp.
1-4.
[22] S.Ascent,3GPPLTEtoolboxandblockset,[OnLine]Available:http//www.steepestascent.
com/content/default.asp?page=s2 10.
[23]mimoOn,mi!Mobile,[OnLine] Available: http://www.mimoon.de/ pages/Products/
miMobile/.
[24]Aricent,LTElayer1- LTEbaseband/PHYlibrary,[OnLine]Available:
http://www.aricent.com/Expertise/LTE.aspx.
[25] J. J. Sanchez, G. Gomez, D. Morales-Jimenez, and J. T. Entrambasaguas,Performance
evaluation of OFDMA wireless systems using WM-SIMplatform,ACM Int. Workshop on
Mobility Management and Wireless Access, MobiWac, 2006, pp. 131134.
[26] G.Piro,LTE-Sim - theLTEsimulator,[OnLine]Available:http://telematics.poliba.it
/LTE-Sim.
[27] G. Piro, L.-A.Grieco,G.Boggia,F.Capozzi,P.Camarda,SimulatingLTECellular
Systems:anOpenSourceFramework,IEEE Transactions Vehicular Technologies, Oct. 2010
[28]A.Pellegrini,G.Piro,Multi-threaded Simulation of 4G Cellular Systems within the LTESimFramework,8th IEEE International Workshop on the Performance Analysis and
Enhancement of Wireless Networks (PAEWN), Barcelona, Spain, IEEE Computer Society,
March 2013.
59

[29] 3GPP TR 37.868 V11.2.0 (2011-09): Study on RAN Improvements for Machine-type
Communications. Sept. 2011.
[30] 3GPP R1-061369,LTErandom-accesscapacityandcollisionprobability, TSG-RAN
WG1 #45, May 8-12, 2006
[31] R.-G. Cheng, C.- H. Wei, S.- L. Tsao, and F.- C.Ren,RACHCollisionProbability for
Machine-typeCommunications,Vehicular Technology Conference (VTC Spring), 2012 IEEE
75th, pp 1 5, May 2012
[32] R. R. Tyagi, K.- D.LeeF.AurzadaS.KimM.Reisslein,EfficientDeliveryofFrequent
Small Data for U-healthcare Applications Over LTE-AdvancedNetworks,MobileHealth12,
June 2012.

60