1

No d'ordre 68/1460/G1-EE/2013

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

UNIVERSITE LIBANAISE

FACULTE DE GENIE

BRANCHE 1

BRANCHE 1

2

3

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.

4

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.

5

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.

6

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

7

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

8

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

4.8 Conclusion ............................................................................................................................... 51

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

Annexe A .................................................................................................................................................... 54

Annexe B .................................................................................................................................................... 55

BIBLIOGRAPHIE ........................................................................................................................................... 58

9

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

10

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

11

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

principalcausparlintroductiondecesapplicationsestlacongestionquiseproduitau 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 nonaffecte.Cest pourquoiplusieurs

organisations essaient de dvelopper une solution convenable pour rsoudre ce problme. 3GPP

a propos 5 solutions diffrentes afin de rduire la congestion.

Lobjectifdece travailestdvaluerces solutionsproposes 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.

12

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,

lautomatisationet lecontrol industriel, etc.Les applicationsM2Mpeuventalorstreutilises

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

13

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

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

14

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

desapplicationsM2Mdans lerseaunest jamaisune tchefacile.Lesoprateursdes rseaux

doiventmettre 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.)

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

15

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

donnesencontinuoupriodiquementcommelecapteurde lapressionsanguinedunpatient.

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

16

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

17

b- LecurderseauEPC

LecurderseauappelEPC(EvolvedPacketCore)utilisedes technologies tout IP,

c'est--dire bases sur les protocoles Internet pour la signalisation, le transport de la voix et des

donnes.Cecurde rseaupermet linterconnexion 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.

18

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 de lE-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

19

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 temps-

frquence. 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'inactivitdans 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.

20

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

21

doitcesserdeffectuer laprocduredaccsalatoireet 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 cetteprocduredaccs afindemieux supporter les communicationsM2M.Ces

solutions ainsi que d'autres de la littrature seront discutes en dtail dans le chapitre 2.

22

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

23

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 communicationMTC [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

24

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

dispositifsMTCsurtout lorsque le rseauest surcharg.LACBest initialementconupour 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].

25

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

26

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

27

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

Granularit possible pour

les diffrentes classes de

service

Le choix et l'adaptation de p n'est

pas vident

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

Utilisation efficace des

ressources

Limite par les ressources

disponibles

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

Similaire a l'ACB mais avec plus

de retard

Efficacedanslecasdunefaible

congestion mais non pas au cas

duneimportante congestion

Slotted access L'approche la plus

efficace en thorie

Ncessite un algorithme

complexe de distribution

L'quit est une question

importante dans la distribution

des slots

28

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.

29

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 LTE-

Sim 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.

30

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.

31

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 cetteprocdureet lintgrerjustelorsquele terminalessaiedaccderau rseau

avant de transmettre ses donnes. Nous avons donc introduit un code reprsentant la procdure

RACH dans le code du simulateur LTE-Sim juste lorsde lacrationde 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 deceprambulevers lENodeB.Si le terminal 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 LTE-

Sim, prcisment au dbut de la mthode Application::Start(), c..d. la procdure RACH est

ralise juste la premire fois le terminal accde au rseau.

32

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

associationest ralisedune faonalatoire, endautres termes,ondfinit10classesdaccs

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.

33

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 dispositifM2M 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

34

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

35

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 lemme 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 :

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

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

0

0.05

0.1

0.15

0 500 1000 1500 2000

Tau

x d

e p

erte

Nombre de dispositifs M2M

Taux de perte des communications H2H

0

0.0005

0.001

0.0015

0.002

0.0025

0.003

0 500 1000 1500 2000

Del

ai (

s)

Nombre de dispositifs M2M

Delai des communications H2H

36

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

37

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 Scnario 1 Scnario 2

Nombre des terminaux H2H 30 30

Nombre des dispositifs M2M 0 1300 0 2000

TypedapplicationH2H CBR CBR + VOIP

Type dapplicationM2M M2M M2M (3 tailles diffrentes, 3

intervalles de temps diffrents)

Temps de simulation (s) 5 5

Vitesse H2H (Km/h) 3 3

Vitesse M2M (Km/h) 0 0

38

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.

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.

0

0.1

0.2

0.3

0.4

0 500 1000 1500 2000 2500Pro

bab

ilit

de

Su

ccs

(s)

Nombre des dispositifs M2M

Probabilit de Succs

Access Barring

Backoff Scheme

Ressources Separation

Slotted Access

39

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.

Figure 3-9: Dlai daccs

0

0.02

0.04

0.06

0.08

0 500 1000 1500 2000 2500

Pro

bab

ilit

de

Co

llisi

on

Nombre des dispositifs M2M

Probabilit de Collision

Access Barring

Backoff Scheme

Ressources Separation

Slotted Access

0

0.001

0.002

0.003

0.004

0.005

0.006

0 500 1000 1500 2000 2500

D

lai d

'acc

s (

s)

Nombre des dispositifs M2M

Dlai d'accs

Access Barring

Backoff Scheme

Ressources Separation

Slotted Access

40

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 vrifiemais 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