These Adrien Van Den Bossche

LABORATOIRE LATTIS EA 4155 Groupe SCSF
Systmes Communicants Sans Fil
MEMOIRE de THESE
DOCTORAT de LUNIVERSIT de TOULOUSE II Ecole Doctorale Systmes
Spcialit : Gnie Informatique, Automatique et Traitement du Signal
Prsent par Monsieur Adrien VAN DEN BOSSCHE

Ingnieur ESEO Matre s Sciences Universit Paris VI
Proposition dune nouvelle mthode daccs dterministe pour un rseau personnel sans fil fortes contraintes temporelles
__________ Soutenue le 6 juillet 2007 devant le jury compos de :
Rapporteurs : Examinateurs : Directeur : Co-encadrant : Invit : F. LEPAGE D. SIMPLOT-RYL D. FOURNIER-PRUNARET M. MISSON T. VAL E. CAMPO C. ZARADER Professeur (61) lUniversit Henri Poincar Nancy I Professeur (27) lUniversit des Sciences et Technologies de Lille I Professeur (61) lINSA de Toulouse Professeur (27) lUniversit de Clermont I Professeur (61) lUniversit de Toulouse II Professeur (63) lUniversit de Toulouse II Directeur technique chez Freescale Toulouse
Lonard de Vinci
Laboratoire de Recherche LATTIS EA4155 I.U.T de Blagnac - 1, Place Georges Brassens BP 60073 31 703 Blagnac cedex Tl. : + 33 (0) 5 62 74 75 75 Fax : + 33 (0) 5 62 74 75 87
Remerciements
Je remercie vivement Monsieur le Professeur Thierry Val, directeur adjoint du laboratoire LATTIS, responsable du groupe de recherche SCSF et directeur de ma th` ese, davoir accept e de prendre la direction de mes travaux. Je tiens ` a le remercier tr` es particuli` erement pour lexcellence de son accompagnement, ainsi que pour la conance et la grande autonomie quil ma accord ees pendant ces trois ann ees, tout en etant tr` es disponible d` es que jen exprimais le besoin, et ce, malgr e ses nombreuses contraintes. Je lui suis tout particuli` erement reconnaissant pour son aide active quant ` a mon int egration dans le milieu de la recherche et pour les responsabilit es enrichissantes quil a accept e de me coner pendant le doctorat. Jexprime ma gratitude ` a Monsieur le Professeur Eric Campo, co-encadrant de ma th` ese, pour avoir accept e de codiriger les travaux. Je tiens ` a le remercier vivement pour ses nombreux et pertinents conseils durant toute la dur ee de mon doctorat, mais aussi pour sa disponibilit e et sa grande rigueur, y compris dans les moments o` u le temps nous etait compt e, et ce, malgr e ses multiples engagements. Je tiens egalement ` a exprimer ici toute ma reconnaissance ` a Monsieur le Professeur Jean-Jacques Mercier, pr ec edant directeur du laboratoire, pour ses g en ereux et constants appuis, ses nombreux encouragements ainsi que pour la richesse de ses conseils. Je le remercie egalement de mavoir accueilli dans le laboratoire et t emoign e une grande conance, et ce, depuis mon premier stage dans l equipe. Je remercie Messieurs les Professeurs Francis Lepage et David Simplot-Ryl pour lint er et quils ont port e` a mes travaux en ayant accept e de les rapporter et de participer au jury de la th` ese. Je remercie egalement Madame le Professeur Danielle Fournier-Prunaret, directrice du LATTIS, pour sa participation au jury, ainsi que Monsieur le Professeur Michel Misson, pour son attention, ses conseils judicieux et sa pr esence au jury. Je remercie egalement Monsieur Cyril Zarader, Directeur Technique chez Freescale Toulouse, pour sa disponibilit e ainsi que son aide technique durant toute la dur ee du doctorat. Merci egalement ` a lui davoir accept e linvitation du jury. Je veux egalement remercier tous les membres de l equipe : permanents Gilles, Fabrice, JeanFran cois, Laurent et Laurence, doctorants et post-doctorants Salim, C eline, Ahc` ene, Tarik, Nicolas et Jackson, ainsi que les stagiaires, qui ont tous largement contribu e` a lexcellente atmosph` ere du laboratoire. Je tiens egalement ` a remercier ici les membres des equipes du groupe L2I. Merci ` a tous et ` a chacun, pour laide et leurs encouragements qui ont contribu e` a la r eussite des travaux. Je remercie egalement chaleureusement le personnel de lIUT de Blagnac : enseignants, techniciens, personnel administratif et coll` egues, pour laide et lint egration quils mont oertes sans lesquelles ces trois ann ees nauraient pas et e aussi enrichissantes. Je tiens egalement ` a exprimer ma gratitude ` a lEcole Doctorale Syst` emes de Toulouse de mavoir accord e une bourse pour nancer mes travaux de th` ese. Merci egalement de mavoir permis de participer a lorganisation du congr` ` es des Doctorants 2005. Je remercie aectueusement ma famille mes parents, grands-parents, fr` eres et sur, cousins ainsi que mes amis de La Troupe et de Toulouse pour laide quils mont apport ee, mais aussi leur soutien et leur patience pendant ces trois ann ees o` u mon investissement a pes e sur ma disponibilit e. Enn, je tiens ` a remercier tr` es aectueusement Marie pour sa grande conance et son soutien malgr e la distance qui nous s epare. Merci pour sa patience et sa disponibilit e qui nous ont permis de nous retrouver r eguli` erement malgr e mon intense activit e au laboratoire ; merci enn ` a son aection qui a, elle aussi, largement contribu e` a la r eussite de mes trois ann ees de doctorat.
Groupe SCSF LATTIS EA4155
Table des mati` eres

1 Les r eseaux sans l et la Qualit e de Service 1 Etat de lart des technologies de r eseaux sans l . . . . . . . . . . . . . . . . . . . . . . . 1.1 Classication des technologies r eseaux . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Les r eseaux sans l etendus (WWAN) . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Les r eseaux sans l m etropolitains (WMAN) . . . . . . . . . . . . . . . . . . . . 1.3.1 La Boucle Locale Radio (BLR) . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 ETSI HiperMAN / IEEE 802.16, WiMAX . . . . . . . . . . . . . . . . 1.3.3 IEEE 802.20, Mobile Broadband Wireless Access (MWBA) . . . . . . . 1.3.4 Le ph enom` ene des r eseaux sans l ruraux et des r eseaux sans l coop erants 1.4 Les r eseaux locaux sans l (WLAN) . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 ETSI HiperLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1.1 HiperLAN/1 (HIgh PERformance LAN, premi` ere version) . . 1.4.1.2 HiperLAN/2 (HIgh PERformance LAN, seconde version) . . . 1.4.2 IEEE 802.11, WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2.1 La norme initiale . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2.2 Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2.3 Les evolutions de 802.11 . . . . . . . . . . . . . . . . . . . . . . 1.5 Les r eseaux personnels sans l (WPAN) . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 IrDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 HomeRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 IEEE 802.15.1, Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 IEEE 802.15.3, Ultra Wide Band (UWB) . . . . . . . . . . . . . . . . . 1.5.5 IEEE 802.15.4, ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Les r eseaux de capteurs (WSN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 La Qualit e de Service dans les r eseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Pr esentation g en erale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Quest ce que la Qualit e de Service ? . . . . . . . . . . . . . . . . . . . . 2.1.2 QoS vs. Surdimensionnement . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Notions fondamentales et principes de QoS . . . . . . . . . . . . . . . . . . . . . 2.2.1 La pr edictablilit e du trac . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Le contr ole dadmission . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Les degr es de Qualit e de Service . . . . . . . . . . . . . . . . . . . . . . 2.3 Quelques exemples de protocoles ` a QoS . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Asynchronous Transfer Mode (ATM) . . . . . . . . . . . . . . . . . . . 2.3.2 IntServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2.1 Prols de QoS au niveau utilisateur . . . . . . . . . . . . . . . 2.3.2.2 Le protocole de signalisation RSVP . . . . . . . . . . . . . . . 2.3.2.3 Conclusion : b en eces et dicult es li es ` a IntServ . . . . . . . . 2.3.3 DiServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Probl ematique de lacc` es au m edium partag e . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Acc eder au m edium partag e : les principes de base . . . . . . . . . . . . . . . . . 3.2 Les principales techniques dacc` es au m edium . . . . . . . . . . . . . . . . . . . . 3.2.1 CSMA/CA (IEEE 802.11 DCF) . . . . . . . . . . . . . . . . . . . . . . 11 13 13 14 14 14 15 16 16 16 17 17 17 18 18 18 19 21 21 22 22 24 25 25 26 26 26 26 27 27 28 28 29 29 30 30 30 31 32 32 33 33 34 34
` TABLE DES MATIERES
3.3
3.2.2 EY-NPMA (HiperLAN/1) . . . . . . . . . . . . . Introduire de la QoS au niveau acc` es au m edium . . . . . . 3.3.1 TDMA Dynamique (HiperLAN/2) . . . . . . . . . 3.3.2 Point Coordination Function (IEEE 802.11 PCF) 3.3.3 Enhanced DCF et Hybrid CF (IEEE 802.11e) . . 3.3.3.1 Enhanced DCF . . . . . . . . . . . . . . 3.3.3.2 Hybrid CF . . . . . . . . . . . . . . . . . 3.3.3.3 Autres am eliorations . . . . . . . . . . . 3.3.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
37 39 39 40 41 42 42 43 43 44 51 53 53 53 53 54 55 55 55 55 56 56 56 56 57 57 58 59 59 60 60 61 61 62 63 63 63 63 65 66 67 67 68 68 68 69 70 70 70 72 72 73 73 73 73
2 Pr esentation des normes IEEE 802.15.4 / ZigBee 1 G en eralit es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Le projet ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Objectifs et domaine dapplication . . . . . . . . . . . . . . . . . 1.3 Consommation energ etique . . . . . . . . . . . . . . . . . . . . . 1.4 Impl ementations . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Topologie etoile . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Topologie point a ` point . . . . . . . . . . . . . . . . . . 1.5.3 Topologies plus complexes . . . . . . . . . . . . . . . . 1.6 Adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 Valeurs typiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Pr esentation de la pile protocolaire ZigBee . . . . . . . . . . . . . . . . . 2.1 Quelques notions fondamentales . . . . . . . . . . . . . . . . . . 2.1.1 Le d ecoupage en di erentes couches . . . . . . . . . . . 2.1.2 Le principe de lencapsulation . . . . . . . . . . . . . . 2.1.3 Protocole d echange entre deux couches voisines . . . . 2.1.4 Repr esentation de la pile protocolaire ZigBee . . . . . . 2.1.5 Les interfaces de communication entre couches . . . . . 2.2 La couche Physique . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Bandes de fr equences et canaux . . . . . . . . . . . . . 2.2.2 Modulations, etalement de spectre . . . . . . . . . . . . 2.2.3 Port ee, puissance d emission et sensibilit e du r ecepteur 2.2.4 Le paquet de niveau physique . . . . . . . . . . . . . . 2.2.5 Services rendus . . . . . . . . . . . . . . . . . . . . . . . 2.3 La couche Liaison . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 La sous-couche MAC . . . . . . . . . . . . . . . . . . . 2.3.1.1 Types dacc` es au m edium . . . . . . . . . . . . 2.3.1.2 Notion de supertrame . . . . . . . . . . . . . . 2.3.2 La sous-couche LLC . . . . . . . . . . . . . . . . . . . . 2.3.3 Structures de trames . . . . . . . . . . . . . . . . . . . 2.3.3.1 Le champ de contr ole de trame . . . . . . . . . 2.3.3.2 Le champ de num ero de s equence . . . . . . . 2.3.3.3 Le champ dadressage . . . . . . . . . . . . . . 2.3.3.4 Le champ payload . . . . . . . . . . . . . . . . 2.3.3.5 Le champ FCS . . . . . . . . . . . . . . . . . . 2.4 La couche R eseau . . . . . . . . . . . . . . . . . . . . . . . . . . ements de la topologie du r 2.4.1 El eseau . . . . . . . . . . . . 2.4.1.1 Topologie en arbre . . . . . . . . . . . . . . . . 2.4.1.2 Topologie maill ee . . . . . . . . . . . . . . . . 2.4.2 Architecture de la couche r eseau . . . . . . . . . . . . . 2.4.3 Services rendus . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Adressage . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4.1 Adressage NHLE-based . . . . . . . . . . . . . 2.4.4.2 Adressage en arbre . . . . . . . . . . . . . . . 4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
` TABLE DES MATIERES
Principes de base du routage ZigBee . . . . . . . . . . . . . . . . 2.4.5.1 Algorithme de routage ` a la demande . . . . . . . . . . . 2.4.5.2 Algorithme de routage hi erarchique : Tree Routing . . . 2.4.6 Ordonnancement des beacons dans un r eseau avec arborescence 2.4.7 Structure du paquet de niveau r eseau . . . . . . . . . . . . . . . Identication des failles dans la m ethode dacc` es propos ee par le standard . . . . 3.1 La gestion des slots garantis ne pr esente pas une garantie absolue . . . . . 3.2 Autres probl` emes identi es . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Conclusion : les am eliorations propos ees . . . . . . . . . . . . . . . . . . .
2.4.5
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
74 75 75 76 76 77 77 78 79
3 Vers un WPAN ` a Qualit e de Service pour des transports dinformations ` a fortes contraintes temporelles 83 1 Une application typique de robotique mobile communicante sans l . . . . . . . . . . . . 85 1.1 Probl ematique g en erale : pourquoi introduire des communications sans l pour des robots ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 1.2 Les attentes vis-` a-vis dun syst` eme de communication adapt e . . . . . . . . . . . 86 1.2.1 Un syst` eme proposant des garanties sur le plan temporel . . . . . . . . 86 1.2.2 Retransmissions vs. redondance et codes correcteurs derreurs . . . . . 86 1.2.3 Taille du r eseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 1.2.4 Topologie du r eseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 1.2.4.1 Communications locales au robot . . . . . . . . . . . . . . . . 87 1.2.4.2 Communications entre robots . . . . . . . . . . . . . . . . . . . 87 1.2.5 D ebit n ecessaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 1.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 2 La proposition protocolaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 2.1 Nouvelles fonctionnalit es propos ees . . . . . . . . . . . . . . . . . . . . . . . . . . 90 2.2 Probl ematique de la cohabitation de plusieurs etoiles sur un m edium commun . 91 2.3 Etude du protocole mis en uvre . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 ements du r 2.3.1 El eseau, liens et port ees . . . . . . . . . . . . . . . . . . . . 92 2.3.2 Organisation temporelle de lacc` es au m edium . . . . . . . . . . . . . . 93 2.3.3 M ecanisme de demande de r eservation du m edium . . . . . . . . . . . . 94 2.3.4 Allocations au pr ealable : arriv ees d eterministes dans le r eseau . . . . . 94 2.3.5 Gestion des acquittements . . . . . . . . . . . . . . . . . . . . . . . . . 95 2.3.6 Gestion et diusion des informations de r eservation . . . . . . . . . . . 96 2.3.7 Un exemple de demande de r eservation du m edium . . . . . . . . . . . 96 2.3.8 Une politique dacc` es d eterministe par d efaut . . . . . . . . . . . . . . . 99 2.3.9 Optimisation de lacc` es au m edium : attribution de GTS simultan es . . 100 2.3.9.1 Le principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 2.3.9.2 N ecessit e dune n egociation protocolaire . . . . . . . . . . . . . 100 2.3.9.3 Application ` a notre topologie . . . . . . . . . . . . . . . . . . . 102 2.4 Impl ementation du protocole : int egration dans une pile IEEE 802.15.4 . . . . . 104 3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 4 Mod elisation, validation et prototypage du protocole 1 Introduction : une d emarche de validation multi-outils . . . . 2 Mod elisation et validation formelle du protocole . . . . . . . . 2.1 Loutil R eseaux de Petri . . . . . . . . . . . . . . . . . 2.2 Pr esentation du mod` ele propos e . . . . . . . . . . . . 2.2.1 Algorithme g en eral d eduit du protocole . . . 2.2.2 Un mod` ele de type P` ere /Fils . . . . . . . . . 2.2.3 Le mod` ele R eseaux de Petri . . . . . . . . . 2.2.3.1 Etude du processus p` ere . . . . . . 2.2.3.2 Etude du processus ls . . . . . . . 2.3 Validation formelle du mod` ele et analyse des r esultats 2.3.1 Pr esentation de loutil TINA . . . . . . . . . 2.3.2 Analyse des r esultats . . . . . . . . . . . . . Adrien van den Bossche 109 111 112 112 112 112 114 115 116 116 116 116 117 5
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
2.4 Conclusion de l etude de validation formelle . . . . . . . . . . . . . . . . . . . . . Simulation : outils et r esultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 D eveloppement dun outil de simulation . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Pr esentation de loutil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1.1 M ecanisme impl ement e et simul e. . . . . . . . . . . . . . . . . 3.1.1.2 Fonctionnement du simulateur d evelopp e . . . . . . . . . . . . 3.1.1.3 Utilisation du simulateur : descriptif de la topologie et exploitation des donn ees . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1.4 Param` etres x es pour la simulation . . . . . . . . . . . . . . . 3.1.2 Analyse des r esultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2.1 Etude de lassociation d eterministe dun coordinateur . . . . . 3.1.2.2 Etude de lassociation d eterministe dun nud . . . . . . . . . 3.2 Les travaux r ealis es sous NS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Pr esentation de loutil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Les mod` eles 802.15.4 / ZigBee existants sous NS2 . . . . . . . . . . . . 3.2.3 Un r esultat obtenu avec NS2 : d ebit utile dans la CAP avec CSMA/CA 3.3 Conclusion sur les travaux de simulation . . . . . . . . . . . . . . . . . . . . . . . Prototype et m etrologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Pr esentation de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Les plateformes IEEE 802.15.4/ZigBee existantes . . . . . . . . . . . . 4.1.2 Modication du rmware existant . . . . . . . . . . . . . . . . . . . . . 4.2 R ealisation doutils de tests et de mesures . . . . . . . . . . . . . . . . . . . . . . 4.3 Conception et r ealisation dune pile prototype . . . . . . . . . . . . . . . . . . . . 4.3.1 Evaluation des performances de la pile prototyp ee . . . . . . . . . . . . 4.3.1.1 Evaluation de la sensibilit e du r ecepteur . . . . . . . . . . . . . 4.3.1.2 Evaluation du temps de traitement dun paquet . . . . . . . . 4.3.1.3 D ebit utile maximum . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.4 Evaluation de la qualit e de la synchronisation entre un coordinateur et ses nuds . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Validation de notre proposition par prototypage . . . . . . . . . . . . . 4.3.2.1 Evaluation de la qualit e de la synchronisation entre le supercoordinateur et ses nuds . . . . . . . . . . . . . . . . . . . . 4.3.2.2 Capacit e maximale dun slot . . . . . . . . . . . . . . . . . . . 4.3.2.3 Validation du concept de SGTS . . . . . . . . . . . . . . . . . 4.3.3 Conclusion sur les mesures r ealis ees sur le prototype . . . . . . . . . . . 4.4 Applications de d emonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Capteur de ligne ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Passerelle IP/ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Flotte de robots ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 Bilan sur les applications de d emonstration . . . . . . . . . . . . . . . .
117 117 117 118 118 119 119 120 121 121 123 125 125 125 126 127 127 127 127 129 130 131 131 131 132 133 134 135 136 136 137 139 142 142 143 144 144 145 149 153 159 162 167
Conclusion Bibliographie g en erale Glossaire Table des gures Liste des tableaux
Introduction
De nos jours, les r eseaux de t el ecommunications sont pr esents dans de tr` es nombreux domaines. Que ce soit dans la production, lespace ou la domotique, les r eseaux sont devenus incontournables. Le multiplexage des donn ees sur un bus unique permet de limiter consid erablement les c ables, abaissant globalement les co uts, tant ` a linstallation qu` a la maintenance. Les c ables sont g en eralement inesth etiques, c outeux, diciles ` a installer et peu pratiques ` a lusage. De plus, dans des domaines industriels o` u lappareil est soumis ` a des contraintes vibratoires tr` es importantes, leur connectique repr esente une faiblesse qui augmente consid erablement le risque de panne. Enn, dans certains domaines comme la eronautique ou le spatial, les c ables repr esentent un poids non n egligeable quil est absolument n ecessaire de limiter par une infrastructure plus l eg` ere. Dans cette d emarche de forte limitation des c ables, le sans l permet daller encore plus loin que le bus de donn ees. Le support de transmission sans l etant immat eriel, il permet de gagner largement en poids, il peut traverser des cloisons sans n ecessit e de per cage et permet une forte mobilit e des appareils connect es. En revanche, si les gains sont importants sur ces aspects, lutilisation du sans l am` ene son lot de contraintes qui emp eche la transposition directe des m ecanismes utilis es sur les bus laires au sans l. Par exemple, le ph enom` ene daveuglement emp eche la d etection des collisions en temps r eel, la forte variabilit e des caract eristiques du m edium radio entra ne une grande incertitude sur la abilit e des liens et la forte att enuation du m edium immat eriel implique des port ees limit ees qui ne sont pas toujours simples ` a appr ehender, m eme avec beaucoup dexp erience. Les perspectives de recherches, tant sur la couche physique que sur les protocoles de niveaux sup erieurs, restent toujours importantes dans ce domaine. Pourtant, dans le cadre dune application communicante de type industriel comme un r eseau de surveillance multi-capteurs, la transmission de linformation doit etre able. Mieux que des performances moyennes globalement correctes, certaines applications peuvent n ecessiter un moyen dacheminement de linformation qui soit en mesure de proposer des garanties, par exemple, sur le volume dinformations ` a transmettre dans un temps donn e (d ebit) ou le d elai de remise dun message (latence). Il est n ecessaire dintroduire des fonctionnalit es de Qualit e de Service pour la gestion du r eseau. Pour une application temps r eel utilisant des mesures issues de capteurs, laspect temporel est primordial car la donn ee repr esentant la grandeur physique mesur ee perd sa pertinence avec le temps ; si le r esultat de la mesure arrive avec un d elai trop important, il doit etre ignor e par lapplicatif car obsol` ete. Il est donc n ecessaire, pour cette cat egorie dapplications ` a tr` es fortes contraintes temporelles, de concevoir des m ethodes de transmission permettant de garantir le d elai du transport de linformation. Bien quutilisant un m edium imparfait, il est cependant possible de abiliser une transmission sans l. Cette abilisation doit etre un souci permanent pour le concepteur, a ` chaque niveau de la pile protocolaire. Au niveau physique, il existe des techniques reconnues et largement utilis ees telles que le codage du canal ou la redondance des donn ees emises. Cependant, m eme si ces techniques permettent de rendre plus robuste la transmission radio, elles ne permettent pas de garantir que 100% des transmissions seront re cues sans erreur. Il est alors parfois n ecessaire de pr evoir la retransmission des donn ees erron ees, ce qui, dans le cadre dune application ` a fortes contraintes temporelles, entra ne des d elais al eatoires qui peuvent se r ev eler g enants et qui accentueront laspect al eatoire de la couche physique. Pour les couches sup erieures, le premier el ement susceptible dintroduire des incertitudes au dessus de la couche physique est lalgorithme de la m ethode dacc` es au m edium. La m ethode dacc` es au m edium (MAC) est le protocole mis en place pour g erer les acc` es concurrents au m edium partag e ; il se situe directement au-dessus de la couche physique et permet de minimiser, voire de supprimer, le ph e-
Introduction
nom` ene des collisions, cest-` a-dire demp echer que deux emetteurs utilisent le m eme m edium en m eme temps. En eet, si plusieurs emetteurs utilisent le m edium partag e au m eme moment, il est probable que la r esultante de la communication soit inaudible pour tous les destinataires. Selon les objectifs attendus, le protocole de la m ethode dacc` es peut etre con cu de di erentes mani` eres, lessentiel etant en premier lieu, que toutes les entit es susceptibles de s echanger des messages suivent le m eme protocole. Pour notre part, nous nous sommes attach es, dans ces travaux de th` ese, aux m ethodes dacc` es pr esentant un caract` ere fortement d eterministe, cest-` a-dire en mesure de proposer des bornes (minimum, maximum) sur laspect temporel de la remise des messages. Au del` a de laspect purement temporel, il nous a sembl e int eressant dimpl ementer une m ethode dacc` es au m edium d eterministe, dans un r eseau compos e dunit es contraintes energ etiquement. En eet, le caract` ere d eterministe de la m ethode dacc` es permet de limiter les collisions, entra nant par la m eme occasion des economies sur le plan energ etique puisque le nombre de r e emissions est consid erablement limit e. La prise en compte de laspect energ etique au niveau MAC permet dentrevoir des perspectives de recherche novatrices : les techniques conventionnelles telles que l ecoute permanente dun m edium inutilis e, le bourrage ou les retransmissions constituent des pertes d energie evidentes quil est possible de r eduire par loptimisation des protocoles, notamment par lintroduction dune m ethode dacc` es d eterministe au m edium. Si lon consid` ere le r eseau dans son ensemble, cest-` a-dire au-del` a du lien de transmission direct entre deux emetteurs-r ecepteurs, il est n ecessaire, an dassurer une Qualit e de Service globale ` a tout le r eseau, dimpl ementer une couche r eseau proposant des fonctionnalit es de QoS au dessus de la couche MAC. En eet, conform ement ` a la description faite par le mod` ele OSI, si la couche MAC, au travers de la m ethode dacc` es, est charg ee de la QoS sur le lien physique, la couche r eseau doit lassurer sur tout le r eseau, globalement. Ces deux couches, du point de vue de la gestion de la QoS, sont intimement li ees. La couche MAC doit permettre la mise en uvre de fonctionnalit es telles que la r eservation du m edium et la di erenciation de service ; elle doit aussi remonter des statistiques sur lutilisation du m edium en temps r eel ` a la couche r eseau pour lui permettre daner la pertinence du protocole de routage. En r esum e, elle doit permettre ` a chaque nud du r eseau dacc eder au m edium selon ses besoins tout en minimisant les acc` es inutiles puisque le m edium radio est une ressource rare. Mieux, elle doit faire en sorte que chaque transmission initi ee sur le m edium et r eussie (cest-` a-dire sans erreur de transmission) parvienne jusquau niveau de lapplication : il est en eet dommageable quun message transmis avec succ` es au niveau physique soit ensuite d etruit dans les couches sup erieures. . . Parmi les nombreuses technologies existantes (technologies de transmission sans l et protocoles de gestion de Qualit e de Service) qui seront pr esent ees dans le premier chapitre de ce m emoire, trop peu proposent les fonctionnalit es qui viennent d etre evoqu ees. La plupart des technologies de r eseaux sans l de type WLAN/WPAN impl ementent des m ethodes dacc` es au m edium fonctionnant en mode Best-Eort, bas ees sur des algorithmes al eatoires, emp echant ainsi la couche r eseau de mettre en uvre des possibilit es nes de gestion de QoS et li ees ` a la technique dacc` es au m edium. Certaines m ethodes dacc` es proposent n eanmoins des fonctionnalit es de di erenciation de service et de r eservation de lacc` es au m edium mais ces m ethodes ne permettent pas den garantir totalement lacc` es. De plus, bien que d ecrites dans les normes et les sp ecications, ces fonctionnalit es ne sont g en eralement pas impl ement ees sur les produits commercialis es (802.11 PCF, 802.15.1), emp echant toute etude de performances r eelles par prototypage. A ce titre, la technologie IEEE 802.15.4/ZigBee, qui a et e utilis ee et am elior ee dans le cadre des travaux de la th` ese, pr esente des caract eristiques int eressantes de notre point de vue, notamment au niveau de la gestion de l energie et de la couche MAC. En eet, cette technologie WPAN est optimis ee pour les petits transferts de donn ees et correspond tout ` a fait aux attentes, sous langle energ etique, dune application robotique de r eseau de capteurs. De plus, la disponibilit e mat erielle de modules totalement reprogrammables, y compris au niveau de la couche MAC, nous a permis dentrevoir des possibilit es avantageuses de prototypage r eel.
Introduction
Le m emoire est structur e de la mani` ere suivante : dans le premier chapitre, nous pr esentons un etat de lart sur les technologies de r eseaux sans l et sur les m ethodes existantes pour g erer la Qualit e de Service. Plusieurs technologies, normes et protocoles, sont pr esent es et compar es ; cette pr esentation nest pas exhaustive, le but etant ici de dresser un etat de lart g en eral de lexistant. A la n de ce premier chapitre, nous pr esentons les principales techniques de m ethodes dacc` es au m edium existantes, avec ou sans possibilit es de QoS. Dans le second chapitre, nous pr esentons les normes et sp ecications IEEE 802.15.4 et ZigBee sur lesquelles sont bas es les travaux elabor es pendant la th` ese. Laspect acc` es au m edium propos e pour cette technologie sera particuli` erement d etaill e et des failles identi ees comme critiques, au regard de nos exigences quant au d eterminisme de la m ethode dacc` es, seront discut ees en n de chapitre. Dans le troisi` eme chapitre, nous proposons une nouvelle m ethode dacc` es enti` erement d eterministe, cest-` a-dire proposant des garanties sur laccessibilit e du m edium r eguli` ere et pr ed etermin ee par un contrat. La m ethode dacc` es est dite enti` erement d eterministe car m eme la phase dassociation au r eseau peut etre r ealis ee sur ce principe. Bien que cette m ethode dacc` es puisse etre g en eralis ee ` a tout type de WLAN/WPAN, elle sappuie cependant sur les failles de IEEE 802.15.4, identi ees comme telles dans le chapitre 2. Dans le quatri` eme chapitre, nous pr esentons les r esultats que nous avons obtenus concernant la m ethode dacc` es d eterministe pr esent ee dans le chapitre 3. Pour tester, valider et evaluer les performances de notre contribution, nous avons r ealis e plusieurs etudes : mod elisation par R eseaux de Petri, simulation et prototypage r eel. Les performances du r eseau et notre analyse quant ` a lecacit e de la m ethode dacc` es au m edium seront d etaill ees dans ce quatri` eme et dernier chapitre.
Adrien van den Bossche
Introduction
10
Chapitre 1
Les r eseaux sans l et la Qualit e de Service

Dans ce premier chapitre, nous dressons un etat de lart des di erentes techniques de transmission r eseau, en nous focalisant particuli` erement sur les technologies sans l et les m ethodes li ees ` a la Qualit e de Service (QoS). Dans un premier temps, nous pr esentons les principales technologies de r eseaux sans l en nous attachant ` a leurs caract eristiques majeures. Dans un deuxi` eme temps, nous pr esentons une etude bibliographique sur les techniques de communication et les protocoles ` a Qualit e de Service. Ces techniques etant malheureusement le plus souvent g er ees au niveau R eseau (niveau 3 OSI), nous reviendrons dans un troisi` eme et dernier temps sur les technologies de transmission sans l et aborderons la probl ematique de la m ethode dacc` es (niveau 2 OSI) ; nous verrons alors comment une Qualit e de Service peut etre avantageusement mise en uvre ` a ce niveau.
Etat 1.1 1.2 1.3
1.4
1.5
de lart des technologies de r eseaux sans l . . . . . . . . . . . . . . . Classication des technologies r eseaux . . . . . . . . . . . . . . . . . . . . . . Les r eseaux sans l etendus (WWAN) . . . . . . . . . . . . . . . . . . . . . . Les r eseaux sans l m etropolitains (WMAN) . . . . . . . . . . . . . . . . . . 1.3.1 La Boucle Locale Radio (BLR) . . . . . . . . . . . . . . . . . . . . . 1.3.2 ETSI HiperMAN / IEEE 802.16, WiMAX . . . . . . . . . . . . . . 1.3.3 IEEE 802.20, Mobile Broadband Wireless Access (MWBA) . . . . . 1.3.4 Le ph enom` ene des r eseaux sans l ruraux et des r eseaux sans l coop erants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les r eseaux locaux sans l (WLAN) . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 ETSI HiperLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1.1 HiperLAN/1 (HIgh PERformance LAN, premi` ere version) 1.4.1.2 HiperLAN/2 (HIgh PERformance LAN, seconde version) . 1.4.2 IEEE 802.11, WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2.1 La norme initiale . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2.2 Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2.3 Les evolutions de 802.11 . . . . . . . . . . . . . . . . . . . . Les r eseaux personnels sans l (WPAN) . . . . . . . . . . . . . . . . . . . . . 1.5.1 IrDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 HomeRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 IEEE 802.15.1, Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 IEEE 802.15.3, Ultra Wide Band (UWB) . . . . . . . . . . . . . . . 1.5.5 IEEE 802.15.4, ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . .
13 13 14 14 14 15 16 16 16 17 17 17 18 18 18 19 21 21 22 22 24 25
DE SERVICE CHAPITRE 1. LES RESEAUX SANS FIL ET LA QUALITE
1.6 Les r eseaux de capteurs (WSN) . . . . . . . . . . . . . . . . . . . . . . . . . . La Qualit e de Service dans les r eseaux . . . . . . . . . . . . . . . . . . . . . 2.1 Pr esentation g en erale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Quest ce que la Qualit e de Service ? . . . . . . . . . . . . . . . . . . 2.1.2 QoS vs. Surdimensionnement . . . . . . . . . . . . . . . . . . . . . . 2.2 Notions fondamentales et principes de QoS . . . . . . . . . . . . . . . . . . . 2.2.1 La pr edictablilit e du trac . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Le contr ole dadmission . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Les degr es de Qualit e de Service . . . . . . . . . . . . . . . . . . . . 2.3 Quelques exemples de protocoles ` a QoS . . . . . . . . . . . . . . . . . . . . . 2.3.1 Asynchronous Transfer Mode (ATM) . . . . . . . . . . . . . . . . . 2.3.2 IntServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2.1 Prols de QoS au niveau utilisateur . . . . . . . . . . . . . 2.3.2.2 Le protocole de signalisation RSVP . . . . . . . . . . . . . 2.3.2.3 Conclusion : b en eces et dicult es li es ` a IntServ . . . . . . 2.3.3 DiServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Probl ematique de lacc` es au m edium partag e . . . . . . . . . . . . . . . . 3.1 Acc eder au m edium partag e : les principes de base . . . . . . . . . . . . . . . 3.2 Les principales techniques dacc` es au m edium . . . . . . . . . . . . . . . . . . 3.2.1 CSMA/CA (IEEE 802.11 DCF) . . . . . . . . . . . . . . . . . . . . 3.2.2 EY-NPMA (HiperLAN/1) . . . . . . . . . . . . . . . . . . . . . . . 3.3 Introduire de la QoS au niveau acc` es au m edium . . . . . . . . . . . . . . . . 3.3.1 TDMA Dynamique (HiperLAN/2) . . . . . . . . . . . . . . . . . . . 3.3.2 Point Coordination Function (IEEE 802.11 PCF) . . . . . . . . . . 3.3.3 Enhanced DCF et Hybrid CF (IEEE 802.11e) . . . . . . . . . . . . 3.3.3.1 Enhanced DCF . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3.2 Hybrid CF . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3.3 Autres am eliorations . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25 26 26 26 26 27 27 28 28 29 29 30 30 30 31 32 32 33 33 34 34 37 39 39 40 41 42 42 43 43 44
12
Etat de lart des technologies de r eseaux sans l
Dans cette partie, nous pr esentons les di erentes technologies de r eseaux sans l existantes. Les caract eristiques principales sont evoqu ees : topologies, fr equences, d ebit bande de base, port ees th eoriques, modulations et etalement de spectre.
1.1
Classication des technologies r eseaux
Les technologies r eseaux sont fr equemment class ees en quatre cat egories. Cette classication tient essentiellement compte de la port ee des dites technologies : les r eseaux personnels (PAN3 ) : ils concernent lentourage imm ediat dune personne (quelques m` etres), les r eseaux locaux (LAN3 ) : ils concernent un environnement de vie plus etendu que les r eseaux personnels comme une maison, une entreprise ou un campus (quelques dizaines de m` etres ` a quelques kilom` etres), les r eseaux m etropolitains (MAN3 ) : ils visent ` a couvrir une r egion etendue comme une ville (plusieurs kilom` etres), les r eseaux etendus (WAN3 ) : ils visent ` a couvrir une zone tr` es vaste comme un pays, une r egion du globe ou toute la plan` ete. Les r eseaux sans l (en anglais Wireless Networks ) n echappent pas ` a cette classication : on parle souvent de WPAN3 (par exemple la technologie Bluetooth ), WLAN3 (par exemple WiFi ), WMAN3 (par exemple WiMAX ) ou WWAN3 (par exemple les r eseaux satellites), comme lillustre la gure 1.1.
Fig. 1.1 Di erents types de r eseaux sans l et port ees typiques
Bien que la port ee constitue le crit` ere de classement le plus r epandu, il peut etre int eressant de classer les technologies r eseaux selon dautres param` etres comme le d ebit propos e, l energie n ecessaire au fonctionnement, le co ut de mise en uvre et dentretien, la simplicit e dutilisation ou bien encore la abilit e. Des compromis di erents sont faits entre ces caract eristiques ; ils donnent lieu ` a une multitude de techniques certaines compl ementaires, dautres concurrentes. Ce grand nombre de produits disponibles permet d` es lors de proposer une (voire plusieurs) solution(s) ` a une probl ematique donn ee. Concernant plus particuli` erement les technologies de r eseaux sans l, et de par le caract` ere embarqu e des equipements vis es, un autre classement, fond e sur la consommation energ etique, serait aussi tr` es pertinent. Nous allons ` a pr esent proposer un etat de lart non exhaustif des principales technologies de communication r eseaux sans l que lon peut rencontrer sur le march e. Adrien van den Bossche 13
1.2
Les r eseaux sans l etendus (WWAN)
Cette cat egorie compte assez peu de technologies ` a lheure actuelle ; en eet, la plupart des r eseaux etendus sont des r eseaux laires1 . Cette constatation sexplique tr` es simplement par la physique des transmissions : lorsque lon souhaite transporter des informations sur un m edium immat eriel, il est g en eralement admis de faire porter ces informations par une fr equence porteuse. Plus le d ebit des informations est elev e, plus la fr equence porteuse doit l etre egalement. Or, on constate qu` a partir dune fr equence porteuse de 50 MHz, les ondes electromagn etiques ne se r e echissent plus sur les di erentes couches de latmosph` ere. Pour ces r eseaux haut d ebits sans l, il est donc impossible datteindre des port ees autres que ` a vue . Les seules technologies de WWAN disponibles sont des technologies utilisant les satellites g eostationnaires ou en orbite basse pour relayer linformation entre plusieurs points du globe. Il existe plusieurs standards de r eseaux utilisant les satellites [PUJO 95] comme VSAT3 [HOWE 87] (utilis es pour la transmission de transactions bancaires) ou DVB-S [SMER 04] (norme grand public pour les diusions de t el evision, radio et service de donn ees par satellite). Nous ne d etaillerons pas plus longuement ces techniques qui d epassent le champ de la th ematique etudi ee.
1.3
Les r eseaux sans l m etropolitains (WMAN)
Les r eseaux m etropolitains ont pour objectif de cr eer un ensemble de liens de communication sur une zone etendue de la taille dune ville ou dune r egion. Ces liens peuvent servir ` a interconnecter plusieurs sites dune m eme entreprise ou dune administration. Ils peuvent etre linitiative dune collectivit e locale : certaines villes en mal dinvestisseurs et de cr eateurs dentreprises participent pour une part importante au nancement de r eseaux tr` es haut d ebit ; cest par exemple le cas de la ville de Pau, dans les Hautes Pyr en ees Fran caises, avec le projet Pau Broadband Country [CAPP 02], un r eseau optique FTTH3 op erationnel depuis 2003 qui couvre la ville et ses environs, donnant un acc` es ` a 100 Mbits/s pour ses abonn es. Bien que certains r eseaux dits m etropolitains soient priv es et ne constituent quun r eseau local etendu, la plupart dentre eux sont en fait des r eseaux dacc` es (ils permettent dacc eder ` a un autre r eseau). En ce qui concerne les r eseaux sans l m etropolitains, ils sont g en eralement utilis es dans les campagnes pour palier ` a la faiblesse des acc` es de type xDSL3 , qui sont plut ot destin es aux zones ` a forte densit e de population. A la n des ann ees 90, un d eploiement de WMAN avait et e entam e en France avec le projet de Boucle Locale Radio, mais cest sans nul doute le standard IEEE3 802.16 [IEE1 04], plus connu sous le nom de WiMAX, qui devrait simposer dans les ann ees ` a venir. Dans cette cat egorie, dautres standards ont aussi et e d evelopp es, ils sont evoqu es ici ` a titre informatif.
1.3.1
La Boucle Locale Radio (BLR)
La Boucle Locale est la partie dun r eseau de t el ecommunications situ ee entre la prise t el ephonique de labonn e et le central t el ephonique : cest la partie terminale du r eseau dacc` es de lop erateur que lon d esigne parfois par le dernier mile . On parle de boucle car, historiquement, le r eseau t el ephonique commut e fonctionnait gr ace ` a une boucle de courant qui alimentait les postes t el ephoniques des usagers. Dans le cas de la Boucle Locale Radio, ou BLR3 , les donn ees sont achemin ees par les ondes hertziennes et non par la paire de cuivre. Cest une solution economique dans la mesure o` u il nest pas n ecessaire de poser des c ables et deectuer des travaux de type G enie Civil. La BLR permet donc de compl eter la desserte laire traditionnelle dans les zones o` u la densit e de clients potentiels est faible. Il est courant de d esigner par BLR toute technologie r epondant ` a lobjectif qui vient d etre enonc e;
1 Contrairement ` a certaines id ees re cues, la majeure partie du trac du r eseau Internet, par exemple, est v ehicul ee par des r eseaux laires (en g en eral optiques), m eme pour acc eder ` a des serveurs situ es ` a loppos e de la plan` ete.
14
cependant, la technologie qui etait la plus r epandue jusquau milieu des ann ees 2000 etait le LMDS3 . Le LMDS est une technologie dacc` es radio large bande. Elle utilise des fr equences tr` es elev ees (situ ees entre 26 et 29 GHz pour la France2 ). Le LMDS est principalement utilis e pour cr eer des liens de type point ` a multipoints (une station de base communique avec plusieurs stations clientes) sur des distances pouvant atteindre 8 kilom` etres et permettant de donner un acc` es r eseau ` a 10 Mbits/s environ. Il est egalement possible de r ealiser des liaisons point ` a point gr ace ` a des antennes directionnelles ; dans ce cas, la port ee peut etre grandement am elior ee et le d ebit ne prote qu` a une paire dentit e communicantes. On parlera alors de faisceau hertzien. La technologie WiMAX, qui sera pr esent ee ci-apr` es, est aujourdhui g en eralement pr ef er ee au LMDS car elle ore globalement de meilleures performances, notamment en terme de d ebit. De plus, WiMAX a et e con cu pour proposer ` a lutilisateur des fonctionnalit es de mobilit e, ce qui nest pas le cas de LMDS.
1.3.2
ETSI HiperMAN / IEEE 802.16, WiMAX
WiMAX est le consortium qui est charg e de la promotion des technologies de r eseaux sans l m etropolitains IEEE 802.16 [IEE1 04] et ETSI HiperMAN [ETS1 06] [ETS2 06] ; il pr one la convergence de ces deux standards pour une technologie unique et interop erable. A ce titre, le consortium WiMAX a cr e e le label WiMAX qui certie que l equipement labellis e est approuv e selon les crit` eres d enis par le consortium et quil est compatible avec les autres equipements labellis es, quelque soit le fabricant du mat eriel3 . De part leurs concepteurs communs, les normes HiperMAN et 802.16 sont tr` es semblables. HiperMAN est une norme propos ee par le comit e europ een de standardisation des t el ecommunications (ETSI) [ETSI] qui a pour objectif de proposer une normalisation des r eseaux sans l m etropolitains, essentiellement pour raccorder les PME et les particuliers ` a un r eseau haut d ebit. HiperMAN propose dutiliser la bande des 2 ` a 11 GHz et pr evoit des m ecanismes dadaptation automatique de la puissance d emission, de la modulation et du codage pour abiliser la transmission dans les conditions les plus diciles, permettant ainsi denvisager des liens de transmission entre deux stations qui ne sont pas ` a vue (en anglais nonline-of-sight ) comme un terminal dans un b atiment. Le standard propose egalement un multiplexage optimis e` a base de TDD3 et de FDD3 . La technologie permet le transport natif de paquets IP3 ou de cellules ATM3 pour des applications multim edia (voix, vid eo, t el ephonie) [GOLD 01] [HOYM 01]. De m eme quHiperMAN, IEEE 802.16 propose lui aussi un standard pour les r eseaux sans l m etropolitains haut d ebits. Comme tous les autres standards issus du comit e de standardisation 802 [IEEE] de lorganisme de standardisation am ericain IEEE, ce standard est le r esultat dun travail men e par le groupe de discussion (Tasking Group ) d esign e par TG16 . Il sp ecie les couches physique et liaison de donn ees, cest ` a dire les deux premiers niveaux du mod` ele OSI (Open System Interconnection, propos e par lISO3 ). 802.16 propose un d ebit bande de base de 70 Mbits/s sur un rayon dune dizaine de kilom` etres, la port ee pouvant bien entendu varier avec les eventuels obstacles. Plusieurs bandes de fr equences sont propos ees (2,5 ` a 3,5 GHz, 10 ` a 66 GHz) ainsi que plusieurs modulations bas ees sur le principe de lOFDM3 qui consiste ` a r epartir plusieurs ux de donn ees sur autant de sous-porteuses. Comme les donn ees sont emises en bande etroite, elles sont moins sujettes ` a la variabilit e des caract eristiques du m edium radio, en particulier pour des transmissions pr esentant des echos importants (multi-trajets). Contrairement ` a la BLR, WiMAX propose dintroduire des fonctionnalit es de mobilit e dans son r eseau : un terminal WiMAX peut se d eplacer tout en conservant un acc` es able au r eseau. Cette fonctionnalit e est introduite par la norme IEEE 802.16e (Mobile WiMAX ) qui a et e rati ee le 7 d ecembre 2005. Linnovation est de taille car cette fonctionnalit e permettrait ` a la technologie WiMAX dentrer en concurrence directe avec les technologies de r eseaux de t el ephonie mobile comme GPRS3 , EDGE3 3 ou UMTS . Par extension, on assisterait l` a ` a une technologie issue du monde Internet qui viendrait
2 Comme pour toute technologie utilisant les ondes electromagn etiques, les fr equences peuvent varier selon la r egion du globe o` u elles sont utilis ees. Aux Etats-Unis, LMDS utilise des fr equences situ ees entre 31,0 et 31,3 GHz. 3 Nous verrons plus loin que le label WiMAX nest pas le seul label dans le monde des r eseaux ; Bluetooth et WiFi sont deux labels qui concernent respectivement les normes IEEE 802.15.1 et IEEE 802.11.
15
marcher sur les plates bandes du monde des op erateurs de t el ecommunications ; il y a l` a un d e economique consid erable. Notons cependant que comme la plupart des technologies WMAN, lutilisation de WiMAX nest g en eralement pas libre. WiMAX peut etre utilis e seulement sous couvert dune licence d elivr ee par lautorit e de r egulation des t el ecommunications de la r egion o` u il est utilis e, au m eme titre quun r eseau dop erateur. En France, cette licence est attribu ee par lARCEP3 [ARCE], anciennement ART3 . Notons que concernant la France, lARCEP na pas autoris e pour linstant lutilisation de Mobile WiMAX (802.16e).
1.3.3
IEEE 802.20, Mobile Broadband Wireless Access (MWBA)
Le comit e de standardisation 802 (LAN/WAN) de lIEEE compte un groupe de discussion sur les r eseaux dacc` es sans l large bande et mobiles (Mobile Broadband Wireless Access, MWBA), le TG20. Lobjectif de ce groupe de discussion est l elaboration dun standard pour une couche physique et une couche liaison de donn ees, pour un r eseau mobile sans l haut d ebit orient e paquets, en vue dun interfa cage direct avec IP. Les objectifs du TG20 sont assez semblables de ceux du TG16e (Mobile WiMAX ). Les principales caract eristiques du r eseau MWBA sont les suivantes : mobilit e des nuds jusqu` a 250 km/h, d ebit 1 Mbits/s (au niveau IP), couche physique utilisant la bande des 3,5 GHz, soumise ` a licence, mode paquets, itin erance de niveau IP (IP roaming & hando ).
A ce jour, les caract eristiques evoqu ees restent un objectif ` a atteindre dans la mesure o` u aucune impl ementation de MWBA na encore et e r ealis ee. IEEE 802.20 est encore ` a l etat de draft (brouillon) ; il a et e adopt e le 18 janvier 2006. Cependant, les travaux du TG20 auraient et e suspendus par lIEEE en juin 2006, ceci pour r epondre aux accusations port ees ` a son encontre selon lesquelles la soci et e Qualcomm aurait pris une part trop importante dans les travaux de 802.20. Dans tous les cas, cette norme promet quelques ambitieuses avanc ees dans le domaine des r eseaux mobiles haut d ebit ; ces derni` eres demandent cependant ` a etre v eri ees exp erimentalement.
1.3.4
Le ph enom` ene des r eseaux sans l ruraux et des r eseaux sans l coop erants
Il peut etre int eressant d evoquer un ph enom` ene nouveau, dorigine plus economique et sociale que technique : le ph enom` ene des r eseaux sans l ruraux et des r eseaux sans l coop erants. On assiste depuis quelques ann ees ` a la cr eation de r eseaux de communication, ind ependants des op erateurs [FON], parfois m eme communautaires [TSF], qui ont pour but de partager des ressources communes ou tout simplement, de recr eer un r eseau dans des r egions o` u lacc` es au r eseau Internet nest pas disponible. Cest notamment le cas dans les r egions rurales des pays occidentaux [RAN] ou dans les zones m etropolitaines des pays en voie de d eveloppement. Techniquement, ces r eseaux proposent un acc` es de quelques Mbits/s sur une zone etendue, mais en se basant sur des technologies tr` es bon march e comme 802.11 qui sera evoqu e ci-apr` es. Bien que ce type de r eseaux nore aucune garantie, notamment en terme de abilit e, ils proposent cependant une alternative que certains op erateurs sont parfois amen es ` a reproduire ou racheter.
1.4
Les r eseaux locaux sans l (WLAN)
Les r eseaux locaux sont de taille plus r eduite que les r eseaux m etropolitains. Ils visent g en eralement la couverture dune zone de quelques centaines de m` etres maximum comme une entreprise ou un petit campus. La majeure partie des r eseaux dits locaux servent ` a partager des ressources communes 16 Groupe SCSF LATTIS EA4155
comme les documents ou les imprimantes. Ils constituent egalement un acc` es ` a des r eseaux dun autre type comme Internet. De plus, lexplosion r ecente des applications de type Voix sur IP (VoIP) apporte une nouvelle utilit e aux r eseaux locaux qui acheminent d esormais les communications t el ephoniques jusquau poste compatible VoIP de labonn e. Par exemple, de grandes entreprises comme Airbus [CHIC 05] passent d esormais des contrats avec des op erateurs de t el ephonie sur IP pour une r eorganisation compl` ete de leur r eseau de t el ephonie interne. Nous assistons l` a` a une convergence des divers r eseaux de t el ecommunications vers un r eseau unique bas e sur IP. Les technologies de r eseaux locaux sans l se d eveloppent elles aussi, parall` element aux technologies laires. Alors que le sans l permet, dans le cadre des r eseaux m etropolitains, lacheminement du r eseau dans les zones diciles (les WMAN constituent une alternative economique ` a un probl` eme social), le r eseau local sans l va plut ot r epondre ` a un objectif de confort pour lutilisateur en lui permettant d etre plus autonome et mobile dans un environnement o` u le c ablage peut rester n eanmoins envisageable. Dans la suite de cette partie, nous allons d ecrire les principales technologies WLAN et exposer leurs caract eristiques essentielles.
1.4.1
ETSI HiperLAN
HiperLAN est une norme de r eseau local sans l mise au point par le comit e RES10 (Radio Equipment and Systems ) de lETSI [ETSI]. Quatre d eclinaisons dHiperLAN ont et e propos ees par le comit e: HiperLAN/1, HiperLAN/2 [ETSI 00], HiperACCESS et HiperLINK. La norme HiperLAN d ecrit simplement linterface radio, la couche physique et la couche liaison ; les sp ecications de la norme HiperLAN concernent donc les deux premi` eres couches du mod` ele OSI.
1.4.1.1
HiperLAN/1 (HIgh PERformance LAN, premi` ere version)
Le premier projet HiperLAN (HiperLAN/1) a et e lanc e en 1991, peu apr` es les premiers travaux sur 802.11 et a et e rati e durant l et e 1996. HiperLAN/1 est une norme tr` es compl` ete qui propose une couche physique, une m ethode dacc` es et un protocole de routage4 (intra-forwarding, bas e sur un algorithme qui sappellera plus tard OLSR3 [BADI 04]) pour elaborer des r eseaux ad hoc maill es et spontan es. Cette technologie op` ere sur la bande des 5,1 GHz - 5,3 GHz et propose un d ebit bande de base de 23,5 Mbits/s, sur une port ee de 50 m` etres environ. Les modulations utilis ees sont de type FSK3 et GMSK3 . En 1996, les concepteurs de cette norme etaient certainement trop en avance sur leur temps et leur proposition davant-garde na pas re cu de soutien economique. Elle a rapidement et e abandonn ee au prot dHiperLAN/2.
1.4.1.2
HiperLAN/2 (HIgh PERformance LAN, seconde version)
HiperLAN/2 [ETSI 00] a et e rati ee en f evrier 2000. Cette seconde version est radicalement di erente de la premi` ere : mode infrastructure, transport natif dATM et UMTS3 , plusieurs couches physiques pour sadapter ` a lenvironnement electromagn etique. HiperLAN/2 a et e la premi` ere technologie ` a mettre en uvre la technique d etalement de spectre OFDM. Elle propose plusieurs modulations (BPSK3 , QPSK3 , 16QAM3 et 64QAM3 ) pour plusieurs d ebits (6, 9, 12, 18, 27, 36 et 54 Mbits/s) sur la bande des 5,4 GHz - 5,7 GHz. Une utilisation de la bande des 17 GHz aurait egalement et e pr evue. La couche physique dHiperLAN/2 a ensuite et e reprise par 802.11a, puis 802.11g, ce qui explique les similarit es des fr equences et des d ebits en bande de base entre HiperLAN/2 et 802.11a/g.
4 On
parlera plut ot de relais de trames, puisque ce processus se situe au niveau 2 OSI.
17
HiperLAN/2 est intimement li ee ` a ATM qui etait pr evu pour etre le protocole de niveau r eseau/transport au dessus dHiperLAN/2. Outre le transport des cellules ATM, HiperLAN/2 peut aussi v ehiculer nativement des donn ees vid eo MPEG, des paquets IP et Firewire IEEE 1394, ainsi que la voix num eris ee des t el ephones cellulaires UMTS. HiperLAN/2 pr evoit egalement une gestion de la mobilit e pour des vitesses inf erieures ` a 10 m/s par handover (changement de cellule) et propose une gestion de Qualit e de Service par des communications etablies en mode connect e. HiperLAN/2 a b en eci e en France du soutien de lART. A loppos e dHiperLAN/1 qui est bas ee sur une topologie de r eseau ad hoc, HiperLAN/2 propose un r eseau sans l dinfrastructure. Les informations echang ees passent par un ou plusieurs points dacc` es (AP, Access Points ) qui g` erent lacc` es au m edium selon le principe du TDMA3 dynamique (repris ensuite dans IEEE 802.16) avec des transports dinformations en mode connect e. Malheureusement pour lui, le RES10 na pas re cu autant de soutien que le groupe IEEE 802.11, son concurrent direct. La commercialisation d equipements au standard HiperLAN/2 a et e tr` es limit ee et le projet est abandonn e aujourdhui.
1.4.2
IEEE 802.11, WiFi
IEEE 802.11 [IEE1 99] est un standard de r eseau sans l local propos e par lorganisme de standardisation Am ericain IEEE. La technologie 802.11 est g en eralement consid er ee comme la version sans l de 802.3 (Ethernet). La norme originale avait et e rati ee en 1997 ; elle a depuis et e largement amend ee par de nombreux groupes de travail et m eme si les principes de base restent les m emes depuis 10 ans mode non connect e, CSMA/CA3 , 802.2 LLC3 IEEE 802.11 est aujourdhui la technologie de r eseaux sans l locaux la plus utilis ee ` a travers le monde, sans doute du fait de sa grande simplicit e, de son faible co ut de mise en uvre mais aussi gr ace aux importants soutiens techniques et nanciers dont elle a b en eci e.
1.4.2.1
La norme initiale
Dans sa version initiale de 1997, 802.11 proposait trois couches physiques [MUHL 02] : Radio, ` a etalement de spectre par utilisation de s equences directes (DSSS3 ), d ebit bande de base 1 Mbits/s et 2 Mbits/s, Radio, ` a etalement de spectre par utilisation de sauts de fr equences (FHSS3 ), ` a 1,6 Mbits/s, Infrarouge, 1 ou 2 Mbits/s. A lheure actuelle, seule la couche physique radio ` a etalement de spectre par s equences directes (DSSS) perdure. Les deux autres (Radio FHSS et infrarouge), bien quayant et e impl ement ees et commercialis ees ` a la n des ann ees 90, nont pas surv ecu. Depuis, les techniques ont et e fortement am elior ees et les derni` eres couches physiques bas ees sur le principe du MIMO3 permettent dobtenir des d ebits de plusieurs centaines de Mbits/s.
1.4.2.2
Topologies
Dans le cadre de 802.11, deux topologies sont possibles aujourdhui5 :

5 Nous verrons ci-apr` es quun groupe de travail de lIEEE travaille actuellement sur une topologie ad hoc maill ee de 802.11, un peu ` a la mani` ere de HiperLAN/1.
18
une topologie centralis ee autour dun ou plusieurs points dacc` es, on parle alors de mode infrastructure (sils sont plusieurs, les points dacc` es seront reli es par une epine dorsale de type Ethernet). Le r eseau est alors form e de plusieurs BSS (Basic Service Set ) qui forment ensemble un unique EBSS (Extended Basic Service Set ). La gure 1.2 repr esente cette topologie,
Fig. 1.2 Topologie Infrastructure de 802.11 une topologie sans el ement central, sans hi erarchie, o` u chaque station a le m eme r ole ; on parle dans ce cas de mode ad hoc. Le r eseau form e est appel e IBSS (Independent Basic Service Set ). La gure 1.3 repr esente cette topologie.
Fig. 1.3 Topologie Ad-hoc de 802.11
1.4.2.3
Les evolutions de 802.11
Nous lavons vu plus haut, le standard initial 802.11 a et e amend e par de nombreux groupes de travail. Chaque groupe de travail fait des propositions qui donnent lieu ` a des am eliorations de la norme. Ils sont cit es ici : 802.11a propose 8 canaux dans la bande des 5 GHz. Cette proposition permet datteindre un d ebit bande de base de 54 Mbits/s sur une port ee dune vingtaine de m` etres environ par utilisation du principe de lOFDM (d ej` a evoqu e dans le paragraphe 1.3.2 sur HiperMAN et WiMAX). 802.11b propose une am elioration de la norme initiale en introduisant la modulation CCK3 dans la bande des 2,4 GHz. Deux nouveaux d ebits sont alors disponibles : 5,5 Mbits/s et 11 Mbits/s sur une port ee de quelques dizaines de m` etres environ. Rati ee en septembre 1999, 802.11b est lamendement de 802.11 qui a donn e sa popularit e au WiFi. Bien que 802.11b soit encore largement utilis e, il est maintenant supplant e par 802.11g.
19
802.11c propose une modication de la norme 802.1d existante pour les r eseaux laires an de la transposer ` a 802.11. Elle permet une normalisation de linterconnexion de niveau 2 (pont) entre un r eseau laire et un r eseau WiFi. 802.11d propose un protocole d echange dinformations sur les fr equences et les puissances d emission en vue dune utilisation dans chaque r egion du monde, quelque soit le pays dorigine du mat eriel. 802.11e propose des outils de Qualit e de Service. Les travaux sp eciques de ce groupe de travail seront d etaill es plus loin dans ce chapitre 1. 802.11f est une recommandation qui propose une extension pour la communication entre points dacc` es compatibles 802.11 par le protocole IAPP (Inter-Access Point Protocol ) en introduisant des capacit es de changement de cellules et d equilibrage des charges (load-balancing ). 802.11g constitue une am elioration directe de 802.11b en proposant un d ebit bande de base de 54 Mbits/s sur la bande des 2,4 GHz. Ce gain en d ebit est r ealis e en reprenant le concept de l etalement de spectre par OFDM utilis e dans 802.11a. Toutefois, 802.11g garde une compatibilit e avec 802.11b, ce qui signie que des mat eriels conformes ` a la norme 802.11g peuvent fonctionner en 802.11b. 802.11h propose des am eliorations pour pallier au futur probl` eme de la sur-utilisation des fr equences d edi ees ` a 802.11. Ce groupe de travail propose dune part une possibilit e de s election dynamique de fr equence appel ee DFS pour Dynamic Frequency Selection, qui permet de choisir le canal le moins perturb e, et dautre part le contr ole de puissance TPC pour Transmit Power Control, qui permet ` a l emetteur de r eduire sa puissance d emission au minimum n ecessaire. 802.11i est la norme qui sp ecie la solution de chirement d esign ee commun ement par le label WPA2 3 . Elle sappuie sur TKIP3 et AES3 et, contrairement ` a WPA, permet aussi bien la s ecurisation des r eseaux en mode infrastructure comme en mode ad hoc. Deux d eclinaisons sont possibles : le WPA personnal qui repose sur la connaissance dune cl e commune (comme le WEP3 , mais qui peut etre de longueur variable, contrairement ` a ce dernier) et le WPA enterprise qui repose sur 802.1x avec un serveur dauthentication, par exemple de type RADIUS. 802.11IR normalise une couche physique de type infrarouge pour 802.11. Elle utilise des signaux optiques de la bande des 800-900 nm et propose deux modulations de type PPM (Pulse Position Modulation ) : 16-PPM qui permet datteindre un d ebit de 1 Mbits/s et 4-PPM pour 2 Mbits/s. Au d epart soutenue pour ses vertus de s ecurit e les signaux infrarouges ne traversent pas les cloisons elle a rapidement et e abandonn ee au prot de 802.11a et 802.11b qui pr esentent tous deux des d ebits plus importants. 802.11j propose une couche physique sp ecique pour satisfaire ` a la r eglementation japonaise. Tr` es proche de 802.11a (OFDM, 54 Mbits/s, etc.), elle travaille dans la bande 4,9 GHz 5 GHz. 802.11n propose un d ebit bande de base de 540 Mbits/s sur une port ee de 50 m` etres environ gr ace ` a lutilisation conjointe des techniques MIMO et OFDM. Elle propose lutilisation des deux bandes de fr equences 2,4 GHz (comme 802.11b et 802.11g) et 5 GHz (comme 802.11a). Comme 802.11g, cette norme reste compatible avec 802.11 ; de plus, elle reprend les concepts de 802.11e pour la gestion de la Qualit e de Service, de 802.11i pour la s ecurit e et de 802.11f pour la gestion des handovers. A lheure o` u ces lignes sont ecrites, 802.11n est encore ` a l etat de draft (brouillon), suite au r esultat inattendu du vote de lIEEE le 2 Mai 2006. Elle devrait etre rati ee courant 2007. Cependant, il est clair que cette norme constituera le prochain standard en terme de WLAN. 802.11s propose une extension ` a la m ethode dacc` es au m edium de 802.11 ainsi quune m ethode de routage pour les r eseaux ad hoc de type Mesh (r eseaux ad hoc maill es). La diusion des routes est assur ee par une m ethode dinondation et un algorithme tr` es proche dOLSR. Comme 802.11n,
20
la norme 802.11s est actuellement en cours d elaboration et na pas encore et e rati ee. Elle devrait l etre dans le courant de lann ee 20086 . 802.11r propose dintroduire des fonctionnalit es suppl ementaires pour permettre le saut de cellule rapide dun BSS ` a lautre. Il devrait permettre aux terminaux mobiles de passer dune cellule ` a une autre sans perte dacc` es au r eseau.
1.5
Les r eseaux personnels sans l (WPAN)
Les r eseaux personnels concernent les liaisons de donn ees en rapport direct avec lindividu et son entourage imm ediat (t el ecommande, appareillage electrom enager et accessoires, etc.). Comme pour les WLAN, le confort de lutilisateur (mobilit e, absence dinfrastructure lourde, etc.) est souvent la motivation premi` ere des concepteurs des produits utilisant ces technologies. Cependant, on note une certaine aptitude de quelques WPAN ` a sadapter au monde industriel. A la di erence des WLAN dont lobjectif principal, voire unique, est de permettre un acc` es sans l ` a un r eseau plus etendu, les WPAN ne permettent que de relier entre eux des equipements autonomes et, de fait, sont con cus pour sadapter parfaitement au monde de lembarqu e.
1.5.1
IrDA
IrDA [IRDA] d enit une norme de communication qui propose dutiliser le m edium infrarouge pour cr eer des r eseaux de tr` es courtes port ees pour des d ebits allant jusqu` a 16 Mbits/s. IrDA sp ecie de nombreux protocoles : IrPHY, IrLAP, IrLMP, IrCOMM, Tiny TP, IrOBEX, IrLAN et IrFR ; gr ace ` a cet ensemble complet de protocoles, IrDA se sut ` a elle m eme et peut fonctionner seule, sans autre protocole comme notamment les protocoles li es ` a TCP/IP. Nous verrons par la suite que cette sp ecicit e est tr` es r epandue chez les r eseaux de la famille des PAN. Bien que la pile soit tr` es compl` ete, nous ne pr esenterons ici que les deux premi` eres couches du mod` ele OSI, IrPHY (pour la couche physique) et IrLAP (pour la couche liaison de donn ees ). IrPHY sp ecie la couche physique dIrDA. Quatre couches physiques sont propos ees : SIR (Serial InfraRed ) propose de couvrir directement les d ebits normalis es dans le cadre dune transmission RS232 classique (9600 bits/s, 19,2 kbits/s, 38,4 kbits/s, 57,6 kbits/s et 115,2 kbits/s). MIR (Medium InfraRed ) propose deux d ebits plus elev es de 576 kbits/s et 1,152 Mbits/s, FIR (Fast InfraRed ) propose un d ebit de 4 Mbits/s et enn VFIR (Very Fast InfraRed ) propose un d ebit de 16 Mbits/s. Une derni` ere version - UFIR (Ultra Fast InfraRed ), 100 Mbits/s - est toujours en cours de d eveloppement. IrLAP est la couche liaison dIrDA. Elle g` ere le contr ole dacc` es au m edium, la d ecouverte automatique des stations potentiellement connectables ; elle abilise la transmission et n egocie les r oles Primaire / Secondaire. Selon la sp ecication IrDA, la station primaire (unique) contr ole lacc` es au m edium des stations secondaires7 .
La principale caract eristique dune transmission IrDA (qui en fait son originalit e mais aussi son principal d efaut) est que deux equipements IrDA doivent forc ement etre en ligne de vue (LOS, Line Of Sight ) pour pouvoir communiquer ensemble. De plus, la plupart des transmetteurs IrDA sont assez directifs (environ 15o ), ce qui oblige lutilisateur ` a orienter les equipements et peut poser quelques probl` emes. En revanche, ` a la di erence de toutes les technologies utilisant le m edium radio, un r eseau IrDA ne peut traverser les murs, ce qui lui conf` ere un certain atout quant ` a la s ecurit e et au cloisonnement
6 Ironie 7 Nous
du sort, 802.11s propose aujourdhui ce quHiperLAN/1 proposait il y a plus de dix ans ! aurons maintes fois loccasion de constater que cette technique est tr` es r epandue. . .
21
(r eutilisation des canaux). Depuis la n des ann ees 90, IrDA est largement d eploy ee dans les ordinateurs portables et les t el ephones cellulaires. Elle permet, entre autres, de synchroniser son agenda et ses contacts et de se servir du t el ephone cellulaire comme modem. Cependant, lapparition de Bluetooth (que nous verrons plus loin) fait que IrDA est d esormais moins utilis ee car son concurrent propose une plus grande port ee et ne n ecessite pas lorientation des el ements emetteurs/r ecepteurs et une vue directe.
1.5.2
HomeRF
Comme son nom lindique, HomeRF [LANS 99] est une norme de r eseau destin ee ` a un usage domestique pour partager un acc` es ` a Internet ou transporter des communications t el ephoniques DECT3 . Elle a et e imagin ee par un consortium industriel form e entre autres par HP, IBM, Siemens, Proxim, Compaq, Intel et Microsoft mais elle soure aujourdhui de la concurrence des autres technologies WLAN, notamment depuis que Microsoft et Intel se sont eloign es du projet. HomeRF proposait une couche physique travaillant dans la bande des 2,4 GHz, en FHSS (` a 50 sauts par secondes), sur une modulation de type 2-FSK ou 4-FSK. Le d ebit bande de base est de 1 Mbits/s ou 2 Mbits/s, suivant la modulation utilis ee. La port ee typique est de lordre dune cinquantaine de m` etres, pour une puissance de 100 mW. HomeRF permet deux types de transports : asynchrones (typiquement pour de lInternet via du TCP/IP) et synchrones (pour de la voix). De part son faible d ebit, HomeRF nest pas adapt e au transport de la vid eo. La capacit e dadressage est de 127 stations ; il est possible de multiplexer jusqu` a 6 liaisons voix ` a 32 kbits/s. Lacc` es au m edium est r ealis e selon le protocole SWAP, pour Shared Wireless Access Protocol, qui m elange CSMA (pour les donn ees asynchrones) et TDMA (pour les donn ees isochrones). Bien que proposant une m ethode dacc` es au m edium int eressante pour la cohabitation de ux asynchrones et synchrones, HomeRF na pas connue de succ` es et est abandonn ee aujourdhui.
1.5.3
IEEE 802.15.1, Bluetooth
IEEE 802.15.1/Bluetooth [IEE1 02] est une norme de r eseau sans l f ed erateur dont lid ee est n ee au d ebut des ann ees 1990. Son objectif initial etait de proposer une norme universelle pour les communications sans l, plus performante et plus globale que les liaisons infrarouge, d ej` a tr` es r epandues ` a l epoque. Comme IEEE 802.11, Bluetooth sest impos ee gr ace aux forts soutiens nanciers dont elle a b en eci e. Aujourdhui, elle se positionne essentiellement sur le march e des t el ephones portables et accessoires associ es, mais egalement de la bureautique, lobjectif etant de pouvoir facilement connecter un t el ephone ou un ordinateur avec ses divers accessoires (oreillette, casque, souris, clavier, etc.). Les applications sont multiples et ` a lheure actuelle, cette technologie prote de sa maturit e. Son utilisation est g en eralement simple ce qui rend Bluetooth tr` es populaire. De plus, ` a linstar de 802.11 avec WiFi et de 802.16 avec WiMAX, Bluetooth est promue par un SIG (Special Interest Group ). La grande di erence entre les deux tr` es populaires technologies WiFi et Bluetooth est que cette derni` ere, comme IrDA, propose une pile protocolaire compl` ete, de la couche physique ` a la couche application, ` a la di erence de WiFi qui se cantonne aux niveaux 1 et 2 de la pile OSI en ne proposant ni plus ni moins quune version sans l dEthernet. Bluetooth utilise la bande ISM des 2,4 GHz (2,402 GHz ` a 2,480 GHz) en divisant cette bande en 79 canaux de largeur 1 MHz et met en uvre une modulation de type GFSK8 en FHSS. Le d ebit en bande de base est de 1 Mbits/s et la fr equence nominale des sauts FHSS de 1600 Hz, soit une p eriode
8 La GFSK est une modulation Gaussienne de fr equence. Les fr equences porteuses ne sont pas ` a valeurs discr` etes comme en FSK mais varient dans le temps de mani` ere ` a ne pas occasionner de discontinuit es. Dun point de vue spectral, la GFSK est moins consommatrice que la FSK.
22
de 625 s. Du fait de lutilisation des sauts de fr equence, Bluetooth impose un fonctionnement en ma tre/esclave pour le partage du m edium radio. Les topologies envisageables dun r eseau Bluetooth sont les suivantes : point ` a point (un ma tre, un esclave, gure 1.4), Piconet (un ma tre, deux ` a sept esclaves actifs, gure 1.5) ou Scatternet (jusqu` a 10 piconets reli es ensemble, gure 1.6). Quelque soit la topologie choisie, toutes les communications de station esclave ` a station esclave passent par la station ma tre ; les esclaves nont donc pas besoin d etre a port ` ee radio les uns des autres. Bluetooth r esout ainsi le probl` eme classique en sans l de la station cach ee. Cependant, le cas particulier du Scatternet impose quun nud puisse etre membre de deux Piconets simultan ement : tant ot ma tre de son Piconet, tant ot esclave dun autre Piconet. Ces deux possibilit es sont illustr ees dans la gure 1.6.
Fig. 1.4 Topologie point ` a point de Bluetooth
Fig. 1.5 Topologie Piconet de Bluetooth
Fig. 1.6 Topologie Scatternet de Bluetooth
23
Comme HomeRF, Bluetooth propose deux types distincts de transports : ACL (asynchrones, orient es donn ees ) et SCO (synchrones, orient es voix ). Bluetooth propose egalement quelques el ements permettant la mise en uvre de la Qualit e de Service, comme nous le verrons dans la partie 3.3.4 de ce chapitre.
1.5.4
IEEE 802.15.3, Ultra Wide Band (UWB)
Le standard IEEE 802.15.3 [IEE1 03] propose de normaliser une couche physique et une couche liaison de donn ees bas ees sur le concept Ultra Wide Band (UWB). LUWB est une technique d etalement de spectre qui consiste ` a transmettre les donn ees sur un spectre tr` es large en un temps tr` es court ; le signal ainsi transmis est proche dune impulsion. La gure 1.7 illustre ce principe qui est egalement utilis e dans les technologies de radars.
Fig. 1.7 Le principe de lUltra Wide Band : utilisation du spectre radio fr equence
LUWB, utilis e dans le cadre des transmissions de donn ees, permet datteindre des d ebits tr` es importants (pr` es dun Gbits/s), mais sur une distance assez courte. En eet, la bande passante dun syst` eme de communication UWB d ecro t exponentiellement avec la distance ; de ce fait, un r eseau UWB maill e a forte densit ` e de nuds devrait th eoriquement proposer un d ebit plus elev e quun r eseau UWB ` a faible densit e de nuds. LUWB pr esente egalement des avantages au niveau propagation : de part la bri` evet e de l emission, les transmissions bas ees sur UWB pr esentent une tr` es bonne immunit e aux multi-trajets. Du fait de loriginalit e de la m ethode de modulation et de codage de linformation, le standard 802.15.3, notamment dans la m ethode dacc` es, devrait etre amen e ` a proposer des m ethodes tr` es innovantes. Bien que cela ne soit pas lobjectif du TG15.3 de lIEEE, on peut egalement entrevoir de nombreux travaux de recherche au niveau du protocole de routage dans le cadre r eseau maill e UWB : la d ecroissance exponentielle de la bande passante avec la distance imposant le principe mieux vaut router que rechercher la port ee la plus longue, va ` a lencontre des principes de routage actuels. Les perspectives a ce niveau semblent nombreuses. ` Bien que UWB soit tr` es prometteur, aucun produit r epondant aux sp ecications de 802.15.3 nest encore disponible ` a ce jour. Cependant, le SIG Bluetooth pr evoirait dint egrer une couche physique de type UWB dans la troisi` eme version de ses sp ecications. 24 Groupe SCSF LATTIS EA4155
1.5.5
IEEE 802.15.4, ZigBee
Le TG15.4 de lIEEE propose une norme pour les r eseaux sans l personnels ` a faible consommation energ etique (Low Power-Wireless Personal Area Network, LP-WPAN). Le standard IEEE 802.15.4 [IEE2 03] propose une norme pour les couches physique et liaison de donn ees orient ee tr` es faible consommation energ etique qui rend cette technologie bien adapt ee aux r eseaux de capteurs. Nos travaux se basant sur 802.15.4, nous nentrerons pas plus dans les d etails de cette technologie qui sera largement pr esent ee et etudi ee dans les chapitres suivants.
1.6
Les r eseaux de capteurs (WSN)
Les r eseaux de capteurs (Wireless Sensor Networks ) [CULL 04] constituent une cat egorie de r eseaux bien distincte des quatres familles vues jusquici. Alors que les WWAN, WMAN, WLAN et WPAN sont con cus pour r epondre ` a des probl ematiques de communications o` u lhomme est souvent un acteur principal (acc` es ` a un r eseau global comme Internet, t el ephonie, t el ecommande. . .), les WSN orent des moyens de communication tr` es souvent spontan es entre objets autonomes, g en eralement sans aucune intervention humaine. Les r eseaux de capteurs sont utilis es dans divers domaines : militaire : surveillance de zones tactiques, espionnage, environnement : surveillance de l ecosyst` eme, pr evention des risques sismiques, commerce : gestion de stocks, identication des colis, m edical : assistance aux personnes, batiment : surveillance des infrastructures, transport : identication des bagages, ...
Bien que les WSN pr esentent des caract eristiques communes avec certains LP-WPAN (notamment au niveau des couches basses), les applications ne sont g en eralement pas les m emes. Dune mani` ere g en erale, les r eseaux de capteurs se di erencient des autres cat egories de r eseaux sur certaines caract eristiques [SIMP 05] : Les nuds dun WSN doivent pouvoir etre d eploy es en tr` es grand nombre (plusieurs centaines voire plusieurs milliers) sans dicult e. La phase de passage ` a l echelle doit donc etre valid ee pour un r eseau compos e de ce nombre de nuds, Les nuds dun WSN nont pas de caract` ere individuel propre (on parlera de population de nuds ) et lobjectif de lapplication a priorit e sur la vie des nuds (la gestion energ etique individuelle dun nud est moins importante que la gestion energ etique de lensemble du r eseau), La port ee typique dun nud WSN est faible (au maximum quelques dizaines de m` etres) ; en revanche, un processus de routage est mis en uvre pour permettre la communication globale sur tout le r eseau, ` a la mani` ere dun r eseau ad hoc, Un WSN est quasiment d edi e` a une unique application. Au niveau des technologies, les WSN peuvent etre d eploy es gr ace ` a des nuds passifs tels que les RFID ou sur des microsyst` emes actifs. Plusieurs projets dorigine acad emique ou militaire ont donn e lieu a des r ` ealisations mais, ` a lheure o` u ces lignes sont ecrites, il ne semble pas quun standard ait normalis e pr ecis ement une technologie de WSN au m eme titre que les normes issues de lIEEE ou de lETSI pr esent ees jusquici. Cependant, il semble que le standard de LP-WPAN IEEE 802.15.4 se rapproche tr` es fortement des caract eristiques exig ees pour un WSN. Adrien van den Bossche 25
La Qualit e de Service dans les r eseaux
Apr` es avoir propos e un etat de lart des di erentes technologies sans l pr esentes sur le march e ou ` l a etude, nous allons maintenant introduire le principe de Qualit e de Service (QoS9 ) et lillustrer, l` a encore, par lexistant. Nous constaterons ` a cette occasion que les travaux les plus r ecents li es ` a la Qualit e de Service concernent majoritairement la couche 3 du mod` ele OSI (niveau r eseau ), m eme si nombre de travaux ant erieurs concernaient la QoS au niveau acc` es au m edium, notamment dans le domaine des R eseaux Locaux Industriels (RLI) [LEPA 91]. Nous reviendrons egalement sur lint er et de traiter la QoS d` es les couches les plus basses.
2.1
2.1.1
Pr esentation g en erale
Quest ce que la Qualit e de Service ?
En r eseau, la notion de Qualit e de Service regroupe toutes les m ethodes permettant de garantir la disponibilit e du r eseau pour ses utilisateurs. La notion de QoS repose sur lhypoth` ese suivante : le r eseau poss` ede des ressources nies et une p enurie de ses ressources est fortement possible dans des conditions dutilisation raisonnables. Le r eseau etant utilis e simultan ement par de nombreux utilisateurs dont les comportements individuels sont ind ependants, ce risque de p enurie existe et il est tout ` a fait probable : cette p enurie serait provoqu ee par une demande dutilisation massive et simultan ee de la ressource partag ee et aurait pour cons equence la congestion du r eseau. Elle peut alors se traduire par un blocage des donn ees et un eondrement partiel ou total des performances du r eseau (augmentation de la latence de transmission, baisse du d ebit oert, pertes de paquets, etc.). D` es lors, les b en eces engendr es par une gestion ne de la QoS protent aussi bien aux utilisateurs (meilleure disponibilit e du r eseau) quaux op erateurs (possibilit e de facturer lutilisateur en cons equence10 !). De ce fait, la Qualit e de Service est un domaine de recherche et dapplication vaste et prometteur car il vise ` a abiliser consid erablement le r eseau, d eviter la p enurie des ressources et la d egradation de ses performances globales.
2.1.2
QoS vs. Surdimensionnement
Nous pouvons opposer au concept de Qualit e de Service la notion de surdimensionnement. Le surdimensionnement consiste ` a d eployer un r eseau dont la capacit e est largement sup erieure aux besoins r eels, le risque de p enurie evoqu e plus haut est donc minimis e mais toujours probable. Le surdimensionnement va tr` es souvent de pair avec lutilisation de protocoles bas es sur le Best-Eort 11 , cest-` a-dire des protocoles ne proposant ni priorit es ni garanties mais dont les performances sont acceptables dans la plupart des cas. La mise en uvre simple et le co ut faible dun r eseau surdimensionn e sont deux crit` eres qui favorisent souvent lutilisation de r eseaux tr` es haut d ebit au d etriment dun r eseau ` a QoS, surtout dans des cas o` u le m edium ne co ute pas cher comme dans le cas dun r eseau local laire. Par exemple, le co ut dinstallation dun r eseau Ethernet Gigabit peut etre tr` es inf erieur au co ut d equipements de contr ole de QoS. En revanche, dans dautres cas o` u le m edium peut avoir un co ut dutilisation plus elev e, lutilisation
QoS est tr` es souvent utilis e pour d esigner la notion de Qualit e de Service. notion de tarication est fondamentale lorsque le r eseau public se voit dot e de fonctionnalit es de QoS : si lon consid` ere quen cas de p enurie, comme nous le verrons plus loin, certains tracs sont prioritaires devant dautres, il est n ecessaire de discipliner les utilisateurs, voire de les forcer ` a se discipliner en leur imposant un co ut nancier proportionnel a leur priorit ` e sur le r eseau. En revanche, dans le cas dun r eseau priv e ou industriel, la QoS est administr ee localement dans lint er et global, sans n ecessit e de surco ut. 11 ` a traduire par faire au mieux.
10 La 9 Lacronyme
26
de protocoles ` a QoS est rentable. Notons que la notion de co ut dutilisation nest pas forc ement dordre nancier ; le m edium peut etre une ressource rare (r eseaux sans l hertziens, r eseaux aquatiques acoustiques [BOUZ 03], r eseaux ` a economie d energie) quil est important d economiser. Le r eel inconv enient dun r eseau ` a QoS est quil n ecessite une administration pointue pour etre ecace. De plus, sur un r eseau exible comme un r eseau paquets 12 , la mise en uvre de la Qualit e de Service aaiblit cette exibilit e et soul` eve des probl ematiques que lon rencontre g en eralement sur un r eseau commut e.
2.2
Notions fondamentales et principes de QoS
La mise en uvre de la Qualit e de Service sur un r eseau implique certaines conditions. Celles-ci sont d etaill ees ci-apr` es.
2.2.1
La pr edictablilit e du trac
La mise en uvre dun r eseau ` a Qualit e de Service repose sur la pr edictablilit e du trac. Pour pouvoir assurer une qualit e constante quelquen soit la charge, ladministrateur doit etre en mesure de pouvoir d ecrire pr ecis ement la physionomie de chaque trac transport e par le r eseau. Il est donc n ecessaire d evaluer les ressources demand ees par les utilisateurs. On consid` ere g en eralement quil nest pas n ecessaire pour lapplication de savoir comment linformation est achemin ee de bout en bout par le r eseau ; cependant, lutilisateur nal est sensible ` a certaines propri et es qui ont un impact direct sur sa satisfaction vis-` a-vis du r eseau. On consid` ere g en eralement que son ressenti peut se r esumer par quatre param` etres qui sont : 1. la latence, cest-` a-dire le d elai instantan e qui impacte la transmission de bout en bout, 2. la gigue, cest-` a-dire la di erence de latence entre les paquets (certains vont tr` es vite, dautres plus lentement), 3. le d ebit, cest-` a-dire le volume dinformation transport e par unit e de temps, 4. la perte de paquets, cest-` a-dire le taux de paquets qui narrivent pas ` a leur destination. Suivant le type dapplication vis e, les quatre param` etres nont pas la m eme importance. Par exemple, dans le cadre dun transfert de chier, la latence et la gigue ont peu dimpact sur lutilisateur, lessentiel etant que le chier soit transf er e rapidement et sans erreur. Dans le cadre dune communication t el ephonique (transport multim edia interactif), le d ebit importe peu, tant quil sut ` a transporter les donn ees vocales num eris ees ; cependant les param` etres temporels (latence, gigue) et le taux de paquets perdus ne doivent pas d epasser un certain seuil pour le confort des participants ` a la conversation t el ephonique. On peut alors d enir deux param` etres pour evaluer les besoins dune application communicante : 1. L elasticit e, cest-` a-dire la facult e dune application r eseau ` a sadapter [MICH 05] ` a un changement brusque de qualit e de connexion (typiquement, une application de transfert de chier ou une application de streaming vid eo avec adaptation automatique du CODEC selon le d ebit de la ligne est fortement elastique), 2. Linteractivit e, cest-` a-dire le niveau dinteraction ou de r eactivit e n ecessaire pour un bon fonctionnement de lapplication entre les deux points communicants (typiquement, les applications de type temps r eel sont fortement interactives).
12 On d esigne souvent par r eseau paquets un r eseau ` a commutation de paquets, cest ` a dire un r eseau o` u les informations sont d ecoup ees en paquets de donn ees pour etre achemin ees de bout en bout, par opposition aux r eseaux commut es (r eseaux ` a commutation de circuits ) o` u le canal est totalement d edi e` a la transmission en cours. La paquetisation permet un multiplexage temporel qui autorise la r eutilisation du m edium en cas dabsence de donn ees.
27
Une fois la physionomie du trac clairement identi ee, des zones de tol erance peuvent etre clairement enonc ees et le trac ne doit pas en sortir. Si cest le cas, les paquets non conformes peuvent etre refus es ou retard es par un reconditionnement ( ecr etage du d ebit au niveau r eseau ou transport). Eventuellement, dans des cas bien pr ecis, le contenu peut etre alt er e (par exemple par une recompression ` a la vol ee de donn ees multim edia).
2.2.2
Le contr ole dadmission
Un r eseau ` a Qualit e de Service ne peut pas sengager ` a transporter tous les ux qui se pr esentent ` a lui ; la mise en application dun protocole ` a QoS va obligatoirement de pair avec la mise en place dun syst` eme de contr ole dadmission, cest-` a-dire un syst` eme qui agit en entr ee du r eseau et dont le r ole est daccepter ou de refuser la prise en charge dun nouveau trac par le r eseau. Un r eseau ` a QoS conna t ses limites et refusera la prise en charge dune nouvelle demande qui ne pourra pas etre satisfaite dans les conditions demand ees13 .
2.2.3
Les degr es de Qualit e de Service
Les trois principaux degr es de Qualit e de Service (trois niveaux de services), du plus able au plus l ache, sont les suivants : 1. Le service garanti, ou premium. Il vise ` a emuler une liaison sp ecialis ee : malgr e un multiplexage des paquets sur le m edium, le lien propose les m emes garanties que sil etait bas e sur une ligne ind ependante. Des pertes de paquets ou une certaine gigue peuvent n eanmoins etre accept ees en fonction du contrat n egoci e. Au niveau technologies, le service garanti se retrouve avec le GS (Guaranteed Service) de IntServ, le EF (Expedited Forwarding) de DiServ et le CBR (Constant Bit Rate) de lATM que nous d etaillerons plus loin, 2. Le service mieux que Best-Eort . 3. Le service Best-Eort. Le protocole IP de base en est un exemple, ou encore UBR de lATM (Unspecied Bit Rate ). En pratique, lapplication de la QoS sur le r eseau se concr etise par deux types dactions : 1. La di erenciation de services. Dans le cadre de la di erenciation de services, certains tracs sont trait es prioritairement par rapport ` a dautres : on parle de traitement pr ef erentiel dun paquet de donn ees. La di erenciation de services est r ealis ee dune part gr ace ` a un marquage des paquets (tagging ) pour identier leur niveau de priorit e (ce marquage peut etre r ealis e au moment de ladmission dans le r eseau) et dautre part gr ace ` a un ordonnancement (scheduling ) au niveau du pr e-traitement et de l emission sur le r eseau : dans les routeurs, les paquets de donn ees ne seront pas trait es selon le principe du premier arriv e, premier servi (FIFO, First In, First Out ) mais selon leur priorit e. La di erenciation de services ne permet pas dapporter de garantie absolue ; la seule garantie est relative aux autres tracs (plus prioritaire, moins prioritaire, ou m eme priorit e). 2. La r eservation de ressources. Dans le cadre de la r eservation de ressources, il est possible de garantir lacheminement des informations sur le r eseau car une partie de ses ressources mat erielles sera bloqu ee et d edi ee ` a lacheminement de cette information. Un r eseau paquets avec r eservation de ressources a une abilit e proche de celle dun r eseau ` a commutation de circuits, le challenge etant de parvenir ` a une description physionomique du trac la plus d` ele possible (proche possible de la r ealit e) pour ne r eserver que les ressources n ecessaires, et pas plus.
13 Nous
sommes bien aux antipodes du r eseau Best-Eort !
28
2.3
Quelques exemples de protocoles ` a QoS
Nous allons ici pr esenter plusieurs exemples de protocoles impl ementant une Qualit e de Service. Nous allons le voir, les approches sont di erentes mais les objectifs naux sont les m emes : permettre a lutilisateur de disposer du r ` eseau ` a tout instant, dans des conditions n egoci ees au pr ealable et ce, quelque soit l etat de ce r eseau ` a linstant o` u les donn ees devront etre achemin ees.
2.3.1
Asynchronous Transfer Mode (ATM)
ATM [PUJO 95], pour Asynchronous Transfer Mode, est une technologie T el ecoms fonctionnant en mode connect e par commutation de cellules (Cells ), etablissant des circuits virtuels. Lobjectif dATM est de pouvoir faire cohabiter des applications tr` es diverses au sein dun m eme r eseau dop erateur, avec une prise en charge native de la Qualit e de Service : ATM est dot e dun protocole de signalisation qui n egocie la QoS d` es l etablissement du circuit virtuel [DESG 03]. Nous naborderons pas ici laspect routage par commutation de cellules mais simplement laspect QoS qui est intrins` equement li e` a la mise en uvre dATM. ATM propose une gestion du trac par contrats, associ es ` a des descripteurs de tracs et un m ecanisme de contr ole dacc` es et de priorit e. Comme nous lavons vu plus haut, il est fondamental, dans un r eseau ` a QoS, de savoir d ecrire le prol de chaque trac ecoul e par le r eseau (d ebit continu ou en rafale, etc.). An de pouvoir r ealiser cette description, la norme ATM propose six descripteurs de trac : PCR (Peak Cell Rate ) MCR (Min Cell Rate ) SCR (Sustainble Cell Rate ) CTD (Cell Transfert Delay ) CDV (Cell Delay Variation ) CLR (Cell Loss Ratio )
Lutilisation (ou non) de ces descripteurs de trac donne existence ` a cinq cat egories de services th eoriques normalis ees : CBR (Constant Bit Rate ) utilise PCR, CTD, CDV et CLR. Les circuits virtuels CBR sont con cus pour les liens ` a d ebit constant et ` a fortes contraintes temporelles, RT-VBR (Real Time-Variable Bit Rate ) utilise PCR, SCR, CTD, CDV et CLR. Comme CBR, les circuits virtuels RT-VBR sont utilis es pour les liens ` a fortes contraintes temporelles mais ` a d ebit variable, NRT-VBR (Non Real Time-Variable Bit Rate ) utilise PCR, SCR et CLR. Dans le cadre de NRTVBR, les descripteurs de trac qui concernent les d elais ne sont pas pris en compte. Les circuits virtuels NRT-VBR sont utilis es pour les liens ` a d ebit variable sans contraintes temporelles, ABR (Available Bit Rate ) utilise PCR et MCR. Les circuits virtuels ABR ne tiennent compte que de deux bornes minimales et maximales pour le d ebit. Ils permettent de ne garantir quun d ebit minimal et un d ebit maximal. UBR (Unspecied Bit Rate ) nutilise aucun descripteur de trac. Les circuits virtuels UBR ne permettent aucune garantie. Cest le mode Best-Eort de lATM. Chaque service propos e par ATM est adapt e` a une utilisation particuli` ere du r eseau ; ` a chaque application communicante (transfert de chiers, echange de donn ees temps r eel, multim edia, etc.) correspond un service ad equat. Quant aux deux derniers services (ABR et UBR), ils permettent dutiliser les reliAdrien van den Bossche 29
quats de bande passante inutilis es par les services ` a fortes contraintes. Ainsi, la partie de bande passante inutilis ee qui avait et e r eserv ee par multiplexage statistique peut etre revendue, ce qui est tr` es int eressant et pour lop erateur (revente de bande passante), et pour le client (acc` es au r eseau sans garantie mais ` a moindre frais). Lorsquun nouveau trac entre dans le r eseau ATM, il doit etre accompagn e de ses descripteurs de trac et de son besoin en QoS (cest-` a-dire le niveau de QoS d esir e par le client). Le nouveau trac est alors soumis au CAC (Call Admission Control ) qui prend la d ecision daccepter le nouveau trac dans le r eseau, ou de le refuser, en fonction de la charge. Si le CAC est favorable, le trac est d ecoup e en cellules qui sont marqu ees (tagging ) et inject ees dans le r eseau. A chaque passage dans un routeur du r eseau, la conformit e du trac est v eri ee. Si le trac nest pas conforme ` a sa description, le surplus de cellules est d etruit, entra nant une perte de donn ees qui sera d etect ee par les couches sup erieures14 .
2.3.2
IntServ
IntServ [WROC 97] est un protocole de gestion de QoS pour un r eseau de petite taille . Son nom est labr eviation de INTegrated SERVices et il est d eni par les RFC 1633 et 2205-2216. Lobjectif dIntServ est d eviter les probl` emes de congestion dans les routeurs sur un r eseau h et erog` ene non isochrone de bout en bout (comme Internet, par exemple). Pour cela, IntServ r eserve une partie des ressources des routeurs du r eseau en xant des bornes sur les d elais et les d ebits. Il sp ecie un protocole de signalisation RSVP, pour Ressource ReSerVation setup Protocol, qui va etre charg e de la communication entre routeurs ` a QoS. A la di erence dATM qui fonctionne par l emulation de circuits virtuels, un r eseau comme Internet consid` ere les paquets de mani` ere ind ependante (principe de la commutation de paquets). IntServ doit donc reconstituer un ot pour permettre le traitement de la Qualit e de Service sur un ensemble de paquets qui seront identi es comme faisant partie dun m eme groupe qui doivent etre trait es de mani` ere homog` ene dun point de vue QoS.
2.3.2.1
Prols de QoS au niveau utilisateur
Au niveau utilisateur, IntServ d enit trois types de prols : 1. le service classique en Best-Eort, 2. un service de charge contr ol ee (Controlled Load ) o` u le r eseau se comporte comme un r eseau Best-Eort peu charg e : trac interactif possible, d ebit moyen et rafale possible si lutilisateur la demand e, 3. un service garanti (Guaranteed load ) o` u lutilisateur poss` ede une vraie garantie sur le d ebit, le d elai et la gigue. De la m eme mani` ere que pour tous les autres protocoles ` a QoS, un ot de donn ees r eclamant une QoS devra etre accept e par un syst` eme de contr ole dadmission et devra par la suite etre conforme ` a la physionomie d ecrite.
2.3.2.2
Le protocole de signalisation RSVP
Le protocole RSVP est le protocole de signalisation sp eci e par IntServ. Il permet aux routeurs de communiquer entre eux et d etablir la r eservation de ressources de bout en bout, selon le contrat sign e avec lutilisateur. Les deux messages principaux de RSVP sont PATH et RESV. Le premier (PATH) est envoy e par un nud d esirant envoyer des donn ees sur le r eseau. Le message contient le descripteur de
14 Cette m ethode peut sembler brutale mais si le trac nest pas conforme ` a sa description pr ealable, le client na pas respect e son contrat. . .
30
Qualit e de Service d esir ee. Chaque routeur du r eseau recevant un message PATH retient ladresse du routeur layant d ej` a relay e. Lorsque le message PATH est re cu par le destinataire nal, celui-ci r epond en renvoyant un message RESV qui suit exactement m eme chemin, mais dans lautre sens. Une fois le message RESV achemin e jusqu` a sa destination, le chemin est etabli avec les r eservations n ecessaires. La gure 1.8 illustre le principe.
Fig. 1.8 Illustration du protocole RSVP
Une fois le chemin etabli, l emetteur doit maintenir la r eservation en reproduisant ce m ecanisme ` a intervalles r eguliers (re emission des messages PATH et RESV). Un changement de r eservation (plus de d ebit, etc.) peut etre eectu e de la m eme mani` ere. Si lun des routeurs sur le chemin ne re coit plus les messages au bout dun certain temps, la r eservation expire et les ressources sont lib er ees. Le protocole pr evoit cependant que les r eservations accumul ees doivent etre rendues par les demandeurs via les messages PATH_TEAR et RESV_TEAR. Ces deux messages sont utilis es de la m eme mani` ere que PATH et RESV.
2.3.2.3
Conclusion : b en eces et dicult es li es ` a IntServ
Lutilisation de IntServ et RSVP sur un r eseau pr esente plusieurs avantages : IntServ permet la r eservation de ressources dans les routeurs sans grandes modications. Son int egration dans un r eseau existant est relativement simple et son principe de traitement par ots sadapte ` a tout r eseau de type paquets. RSVP sint` egre parfaitement dans une architecture de r eseau multicast, comme par exemple la diusion de ux multim edia, o` u les principes de QoS sont tr` es appr eci es. Cependant, IntServ pr esente aussi certains inconv enients : Le choix du traitement par ot est tr` es consommateur de ressources : les tables de descripteurs de ots consomment beaucoup de m emoire, m eme pour un ot qui peut etre tr` es court : sur Internet, une requ ete HTTPv1.0 tient en quelques dizaines doctets. Il sera plus long d etablir la QoS que de traiter la demande elle m eme. De plus, si la taille du r eseau et/ou le nombre de ots est grand, la quantit e de m emoire n ecessaire aux tables de descripteurs de ots devient trop importante. De ce fait, IntServ nest pas adapt e aux grands r eseaux comme Internet, De part la cr eation du chemin de r eservation, IntServ nest pas adapt e` a un r eseau mobile sans l Adrien van den Bossche 31
et revient ` a utiliser le r eseau paquets comme un r eseau ` a commutation de circuits. Une partie de la souplesse est perdue, Enn, les messages RSVP etant transport es par le m eme protocole que les donn ees utiles (signalisation et donn ees transport ees par le m eme r eseau), ils risquent d etre perdus au m eme titre que les donn ees en cas de congestion r eseau ; la gestion de la QoS sera alors inecace et les performances globales du r eseau s ecrouleront. Id ealement, les messages de signalisation devraient etre di erenci es ` a un niveau plus bas (N ecessit e de la mise en uvre dune QoS au niveau Liaison, comme nous le verrons ` a la n de ce chapitre).
2.3.3
DiServ
Lapproche DiServ [NIC1 98] [NIC2 98] (pour DIFFerentiated SERVices ) est souvent compar ee ` a celle de IntServ pour sa capacit e` a etre d eploy ee sur de grands r eseaux ; alors que IntServ, de par le traitement par ots, ne peut sappliquer que sur des r eseaux de petite taille , DiServ r eduit au maximum la taille des tables en consid erant des agr egations de ots. Ainsi, les ots ne sont pas trait es individuellement mais par agr egats, ce qui all` ege consid erablement la charge des routeurs du r eseau. De plus, le contr ole dadmission nest plus assur e individuellement par chaque routeur travers e, mais par les routeurs de bordures, rendant DiServ beaucoup plus adapt e aux grands r eseaux, et notamment aux R eseaux dop erateurs 15 . Le niveau de QoS dun ot est indiqu e dans un champ de len-t ete de ses paquets. Lorsquun routeur de bordure d ecide dadmettre un nouveau trac dans le r eseau, il xe la valeur du champ DSCP (Differentiated Services CodePoint) dans len-t ete IP : le code 0 signie que le paquet doit etre trait e en Best-Eort, apr` es tous les autres (niveau le moins prioritaire), un code autre que 0 aura une autre signication ; cette correspondance est x ee par lop erateur lui-m eme, selon les contrats quil propose ` a ses clients. Lorsquun routeur du cur du r eseau (routeur core ) devra traiter ce paquet, il devra inspecter le champ DSCP et traiter le paquet en cons equence. Ainsi, DiServ pr esente lavantage de ne pas n ecessiter de signalisation puisque le d ecodage du champ DSCP se fait via des tables inscrites dans la m emoire du routeur. Le contr ole de congestion se fait directement par les routeurs de bordure, selon le principe de la capacit e nie et connue du r eseau. Dans le cur du r eseau, il ny a pas de r eservation de ressources, seule la di erentiation de traitement des paquets sut ` a appliquer une qualit e de service pour la travers ee du paquet dans le r eseau. Cependant, an de palier les pertes sur le m edium, le r eseau cur, par exemple un r eseau ATM, n ecessite d etre l eg` erement surdimensionn e.
2.4
Conclusion
Nous avons pris pour exemple trois protocoles qui mettent en uvre de la QoS sur un r eseau. Les protocoles sont di erents mais la recette reste la m eme : description du trac, acceptation si le r eseau en a la capacit e, acheminement de bout en bout. Eventuellement, le principe de di erenciation de services permet dacheminer les donn ees les plus prioritaires en cas dune eventuelle congestion. Cependant, nous avons pu constater que la gestion de la QoS sur tout le r eseau nest pas chose simple. Une solution de type IntServ n ecessite un trac de gestion important (qui peut devenir tr` es lourd pour des petits tracs irr eguliers) et nest pas du tout adapt ee ` a un r eseau mobile. Une solution de type DiServ n ecessite un surdimensionnement du r eseau cur pour palier aux pertes des couches 1 et 2, ce qui, en sans l nest pas envisageable (les pertes de niveau 1 et 2 sont trop importantes). Quelque
15 Les r eseaux dop erateurs sont constitu es de trois types de routeurs : les routeurs core qui constitue le cur du r eseau, les routeurs de bordures (edge ) qui echangent les donn ees avec dautres r eseaux (on parle aussi de peering ) et les routeurs dacc` es, qui font le lien avec les clients.
32
Probl ematique de lacc` es au m edium partag e
soit la solution retenue, il est essentiel de limiter les pertes ` a tous les niveaux car pour le syst` eme de contr ole dadmission, de fortes pertes aux niveaux 1 et 2 constituent une source dincertitude qui lui font perdre sa pertinence ; pour la couche physique, un bit transmis correctement qui serait ensuite d etruit par les couches sup erieures pour lisser le trac constitue une perte s` eche de bande passante. La solution id eale doit assurer une transversalit e de la QoS dans toute la pile protocolaire.
Dans les techniques de t el ecommunications, un des probl` emes fondamentaux est le contr ole dacc` es au m edium partag e : lorsque deux emetteurs utilisant le m eme canal de communication emettent des informations en m eme temps, il y a risque de perturbations pour les eventuels r ecepteurs. Il est possible de comprendre cette probl ematique en faisant une analogie avec la parole humaine : si dans une m eme pi` ece, deux personnes proches lune de lautre parlent en m eme temps, la conversation sera tr` es dicile ` a suivre, voire inaudible pour eux-m emes ou leurs interlocuteurs. Dans le cadre des t el ecommunications, le probl` eme est exactement le m eme, quil sagisse de t el ecommunications laires ou sans l. Dans la mesure o` u une perturbation risque de d egrader consid erablement les performances du r eseau de communication, on cherchera g en eralement ` a eviter que deux emetteurs emettent en m eme temps sur le m eme canal. Si cette perturbation ne peut etre evit ee, on d esignera ce ph enom` ene par le terme collision. Pour r esoudre cette probl ematique, les concepteurs ont et e amen es ` a d evelopper des m ethodes dacc` es au m edium, cest-` a-dire des algorithmes permettant de minimiser voire de supprimer le ph enom` ene des collisions. On parlera aussi de contr ole dacc` es au m edium, et plus souvent en anglais, de Medium Access Control, ou MAC. De nombreuses techniques ont et e envisag ees pour la r esolution de cette probl ematique ; nous nous limiterons ` a pr esenter les plus importantes.
3.1
Acc eder au m edium partag e : les principes de base
Le canal de communication est g en eralement utilis e par plusieurs el ements communicants du r eseau car il est dot e dune certaine capacit e. Il sut de coordonner la r epartition de cette capacit e pour faire cohabiter plusieurs emetteurs sur le m eme canal de communication sans quils se perturbent et que leurs donn ees emises nentrent en collision. On parlera dans ce cas, dacc` es multiple au m edium ou de multiplexage, comme lillustre la gure 1.9.
Fig. 1.9 Proc ed e de multiplexage / d emultiplexage pour la cohabitation de plusieurs tracs sur le m eme canal de communication Le multiplexage consiste ` a diviser une composante du canal pour le r epartir sur n emetteurs. En t el ecommunications, on consid` ere quil existe trois types de multiplexage de base (trois espaces du canal divisibles) : 1. Un multiplexage de type fr equentiel, ou FDMA3 (Frequency Division Multiple Access ) dans lequel lespace fr equentiel est divis e entre tous les emetteurs. L emission peut alors se faire temporellement en continu. Le FDMA est simple ` a mettre en uvre mais son inconv enient principal est quil faut un r ecepteur d edi e par canal ` a ecouter. Cette technique de multiplexage est la plus ancienne ; Adrien van den Bossche 33
elle est encore largement utilis ee dans les diusions comme la t el evision et la radio. 2. Un multiplexage de type temporel, ou TDMA3 (Time Division Multiple Access ) dans lequel lespace temporel est divis e entre tous les emetteurs. L emission peut alors se faire sur la m eme bande de fr equence puisque celle-ci est tour ` a tour utilis ee par les di erents emetteurs du r eseau. La m ethode du TDMA est int eressante dans la mesure o` u il nest pas n ecessaire de changer de fr equence pour ecouter dautres emetteurs. En revanche, les emetteurs doivent se synchroniser pour ne pas utiliser le canal en m eme temps. Le TDMA est tr` es adapt e aux transports dinformations de type paquets ; cest aussi pour cette raison que son principe est largement utilis e. 3. Un multiplexage par codage, ou CDMA3 (Code Division Multiple Access ) dans lequel lespace des codes est divis e entre tous les emetteurs. Chaque emetteur poss` ede un code unique que ses r ecepteurs doivent conna tre. Dans lid eal, les codes choisis doivent etre orthogonaux, cest ` a dire quils doivent respecter des propri et es math ematiques qui les rendent totalement di erents y compris dun point de vue spectral ; dans ce cas, si un r ecepteur ne conna t pas le code dun emetteur, son signal sera re cu comme du bruit. Le CDMA, en tant que m ethode dacc` es, est assez peu utilis e dans la pratique, bien que le principe de l etalement de spectre sur lequel il repose, soit, lui, largement utilis e, mais plut ot pour ses propri et es de abilisation de la transmission.
Bien entendu, ces trois multiplexages de base peuvent etre combin es pour donner lieu ` a des techniques de multiplexages elabor ees comme le FHSS, qui associe TDMA et FDMA en r ealisant des sauts de fr equences. Plus simplement, dautres techniques de diusion comme le DVB-T3 (utilis e pour la T el evision Num erique Terrestre, TNT) ou le DVB-S (pour les Radios, T el evisions et services de donn ees par satellite g eostationnaire) pr evoient d emettre sur plusieurs fr equences (FDMA) et multiplexer plusieurs programmes sur une m eme fr equence (TDMA). On pourra egalement noter le cas particulier de lOFDMA3 , bas e sur le principe de lOFDM, qui permet ` a plusieurs stations d emettre en m eme temps sur des sous-porteuses di erentes (un peu comme en FDMA) mais en ne n ecessitant quun seul r ecepteur capable de recevoir simultament toutes les sous-porteuses. Cependant, dans le cadre du TDMA, le temps est divis e entre tous les emetteurs et il est n ecessaire de r epartir ce temps, si possible, de mani` ere automatique et exible. Bien que le concept de TDMA soit tr` es simple ` a envisager, sa mise en uvre, en revanche, nest pas chose ais ee. Nous allons voir par la suite plusieurs techniques dacc` es au m edium impl ement ees dans les technologies pr esent ees en d ebut de chapitre. Nous allons egalement constater que la plupart de ces m ethodes dacc` es sont bas ees sur des protocoles al eatoires qui ne r` eglent pas de mani` ere certaine le probl` eme des collisions ce qui, dun point de vue QoS, peut poser probl` eme.
3.2
3.2.1
Les principales techniques dacc` es au m edium

CSMA/CA (IEEE 802.11 DCF)
IEEE 802.11 [IEE1 99] propose deux m ethodes dacc` es au m edium : la m ethode DCF (Distributed Coordination Function ) et la m ethode PCF (Point Coordination Function ) que nous pr esentons dans la section suivante. La m ethode dacc` es DCF est une m ethode dacc` es en mode Best-Eort, cest ` a dire sans priorit e et sans garantie. Elle est tr` es ecace pour transporter les tracs ne n ecessitant pas de garantie sur la latence de transmission ou le d ebit oert (t el echargement, navigation sur Internet, etc.). Elle sappuie sur lalgorithme CSMA/CA, qui est lune des nombreuses variantes de la m ethode dacc` es au m edium CSMA. Cette variante pr esente la particularit e d etre adapt ee au m edium sans l dans la mesure o` u, dans le cas dun m edium sans l, il est dicile de d etecter une collision instantan ement. Contrairement a un m ` edium laire, il nest pas possible, sur un m edium sans l, dentendre le m edium en m eme temps 34 Groupe SCSF LATTIS EA4155
que lon transmet des donn ees, ceci ` a cause des ph enom` enes daveuglement 16 et daaiblissement 17 , 3 alors quen laire, Ethernet utilise la variante CSMA/CD qui permet de d etecter une collision quasiinstantan ement : la comparaison de ce qui est emis et de ce qui est entendu permet de savoir si il y a collision alors que dans le cadre de CSMA/CA, la collision est d etect ee ult erieurement par la nonr eception dun message dacquittement. Lalgorithme CSMA/CA fonctionne ainsi : une station voulant emettre des donn ees commence par d eterminer si le m edium est libre : si cest le cas, elle peut envoyer ses donn ees imm ediatement (gure 1.10),
Fig. 1.10 Illustration de CSMA/CA si le m edium est initialement libre si le m edium est occup e (gure 1.11), elle doit di erer cet envoi de la mani` ere suivante : attente (1-persistant) que le m edium redevienne libre, puis attente dun temps DIFS3 + un temps al eatoire de CW slots (Contention Window, fen etre de contention18 ), si, ` a la suite de cette attente, le m edium est toujours libre, la station a gagn e lacc` es au m edium et peut ainsi emettre ses donn ees sans attendre plus longtemps (cas de la station A sur la gure 1.11), si, alors quelle est dans la phase de fen etre de contention, le m edium est repris par une autre station, le processus est abandonn e jusqu` a la prochaine p eriode. Cependant, la station m emorise le temps quil lui restait ` a attendre, pour reprendre l` a o` u elle etait rest ee, lors de la prochaine n egociation dacc` es au m edium (cas de la station B sur la gure 1.11).
Fig. 1.11 Illustration de CSMA/CA si le m edium est initialement occup e

16 Pour un r ecepteur recevant deux emetteurs simultan ement, si la di erence de puissance des signaux per cus est importante, le r ecepteur est dit aveugl e par le signal le plus puissant car il est dans limpossibilit e de d ecoder le signal le plus faible. 17 En sans l, une grande partie de l energie emise est perdue d` es que le r ecepteur s eloigne de l emetteur. Cette propri et e est d emontr ee par la formule de Friis 18 Cette fen etre de contention permet de di erer la reprise de l emission et, ainsi, de r epartir lacc` es au m edium entre les stations.
35
Notons que les acquittements ne sont pas repr esent es sur les gures 1.10 et 1.11, et que, bien entendu, l equit e de cet algorithme repose sur le respect du tirage al eatoire de CW. Notons egalement quune station qui nest pas en emission doit ecouter le m edium car si elle re coit une trame qui lui est destin ee, elle doit lacquitter par lenvoi dune trame dacquittement (ACK). En ajoutant le m ecanisme RTS/CTS ` a la technique CSMA/CA, IEEE 802.11 permet de contrer leet du terminal cach e. Consid erons trois stations A, B et C : B peut communiquer avec A et C, mais A et C ne peuvent communiquer ensemble, par exemple parce quelles sont trop eloign ees lune de lautre ou parce quun obstacle les s epare. Consid erons que A est en train d emettre un message destin e a B, et que C d ` esire egalement acc eder au m edium ; si C respecte le protocole CSMA/CA tel quil a et e expos e plus haut, C va croire que le m edium est libre et va pouvoir emettre imm ediatement et ` a coup s ur provoquer une collision au niveau de B puisquelle nentend pas A. Pour contrer ce ph enom` ene tr` es fr equent en sans l, avant de pouvoir envoyer ses donn ees (trame DATA), une station devra dabord envoyer une trame RTS (Request To Send ) contenant ladresse de la station de destination et la dur ee approximative de l emission (NAV, Network Allocation Vector ), jusqu` a lacquittement ACK ; la station de destination r epond ` a ce message par un CTS (Clear To Send ), en diusant elle aussi linformation de dur ee contenue dans le RTS. Ainsi, toutes les stations ` a port ee de la source comme de la destination sont inform ees quelles ne doivent pas utiliser le m edium pendant le temps annonc e dans les trames RTS et CTS. La gure 1.12 illustre un r eseau compos e de trois stations A, B et C dont deux (A et C) ne se voient pas ` a cause dun obstacle.
Fig. 1.12 Topologie pr esentant deux terminaux mutuellement cach es
Au niveau de lacc` es au m edium, la gure 1.13 illustre le d eroulement temporel de lactivit e du m edium. Dans cet exemple, nous avons ajout e une station D, qui ne re coit que la station A.
Fig. 1.13 D eroulement de lacc` es au m edium par la m ethode CSMA/CA
36
Notons que ce syst` eme ne permet pas d eviter toutes les collisions, notamment les collisions de RTS et/ou CTS. A ce titre, 802.11 pr evoit un seuil RTS-Threshold sur la longueur de la trame ` a partir de laquelle le m ecanisme de RTS/CTS est actif. Si la longueur de la trame est inf erieure ` a ce seuil, le m ecanisme nest pas activ e et la trame peut etre envoy ee directement. En eet, pour de petites trames, il y a autant de chance de provoquer une collision sur le RTS que sur la trame de donn ee, donc autant envoyer la donn ee directement sans perte de temps et de d ebit19 [XU 02]. Pour nir cette description de 802.11 DCF, et comme on peut le voir sur la gure 1.13, 802.11 pr econise lusage de plusieurs temporisations inter-trames ; il en existe trois, de la plus courte ` a la plus longue : 1. SIFS, pour Short Inter-Frame Spacing, la plus courte, pr ec` ede toutes les trames au sein dun m eme echange, i.e. entre le RTS et le CTS, entre le CTS et les donn ees puis enn entre les donn ees et laccus e de r eception : une fois lacc` es au m edium remport e, tout l echange se fait avec des temps inter-trame prioritaires pour conserver lacc` es au m edium. Les trames emises avec un temps inter-trame SIFS seront donc les plus prioritaires, 2. PIFS, pour Point Coordination Inter-Frame Spacing, pr ec` ede les trames de polling emises par le point dacc` es en mode PCF (voir section 3.3.2), 3. DIFS, pour Distributed Inter-Frame Spacing, la plus longue, pr ec` ede les trames envoy ees en mode DCF. Comme cette dur ee inter-trame est la plus longue, on peut noter ici que les trames DCF sont moins prioritaires que les trames PCF. L` a encore, il est important de respecter ces trois temps pour conserver un acc` es au m edium equitable. Comme nous lavions enonc e en lintroduisant, la m ethode DCF propos ee par lIEEE pour 802.11 ne propose quun service de type Best Eort. En eet, m eme si le dispositif RTS/CTS permet d eviter un grand nombre de collisions20 , certaines sont in evitables, en particulier quand les deux stations pensent en m eme temps que le m edium est libre. Cette m ethode dacc` es ne pr esente donc aucune garantie, ni sur le d ebit, ni sur la latence. En cas de trac elev e, les performances du r eseau s ecroulent21 .
3.2.2
EY-NPMA (HiperLAN/1)
La m ethode dacc` es au m edium propos ee par lETSI [ETSI] pour HiperLAN/1 est le EY-NPMA3 (Elimination Yeld Non-preemptive Priority Multiple Access ). Cette technique dacc` es au m edium [APOS 96] [WEIN 97] limite les collisions en les regroupant en d ebut de trame et en les d etectant, de mani` ere ` a les eviter dans la suite de la transmission, jusqu` a la trame suivante. Lacc` es au m edium est r ealis e en trois etapes : 1. R esolution des priorit es : le m ecanisme dacc` es tente dattribuer le m edium ` a la station la plus prioritaire : cinq niveaux de priorit e sont pr evus, de 0 (le plus prioritaire) ` a 4 (le moins prioritaire). Chaque nouvelle p eriode de contention d ebute par 5 slots, un pour chaque niveau de priorit e. Une station de priorit e n na le droit de prendre la parole qu` a partir du slot n et seulement si aucune autre station plus prioritaire na pris la parole avant. 2. Phase d elimination : une station voulant prendre le m edium durant la phase de r esolution des priorit es emet alors un ot de donn ees quelconque (burst ) de dur ee al eatoire. Cette dur ee est
19 Concernant des petites trames de donn ees, le RTS/CTS constitue une perte de temps et de bande passante non n egligeable ! 20 Notamment dans le cadre dun r eseau de type infrastructure, puisque toutes stations connect ees au point dacc` es entendent forc ement le RTS ou le CTS, puisque la communication de station ` a station est impossible. 21 Bien quil ne sagisse pas dune probl ematique de niveau MAC, nous pouvons egalement relever ici laberration de 802.11 qui oblige lensemble des stations dun m eme r eseau ` a travailler avec le d ebit le plus faiblement n egoci e. En eet, si toutes les stations n egocient un d ebit de 11 Mbit/s alors quune seule station ne peut n egocier un d ebit sup erieur ` a 1 Mbit/s, lensemble du r eseau travaillera ` a 1 Mbit/s, ce qui d egrade fortement les performances de lensemble du r eseau.
37
distribu ee selon une loi de probabilit es discr` etes. Toutes les stations de priorit en emettent ce ot de donn ees quelconques. 3. Phase de capitulation : une fois cette dur ee al eatoire ecoul ee, la station passe ` a l ecoute : si aucune autre station nest en train d emettre, cela signie quelle a gagn e lacc` es au m edium. Elle peut alors emettre ses donn ees. Si une autre station est en train d emettre, elle capitule et ne transmettra pas ses donn ees pendant cette p eriode ; elle devra retenter sa chance ` a la p eriode suivante. La gure 1.14 illustre le d eroulement dun acc` es au m edium r eussi par EY-NPMA. Dans le cas illustr e, le r eseau est compos e de trois stations, dont deux ont le m eme niveau de priorit e. Au nal, dans le cas illustr e, cest la station no 1 qui remporte lacc` es au m edium. En revanche, si deux stations de m eme priorit e choisissent la m eme dur ee al eatoire, la phase de capitulation ne permettra pas de d etecter la station concurrente et une collision sera produite. La gure 1.15 illustre ce cas.
Fig. 1.14 D eroulement dun acc` es au m edium r eussi par la m ethode EY-NPMA
Fig. 1.15 D eroulement dun acc` es au m edium par la m ethode EY-NPMA ayant echou e
38
Notons cependant que cette m ethode dacc` es a un inconv enient majeur : elle ne r` egle pas le probl` eme de la station cach ee. Dans le cadre de HiperLAN/1, lETSI propose donc la mise en uvre dune m ethode dacc` es qui r` egle le probl` eme des collisions en se basant sur des grandeurs al eatoires, mais en permettant ` a certains ux ou certaines stations d etre prioritaires devant dautres. Cette notion de di erenciation de service que nous avions abord e plus haut est un premier pas vers lint egration de la Qualit e de Service dans le r eseau. Cependant, et cest l` a lobjectif de nos travaux, cette m ethode dacc` es nore aucune garantie sur le plan temporel, puisque la m ethode dacc` es nest pas d eterministe : en eet, si deux stations de m eme priorit e tirent la m eme p eriode al eatoire dans la phase d elimination, il y a collision, comme lillustre sur la gure 1.15. De plus, la non r esolution du probl` eme de la station cach e augmente consid erablement la probabilit e de collision.
3.3
Introduire de la QoS au niveau acc` es au m edium
Les m ethodes dacc` es que nous venons de pr esenter ne permettent pas de pratiquer des acc` es au m edium ` a QoS, m eme si la couche imm ediatement sup erieure le pr evoit. 802.11 DCF ne propose quun service de type Best-Eort et au mieux, HiperLAN/1, avec EY-NPMA, ne permet que de rendre prioritaire certains services par rapport ` a dautres. Mais aucune m ethode dacc` es ne propose de garantie stricte, cest ` a dire un d ebit minimal et une latence de transmission maximale. Dans cette partie, nous allons pr esenter des m ethodes dacc` es au m edium qui proposent des fonctionnalit es suppl ementaires au niveau QoS ; nous verrons egalement que toutes ont cependant des limites dans ce domaine.
3.3.1
TDMA Dynamique (HiperLAN/2)
La m ethode dacc` es au m edium propos ee pour HiperLAN/2 [ETSI 00] est le TDMA Dynamique [APOS 96]. Rappelons que HiperLAN/2 est un r eseau infrastructur e, cest ` a dire constitu e de points dacc` es (AP) qui permettent ` a des terminaux sans l dacc eder ` a un r eseau laire. Les terminaux sont associ es ` a lun des points dacc` es, lacc` es au m edium est cadenc e par lAP. Dans HiperLAN/2, les transports se font en mode connect e ; chaque demande de connexion est eectu ee par un terminal qui communique ses besoins ` a lAP. Pour ce faire, le point dacc` es divise le temps en portions appel ees supertrame . A lint erieur de la supertrame, le temps est encore divis e en quatre canaux temporels, comme illustr e par la gure 1.16 :
Fig. 1.16 La supertrame HiperLAN/2
1. canal de diusion (broadcast channel ) : il contient des informations destin ees ` a tous les terminaux comme sa puissance d emission, son identiant et lidentiant du r eseau, la structure des canaux descendant et montant (ressources accord ees), les donn ees dius ees, etc. 2. canal descendant (downlink channel ) : il contient les donn ees transport ees dans le sens point dacc` es vers stations selon la r epartition d ecrite dans le canal de diusion. Les donn ees sont d ecoup ees en PDU (Protocol Data Unit ) de 54 octets22 .
22 Ce d ecoupage permet le transport direct et natif des cellules ATM par le r eseau HiperLAN. Si c etait ` a refaire, cette d ecision ne serait peut- etre plus prise aujourdhui, car le tr` es populaire IP domine au niveau des protocoles de niveau 3. . .
39
3. canal montant (uplink channel ) : idem canal descendant mais dans le sens terminaux vers point dacc` es . Lacc` es au m edium se fait alors sans collision. 4. canal dacc` es al eatoire (random access channel ) : cette p eriode est accord ee par le point dacc` es pour que les terminaux puissent eectuer les demandes de ressources pour les trames suivantes. Dans ce cr eneau temporel, lacc` es au m edium se fait en mode al eatoire. Pour sassocier au r eseau, un terminal HiperLAN/2 doit sidentier aupr` es du point dacc` es par lenvoi dun message dans le canal dacc` es al eatoire. Une fois lacc` es accord e et la communication etablie par le point dacc` es, celui-ci accorde des slots temporels ` a ce nouveau terminal, en fonction des besoins quil a communiqu e. Le transport des donn ees se fait alors sans collision dans le canal montant. Les donn ees ` a destination des stations connect ees sont quant ` a elles transport ees dans le canal descendant. Le TDMA Dynamique propos e pour HiperLAN/2 limite donc fortement les collisions, au moins dans les phases downlink et uplink channel. Cependant, sur le plan temporel, cette m ethode dacc` es nassure pas de garantie quant ` a la latence de transmission qui impacte les donn ees transmises car la demande de connexion au r eseau est eectu ee en mode al eatoire. Nous verrons par la suite que ce d efaut est tr` es r ecurrent dans le monde des r eseaux sans l. Ce probl` eme sera dailleurs evoqu e dans le deuxi` eme chapitre pour le cas dIEEE 802.15.4. En revanche, une fois la connexion etablie, un terminal est certain dacc eder r eguli` erement au m edium, ce qui, mis ` a part la latence engendr ee par les erreurs de transmission, permet de proposer une garantie de niveau liaison sur le d ebit oert et la latence. On peut dailleurs noter ici quHiperLAN/2 applique de fait le vieux principe adopt e en t el ecommunications qui consiste ` a assurer la qualit e des communications d ej` a engag ees au d etriment d eventuelles nouvelles connexions.
3.3.2
Point Coordination Function (IEEE 802.11 PCF)
Pour palier aux lacunes de la m ethode dacc` es DCF, lIEEE a initialement pr evu une seconde m ethode dacc` es au m edium pour 802.11, la m ethode PCF (Point Coordination Function ). Elle est bas ee sur linterrogation des stations (Polling ) par une entit e sp eciale appel ee point de coordination. Ce r ole sera jou e par le point dacc` es. La m ethode dacc` es PCF permet de garantir lacc` es au m edium pour certaines stations, par exemple pour la transmission de donn ees avec contraintes temporelles et/ou de d ebit comme la t el ephonie ou la vid eo. Notons que, de par sa structure centralis ee autour du point dacc` es, la m ethode dacc` es PCF nest pas utilisable sur un r eseau de type ad hoc. Dans le cadre de la m ethode dacc` es PCF, le point de coordination orchestre les acc` es au m edium en interrogeant tour ` a tour les stations qui n ecessitent une certaine garantie dacc` es au m edium. Cette m ethode, proche de lacc` es basique de type TDMA, permet dintroduire des priorit es pour ces stations par rapport aux stations normales . Avec lacc` es PCF, le temps est divis e en supertrame, permettant une alternance cyclique entre acc` es sans contention PCF et acc` es avec contention en DCF23 . La partie avec acc` es PCF sera appel ee CFP, pour Contention Free Period, alors que la partie DCF sera la CP, pour Contention Period. Le d eroulement temporel dune CFP est illustr e gure 1.17 ; il se d eroule ainsi : 1. Au d ebut de la supertrame, le point de coordination sonde le canal. Si le canal est libre, le point de coordination attend une p eriode PIFS et transmet une trame balise , ou beacon. Cette trame marque le d ebut de la supertrame et de la p eriode dacc` es en PCF. Elle contient aussi lidentiant du r eseau (BSSID, Basic Service Set IDentier ), la p eriode des trames Beacon et la dur ee maximale de la CFP. Ces deux derni` eres donn ees vont permettre aux stations qui minimisent leur energie de couper leurs fonctions de r eception radio. 2. Ensuite, le point dacc` es interroge tour ` a tour les stations (polling ). Cette interrogation se fait par lenvoi de trames CF-Pool par le point de coordination si celui-ci na pas de donn ees ` a envoyer a cette station, ou DATA+CF-Pool si des donn ` ees du point dacc` es sont en attente pour la station
23 Une possibilit e r ecurrente dacc` es en DCF est n ecessaire pour permettre aux stations non contraintes temporellement de pouvoir acc eder au m edium sans garantie en mode Best-Eort.
40
Fig. 1.17 D eroulement temporel dune p eriode dacc` es sans contention dans le cadre de 802.11 PCF
concern ee. Le destinataire, quel quil soit, doit acquitter les donn ees par une trame CF-ACK. Si la station interrog ee doit envoyer des donn ees, elle peut le faire apr` es r eception du CF-Pool ou du DATA+CF-Pool, en r epondant respectivement par un DATA ou un DATA+ACK. Notons que tous ces echanges se font en utilisant un temps inter-trame SIFS, sauf si une station ne r epond pas ` a la trame CF-Pool. Dans ce cas pr ecis, le point de coordination reprend le m edium apr` es une dur ee PIFS pour continuer le polling. En tout etat de cause, SIFS et PIFS etant plus courts que DIFS, les tentatives dacc` es DCF pendant la CFP sont m ecaniquement di er es. 3. Pour nir, le point dacc` es envoie une trame CF-End pour indiquer la n de la p eriode sans contention et, par cons equent, le d ebut de la p eriode avec contention. De notre point vue concernant le transport dinformations ` a fortes contraintes temporelles, la m ethode dacc` es PCF pr esente un avantage sur la m ethode DCF : lacc` es au m edium des stations PCF nest pas bas e sur un algorithme al eatoire, ce qui permet dentrevoir un embryon de gestion dacc` es au m edium avec Qualit e de Service. Cependant, deux probl` emes subsistent : 1. En premier lieu, pour gurer dans la liste des noeuds interrog es, les stations doivent etre associ ees au point dacc` es. Or comme cest le cas pour beaucoup dautres technologies WLAN/WPAN, le m ecanisme dassociation ne peut etre consid er e comme d eterministe car la demande dassociation est envoy ee dans la DCF par utilisation de CSMA/CA. Si le m edium est alors surcharg e, lassociation sera impossible, m eme si le nud voulant entrer dans le r eseau a des informations critiques ` a envoyer. 2. Enn, les stations ayant souscrits ` a lacc` es PCF ne sont pas pour autant certaines dacc eder au m edium car le point dacc` es peut di erer linterrogation dune station si le temps restant avant la n de la CFP nest pas susant pour naliser la transaction avec cette station. Ainsi, le mode dacc` es PCF pr esente une trop forte caract eristique egalitaire dans la mesure o` u toutes les stations sont inlassablement interrog ees ` a tour de r ole sans di erenciation des besoins. De ce fait, le mode PCF ne permet pas denvisager de garanties fortes sur le plan temporel.
3.3.3
Enhanced DCF et Hybrid CF (IEEE 802.11e)
Nous lavons vu plus haut, la norme originale 802.11 ne propose pas doutils r eels pour la gestion de la qualit e de service. Le mode DCF ne supporte que des tracs en Best-Eort et ne propose pas doutils pour r eserver la bande passante, ni pour limiter la latence et la gigue de transmission. De plus, les Adrien van den Bossche 41
nombreuses etudes r ealis ees montrent que les performances sont fortement d egrad ees [WEI 02] lorsque le r eseau est tr` es sollicit e (nombre de nuds, transferts nombreux et consommateurs de bande passante, mod` eles de tracs di erents). Le mode PCF, bien quil propose th eoriquement quelques am eliorations, ne permet cependant pas de garantir ni le d ebit ni une latence de transmission puisque le m ecanisme de souscription ` a linterrogation r eguli` ere est r ealis e en mode al eatoire et les interrogations, bien quelles restent egalitaires, peuvent etre di er ees dans le temps. Dans le but dintroduire une vraie QoS au niveau MAC, un groupe de discussion (TG11e) a et e mis en place par lIEEE. Ce groupe a propos e un amendement [IEE1 05] au standard de base IEEE 802.11 qui a et e valid e en juillet 2005. 802.11e pr evoit deux m ecanismes pour la gestion de la Qualit e de Service dans 802.11 : Enhanced DCF et Hybrid CF [YU 04].
3.3.3.1
Enhanced DCF
Enhanced DCF (EDCF), parfois d esign e par Enhanced DCF Channel Access (EDCA) propose une am elioration de loriginal DCF en introduisant 8 classes de trac. En interfa cant nement lEDCF avec les couches sup erieures, les tracs n ecessitant des limites de latence et/ou de d ebits (vid eo, t el ephonie) peuvent etre rendus prioritaires. EDCF permet donc de r ealiser une di erenciation de services au niveau MAC. Pour la r ealiser, le groupe de travail 802.11e propose dune part dintervenir sur les temps intertrames et dautre part sur plusieurs instances pour la gestion des fen etres de contention (CW) : Temps inter-trames : SIFS, PIFS et DIFS sont conserv es, mais une nouvelle dur ee inter-trame de valeur variable et proportionnelle ` a chaque classe et sup erieure ` a DIFS, est introduite : AIFS pour Arbitration Inter Frame Space. Fen etres de contention : nous avons vu plus haut que les fen etres de contention al eatoires permettent de d esynchroniser les acc` es au m edium concurrents pour limiter le ph enom` ene des collisions. Nous avons egalement vu que si une station ne remporte pas lacc` es au m edium, elle conserve sa valeur restant ` a courir de CW pour avoir plus de chance de le remporter ` a la tentative suivante. Avec le syst` eme de classe de tracs, 802.11e propose de g erer plusieurs instances de cette fen etre de contention pour chaque trac. Lusage de ces deux nouvelles fonctionnalit es permet de consid erer jusqu` a 8 stations virtuelles, au sein dune m eme station physique ; chaque station virtuelle poss` ede sa propre FIFO pour les donn ees, son AIFS et sa propre instance de CW et chaque station virtuelle est g er ee ind ependamment des autres. De plus, chaque niveau de priorit e est associ e` a une valeur d esign ee par opportunit e de transmission (Transmit Opportunity, TXOP). TXOP d enit un intervalle de temps pendant lequel une station peut conserver lacc` es au m edium et envoyer autant de trames quelle le souhaite. Lintroduction de TXOP permet de mieux r epartir les acc` es au m edium ; dans le cadre de 802.11 DCF, les stations n ecessitant un acc` es bas d ebit etaient favoris ees par rapport ` a celles n ecessitant un haut d ebit. EDCF permet donc dintroduire des niveaux de priorit es (di erenciation de services) au niveau MAC [GARC 02], un peu comme le permettait la m ethode dacc` es au m edium EY-NPMA utilis ee dans HiperLAN/1. Il permet donc ` a certains tracs d etre plus prioritaires que dautres [CHOI 03] ; en revanche, aucune garantie nest possible et les tracs peuvent toujours entrer en collision.
3.3.3.2
Hybrid CF
Hybrid CF (HCF), parfois d esign e par Hybrid CF Channel Access (HCCA) propose une gestion de lacc` es au m edium orient ee d eterminisme qui am eliore le PCF initial de 802.11 en le rendant plus souple. Le probl` eme majeur du PCF est que les derni` eres stations interrog ees par le point dacc` es pouvaient voir leur interrogation di er ee ` a la supertrame suivante. Avec 802.11 PCF, la limite entre zone sans 42 Groupe SCSF LATTIS EA4155
contention (CFP) et zone avec contention (CP) est x ee davance par le Point de Coordination (le point dacc` es) et annonc ee dans le beacon, alors que la dur ee dinterrogation des stations est variable ; de ce fait, si les premi` eres stations interrog ees utilisent copieusement le m edium, il ne restera pas assez de temps pour les derni` eres et lacc` es au m edium leur sera di er e. Dans le cadre de 802.11e [IEE1 05], HCF cette limite entre CFP et CP est variable, le Point de Coordination pouvant d ecider de rajouter du temps ` a la CFP pour permettre linterrogation de toutes les stations.
3.3.3.3
Autres am eliorations
802.11e propose quelques am eliorations suppl ementaires evoqu ees ici ` a titre indicatif : Automatic Power Save Delivery (APSD) est une am elioration signicative de la gestion energ etique dans 802.11. Il permet ` a un point dacc` es de tamponner les donn ees ` a destination dun nud endormi jusqu` a ce que ce nud signale son r eveil en transmettant une trame de donn ees. D` es que le point dacc` es re coit la trame, il renvoie les donn ees en attente. APSD est ecace si la bande passante utilis ee est sym etrique, ce qui est le cas des applications de t el ephonie IP pour lesquelles il a et e con cu. Block Acknowledgments (BA) permet au destinataire dacquitter toutes les trames dun TXOP par un seul acquittement. BA permet la r eduction de loverhead 24 provoqu e par des acquittements multiples. NoAck permet la mise en place de classes de services avec lesquels les messages transmis ne sont pas acquitt es. Cette am elioration permet d eviter la retransmission inutile de donn ees ` a haute criticit e temporelle. Direct Link Setup (DLS), ou Direct Link Protocol (DLP) permet lenvoi direct de donn ees de station ` a station dun m eme BSS ; cette fonctionnalit e permet en fait lenvoi de messages dans un pseudo mode ad hoc, cest-` a-dire sans passer par le point dacc` es, ce qui permet de multiplier par pr` es de deux la bande passante dans le cas dun transfert de station ` a station.
3.3.4
Bluetooth
De part lutilisation de l etalement de spectre par sauts de fr equence (FHSS), Bluetooth impose un fonctionnement en ma tre/esclave au niveau des couches physique et liaison de donn ees, comme cela a et e evoqu e dans le paragraphe 1.5.3. De ce fait, la m ethode dacc` es est naturellement proche de TDMA o` u le ma tre, el ement central, distribue les temps de parole sur le m edium. A ce titre, Bluetooth propose plusieurs m ethodes dutilisation du m edium dont les deux principaux sont des liens ACL (asynchrones, orient es donn ees ) et SCO (synchrones, orient es voix ). Les liens SCO proposent un d ebit xe de 64 kbits/s avec un d elai dacheminement minimal gr ace a une absence dacquittement. En contrepartie, m ` eme si les liens SCO peuvent mettre en uvre une certaine redondance des donn ees par lemploi de FEC (Forward Error Correction ), les liens SCO ne sont pas ables dans la mesure o` u, m eme si une trame est d etect ee comme erron ee par le r ecepteur, elle ne fera pas lobjet dune retransmission. Typiquement, les liens SCO sont d edi es au transport de la voix o` u la pr esence dun echantillon erron e provoque une sensation moins d esagr eable ` a loreille quun retard.
24 Loverhead est le volume de donn ees utile (part du d ebit oert) perdu car utilis e dans les en-t etes et les messages de gestion du r eseau (acquittements, etc.).
43
En revanche, les liens ACL permettent la abilit e mais sont sujets ` a une gigue de transmission importante, ` a cause des retransmissions. Les liens ACL sont typiquement d edi es au transport de donn ees n ecessitant une abilit e certaine mais non contraintes temporellement. De part leur structure intrins` eque, les liens SCO sont tr` es adapt es aux transports ` a fortes contraintes temporelles. Cependant, les sp ecications Bluetooth ne pr evoyant aucune autre application que le transport de la voix pour les liens SCO, les donn ees num eriques empruntant des liens SCO sont cod es selon des lois A ou par des CODECS internes et sont dicilement exploitables pour dautres applications. De plus, le d ebit g e de 64 kbits/s, qui plus est sym etrique, restreint consid erablement les applications potentielles. Des travaux ont n eanmoins et e entrepris pour utiliser les liens SCO pour le transport de donn ees de capteurs [ELHO 04]. En revanche, on trouve dans la litt erature [VAND 01] [MERC 03] des travaux evoquant des fonctionnalit es de gestion de la Qualit e de Service sur les liens ACL de Bluetooth. D` es la premi` ere version de la norme [IEE1 02], des param` etres ont et e pr evus au niveau L2CAP3 : Type de service : Best Eort ou Guaranteed, active ou d esactive la gestion de la QoS, Token Rate permet de sp ecier le d ebit moyen (en octets/seconde), Token Bucket Size sp ecie la taille maximale dune raale de donn ees (en octets), Peak Bandwidth sp ecie le d ebit maximum autoris e (en octets/seconde), Latancy sp ecie le d elai maximum tol erable pour lapplication entre le moment o` u les donn ees sont re cues par le modem et le d ebut de la transmission eective sur radio (en millisecondes), Delay variation sp ecie la di erence entre le minimum et le maximum du d elai tol erable par lapplication. Dapr` es la pr esentation de ces param` etres propos es par le standard, Bluetooth appara t comme la technologie WLAN/WPAN la plus aboutie en mati` ere de gestion de la Qualit e de Service au niveau de la m ethode dacc` es au m edium. Malheureusement, encore aujourdhui, il est impossible de trouver un module impl ementant toutes ces fonctionnalit es sur le march e. Il semblerait que, comme dans le cas de 802.11 avec le mode PCF, les industriels ne parviennent pas ` a trouver un march e grand-public pour ces protocoles proposant des fonctionnalit es evolu ees et se contentent de commercialiser des equipements ne proposant que les fonctionnalit es basiques des normes et des protocoles.
Conclusion
Dans ce chapitre, nous avons pu constater quil existe un large choix en mati` ere de technologies WLAN/WPAN. Les normes et les produits sont nombreux ; certains pr esentent des fonctionnalit es originales et int eressantes, dautres proposent des services comparables et equivalents, mais tous permettent de rendre tr` es abordable une technologie electronique de pointe (tr` es hautes fr equences, micro electronique complexe) par le grand public. L etude sur les protocoles de Qualit e de Service de niveau r eseau, tr` es r epandus dans le monde IP, nous a permis de conclure sur la r eelle n ecessit e de penser la QoS au niveau 2 lorsque lon envisage de d eployer un protocole ` a QoS de niveau 3 et sup erieurs. En eet, bien que le m edium de transmission ne soit pas parfait et que, par cons equent, on constate toujours des erreurs au niveau de la couche physique (BER=0), il est absolument n ecessaire de limiter les pertes dinformations dans les niveaux sup erieurs lorsque les bits, au niveau physique, sont transmis correctement, a fortiori lorsque le m edium pr esente une faible abilit e comme en sans l. Nous avons vu quil existe de nombreuses techniques dacc` es au m edium mais que peu proposent des fonctionnalit es pour eviter totalement le ph enom` ene des collisions, premi` ere source de pertes de donn ees au dessus du niveau physique. Si certaines m ethodes comme le TDMA Dynamique dHiperLAN/2, le PCF de 802.11 ou le HCF de 802.11e permettent de garantir un acc` es r egulier au m edium sans collision, aucune de ces technologies ne propose une m ethode permettant un acc` es totalement d eterministe au m edium, avec des garanties sur le plan temporel. Dans le chapitre suivant, nous pr esenterons la technologie IEEE 44 Groupe SCSF LATTIS EA4155
Conclusion
802.15.4 qui propose des fonctionnalit es int eressantes sur ce point. M eme si la gestion de la QoS dans 802.15.4 nest pas parfaite, les produits compatibles sont disponibles et permettent une reprogrammation partielle ou totale de la couche MAC, laissant entrevoir des possibilit es de prototypage int eressantes.
45
46
Bibliographie du chapitre 1
[APOS 96] C. Apostolas, R. Tafazolli et B.G. Evans Comparison between elimination yield non pre-emptive prioritymultiple access (EY-NPMA) and dynamic TDMA (D-TDMA) 7th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRCapos96) vol 2, issue 15-18 Oct 1996 pp 663-667 (1996) [ARCE] Le site web de lARCEP (Autorit e de R egulation des Communications Electroniques et des Postes) http ://www.arcep.fr [BADI 04] H. Badis et K. Al Agha QOLSR Multi-path Routing for Mobile Ad Hoc Networks Based on Multiple Metrics 59th IEEE Vehicular Technology Conference (IEEE VTC04-Spring), Milan, Italie (Mai 2004) [BOUZ 03] A. Bouzoualegh, T. Val, F. Peyrard et E. Campo Study of the Characteristics Needed for Underwater Acoustic Networks 7th WSEAS International Conference on Circuits, Systems, Communications and Computers (CSCC2003), Corfu, Grece (Juillet 2003) [CAPP 02] Communaut e dagglom eration Pau Pyr en ees Pau Broadband Country (large bande pour tous) Dossier de pr esentation (F evrier 2002) [CHIC 05] O. Chicheportiche Airbus passe ` a la VoIP avec France T el ecom http ://www.silicon.fr/fr/silicon/news/2005/07/12/airbus-passe-voip-france-telecom
[CHOI 03] S. Choi, J. del Prado, S. Shankar et S. Mangold IEEE 802.11e Contention-Based Channel Access (EDCF) Performance Evaluation IEEE International Conference on Communications (ICC03) vol.2, pp 1151-1156 (Mai 2003) [CULL 04] D. Culler, D. Estrin et M. Srivastava Overview of Sensor Networks IEEE Computer vol.37, issue 8 (Ao ut 2004) [DESG 03] G. Desgeorges R eseaux haut d ebit et r eseaux sans l Cours ding enieur ESEO, sp ecialit e R&T (2003) [ELHO 04] S. El Homsi, E. Campo, T. Val et J.J. Mercier Utilisation de la technologie Bluetooth pour la transmission de donn ees num eriques dans les applications ` a contraintes temporelles vari ees Congr` es des doctorants de lEcole Doctorale de G enie Electrique, Electronique et T el ecommunications (GEET), Supaero, Toulouse (Mars 2004) [ETS1 06] ETSI Project Broadband Radio Access Networks Broadband Radio Access Networks (BRAN) : HiperMAN Physical (PHY) Layer ETSI Technical Specication ETSI TS 102 177 V1.3.1 (F evrier 2006) [ETS2 06] ETSI Project Broadband Radio Access Networks Broadband Radio Access Networks (BRAN) : HiperMAN Data Link Control (DLC) Layer ETSI Technical Specication ETSI TS 102 178 V1.3.2 (Mars 2006) [ETSI 00] ETSI Project Broadband Radio Access Networks Broadband Radio Access Networks (BRAN) : HiperLAN Type 2 System Overview ETSI Technical report ETSI TR 101 683 V1.1.1 (F evrier 2000) [ETSI] Le site web de lETSI (European Telecommunications Standards Institute ) http ://www.etsi.org [FON] Le mouvement Fon http ://www.fon.com
BIBLIOGRAPHIE DU CHAPITRE 1
[GARC 02] J.A. Garc a-Mac as, F. Rousseau, G. Berger-Sabbatel, L. Toumi et A. Duda Di erenciation des services sur les r eseaux sans-l 802.11 9ieme Colloque Francophone sur lIng enierie des Protocoles (CFIP2002), Montr eal, Quebec (Mai 2002) [GOLD 01] M. Goldhammer ETSI BRAN HiperMAN Liaison Report 2001-11-08 [LANS 99] J. Lansford HomeRF : Bringing Wireless Connectivity Home Intel HomeRF technology Tutorial (Avril 1999) [HOWE 87] D.A. Howe Ku-band Satellite Two-Way Timing Using a Very Small Aperture Terminal (VSAT) 41st Annual Symposium on Frequency Control pp 149-160 (1987) [HOYM 01] C. Hoymann, M. P uttner et I. Forkel The HiperMAN Standard - a Performance Analysis [IEE1 02] LAN-MAN Standards Committee of the IEEE Computer Society 802.15.1 IEEE Standard for Information technology, Part 15.1 : Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specications for Wireless Personal Area Networks (WPANS) IEEE Std 802.15.12002 (2002) [IEE1 03] LAN-MAN Standards Committee of the IEEE Computer Society 802.15.3 IEEE Standard for Information technology, specic requirements part 15.3 : Wireless Medium Access Control (MAC) and Physical Layer (PHY) specications for high rate wireless personal area networks (WPANs) IEEE Std 802.15.3-2003 (2003) [IEE1 04] IEEE Computer Society and IEEE Microwave Theory and Techniques Society 802.16 IEEE Standard for Local and metropolitan area networks part 16 : Air Interface for Fixed Broadband Wireless Access Systems IEEE Std 802.16-2004 (Octobre 2004) [IEE1 05] LAN-MAN Standards Committee of the IEEE Computer Society 802.11 IEEE Standard for Information technology, Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Amendment : Medium Access Control (MAC) Quality of Service (QoS) Enhancements IEEE (2005) [IEE1 99] LAN-MAN Standards Committee of the IEEE Computer Society 802.11 IEEE Standard for Information technology, Specic Requirements Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications IEEE standard 8802-11 (1999) [IEE2 03] LAN-MAN Standards Committee of the IEEE Computer Society 802.15.4 IEEE Standard for Information technology, Part 15.4 : Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specications for Low-Rate Wireless Personal Area Networks (LR-WPANs) IEEEStd 802.15.4-2003 (2003) [IEEE] Le site web du comit e de standardisation IEEE 802 (IEEE 802 LAN/MAN Standards Committee ) http ://www.ieee802.org [IRDA] Le site web de IrDA (Infrared Data Association ) http ://irda.org [LEPA 91] F. Lepage Les R eseaux Locaux Industriels - Principes illustr es par des exemples Hermes (1991) [MERC 03] A. Mercier, P. Minet et L. Georges Introducing QoS support in Bluetooth Piconetwith a Class-Based EDF Scheduling Rapport de recherche de lINRIA RR-5054 (D ecembre 2003) [MICH 05] F. Michaut et F. Lepage Adaptation des applications distribu ees ` a la qualit e de service du r eseau de communication Ecole d et e temps r eel 2005 (ETR05) Nancy, France (Septembre 2005) [MUHL 02] P. Muhlethaler 802.11 et les r eseaux sans l Eyrolles (2002) [NIC1 98] K. Nichols, S. Blake, F. Baker et D. Black Denition of the Dierentiated Services Field (DS Field) in the IPv4 and IPv6 Headers RFC 2474, IETF Network Working Group (Decembre 1998) [NIC2 98] K. Nichols, S. Blake, F. Baker et D. Black An Architecture for Dierentiated Service RFC 2475, IETF Network Working Group (Decembre 1998) [PUJO 95] G. Pujolle Les r eseaux Eyrolles (1995) [RAN] Le web ring des RAN (Rural Area Network ) http ://ran.vaour.net/webring 48 Groupe SCSF LATTIS EA4155
[SIMP 05] D. Simplot-Ryl Real-time aspects in Wireless Sensor Networks Ecole dEt e Temps R eel 2005 (ETR05), Nancy, France (Septembre 2005) [SMER 04] S.A. Smerzi, G. Girlando, T. Copani et G. Palmisano A Ku-band monolithic receiver for DVB-S applications IEEE Communications Magazine, vol.42 issue 8, pp 132-139 (Ao ut 2004) [TSF] Le site web de lassociation Toulouse Sans Fil http ://www.toulouse-sans-l.net [VAND 01] M. van der Zee et G. Heijenk Quality of Service in Bluetooth Networking 10/0362FCP NB 102 88 Uen (Janvier 2001) [WEI 02] A. Wei et S. Boumerdassi Support de la QoS dans les r eseaux 802.11 Rapport scientique CEDRIC No 401 (2002) [WEIN 97] J. Weinmiller, M. Schl ager, A. Festag et A. Wolisz Performance Study of Access Control in Wireless LANs - IEEE 802.11 DFWMAC and ETSI RES 10 HiperLAN Mobile Networks and Applications, vol.2, pp 55-67 (1997) [WROC 97] J. Wroclawski The Use of RSVP with IETF Integrated Services RFC 2210, IETF Network Working Group (Septembre 1997) [XU 02] K. Xu, M. Gerla et S. Bae How eective is the IEEE 802.11 RTS/CTS handshake in ad hoc networks IEEE Global Telecommunications Conference (GLOBECOM02) vol.1, pp 72-76 (Novembre 2002) [YU 04] J. Yu IEEE 802.11e QoS for Wireless LAN : A Research Direction Multimedia Networking Research Laboratory (MNLAB) Networking Seminar (D ecembre 2003)
49
50
Chapitre 2
Pr esentation des normes IEEE 802.15.4 / ZigBee

Ce chapitre pr esente les normes et sp ecications des technologies r eseaux personnels sans l IEEE 802.15.4 et ZigBee sur lesquelles sont bas es les travaux eectu es durant la th` ese. Nous verrons dans ce chapitre que ces deux technologies sont intimement li ees, mais aussi quelles pr esentent certaines failles que nous proposerons de r esoudre par la suite, dans le chapitre 3.
G en eralit es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Le projet ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Objectifs et domaine dapplication . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Consommation energ etique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Impl ementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Topologie etoile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Topologie point ` a point . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 Topologies plus complexes . . . . . . . . . . . . . . . . . . . . . . . 1.6 Adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 Valeurs typiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pr esentation de la pile protocolaire ZigBee . . . . . . . . . . . . . . . . . . 2.1 Quelques notions fondamentales . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Le d ecoupage en di erentes couches . . . . . . . . . . . . . . . . . . 2.1.2 Le principe de lencapsulation . . . . . . . . . . . . . . . . . . . . . 2.1.3 Protocole d echange entre deux couches voisines . . . . . . . . . . . 2.1.4 Repr esentation de la pile protocolaire ZigBee . . . . . . . . . . . . . 2.1.5 Les interfaces de communication entre couches . . . . . . . . . . . . 2.2 La couche Physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Bandes de fr equences et canaux . . . . . . . . . . . . . . . . . . . . 2.2.2 Modulations, etalement de spectre . . . . . . . . . . . . . . . . . . . 2.2.3 Port ee, puissance d emission et sensibilit e du r ecepteur . . . . . . . 2.2.4 Le paquet de niveau physique . . . . . . . . . . . . . . . . . . . . . 2.2.5 Services rendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 La couche Liaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 La sous-couche MAC . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1.1 Types dacc` es au m edium . . . . . . . . . . . . . . . . . . . 2.3.1.2 Notion de supertrame . . . . . . . . . . . . . . . . . . . . . 2.3.2 La sous-couche LLC . . . . . . . . . . . . . . . . . . . . . . . . . . .
53 53 53 53 54 55 55 55 55 56 56 56 56 57 57 58 59 59 60 60 61 61 62 63 63 63 63 65 66
CHAPITRE 2. PRESENTATION DES NORMES IEEE 802.15.4 / ZIGBEE
Structures de trames . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3.1 Le champ de contr ole de trame . . . . . . . . . . . . . . . . 2.3.3.2 Le champ de num ero de s equence . . . . . . . . . . . . . . 2.3.3.3 Le champ dadressage . . . . . . . . . . . . . . . . . . . . . 2.3.3.4 Le champ payload . . . . . . . . . . . . . . . . . . . . . . . 2.3.3.5 Le champ FCS . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 La couche R eseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ements de la topologie du r 2.4.1 El eseau . . . . . . . . . . . . . . . . . . . 2.4.1.1 Topologie en arbre . . . . . . . . . . . . . . . . . . . . . . . 2.4.1.2 Topologie maill ee . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Architecture de la couche r eseau . . . . . . . . . . . . . . . . . . . . 2.4.3 Services rendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4.1 Adressage NHLE-based . . . . . . . . . . . . . . . . . . . . 2.4.4.2 Adressage en arbre . . . . . . . . . . . . . . . . . . . . . . . 2.4.5 Principes de base du routage ZigBee . . . . . . . . . . . . . . . . . . 2.4.5.1 Algorithme de routage ` a la demande . . . . . . . . . . . . . 2.4.5.2 Algorithme de routage hi erarchique : Tree Routing . . . . . 2.4.6 Ordonnancement des beacons dans un r eseau avec arborescence . . 2.4.7 Structure du paquet de niveau r eseau . . . . . . . . . . . . . . . . . Identication des failles dans la m ethode dacc` es propos ee par le standard 3.1 La gestion des slots garantis ne pr esente pas une garantie absolue . . . . . . . 3.2 Autres probl` emes identi es . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Conclusion : les am eliorations propos ees . . . . . . . . . . . . . . . . . . . . .
2.3.3
67 67 68 68 68 69 70 70 70 72 72 73 73 73 73 74 75 75 76 76 77 77 78 79
52
G en eralit es
G en eralit es
ZigBee est une technologie de r eseau sans l personnel (WPAN3 ) destin ee ` a l electronique embarqu ee a tr` ` es faible consommation energ etique. Elle propose une pile protocolaire propri etaire et l eg` ere, d eclinable dans plusieurs versions plus ou moins compl` etes, pour des applications de transferts de donn ees ` a faibles d ebits et de faibles taux dutilisation du m edium.
1.1
Le projet ZigBee
Lid ee initiale du projet ZigBee date de 1998 ; une premi` ere proposition (v0.1) a et e pr esent ee courant 2000 puis rapidement une seconde (v0.2) a ` la n de la m eme ann ee. Apr` es une soumission ` a lIEEE mi 2001, la ZigBee Alliance [ZBAL] a et e cr e ee pour d evelopper et promouvoir la norme. La production de modules compatibles f ut alors pr evue et les premiers produits (puces radio, piles protocolaires, modules int egr es, kits de d eveloppement, etc.) sont apparus et sont disponibles depuis la n de lann ee 2004. ZigBee sappuie sur la norme IEEE 802.15.4 [IEE2 03] [CALL 02] (que nous d esignerons par la suite par 802.15.4 ) pour les couches physique et liaison, qui sont les couches 1 et 2 du mod` ele OSI (cf. la gure 2.6). ZigBee propose ensuite ses propres couches sup erieures (r eseau, etc.) qui doivent faire lobjet dune demande aupr` es de la ZigBee Alliance pour etre utilis ees. A ce titre, des droits sont per cus par la ZigBee Alliance pour tout emploi dune pile ZigBee dans le cadre dune application industrielle.
1.2
Objectifs et domaine dapplication
ZigBee est un LP-WPAN3 : cest un r eseau sans l ` a courte port ee qui utilise les ondes hertziennes pour transporter des messages entre deux ou plusieurs entit es r eseaux. Il est caract eris e par une port ee comprise entre quelques m` etres et quelques centaines de m` etres et un d ebit faible (max. 250kbits/s). La di erence entre ZigBee et la plupart des autres WPAN existants se situe au niveau de lutilisation du m edium hertzien ; ZigBee est optimis e pour une faible utilisation du m edium partag e par tous, par exemple 0.1% du temps [ZHEN 04]. Typiquement, un module ZigBee occupera le m edium pendant quelques millisecondes en emission, attendra eventuellement une r eponse ou un acquittement, puis se mettra en veille pendant une longue p eriode avant l emission suivante, qui aura lieu ` a un instant pr ed etermin e. Cette n ecessit e introduit des probl ematiques de recherche int eressantes, notamment au niveau des couches Liaison (temporisation et stockage des messages, acc` es original au m edium) et R eseau (routage avec respect de contraintes energ etiques). ZigBee est con cu pour interconnecter des unit es embarqu ees autonomes comme des capteurs/actionneurs, ` a des unit es de contr ole ou de commande. De telles entit es embarqu ees pouvant d` es lors etre aliment ees pendant plusieurs mois par des piles standards.
1.3
Consommation energ etique
Le point fort de ZigBee est sa tr` es faible consommation energ etique, gr ace ` a un mode de fonctionnement appel e doze ou somnolence. Ce mode permet ` a une entit e communicante ZigBee de consommer tr` es peu d energie (100W) tout en permettant de passer en mode op erationnel en tr` es peu de temps (300 s, cf. tableau 2.1), contrairement ` a dautres WPAN comme Bluetooth par exemple [VDB1 05] [KHOU 05]. Bien que les progr` es de l electronique en terme de consommation energ etique soient sensibles ces derniers temps (possibilit es accrues et rapides de mise en veille, baisse signicative des courants de fuites dans le silicium, etc.), les bonnes performances de ZigBee sur ce plan sont essentiellement dues au mode somnolence, qui implique par cons equent une faible utilisation protocolaire du m edium. Un Adrien van den Bossche 53
r eseau ZigBee utilis e en continu, par exemple pour une application de type streaming audio consommera autant d energie que tout r eseau sans l classique, ` a puissance d emission et d ebit equivalents. A titre dexemple, la consommation energ etique dun modem ZigBee type fabriqu e par Freescale [FRE1 04] est donn ee dans le tableau 2.1. Le modem consid er e est le MC13192 [FRE2 04] [FRE3 04]. Notons que le mode de fonctionnement normal du module est le mode repos, et de ce fait, les temps de basculement sont donn es par rapport ` a cet etat de r ef erence.
Tab. 2.1 Consommation typique dun modem 802.15.4 avec temps de basculement entre chaque etat (source Freescale)
Fig. 2.1 Graphe des etats dun modem 802.15.4 (source Freescale)
1.4
Impl ementations
La technologie ZigBee pr evoit deux types dentit es : 1. les entit es compl` etes, ou FFD3 , 2. les entit es r eduites, ou RFD3 . Les FFD impl ementent la totalit e de la sp ecication ZigBee alors que les RFD sont des entit es all eg ees dans un objectif de moindre consommation energ etique et de moindre utilisation m emoire pour le micro-contr oleur. Les entit es RFD sont n ecessairement des nuds terminaux du r eseau ; un tel nud ne saura pas router un paquet sur le r eseau. Typiquement, un capteur embarqu e sera RFD et aliment e sur batteries, alors quune unit e centrale de traitement, aliment ee par une source non contrainte energ etiquement main powered , sera FFD avec une fonction de coordination du r eseau, comme nous verrons dans le paragraphe suivant. 54 Groupe SCSF LATTIS EA4155
G en eralit es
1.5
Topologies
Selon les besoins de lapplication, la norme IEEE 802.15.4 pr evoit deux topologies : etoile (star ) ou point ` a point (peer to peer ). Le r eseau form e est appel e PAN3 . Ces deux topologies sont repr esent ees en gures 2.2 et 2.3. Au dessus de 802.15.4, la couche r eseau de ZigBee permet la cr eation de r eseaux plus complexes comme les r eseaux maill es (mesh ) ou arborescents (tree ) gr ace ` a un routage automatique des paquets de niveau 3 (niveau r eseau ).
1.5.1
Topologie etoile
Dans la topologie etoile, les entit es RFD sont connect ees ` a un nud FFD central appel e coordinateur 1 ; dans cette topologie, tous les messages sont relay es par le coordinateur, comme dans un Piconet Bluetooth avec le ma tre ou dans un r eseau WiFi en mode infrastructure avec le point dacc` es. Les communications directes entre entit es RFD sont impossibles. Notons que le r ole central du coordinateur implique de plus fortes d epenses energ etiques ; un coordinateur devra donc g en eralement pr evoir une source dalimentation non contrainte (batteries cons equentes, secteur) [LLI2 06].
Fig. 2.2 Repr esentation de la topologie en etoile
1.5.2
Topologie point ` a point
Dans la topologie point ` a point (peer-to-peer ), un FFD peut communiquer directement avec tout autre FFD si ils sont ` a port ee radio lun de lautre. Dans cette topologie, on retrouve un coordinateur unique comme dans la topologie etoile. Son r ole est de tenir ` a jour une liste des participants au r eseau et de distribuer les adresses courtes (cf. paragraphe 1.6 de ce chapitre).
Fig. 2.3 Repr esentation de la topologie point ` a point
1.5.3
Topologies plus complexes
Avec laide dune couche r eseau et dun syst` eme de routage des paquets de donn ees, il est possible d elaborer des topologies plus complexes. La technologie ZigBee propose une couche r eseau permettant de cr eer facilement de telles topologies gr ace ` a des algorithmes de routage automatique tels que le cluster
1 Dans
la litt erature, on retrouve egalement la d enomination contr oleur primaire du r eseau.
55
tree (arborescence de cellules) ou les r eseaux maill es mesh. Nous aborderons ces techniques plus loin dans cette th` ese, dans la partie consacr ee ` a la couche r eseau (cf. paragraphe 2.4 de ce chapitre, page 70).
1.6
Adressage
Toute entit e 802.15.4 poss` ede une adresse unique appel ee adresse MAC 3 . A la di erence de 802.3, une adresse MAC 802.15.4 a une longueur de 64 bits, soit 8 octets, contre 6 dans 802.3 ou 802.11. Dans 802.15.4, cette adresse est egalement appel ee adresse etendue. Elle peut etre utilis ee dans les dialogues au sein du PAN, mais une seconde adresse appel ee adresse courte, sur 16 bits, sera pr ef er ee dans la plupart des cas compte tenu des d ebits de transmission, relativement faibles. Ladresse courte est attribu ee par le coordinateur du PAN au moment de lassociation au r eseau. La norme 802.15.4 ne pr evoit pas de r` egle pour le choix de ces adresses, cette t ache est laiss ee au libre arbitre des couches sup erieures. Nous verrons plus loin que dans la sp ecication de sa couche r eseau, ZigBee propose un algorithme de distribution dadresses automatique et d ecentralis e. Notons dores et d ej` a que ZigBee propose lutilisation dun adressage commun pour les couches 2 et 3, mais, ` a la di erence dautres protocoles comme IPv6, cest la couche 3 qui impose son adresse ` a la couche 2.
1.7
Valeurs typiques
Pour conclure cette partie sur les g en eralit es des deux normes, voici en r esum e les valeurs typiques caract erisant IEEE 802.15.4 et ZigBee : D ebit : 250 kbits/s sur le m edium physique pour PHY2450, Puissance d emission typique : entre 0 et 3 dBm, Port ee radio : quelques centaines de m` etre en espace libre, Consommation energ etique du composant d emission / r eception (hors traitement CPU) : 3 A en hibernation (hibernate mode ), 40 A en somnolence (doze mode ), 1 mA au repos (idle mode ), 30 mA en emission, 40 mA en r eception. Taille de la pile protocolaire (code + m emoire) : inf erieure ` a 20 ko pour une entit e r eduite (RFD), entre 40 ` a 60 ko pour une pile compl` ete (FFD). Nombre dentit es connectables au r eseau : 256 dans une etoile (28 ), 65536 dans un PAN maill e (216 ), 18446744073709551616 adresses MAC disponibles (264 ) Acc` es au m edium : pur CSMA/CA3 (sans RTS/CTS3 ) ou organis e (mode balis e avec slots d edi es), D etection / correction derreurs : FCS3 16 bits dans la trame MAC.
2
2.1
Pr esentation de la pile protocolaire ZigBee

Quelques notions fondamentales
Comme la plupart des technologies r eseaux, lensemble des protocoles d ecrits par la norme ZigBee est repr esentable sous la forme dune pile protocolaire d ecoup ee en plusieurs couches. Ce d ecoupage permet de s eparer clairement les di erentes t aches ; lidentication des sp ecialit es des di erents acteurs et des di erents m etiers de la conception r eseau est ainsi rendue plus claire. 56 Groupe SCSF LATTIS EA4155
2.1.1
Le d ecoupage en di erentes couches
La pile propos ee par lIEEE et la ZigBee Alliance suit les recommandations de lISO en terme de s eparation des r oles attribu es aux di erentes couches. Comme cela a et e dit pr ec edemment, cette pile reprend les couches 1 et 2 normalis ees dans la norme 802.15.4 et ajoute ses propres couches sup erieures. La couche 1 (couche physique) d ecrit les caract eristiques de linterface radio (fr equences, largeur de bande, modulation, d ebit binaire, etc.) ; la couche 2 (couche liaison) d ecrit les caract eristiques de la souscouche MAC (gestion des acc` es au m edium) et la sous-couche SSCS3 (formation de trame, convergence des donn ees) ; la couche 3 (couche r eseau) d ecrit le processus de routage des donn ees sur le r eseau ; enn, la couche la plus haute (couche application) d ecrit le syst` eme elabor e de prols, ` a linstar de Bluetooth ou IrDA (comme vu dans le chapitre 1), qui permet la normalisation du niveau application directement dans la pile protocolaire, au m eme titre que les couches basses. Une description plus pr ecise du r ole et des caract eristiques de chaque couche est faite dans les sections suivantes.
2.1.2
Le principe de lencapsulation
Rappelons tout dabord le principe g en erique de lencapsulation : lorsque deux entit es dune m eme couche s echangent des messages, les donn ees sont de fait v ehicul ees par les couches inf erieures. Les couches les plus hautes auront g en eralement une bonne connaissance de la raison de la communication, mais une pi` etre id ee de ce qui se passe r eellement sur le m edium (le chemin emprunt e par linformation, etc.). A loppos e, les couches les plus basses auront une connaissance tr` es pr ecise sur la mani` ere dont les donn ees sont g er ees et transport ees, mais tr` es peu dinformations sur le contenu r eel et ce quelles repr esentent. Cependant, cest le syst` eme dans son ensemble qui va permettre de transmettre des informations de mani` ere able sur un r eseau etendu et h et erog` ene. Le r ole dun r eseau est bel et bien de transmettre des donn ees ; les donn ees que re coit une couche N par la couche N+1 sont appel ees les donn ees de service. On parlera dune unit e de donn ees de service, ou SDU3 , pour d esigner un ensemble de donn ees pass ees par la couche sup erieure. Lorsquune couche veut transmettre un message, elle le transmet ` a la couche imm ediatement inf erieure en y ajoutant des informations que son homologue, lentit e de m eme couche ` a lautre bout du r eseau, saura comprendre pour traiter les donn ees re cues. Ces informations ajout ees peuvent pr ec eder les donn ees ` a transmettre on parlera alors den-t ete, ou header, HR ou bien les succ eder on parlera alors de postambule. Lensemble pass e ` a la couche inf erieure (en-t ete, donn ees de service, postambule) formera lunit e de donn ees du protocole, ou PDU3 . La couche inf erieure traitera le PDU de la couche sup erieure comme son SDU. G en eralement, on ajoute la premi` ere lettre du nom de niveau pour d esigner un HR, un PDU ou un SDU. Par exemple, un PDU de niveau MAC sera d esign e par MPDU (MacPDU) et un SDU de niveau Physique sera d esign e par PSDU (PhySDU). Notons quun MPDU est equivalent au PSDU, puisque les niveaux PHY et MAC sont mitoyens dans une pile protocolaire classique comme celle de ZigBee. Le principe g en erique de lencapsulation est illustr e par la gure 2.4. Un exemple appliqu e` a 802.15.4 sera illustr e plus loin dans ce chapitre par la gure 2.20, page 76.
57
Fig. 2.4 Le principe g en erique de lencapsulation
2.1.3
Protocole d echange entre deux couches voisines
Les echanges de messages entre deux couches mitoyennes se font selon le principe classique du service de niveau n, service assur e par la nieme couche de la pile. Pour acc eder ` a ce service, la couche imm ediatement sup erieure (n + 1) peut acc eder au Point dAcc` es de Service (SAP3 ) de niveau n. Pour etre accessible, un SAP propose un jeu de primitives propre ` a ses capacit es (par exemple : scanner le m edium radio 2,4GHz, cr eer une connexion au r eseau, envoyer des donn ees, etc.). Selon ses besoins, la couche sup erieure appelle les primitives quelle souhaite dans lordre impos e par son protocole. Pour s echanger des messages, deux couches mitoyennes disposent de quatre types de primitives :
1. Request : demande eectu ee par le service local de niveau n + 1 au SAP de niveau n. 2. Indication : la demande qui vient d etre faite par le request est achemin ee jusquau nud destinataire par le r eseau ; le SAP distant de niveau n le transmet ` a la couche n + 1. 3. Response : la couche distante de niveau n + 1 r epond en envoyant un message ` a son entit e paire. Pour etre achemin e par le r eseau, le message est pass e au SAP de niveau n. 4. Conrm : le SAP local de niveau n transmet cette r eponse au service de niveau n + 1, qui avait initi e la requ ete.
La gure 2.5 illustre ce fonctionnement.
Fig. 2.5 Communication respectant le protocole normalis e
58
2.1.4
Repr esentation de la pile protocolaire ZigBee
La pile protocolaire ZigBee est repr esent ee sur la gure 2.6. On y retrouve le d ecoupage classique recommand e par lOSI. Une description ne des trois couches les plus basses sur lesquelles portent le travail eectu e pendant la th` ese sera faite dans la suite de ce chapitre.
Fig. 2.6 La pile protocolaire 802.15.4 / ZigBee
2.1.5
Les interfaces de communication entre couches
La norme ZigBee pr evoit plusieurs interfaces pour la communication entre couches. Ces interfaces sont les Points dAcc` es de Service (SAP) vus pr ec edemment. La gure 2.7 repr esente cet interfa cage protocolaire. A linstar des autres piles protocolaires comme 802.11 [IEE1 99], chaque couche de la pile protocolaire ZigBee compte deux entit es, chacune ayant sa propre interface : Une entit e d edi ee aux transferts de donn ees. Cette entit e est sollicit ee lorsque la couche sup erieure veut envoyer ou recevoir des donn ees sur le r eseau. Les primitives pr esentes sur cette interface sont g en eralement peu nombreuses (envoyer des donn ees, recevoir des donn ees) et elles se retrouvent ` a chaque niveau de la pile, pour chaque couche. Une entit e d edi ee ` a la gestion de la couche. Cette entit e sert ` a commander toutes les t aches propres ` a la couche. Elle dispose g en eralement dun jeu de primitives plus eto e que linterface d edi ee aux transferts de donn ees. Chaque couche ayant un r ole bien pr ecis, chaque niveau dispose dun jeu qui lui est propre. Voici quelques exemples de primitives : pour le niveau Physique : changer de canal radio, passer en emission, Adrien van den Bossche 59
d etecter l energie sur le m edium. pour le niveau Liaison : rechercher un coordinateur, se synchroniser sur une autre entit e, notier que lon quitte le r eseau, demander de la bande passante ` a un coordinateur (plus de droit ` a la parole). pour le niveau R eseau : diuser les routes connues, demander une route.
Fig. 2.7 Principe dinterfa cage entre couches et SAP pour ZigBee
Notons que les constructeurs ajoutent parfois des entit es et/ou des interfaces propres ` a leur produits, quils soient mat eriels ou logiciels. Cest le cas du constructeur Freescale qui ajoute une interface ASP3 au niveau MAC de sa solution ZigBee [FRE4 04]. Cette interface permet de piloter les fonctions d economie d energie du jeu de composants d emission/r eception. Bien entendu, la partie logicielle g erant le composant (driver ) devra utiliser cette interface pour optimiser la solution r eseau en terme de consommation energ etique.
2.2
2.2.1
La couche Physique
Bandes de fr equences et canaux
Conform ement ` a IEEE 802.15.4, ZigBee peut travailler sur trois bandes de fr equences di erentes : 868 MHz pour la r egion Europe, 915 MHz pour lAm erique du nord, et 2,4 GHz pour une couverture mondiale. La norme pr evoit deux couches physiques di erentes (PHY), une pour le 868/915MHz (PHY868/915) et une seconde pour le 2,4 GHz (PHY2450). Le tableau 2.2 r esume les caract eristiques et les param` etres des deux couches physiques propos ees (PHY868/915 et PHY2450).
60
Tab. 2.2 Caract eristiques des deux couches physiques propos ees (PHY868/915 et PHY2450)
Au total, 27 canaux (num erot es de 0 ` a 26) sont r epartis sur ces trois bandes, cette diversit e en terme dutilisation du spectre radio-fr equence permettant ` a la technologie de r epondre aux nombreuses r eglementations et d etre utilisable sur toutes les r egions du globe. Soit k le num ero de canal compris entre 0 et 26, on peut alors obtenir la fr equence de chaque canal ainsi : Fc = 868,3 MHz, pour k = 0 Fc = 906 + 2(k-1) MHz, pour k = 1, 2, ..., 10 Fc = 2405 + 5(k-11) MHz, pour k = 11, 12, ..., 26.
2.2.2
Modulations, etalement de spectre
Comme beaucoup dautres technologies WLAN/WPAN, 802.15.4 met en uvre une modulation ` spectre a etal e. Une modulation utilisant l etalement de spectre permet dam eliorer limmunit e aux interf erences et aux multi-trajets, en sacriant quelque peu les performances en terme de d ebit. De plus, gr ace au codage r ealis e par la s equence pseudo-al eatoire, aussi appel ee PN-codes3 qui permet de r ealiser l etalement [GUIL 05], la condentialit e des echanges est am elior ee. Cependant, cette technique ne garantit pas les propri et es de condentialit e et dauthentication ; une partie de la couche liaison eectuera cette t ache. La couche PHY868/915 est relativement simple et basique : les symboles sont binaires, gr ace ` a lemploi dun modulation BPSK3 et un d ebit peu elev e (20 kbits/s pour le 868 MHz, 40 kbits/s pour le 915 MHz). En revanche, la couche PHY2450 propose une modulation plus complexe, O-QPSK3 , qui permet un d ebit plus int eressant.
2.2.3
Port ee, puissance d emission et sensibilit e du r ecepteur
IEEE 802.15.4 pr evoit une port ee classique de quelques dizaines ` a quelques centaines de m` etres suivant lenvironnement consid er e. La puissance maximale emise par un module 802.15.4 ou ZigBee nest pas d enie par la norme ; celle-ci est laiss ee dune part ` a lappr eciation de lautorit e de r egulation de la zone o` u est eectu ee la transmission, et dautre part au constructeur pour des questions evidentes dautonomie energ etique du syst` eme dans lequel il est implant e. N eanmoins, la puissance typique recommand ee est de 1 mW (soit 0 dBm) et la sensibilit e du r ecepteur doit etre meilleure que -85 dBm (` a 2,4 GHz, pour un taux derreur paquet meilleur que 1%). En pratique, un nud ZigBee a une port ee de quelques dizaines de m` etres, jusqu` a une centaine de m` etres en ext erieur et sans obstacle. Notons que de part la robustesse de la couche physique, les port ees dun transceiver 802.15.4 sont comparables ` a celle dun transceiver 802.11, mais avec une puissance d emission plus faible : ` a rapport signal sur bruit (SNR3 ) egal, 802.15.4 dispose dun taux derreur bit Adrien van den Bossche 61
(BER3 ) meilleur que les autres technologies sans l propos ees par lIEEE, comme lillustre le graphe de la gure 2.8. Notons que comme pour toutes les technologies de r eseau sans l, la port ee eective dun transceiver 802.15.4 est tr` es li ee ` a sa puissance d emission. Certains modules sont dot es dun etage amplicateur en sortie HF et/ou dun amplicateur ` a faible bruit en entr ee, ce qui permet d etendre consid erablement la port ee radio. A titre dexemple, les modules XBeePRO fabriqu es par la soci et e MaxStream [MAXS] sont vendus pour une port ee de 1,6 km en ligne de vue. Notons que l etendue dun r eseau ZigBee peut etre largement sup erieure ` a la port ee eective de deux modules gr ace ` a la topologie maill ee (multi-sauts), comme nous le verrons plus loin dans ce chapitre. Enn, comme cest le cas dans tous les r eseaux hertziens, la port ee est largement conditionn ee par la pr esence dobstacles ou par la pollution du spectre radio-fr equence. A ce titre, le coordinateur du r eseau peut d ecider deectuer un changement de canal ` a titre exceptionnel si le taux derreur sur le r eseau est trop important.
Fig. 2.8 Rapport entre BER et SNR pour diverses technologies de transmission sans l (source IEEE)
2.2.4
Le paquet de niveau physique
La norme pr evoit un paquet2 de niveau physique repr esent e sur la gure 2.9. Ce paquet comprend un en-t ete de synchronisation, un en-t ete PHY et les donn ees PHY. Len-t ete de synchronisation comprend 6 octets : un pr eambule dune longueur de 5 octets qui permet au r ecepteur de parfaire sa synchronisation et un fanion de START sur 1 octet. Ce fanion rompt lalternance des bits transmis lors du pr eambule, indiquant ainsi limminence de la transmission de donn ees. Apr` es len-t ete de synchronisation vient len-t ete PHY dont le r ole est de sp ecier la longueur du
2 Bien que le terme paquet soit g en eralement r eserv e au niveau 3 (r eseau), cest bien ce terme qui est utilis e par lIEEE pour d esigner ce groupe de bits envoy e sur le m edium.
62
Fig. 2.9 Structure du paquet de niveau physique
paquet. Les donn ees suivent cet en-t ete, 127 octets maximum par paquet, soit une dur ee de transmission maximum de 4,256 ms par paquet sur la couche PHY2450 (250 kbits/s).
2.2.5
Services rendus
La couche PHY de 802.15.4 rend deux services : un service de donn ees PHY (PHY data service ), qui permet l emission et la r eception de PPDU3 sur le m edium radio, un service de gestion PHY (PHY management service ), qui permet linterfa cage entre le logiciel et lentit e de gestion de la couche physique. Les capacit es de cette entit e sont les suivantes (liste exhaustive) : activation/d esactivation du transceiver, ED3 , LQI3 sur les paquets re cus, s election 3 du canal, CCA pour le CSMA/CA de la sous-couche MAC.
2.3
La couche Liaison
De fa con tr` es similaire au mod` ele d eni par le groupe 802 de lIEEE, le niveau liaison de 802.15.4 (Niveau 2 OSI) comprend une sous-couche dacc` es au m edium (MAC) et une sous-couche de convergence (SSCS).
2.3.1 2.3.1.1
La sous-couche MAC Types dacc` es au m edium
La sous-couche MAC g` ere les acc` es au m edium radio, r esolvant notamment les probl` emes dacc` es concurrents. 802.15.4 propose deux modes pour lacc` es au m edium : un mode non coordonn e (totalement CSMA/CA, sans RTS/CTS3 ) et un mode coordonn e, ou beacon mode, disponible uniquement dans une topologie etoile o` u le coordinateur de cette etoile envoie p eriodiquement des trames balises (beacon ) pour synchroniser les nuds du r eseau. Lemploi du m ecanisme CSMA/CA dans le mode non coordonn e est relativement classique et 802.15.4 nore que peu dinnovations par rapport aux autres technologies sans l dans ce mode ; en revanche, le mode coordonn e permet dentrevoir des applications int eressantes mettant en uvre une Qualit e de Service. Le mode non coordonn e, totalement CSMA/CA Dans le mode non coordonn e, il ny a pas d emission de beacon donc pas de synchronisation entre les di erents nuds du r eseau. Les nuds voulant emettre des donn ees doivent utiliser le protocole CSMA/CA non slott e , cest-` a-dire que le d ebut dune emission se fait d` es que le m edium est jug e libre, sans attendre le d ebut dun eventuel slot. Cependant, m eme si lalgorithme est dit non slott e , il se base tout de m eme sur une unit e temporelle discr` ete appel ee p eriode de backo pour
3 Se
reporter au premier chapitre pour plus de d etail sur cette technique
63
pouvoir retarder plus ou moins l emission dune trame et eviter les collisions. Limpl ementation du CSMA/CA dans 802.15.4 est tr` es proche de celle de 802.11, ` a deux exceptions pr` es : 1. Absence de RTS/CTS : ` a la di erence de 802.11, la m ethode dacc` es avec contention de 802.15.4 ne pr evoit pas de m ecanisme pour r eserver le m edium avant de commencer ` a emettre les donn ees. Ceci sexplique par le fait que dans un r eseau 802.15.4, les trames DATA sont tr` es courtes et le d ebit tr` es faible et, de fait, lutilisation dun protocole de type RTS/CTS serait tr` es co uteuse. Apr` es avoir attendu un nombre al eatoire de p eriodes de backo, si le m edium est libre, la trame de donn ees est emise. 2. Gestion des temps inter-trames : 802.15.4 en pr evoit trois, du plus court au plus long : tACK est le d elai impos e entre une trame de donn ees et son acquittement. Il doit etre le plus court possible, mais dans tous les cas sup erieur ` a aTurnaroundTime (192 s), SIFS3 , pour Short Inter-Frame Spacing, suit les trames dites courtes , cest-` a-dire dune longueur inf erieure ou egale a ` aMaxSIFSFrameSize (18 octets), LIFS3 , pour Long Inter-Frame Spacing, suit les trames dites longues , cest-` a-dire dune longueur strictement sup erieure ` a aMaxSIFSFrameSize (18 octets). Dans un objectif d economie d energie, cette gestion des temps inter-trames, en fonction de la longueur de la trame, est n ecessaire compte tenu des faibles ressources de traitement (CPU) des nuds r ecepteurs : plus le volume des donn ees est important, plus le temps de traitement n ecessaire est grand. Le mode coordonn e, ou balis e Dans le mode coordonn e, une ou plusieurs entit e(s) du r eseau diuse(nt) p eriodiquement des trames appel ees balises, ou beacon. Tout membre du r eseau qui entend cette balise peut utiliser la r eception de cette trame pour se synchroniser avec son emetteur et se servir de lui comme relais. Ce mode de fonctionnement permet les meilleures performances sur le plan energ etique car une fois linformation transmise au relais, le nud communicant peut somnoler ; de plus, les messages en attente etant stock es dans la m emoire du relais, un nud peut choisir de se r eveiller selon ses besoins, et demander alors les donn ees en attente. On parle alors de transfert de donn ees indirect dans une topologie en etoile, car tout echange sur le r eseau passe par le relais. On appellera par la suite ce relais le coordinateur d etoile. La gure 2.10 illustre le fonctionnement de transfert de donn ees dans une etoile.
Fig. 2.10 Principe du transfert de donn ees dans une etoile Le transfert de donn ees direct est illustr e par lenvoi du message (1) de type data. Le nud envoie directement ses donn ees au coordinateur de l etoile puis se rendort.
64
Le nud de destination r ecup` ere ses donn ees de mani` ere indirecte : le message beacon (2) annonce les donn ees en attente pour tous les nuds ; le nud de destination ecoute le beacon, constate que des donn ees sont en attente et les r eclame par le message data_request (3). Le coordinateur peut alors transmettre les donn ees en attente en envoyant le message data (4).
2.3.1.2
Notion de supertrame
Lespace temporel durant lequel les communications prennent part est appel e supertrame. Une supertrame est toujours divis ee en 16 slots temporels de dur ees egales, la trame balise occupant le premier slot ; cette trame permet de diuser la synchronisation pour tous les nuds ` a port ee radio, mais egalement lidentiant du PAN et la structure dynamique de la pr esente supertrame, en fonction des demandes qui ont et e faites par les nuds membres de l etoile. La structure dune supertrame est repr esent ee gure 2.11.
Fig. 2.11 Repr esentation dune supertrame IEEE 802.15.4 La supertrame poss` ede deux param` etres fondamentaux : BO3 (Beacon Order ), qui xe lintervalle de temps entre lenvoi de deux messages beacon par le coordinateur. On d eduit de BO le param` etre BI 3 (Beacon Interval ), selon la loi : BI = 2BO 15, 36 ms avec 0 BO 14 SO3 (Superframe Order ). Ce param` etre xe la dur ee active de la supertrame selon la loi : dactive = 2SO 15, 36 ms avec 0 SO BO Lorganisation de lacc` es au m edium par supertrame permet les meilleures economies sur le plan energ etique. Les nuds du r eseau se r eveillent juste avant le slot 0 et se mettent ` a l ecoute. A la r eception du beacon, ils prennent connaissance de la structure de la supertrame qui d ebute : valeurs de BO et SO, pr esence de donn ees en attente, etc. Sils nont de donn ees ni ` a emettre, ni ` a recevoir, ils peuvent somnoler jusquau beacon suivant. Notons que plus BO et SO sont faibles, plus la fr equence des supertrames est elev ee, donc plus le r eseau est r eactif (latence faible). En revanche, plus la di erence entre BO et SO est grande, meilleures sont les economies sur le plan energ etique. Il faudra donc trouver un compromis entre ces deux constantes selon lapplication. Le mode coordonn e de 802.15.4 propose deux m ethodes dacc` es au sein de la supertrame : un mode avec contention avec lequel les acc` es se font de fa con classique selon le protocole CSMA/CA slott e. Cependant, les trames balises sont toujours emises p eriodiquement en d ebut de supertrame, pour assurer la synchronisation entre les entit es du r eseau. Ce mode dacc` es au Adrien van den Bossche 65
m edium est toujours possible et une partie de la supertrame doit etre syst ematiquement d edi ee par le coordinateur aux acc` es se faisant dans ce mode. Cette partie de la supertrame est appel ee CAP3 (cf. 2.11). un mode sans contention, contention free , optionnel, avec lequel les acc` es au m edium sont ma tris es par le coordinateur. Ce mode peut etre utilis e par les nuds qui en font la demande. Si la capacit e du r eseau le permet, le coordinateur pourra choisir dhonorer la demande du nud en lui allouant un ou plusieurs slots, dans la direction ( emission ou r eception) qui a et e demand ee ; on parle de GTS3 . Les GTS sont toujours plac es en n de supertrame, dans les derniers slots. On appelle cette partie de la supertrame CFP3 . Dans cette p eriode, lacc` es au m edium est donc organis e et r eparti par le coordinateur et les collisions sont rendues plus rares. Ce mode sans contention rend possible une r eservation de bande passante et peut orir une certaine garantie sur le plan temporel. Pour se faire, le coordinateur peut attribuer jusqu` a 7 GTS, alors quun GTS peut occuper un ou plusieurs des 16 slots que comporte la supertrame ; le d ebut de la supertrame, via la CAP, reste toujours en acc` es libre par CSMA/CA pour permettre lacc` es aux transports ne n ecessitant pas ou peu de garantie, de ne pas etre bloqu es par un nombre trop important de GTS. De fait, 802.15.4 pr evoit une taille limite pour la CAP dans la supertrame (aMinCAPlength de 440 symboles, soit 7,04 ms et ce, quelques soient les valeurs de BO et SO). Notons d` es maintenant, bien que cela soit longuement evoqu e en n de chapitre, que les demandes de GTS ainsi que les demandes dassociation au r eseau ne peuvent se faire que dans la CAP. Il est donc primordial, pour ne pas bloquer le r eseau, de limiter la taille de la CFP au sein la supertrame.
2.3.2
La sous-couche LLC
Conform ement ` a la plupart des standards 802.n, IEEE 802.15.4 propose une sous-couche de convergence de type LLC pour normaliser linterfa cage des couches d ecrites par le standard avec une couche de niveau sup erieur, typiquement une couche de niveau 3 compatible LLC. Cette convergence est assur ee par la sous-couche SSCS qui est d ecrite par le standard. Une couche de convergence typique doit jouer plusieurs r oles : 1. La v erication de lint egrit e des donn ees re cues avant la remise ` a la couche sup erieure, par exemple par utilisation conjointe dun Code de Redondance Cyclique (CRC) et dun m ecanisme dacquittement, 2. Le contr ole de ux, an d eviter la saturation des tampons de r eception et la perte eventuelle de donn ees ou les d ebordements de m emoire, 3. La convergence dadressage, cest-` a-dire la correspondance des adresses de niveau 3 (niveau r eseau, ladressage est g en eralement globalis e sur tout le r eseau) avec les adresses de niveau 2 (niveau liaison, ladressage est g en eralement local et limit e au m edium utilis e). La convergence dadressage permet egalement la gestion des proc ed es de diusion (broadcast ) et de diusion par classes (multicast ). Dans le cadre de 802.15.4, la sous-couche de convergence propos ee est tr` es simple, et ce pour plusieurs raisons : 1. Tout dabord, et cest le cas avec la plupart des technologies sans l, dans IEEE 802.15.4, le m ecanisme dacquittement sert non seulement ` a assurer ` a un emetteur que le destinataire a re cu correctement les donn ees envoy ees, mais aussi ` a d etecter que la transmission sur le m edium partag e na pas subi de collision (CSMA/CA). De ce fait, lacquittement est pris en charge par le processus de gestion dacc` es au m edium et le standard ne pr evoit pas de le faire remonter jusqu` a la sous-couche SSCS ; la gestion de ce dernier reste cantonn ee ` a la sous-couche MAC. De plus, la 66 Groupe SCSF LATTIS EA4155
pr esence dun syst` eme evolu e de gestion de la couche MAC n ecessite lint egrit e des messages de gestion ` a ce niveau : cette v erication est donc assur ee par un processus qui se situe en dessous de la couche liaison. La sous-couche de convergence na donc pas ` a assurer cette t ache une seconde fois. 2. Dans IEEE 802.15.4, le contr ole de ux est implicite et r ealis e tr` es simplement car, etant donn e le faible volume de donn ees echang ees et la faible capacit e m emoire des nuds, le syst` eme denvoi des paquets de donn ees est de type send & wait, cest-` a-dire que la couche sup erieure attend le traitement int egral du paquet de donn ees (y compris la gestion de lacquittement) avant lenvoi du paquet suivant (pas danticipation). 3. Dans IEEE 802.15.4, la gestion dadressage est simpli ee dans la mesure o` u il ny a pas de conversion ` a r ealiser. Le plan dadressage est le m eme entre la couche liaison et la couche r eseau, les nuds utilisent leur adresse MAC pour sassocier au r eseau puis se voient attribu es une adresse courte par le coordinateur du PAN. La sous-couche SSCS propose un jeu de trois primitives : 1. MA-UNITDATA.request permet ` a une instance LLC dordonner lenvoi dun paquet de donn ees. Seuls trois param` etres sont alors pass es : adresse source, adresse destination et donn ees. 2. MA-UNITDATA.indication permet ` a lentit e 802.15.4 dindiquer ` a lentit e LLC sup erieure que des donn ees valides ont et e re cues. Si les donn ees sont invalides, la couche MAC les ignorent et lentit e LLC nest pas inform ee. 3. MA-UNITDATA-STATUS.indication permet ` a lentit e 802.15.4 de reporter le r esultat de la derni` ere transmission de donn ees. Ce rapport est automatiquement g en er e apr` es un appel ` a MAUNITDATA.request.
2.3.3
Structures de trames
802.15.4 propose 4 types de trames : donn ees (data), acquittement (ack), balise (beacon), service (MAC command).
Ces quatre types de trames ont une structure commune : un champ contr ole de trame (frame control ), un champ num ero de s equence (sequence number ), un ou plusieurs champs propres au type de la trame puis une s equence de contr ole sur 16 bits (Frame Check Sequence ).
2.3.3.1
Le champ de contr ole de trame
Le champ de contr ole de trame a une longueur de 16 bits. Il indique : le type de trame, si la trame MAC est chir ee ou non, si des donn ees restent encore ` a envoyer au destinataire, si la trame envoy ee n ecessite un acquittement, si la trame est destin ee au PAN (intra-PAN ) ou ` a lext erieur du PAN (inter-PAN ), si les champs dadressages source et/ou destination sont pr esents ou non, si les adresses pass ees sont courtes (16 bits) ou etendues (64 bits). 67
2.3.3.2
Le champ de num ero de s equence
Le champ de num ero de s equence a une longueur de 8 bits. Suivant le type de la trame, ce champ peut avoir des signications di erentes. Dans le cas dune trame balise, ce champ sp ecie le num ero de s equence du beacon (BSN3 ) ; ce num ero est choisi au hasard dans un premier temps par le coordinateur puis incr ement e` a chaque balise. Dans le cas des trames de donn ees, acquittement ou service, ce champ sp ecie le num ero de s equence des donn ees (DSN3 ) ; ce num ero est propre ` a une communication dune entit e avec une autre. De m eme que pour le BSN, ce num ero est choisi au hasard puis incr ement e ` a chaque trame.
2.3.3.3
Le champ dadressage
Le champ dadressage est compos e de 4 sous-champs : Identiant de PAN destination : sur 16 bits. Si la valeur 0xFFFF est pass ee (diusion, broadcast ), toutes les entit es ` a l ecoute de ce canal consid ereront le message, Adresse de destination : elle peut etre sur 16 ou 64 bits, selon ce qui a et e d eni dans le champ de contr ole de trame. De m eme, si ladresse courte 0xFFFF est pass ee, toutes les entit es ` a l ecoute de ce canal consid` ereront le message, Identiant de PAN source, Adresse source. Les identiants de PAN (PAN-id, 16 bits) sont x es au moment de la cr eation du PAN par le coordinateur. En cas de conit, cest-` a-dire si une entit e du r eseau d etecte que deux coordinateurs utilisent le m eme PAN id, une proc edure de r esolution de conit est d eclench ee an de changer lidentiant. Enn, notons que ces sous-champs peuvent etre absents si labsence dadressage a et e sp eci ee dans le champ de contr ole de trame.
2.3.3.4
Le champ payload
Le champ payload (charge utile) contient les donn ees utiles de la trame. Sa structure est di erente selon le type de trame. Si le chirement a et e pr ecis e dans le champ de contr ole de trame, cette partie de la trame est chir ee. La trame balise est envoy ee par un coordinateur d etoile. Elle contient des informations sur la structure de la supertrame, sa dur ee eective, la dur ee de la p eriode d ecoute obligatoire pour les entit es synchronis ees et le moment o` u commencera la suivante. Cette trame indique egalement si la demande dassociation au PAN est possible ou non, si la r eservation de cr eneaux temporels (GTS) est possible et leur nombre eventuel.
Fig. 2.12 Structure de la trame balise La trame de donn ees contient les donn ees pass ees par la couche sup erieure, cest-` a-dire la couche r eseau. La structure de sa charge utile (MSDU) interne d epend donc de cette couche. 68 Groupe SCSF LATTIS EA4155
Fig. 2.13 Structure de la trame de donn ees
La trame dacquittement est la seule qui ne contient pas de champ payload. Lidentication de la trame qui est acquitt ee se fait gr ace au num ero de s equence de la trame dacquittement, qui est egal au DSN de la trame ` a acquitter.
Fig. 2.14 Structure de la trame dacquittement La trame de service permet de faire des requ etes aupr` es de la couche MAC des autres entit es du r eseau. Ces requ etes sont les suivantes : demande ou r eponse dassociation, notication de d esassociation, demande de donn ees, notication et r eponse ` a un orphelin (perte du coordinateur), demande dune balise, demande dun GTS, notication de conit de PAN ID.
Fig. 2.15 Structure de la trame de service
2.3.3.5
Le champ FCS
Le champ FCS (Frame Check Sequence ) eectue la d etection derreurs. Il est bas e sur un CRC 16 bits ITU-T. Il prend en compte toute la trame de niveau 2, depuis le champ de contr ole de trame jusqu` a la charge utile (payload ). Du fait de certaines trames (messages de gestion de niveau MAC) qui ne remontent pas au dessus de la sous-couche MAC, la v erication de lint egrit e des donn ees doit etre r ealis ee par la sous-couche MAC, alors que cette t ache est g en eralement laiss ee ` a la sous-couche de convergence situ ee au dessus de la sous-couche MAC4 .
4 Cette particularit e est tr` es r epandue dans les technologies de r eseau qui n ecessitent une gestion ne au niveau de la sous-couche MAC. Comme la m ethode dacc` es est bas ee sur un echange de messages, leur int egrit e doit etre imp erativement v eri ee, ce qui ne peut etre fait au niveau LLC. . .
69
2.4
La couche R eseau
Nous lavions vu au d ebut de ce chapitre, ZigBee recommande lutilisation de la technologie propos ee par le standard IEEE 802.15.4 pour les deux premi` eres couches du mod` ele OSI (couche physique et couche liaison ). Pour les couches sup erieures, la ZigBee Alliance propose sa propre sp ecication [ZBAL 05], et notamment, sa propre couche R eseau (niveau 3 OSI). Bien que les travaux elabor es pendant la th` ese portent essentiellement sur la m ethode dacc` es, et donc, sur la couche liaison, il est int eressant et m eme n ecessaire de comprendre le fonctionnement de la couche 3 qui a un impact direct sur la fa con dont la m ethode dacc` es va etre sollicit ee. Evoquons tout dabord les topologies possibles ayant une inuence sur le travail de la couche 3.
2.4.1
ements de la topologie du r El eseau
ZigBee d enit trois types d el ements pour constituer un r eseau. 1. Le Coordinateur ZigBee, ou ZigBee Coordinator, ZC : il est unique pour tout le r eseau ZigBee et il est ` a lorigine de la cr eation du r eseau, il reprend les t aches du PAN Coordinator d ecrit dans le standard IEEE 802.15.4, il agit comme simple routeur (ZR, voir point suivant) une fois le r eseau cr e e. 2. Le Routeur ZigBee, ou ZigBee Router, ZR : il doit dabord sassocier avec le ZC ou un autre ZR, il accepte que dautres el ements du r eseau sassocient ` a lui, il reprend les t aches du coordinateur 802.15.4, il relaie les messages selon un protocole de routage qui sera pr esent e plus bas, il est optionnel. 3. Le nud terminal, ou ZigBee End Device, ZED : il doit dabord sassocier avec le ZC ou un ZR, il ne constitue quun el ement nal du r eseau : il naccepte ni association, ni participation au routage des messages. il est lui aussi optionnel. Ces trois types d el ements sont tr` es semblables ` a ce que propose le standard IEEE 802.15.4. Nous pouvons constater, comme nous l evoquions en d ebut de chapitre, que le r eseau ZigBee peut avoir une port ee plus etendue que le rayonnement dun simple nud 802.15.4 gr ace au processus de routage qui permet le relais dun message par une ou plusieurs entit es jusqu` a la destination nale. Ce processus n ecessite une connaissance du r eseau qui est r ealis ee par un algorithme de d ecouverte automatique que nous d ecrirons plus en d etails par la suite.
2.4.1.1
Topologie en arbre
Dans le cadre dune topologie en arbre, le processus de cr eation du r eseau sarticule autour du ZC dont la mise en service marque le d ebut de la phase de cr eation. Par la suite, toutes les entit es qui se trouvent ` a port ee radio de ce nud se rattachent ` a lui. Les entit es qui ne sont pas ` a port ee du ZC se rattachent ` a lun des ZR, de proche en proche, jusqu` a la formation totale du r eseau, comme lillustre la gure 2.16. Sur lexemple de la gure, le r eseau se forme en trois temps. Cette formation hi erarchis ee forme un arbre dont la racine est le ZC ; il convient de lier cette topologie ` a ladressage et au routage ad equat, comme nous le verrons plus loin. 70 Groupe SCSF LATTIS EA4155
Fig. 2.16 Exemple de cr eation du r eseau ZigBee en arbre
71
2.4.1.2
Topologie maill ee
Avec la topologie maill ee, ou mesh, tous les ZR ` a port ee radio les uns des autres peuvent dialoguer entre eux, sans structure hi erarchique, comme lillustre la gure 2.17. Un processus de routage doit etre mis en place pour relayer les paquets de bout en bout du r eseau ; nous verrons ce processus plus loin (cf. paragraphe 2.4.5).
Fig. 2.17 Exemple de topologie maill ee
2.4.2
Architecture de la couche r eseau
A linstar de la couche liaison d ecrite plus haut par le standard IEEE 802.15.4, la couche r eseau propos ee par ZigBee se d ecompose en deux entit es : une premi` ere entit e (NLDE3 ) traitant lenvoi, la r eception des donn ees et eventuellement la r e- emission de donn ees re cues dans le cadre du routage, et une seconde entit e (NLME3 ) charg ee de la gestion et de la maintenance du r eseau (routage, adressage, etc.). Lentit e NLDE communique avec la couche 2 via le point dacc` es MCPS-SAP3 et met ` a disposition des couches sup erieures son propre point dacc` es NLDE-SAP3 . Lentit e NLME communique avec la couche 2 via le point dacc` es MLME-SAP3 et permet au ZDO3 de pouvoir communiquer avec elle via son point dacc` es : NLME-SAP3 . La couche r eseau contient egalement une base dinformations appel ee NIB3 . Elle contient les informations sur les nuds voisins et la table de routage. La structure de la couche r eseau propos ee par ZigBee est repr esent ee gure 2.18.
Fig. 2.18 Structure de la couche r eseau propos ee par ZigBee
72
2.4.3
Services rendus
La couche R eseau de ZigBee est en charge des op erations suivantes : Cr eation et traitement des PDU de niveau R eseau (NPDU3 ), Participation au routage des paquets, Cr eation (Coordinateur ZigBee) ou rattachement ` a un r eseau existant, Adressage, D ecouverte du voisinage et stockage des informations li ees aux nuds voisins, Contr ole du r ecepteur, economie d energie (fonctions li ees ` a la couche MAC).
2.4.4
Adressage
La sp ecication ZigBee autorise deux types dadressage : un adressage libre laiss e` a la convenance de la couche sup erieure (HHLE-based addressing 3 ) et un adressage de type hi erarchique en arbre (Tree Structure ). Si ladressage de type hi erarchique doit etre utilis e, lattribut nwkUseTreeAddrAlloc de la NIB devra etre positionn e` a TRUE. Si, au contraire, cest le mode dadressage NHLE-based qui doit etre utilis e, nwkUseTreeAddrAlloc devra etre positionn e` a FALSE.
2.4.4.1
Adressage NHLE-based
Si lattribut nwkUseTreeAddrAlloc de la NIB est positionn e ` a FALSE, une couche sup erieure doit prendre en charge ladressage et doit, pour cela, tenir compte de trois attributs de la NIB : nwkNextAddress indique la prochaine adresse qui sera attribu ee, nwkAvailableAddresses est d ecr ement e` a chaque nouvelle association, nwkAddressIncrement est la valeur de lincr ement qui doit modier nwkNextAddress ` a chaque nouvelle association. Si lattribut nwkAvailableAddresses vaut 0, le ZR ne peut plus honorer de nouvelles demandes dassociation et doit positionner son attribut macAssociationPermit ` a FALSE.
2.4.4.2
Adressage en arbre
Si lattribut nwkUseTreeAddrAlloc de la NIB est positionn e ` a TRUE, les adresses sont distribu ees suivant un algorithme hi erarchique ayant une structure arborescente. Lavantage de cette distribution est quelle est totalement d ecentralis ee tout en garantissant lunicit e des adresses distribu ees, car chaque routeur ZigBee dispose dun certain nombre dadresses quil peut distribuer aux nuds qui sassocient a lui. Pour r ` ealiser cette distribution dadresses, chaque routeur doit conna tre sa profondeur (not ee d, pour depth, cest-` a-dire le nombre de sauts ` a eectuer pour atteindre le coordinateur), ainsi que trois autres param` etres : nwkMaxDepth, ou Lm, qui xe la profondeur maximale du r eseau ZigBee, nwkMaxRouters, ou Rm, qui xe le nombre maximal de routeurs de profondeur d 1 associ es ` a un routeur de profondeur d, nwkMaxChildren, ou Cm, qui xe le nombre maximal dentit es (ZR ou ZED) associ ees ` a un routeur.
73
La gure 2.19 illustre ces di erents param` etres.
Fig. 2.19 Illustration de la hi erarchie des adresses dans le cadre de ladressage automatique en arbre Connaissant ces quatre param` etres (d, Lm, Rm et Cm ), il est possible de calculer les di erentes adresses des nuds qui sassocient ` a un routeur. Ladresse An du nime nud associ e` a un routeur de profondeur d + 1 sera : An = Aparent + Cskip(d) Rm + n avec 1 + Cm.(Lm d 1) si Rm = 1 1+CmRmCm.RmLmd1 sinon 1Rm
Cskip(d) =
Le principe de ladressage en arbre est tr` es int eressant car il permet dune part de distribuer automatiquement des adresses de fa con d ecentralis ee et d eterministe il sut de conna tre les quatre param` etres sur lesquels se basent les calculs pour d enir localement ladressage coh erent sur tout le r eseau ce qui minimise les echanges de messages de gestion. Cette economie de messages echang es va dans le sens de l economie d energie. Dautre part, et nous allons le voir plus bas, cet adressage permet un routage automatique en se basant sur les adresses ; l` a encore, nul besoin d echange de messages pour d eterminer quelle route emprunter ! En terme d economie d energie, un r eseau ZigBee a tout int er et si possible, par rapport ` a la g eom etrie des liens, les port ees des nuds et la pr esence dobstacles ` a utiliser ce type dadressage car il va de pair avec une limitation des requ etes des demandes de route et une r eduction de la m emoire utilis ee pour le processus de routage.
2.4.5
Principes de base du routage ZigBee
Du fait de la m emoire tr` es limit ee des nuds, le routage ZigBee [MERC 04] [FRAN 06] suit le principe de base suivant : si la table de routage contient une entr ee qui correspond au routage demand e, il faut router le paquet selon cette entr ee,
74
si elle ne contient aucune entr ee et si la m emoire libre le permet, il faut lancer le processus de d ecouverte de route, sinon, il faut router le paquet selon le routage hi erarchique en arbre (Tree Routing ). La structure de la table de routage dun nud ZigBee est repr esent ee dans le tableau 2.3
Tab. 2.3 Structure de la table de routage dun nud ZigBee
2.4.5.1
Algorithme de routage ` a la demande
Lalgorithme de routage ` a la demande propos e par la ZigBee Alliance est proche dAODV3 [PERK 97]. AODV est un protocole de routage purement ` a la demande cest-` a-dire que les nuds qui participent au routage ne cherchent pas ` a maintenir des informations sur la topologie du r eseau ou sur les routes. Lorsquun nud veut envoyer un message ` a un autre nud et quil ne poss` ede pas lentr ee correspondante dans sa table de routage, il lance le processus de recherche de chemin (Path Discovery ) en diusant une requ ete de recherche de route (route_request). Cette requ ete est relay ee par les routeurs voisins, et ainsi de suite, par inondation sur tout le r eseau. Lorsque le nud de destination re coit la requ ete, il r epond en envoyant un message de r eponse (route_reply) mais ` a la di erence du route_request qui avait et e envoy e par diusion, la r eponse est envoy ee seulement au dernier routeur ayant relay e la diusion et ainsi de suite, jusquau nud qui avait initialement demand e la route. Pour retrouver le chemin inverse, chaque routeur rediusant un message route_request doit m emoriser par quel voisin ce message lui est parvenu.
2.4.5.2
Algorithme de routage hi erarchique : Tree Routing
Le cas particulier de la topologie en arbre permet de simplier grandement le routage puisque, dans le cadre de cette topologie hi erarchique, ladressage est fonction de la topologie. Il sut donc dobserver ladresse du nud de destination pour d eterminer ` a quel voisin envoyer le paquet. Ladresse du routeur voisin est d etermin ee ainsi : soit A ladresse du ZR, et D ladresse de destination, si lin egalit e A < D < A + Cskip(d 1) est fausse, alors la destination est situ ee plus haut , cest-` a-dire vers la racine de larbre, donc vers le coordinateur ZigBee ; il faut donc router le paquet en le transmettant ` a son nud p` ere . sinon, la destination est situ ee plus bas , cest-` a-dire dans sa propre prog eniture . Deux cas peuvent alors se pr esenter : si le ZR na quun seul ls , il route le paquet en lenvoyant ` a ce dernier, si le ZR a plusieurs ls , il route le paquet en lenvoyant au ls dadresse A+1+
D (A+1) Cskip(d) .Cskip(d)
75
Le probl` eme principal de cet algorithme de routage est que, de part sa structure arborescente, il ne permet pas la redondance des liens comme dans un r eseau mesh. Si un lien vient ` a tomber, cest toute une partie du r eseau qui se retrouve isol ee. Conceptuellement, sa abilit e para t plus faible que celle dun r eseau mesh. De plus, il nest pas toujours r ealisable facilement, par exemple dans le cas dun r eseau assez mobile.
2.4.6
Ordonnancement des beacons dans un r eseau avec arborescence
Dans le cadre dune topologie multi-sauts, il est n ecessaire dordonnancer l emission des trames beacons an d eviter que celles-ci nentrent en collision avec dautres trames beacons5 . Dans sa sp ecication, ZigBee propose un m ecanisme d evitement de collisions de beacon en r epartissant les portions actives des supertrames dans le temps pour des ZR se trouvant dans le m eme voisinage. Pour ce faire, les param` etres BO et SO doivent etre di erents et, si possible, BO doit etre le plus 2BO 6 grand possible devant SO. Le temps est alors d ecoup e en portions de dur ee 2SO et chaque ZR du voisinage doit placer la portion active de sa supertrame (qui commence par un beacon) dans lune de ces portions. Le d elai qui aecte l emission des beacons est indiqu e dans le beacon emis. La connaissance de cette information permet dune part de d eterminer le moment o` u sa propre entit e p` ere re coit le beacon de son entit e sup erieure (le beacon de son propre grand-p` ere , en quelque sorte !), mais aussi le moment o` u chaque nud du voisinage re coit le beacon de son parent. En ayant connaissance de toutes ces informations et aussi de la valeur de SO, chaque nud du r eseau peut eviter de provoquer des collisions de beacons, mais aussi plus g en eralement des collisions de portions actives de supertrames . Notons cependant quun nud doit n ecessairement etre actif dans la portion active de son p` ere ( ecoute des beacons, transfert de donn ees indirect, etc.).
2.4.7
Structure du paquet de niveau r eseau
Nous concluons cette partie sur le niveau r eseau de ZigBee par la structure du paquet de niveau 3, comme lillustre la gure 2.20. Sur cette gure, on peut egalement voir comment le paquet de niveau 3 est encapsul e dans la trame DATA de niveau 2 (802.15.4).
Fig. 2.20 Structure du paquet de niveau r eseau et encapsulation dans une trame de donn ees 802.15.4 Comme la trame 802.15.4, le paquet ZigBee poss` ede un champ de contr ole et un champ de num ero de s equence propre, ainsi quun champ dadressage (source, destination) pour ladressage de bout-en-bout
5 Cet ordonnancement est n ecessaire dans le cas dune topologie multi-sauts avec arborescence mais pas dans le cas dune topologie multi-sauts maill ee, puisque dans ce cas pr ecis, l emission r eguli` ere de beacons nest pas autoris ee. 6 Le plus grand possible, autant que lapplication le permet. . .
76
Identication des failles dans la m ethode dacc` es propos ee par le standard
du r eseau. Notons egalement la pr esence du champ rayon qui est modi e ` a chaque passage dans un routeur (similaire au Time-To-Live dIP).
Apr` es avoir pr esent e les trois premiers niveaux (physique, liaison et r eseau ) de 802.15.4/ZigBee, nous d etaillons ` a pr esent les di erentes failles que nous avons identi ees dans lensemble de ces protocoles, au regard de notre objectif principal de transport dinformations ` a fortes contraintes temporelles.
3.1
La gestion des slots garantis ne pr esente pas une garantie absolue
Comme nous lavons evoqu e pr ec edemment, IEEE 802.15.4 propose un m ecanisme de r eservation du m edium qui permet ` a quelques nuds privil egi es, dans une phase particuli` ere du protocole, d etre epargn es par le ph enom` ene des collisions (GTS). Cependant, ce m ecanisme nest pas parfait car lobtention dune r eservation du m edium est conditionn ee par deux points :
1. Le r eseau ne doit pas etre satur e ; eectivement, sa capacit e nest pas innie. Mais la norme ne fournit aucune possibilit e au coordinateur dune etoile de r eserver a priori une part de la bande passante7 ` a certains nuds que lon pourrait qualier de critiques . Les premiers demandeurs sont les premiers servis, ce qui est une politique dordonnancement de type Best-Eort, incompatible avec lid ee de Qualit e de Service [BOUY 97]. 2. Lappel de la primitive de demande de r eservation de bande passante (GTS.request) g en` ere une trame qui est envoy ee au coordinateur en utilisant le protocole CSMA/CA. Comme nous lavons vu dans le premier chapitre dans le cadre de 802.11PCF, ce protocole fonctionne enBest-Eort et il ne permet donc pas davoir de certitude sur le plan temporel, dune part ` a cause du d elai sur lequel repose son algorithme, mais aussi dautre part ` a cause des collisions, toujours probables puisque lalgorithme nest pas d eterministe. Comme lillustre la gure 2.21, les GTS.request, comme le reste du trac CSMA/CA, peuvent etre report es sans garantie dacc` es au m edium.
Fig. 2.21 Les messages GTS.request peuvent entrer en collision avec le reste du trac CSMA/CA Par extension, le m ecanisme dassociation au r eseau, qui utilise la primitive association.request, n ecessite lenvoi de messages soumis aux al eas inh erents ` a cet algorithme ; l` a encore, aucune certitude nest possible quant au temps n ecessaire pour sassocier au r eseau, r eserver de la bande passante, et transmettre ses donn ees.
7 Nous
appelons ici bande passante le d ebit oert par la couche 2.
77
3.2
Autres probl` emes identi es
Dans le cadre dune utilisation de 802.15.4 dans un r eseau de capteurs tr` es contraints temporellement, il serait int eressant de pouvoir garantir un d ebit et un d elai de transmission pour certains nuds critiques pour lapplication communicante. De plus, le r eseau peut etre amen e` a prendre en charge des tracs tr` es di erents : forts d ebits sporadiques, faibles d ebits tr` es contraints temporellement, tr` es faibles d ebits r eguliers issus de nuds contraints energ etiquement. Ainsi, dautres faiblesses li ees ` a lutilisation des GTS apparaissent : Un nud, sil arrive ` a sassocier au r eseau et ` a obtenir la bande passante quil d esire dans le temps imparti, ne peut cependant pas conserver son acquisition tant quil le souhaite. En eet, dans l etat actuel de la norme, une suite de GTS est attribu ee pour un nombre x e de supertrames (d ependant de BO ), et ne peut pas etre maintenue sans reprendre enti` erement le processus de requ ete (nouvelle g en eration dune GTS.request enBest-Eort, etc.). Il nest pas possible dassurer la continuit e du service garanti car le message GTS.request ne peut etre envoy e dans lun des derniers GTS attribu e. La gure 2.22 illustre ce d efaut o` u, apr` es avoir b en eci e dune s erie de GTS, un nud ne peut pas acc eder au m edium trop sollicit e et perd son acc` es d eterministe.
Fig. 2.22 Le service garanti (GTS) ne peut etre maintenu de mani` ere d eterministe Si il est possible daecter plusieurs GTS ` a un m eme nud dans la m eme supertrame (donc daugmenter le d ebit d edi e` a ce nud), il nest en revanche pas pr evu de pouvoir aecter un GTS toutes les deux supertrames, voire encore moins fr equemment (diminuer le d ebit r eserv e mais conserver un acc` es d eterministe et r egulier au m edium). Les GTS reviennent p eriodiquement avec la m eme fr equence : celle de la supertrame. Pour faire changer cette fr equence, il convient de changer les param` etres BO et SO, donc faire varier lhorloge de tous les transferts de donn ees de l etoile. Il nest pas possible, par exemple, de pr evoir un GTS toutes les deux supertrames ; la bande passante est alors perdue, comme lillustre la gure 2.23. Autrement dit, dans l etat actuel de la norme, il nest pas pr evu, dans le mode sans contention, de pouvoir faire cohabiter des tracs tr` es di erents les uns des autres.
78
Fig. 2.23 Un GTS inutilis e constitue une perte de bande passante non r eutilisable Si plusieurs etoiles cohabitent dans la m eme zone de port ee radio et sur le m eme canal, il y a risque de collisions pour des tracs utilisant des GTS car la norme ne pr evoit pas de m ecanisme de communication entre deux coordinateurs d etoile (cf. gure 2.17 page 72, liens pleins) qui d ecident, chacun de leur c ot e, dattribuer des GTS ` a leurs nuds. Dans ce cas, on peut parler de collisions de GTS, comme lillustre la gure 2.24.
Fig. 2.24 Plusieurs coordinateurs attribuant des GTS peuvent provoquer des collisions de GTS
3.3
Conclusion : les am eliorations propos ees
A la lumi` ere de ce qui vient d etre evoqu e, le m ecanisme de r eservation du m edium pourrait etre am elior e pour permettre le transport de ux ` a tr` es fortes contraintes temporelles. Les principes de base peuvent etre conserv es mais deux points doivent etre optimis es : La distribution et la r epartition des GTS doivent gagner en souplesse, le m ecanisme doit pouvoir etre plus dynamique pour permettre au r eseau de prendre en charge des ux de physionomies di erentes, Les coordinateurs ou les ZR qui cohabitent dans la m eme zone de port ee radio et sur le m eme canal radio doivent pouvoir s echanger des informations sur la r epartition des GTS an de limiter les collisions de GTS dans la CFP. Le m ecanisme dordonnancement des beacons pr evu par ZigBee (cf. section 2.4.6 de ce chapitre, page 76) constitue un point de d epart int eressant dans la mesure o` u les collisions de beacons sont rendues plus rares mais, en revanche, il ne r` egle pas le probl` eme des collisions de GTS. Adrien van den Bossche 79
Ainsi, nous proposons de renforcer ce m ecanisme par la mise en uvre dune m ethode dacc` es au m edium totalement d eterministe, comme cela peut etre requis dans le cadre dun r eseau de capteurs et, plus largement, dans les r eseaux industriels sans l. La gestion des acc` es d eterministes doit egalement etre tr` es souple, an de rendre possible la cohabitation de ux ` a physionomies radicalement di erentes. Dans le chapitre suivant, nous pr esentons les principes et les am eliorations que nous proposons dans ce travail, ainsi quune application typique pour illustrer les besoins.
80
[BOUY 97] E. Bouyer et E. Horlait Bandwidth Management and Reservation over Shared Media Segundo Semin ario Franco-Brasileiro em Sistemas Inform aticos Distribu dos (SFBSID97), Fortaleza, Brazil (1997) [CALL 02] E. Callaway, P. Gorday, L. Hester, J.A. Gutierrez, M. Naeve, B.Heile et V. Bahl Home Networking with IEEE 802.15.4 : a developing standard for low-rate wireless personal area networks IEEE Communications Magazine vol. 40, no. 8, pp 70-77 (Ao ut 2002) [FRAN 06] J. Francomme, G. Mercier et T. Val A simple method for guaranteed deadline of periodic messages in 802.15.4 cluster cells for automation control applications IEEE International Conference on Emerging Technologies and Factory Automation (ETFA2006), Prague. Czech Republic (Septembre 2006) [FRE1 04] Freescale Semiconductor ZigBee / IEEE 802.15.4 Freescale solution Technology General Information (2004) [FRE2 04] Freescale Semiconductor ZigBee Reference Disign (ZRD01) documentation & applications notes (2004) [FRE3 04] Freescale Semiconductor MC13192 Reference Manual (2004) [FRE4 04] Freescale Semiconductor 802.15.4 MAC/PHY Software Users Guide (2004) [GUIL 05] C. Guilleminot, L. Andrieux et J.J. Mercier A contribution to a virtual prototyping for a spread spectrum telecommunication system using VHDL-AMS BMAS05, San Jose, Californie, USA (Septembre 2005) [IEE1 99] LAN-MAN Standards Committee of the IEEE Computer Society 802.11 IEEE Standard for Information technology, Specic Requirements Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications IEEE standard 8802-11 (1999) [IEE2 03] LAN-MAN Standards Committee of the IEEE Computer Society 802.15.4 IEEE Standard for Information technology, Part 15.4 : Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specications for Low-Rate Wireless Personal Area Networks (LR-WPANs) IEEEStd 802.15.4-2003 (2003) [KHOU 05] T. Khoutaif et F. Peyrard Performances evaluation of the asynchronous Bluetooth links in a real time environment IEEE Personal Wireless Communications (PWC2005), Colmar, France (Ao ut 2005) [LLI1 06] J.F. Llibre, P. Pinel et E. Campo Dimensionnement dun g en erateur photo volta que pour un syst` eme communicant autonome XIIieme Colloque National de la Recherche dans les IUT, Brest, France (2006) [MAXS] Le site web de MaxStream http ://www.maxstream.net [MERC 04] G. Mercier Un r eseau sans l faible consommation : IEEE 802.15.4 (alias ZigBee) (2004) [PERK 97] C. Perkins et E. Royer Ad-hoc on-demand distance vector routing MILCOM97 (Novembre 1997) [VDB1 05] A. van den Bossche, T. Val et E. Campo M etrologie pour lanalyse comparative des performances temporelles des liens Bluetooth IEEE Sciences of Electronic, Technologies of Information and Telecommunication (SETIT2005), Sousse, Tunisie (Mars 2005)
[ZBAL 05] ZigBee Alliance ZigBee Specication ZigBee Document 053474r06, version 1.0 (2005) [ZBAL] Le site web de la ZigBee Alliance www.zigbee.org [ZHEN 04] J. Zheng et M. J. Lee Will IEEE 802.15.4 make ubiquitous networking a reality ? : A discussion on a potential low power, low bit rate standard IEEE Communications Magazine, vol. 27, no. 6, pp. 23-29 (2004)
82
Chapitre 3
Vers un WPAN ` a Qualit e de Service pour des transports dinformations ` a fortes contraintes temporelles
Apr` es avoir d etaill e les normes IEEE 802.15.4/ZigBee et identi e certaines failles sur la m ethode dacc` es au m edium, ce chapitre expose notre contribution au transport dinformations ` a fortes contraintes temporelles sur un r eseau personnel sans l (WPAN). Dans un premier temps, et an de situer le travail dans son contexte, nous pr esenterons une application typique de robotique communicante sur laquelle a et e d etermin e le cahier des charges, m eme si la proposition peut sappliquer ` a tout type de r eseau sans l personnel. Dans un second temps, nous pr esenterons le protocole qui a et e propos e pour r epondre aux exigences de QoS et d economie d energie.
Une application typique de robotique mobile communicante sans l . . . 1.1 Probl ematique g en erale : pourquoi introduire des communications sans l pour des robots ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Les attentes vis-` a-vis dun syst` eme de communication adapt e . . . . . . . . . 1.2.1 Un syst` eme proposant des garanties sur le plan temporel . . . . . . 1.2.2 Retransmissions vs. redondance et codes correcteurs derreurs . . . . 1.2.3 Taille du r eseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Topologie du r eseau . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4.1 Communications locales au robot . . . . . . . . . . . . . . 1.2.4.2 Communications entre robots . . . . . . . . . . . . . . . . . 1.2.5 D ebit n ecessaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La proposition protocolaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Nouvelles fonctionnalit es propos ees . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Probl ematique de la cohabitation de plusieurs etoiles sur un m edium commun 2.3 Etude du protocole mis en uvre . . . . . . . . . . . . . . . . . . . . . . . . . ements du r 2.3.1 El eseau, liens et port ees . . . . . . . . . . . . . . . . . . 2.3.2 Organisation temporelle de lacc` es au m edium . . . . . . . . . . . . 2.3.3 M ecanisme de demande de r eservation du m edium . . . . . . . . . . 2.3.4 Allocations au pr ealable : arriv ees d eterministes dans le r eseau . . . 2.3.5 Gestion des acquittements . . . . . . . . . . . . . . . . . . . . . . . 2.3.6 Gestion et diusion des informations de r eservation . . . . . . . . . 2.3.7 Un exemple de demande de r eservation du m edium . . . . . . . . . 2.3.8 Une politique dacc` es d eterministe par d efaut . . . . . . . . . . . . .
85 85 86 86 86 87 87 87 87 88 89 90 90 91 92 92 93 94 94 95 96 96 99
` QUALITE DE SERVICE POUR DES TRANSPORTS DINFORMATIONS A ` CHAPITRE 3. VERS UN WPAN A FORTES CONTRAINTES TEMPORELLES
Optimisation de lacc` es au m edium : attribution de GTS simultan es 2.3.9.1 Le principe . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.9.2 N ecessit e dune n egociation protocolaire . . . . . . . . . . . 2.3.9.3 Application ` a notre topologie . . . . . . . . . . . . . . . . . 2.4 Impl ementation du protocole : int egration dans une pile IEEE 802.15.4 . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.9
100 100 100 102 104 105
84
Une application typique de robotique mobile communicante sans l
Dans cette partie, nous pr esentons une application typique de robotique mobile dont les besoins en terme de communication nous permettent de d enir un cahier des charges pour notre r eseau.
1.1
Probl ematique g en erale : pourquoi introduire des communications sans l pour des robots ?
Dans une application de robotique communicante, les robots communiquent, soit avec une ou plusieurs entit es de commande, soit avec dautres robots. On parlera dans ce dernier cas de robots coop erants. Notre application prend place dans ce domaine de la robotique mobile. Notre application comprend deux objectifs :
1. dune part, la suppression des nombreux c ablages internes aux robots mobiles autonomes, ceci dans le but de faciliter leur fabrication et leur maintenance, de les all eger, et de pouvoir rapidement les r eparer ou les modier sans c ablage complexe (capteurs interchangeables, temporaires), 2. dautre part, la communication des robots entre eux au travers dun m eme canal de communication.
Ce dernier point sur lunicit e du canal de communication est fondamental. En eet, dun point de vue protocolaire, si le syst` eme de communication utilise plusieurs canaux et un seul r ecepteur par robot (un seul canal accessible ` a un instant t ), il devient tr` es complexe de suivre simultan ement sans perte de temps toutes les communications de type point/multipoints1 . De plus, si le syst` eme peut fonctionner sur un canal unique, rien nemp eche ensuite de d evelopper un applicatif utilisant plusieurs canaux. Dun point de vue applicatif, lunicit e du canal de communication est tr` es int eressante dans le cadre de robots coop erants car les informations issues des capteurs internes ` a un robot peuvent etre r ecolt ees a tout moment par tous les autres robots, y compris de mani` ` ere passive si les capteurs du robot no 1 peuvent emettre jusquau robot no 2. Si lon consid` ere simplement deux robots coop erants qui evoluent dans un m eme milieu, chaque robot pourra alors proter des capteurs de son associ e. La facult e ainsi d evelopp ee qui consiste ` a voir dans les yeux de lautre est int eressante car les robots re coivent alors plus dinformations et peuvent acc eder ` a une meilleure connaissance du milieu dans lequel ils evoluent. Si lun des robots subit une panne li ee ` a un environnement hostile (chaleur excessive, chute dans une cavit e, etc.) et sil est equip e dun capteur capable de d etecter un tel ev enement, les autres robots de la otte sont imm ediatement pr evenus. Ils peuvent ainsi prendre connaissance du danger et r eagir en cons equence par anticipation avant m eme que leurs propres capteurs ne d etectent le probl` eme. La fonctionnalit e de voir dans les yeux de lautre se justie dautant plus que les robots mobiles sont par d enition des entit es embarqu ees, donc contraintes energ etiquement. La multiplicit e des voies dacquisition de donn ees constitue un moyen int eressant d economiser de l energie au niveau applicatif puisquune information acquise par un capteur dun autre robot de la otte coop erante nest plus ` a acqu erir. De plus, de nombreux roboticiens sont frein es par la lourde et in evitable complexit e inh erente ` a la pause dun nouveau capteur sur un robot, surtout si ce robot est un prototype en constante evolution. Le d eveloppement dun capteur totalement autonome (sans l, y compris en alimentation [LLI2 06]), de petite taille, avec une tr` es grande facilit e de xation (type aimant sur un carter) donnerait plus de exibilit e` a la construction de robots multi-sensoriels.
1 Cest ` a dire des communications dont l emetteur envoie des messages ` a destination de plusieurs points comme dans le cadre dune diusion g en erale (broadcast ) ou dune diusion par classes (multicast ).
85
1.2
1.2.1
Les attentes vis-` a-vis dun syst` eme de communication adapt e

Un syst` eme proposant des garanties sur le plan temporel
Notre application n ecessite un support de communication tr` es able ; les ordres transmis, cest-` adire les donn ees achemin ees par le r eseau, doivent bien s ur arriver sans erreur ` a leur destinataire, mais aussi ` a temps. Le syst` eme de communication doit donc int egrer des propri et es de Qualit e de Service (QdS3 ), pour pouvoir proposer des garanties sur le transport de linformation, notamment sur le d elai dacheminement et sur les pertes des paquets comme le proposent certaines technologies de bus de terrain et/ou R eseaux Locaux Industriels [THOM 05]. Cependant, nous lavons vu dans le premier chapitre de cette th` ese, de nombreuses technologies WLAN3 /WPAN3 proposent des m ecanismes de QdS, mais ceux-ci sont g en eralement incomplets quand ils sont disponibles mat eriellement [VAL 05]. Dun autre c ot e, il faut garder ` a lesprit que toute technologie de transmission utilisant les ondes hertziennes sera soumise ` a de nombreuses perturbations et ` a un aaiblissement signicatif du signal avec la distance ou les obstacles. La mobilit e des robots entra ne egalement des probl ematiques car le r eseau est mobile (probl ematiques de niveau physique : eet doppler, adaptation du r ecepteur, etc. mais aussi probl ematiques de niveau r eseau : routage, etc.). Toutes ces contraintes impos ees par la nature et par lapplication limiteront fortement et dans tous les cas la port ee et les d ebits dune transmission r ealis ee sur le m edium immat eriel.
1.2.2
Retransmissions vs. redondance et codes correcteurs derreurs
Proposer des garanties temporelles sur un r eseau sans l, qui de plus est bas e sur un m edium partag e, nest pas chose facile. Les perturbations ponctuelles qui aecteront la transmission pourront occasionner des erreurs, qui, si elles sont d etect ees, donneront lieu ` a des retransmissions. La r e- emission des donn ees est n ecessaire pour assurer lint egrit e de la transmission. Cependant, les donn ees r e- emises : diminuent le d ebit ecace de la transmission (m eme message envoy e` a plusieurs reprises), augmentent le d elai de transmission, ce qui impacte la latence globale du transport de linformation, occasionnent des pertes d energie puisque les donn ees sont retransmises une nouvelle fois. De plus, un syst` eme de abilisation par retransmission n ecessite une gestion de messages dacquittement qui contribuent ` a la surcharge du canal et ` a laugmentation des d elais pour la communication globale : pour certaines applications de r eseaux de capteurs, la dur ee de validit e dune information est si courte que lobsolescence du message est certaine d` es la premi` ere retransmission. De part la nature des donn ees v ehicul ees (donn ees issues de capteurs/actionneurs qui imposent de fortes contraintes temporelles) et le caract` ere embarqu e (qui impose de fortes contraintes energ etiques) le syst` eme de communication adapt e` a une application de robotique mobile devra donc imp erativement proposer des m ecanismes de gestion du m edium qui limitent le ph enom` ene des retransmissions. Fort heureusement, les m ecanismes de retransmissions ne sont pas les seules solutions pour abiliser une transmission de donn ees. Les codes correcteurs derreurs constituent egalement un moyen pour abiliser un transport dinformations, mais cette fois-ci sans augmenter exag er ement la latence de transmission, si ce nest par le volume des donn ees ` a transmettre plus important2 . Les techniques de corrections par codes correcteurs sont nombreuses (codage canal, FEC, codes de Hamming, codes convolutionnels, turbocodes, Reed Salomon, etc.). De plus, les avanc ees technologiques dans le domaine de la micro- electronique permettent dint egrer les algorithmes de d etection/correction derreurs directement dans le silicium, int egration synonyme de performances sur les plans temporel et energ etique. Cependant, les codes correcteurs pr esentent un inconv enient : ils sont consommateurs de bande passante
2 Avec un syst` eme de abilisation des donn ees bas e sur les retransmissions, le risque est davoir une gigue de transmission importante. Avec un syst` eme bas e sur des codes correcteurs, toutes les transmissions seront l eg` erement plus longues (plus de donn ees ` a transmettre : temps de s erialisation et temps de traitement) mais la gigue sera th eoriquement plus faible.
86
mais, a priori ce dernier point nest pas g enant dans notre application o` u le volume des informations echang ees reste tr` es faible (comme dans tout r eseau industriel de capteurs). Dun point de vue applicatif, il est egalement possible de doubler les envois de messages (sur echantillonnage ) pour palier aux eventuelles pertes dues ` a un taux derreur bit trop important.
1.2.3
Taille du r eseau
Lapplication propos ee requiert un r eseau relativement petit et de dimension nie : dune part, le nombre dentit es communicantes est faible on pourra consid erer quil ny aura pas plus de 20 nuds connect es et la phase de passage ` a l echelle tiendra compte de cette hypoth` ese et dautre part, toutes les entit es sont connues ` a lavance.
1.2.4
Topologie du r eseau
Comme nous lavons evoqu e plus haut, lobjectif du r eseau de communication dans cette application est double : dune part, de permettre la communication entre capteurs, actionneurs et unit e de contr ole/commande dun m eme robot et dautre part, de permettre ` a une otte de robots coop erants de communiquer entre eux, voire avec lext erieur (une unit e de t el ecommande, de gestion/administration ou bien encore une passerelle vers un autre r eseau comme Ethernet ou m eme Internet).
1.2.4.1
Communications locales au robot
Concernant le premier objectif les communications locales ` a un robot cest naturellement une topologie en etoile qui est propos ee, etoile qui a pour centre lunit e de contr ole/commande du robot et autant de branches que le robot compte de capteurs et dactionneurs. La topologie en etoile convient parfaitement ` a notre application car avec cette topologie, tous les messages passent par le point central, ce qui correspond bien au cheminement naturel des donn ees dans le cadre de notre application : on voit mal en eet, dans notre application, comment un capteur pourrait prendre linitiative denvoyer un ordre ` a un actionneur sans passer par le centre de contr ole/commande. M eme dans un cas dextr eme urgence o` u une information capt ee n ecessite une intervention imm ediate (freinage soudain, changement de direction pour eviter un obstacle impr evu, etc.), le capteur doit n ecessairement informer le centre de contr ole car celui-ci est le seul ` a conna tre tous les el ements n ecessaires pour d ecider de laction ` a mener (vitesse de d eplacement, pr esence ou non dobstacles lat eraux ou arri` eres, etc.). En revanche, lexemple montre quil est absolument n ecessaire de pouvoir compter sur un syst` eme de communication tr` es able, tant sur lint egrit e des donn ees que sur leur temps dacheminement par le r eseau, notamment pour des messages qui pourraient etre consid er es comme critiques pour le robot. Lexemple montre aussi que tous les messages multiplex es ne sont pas egaux sur le plan de la priorit e : le syst` eme doit donc etre en mesure de pouvoir plusieurs classes pour pouvoir rendre certains messages plus prioritaires. Le centre de contr ole/commande jouera le r ole de coordinateur d etoile (FFD3 , ZR3 ), les cap3 3 teurs/actionneurs seront des nuds terminaux (RFD , ZED ). La gure 3.1 illustre la topologie du r eseau propos e pour la communication interne au robot ou charriot.
1.2.4.2
Communications entre robots
Concernant le second objectif les communications entre robots cest une topologie en point ` a point qui est propos ee. Les robots entrent directement en communication les uns avec les autres, selon les besoins de coop eration. Chaque centre de contr ole/commande peut etablir un lien point ` a point avec un autre centre de contr ole/commande et router une information issue de lun de ses capteurs vers Adrien van den Bossche 87
Fig. 3.1 Topologie propos ee pour la communication interne au robot
les autres robots ou interpr eter un message issu de lun de ses collaborateurs. Eventuellement, si deux robots d esireux de communiquer ensemble ne sont pas a ` port ee radio lun de lautre, un dispositif de routage assurera la connectivit e. Ajoutons que dans le cadre de notre application, il est egalement possible de rencontrer un autre type dentit e : un coordinateur d epourvu de nud terminal, soit parce que ses nuds sont tous inactifs pour une dur ee prolong ee, soit parce quil nest li e ` a aucun capteur ou actionneur. Cette entit e peut par exemple etre une entit e xe comme une balise de localisation, une passerelle vers un autre r eseau (Internet...). La gure 3.2 illustre la topologie du r eseau propos e pour la communication entre les robots de la otte coop erante.
Fig. 3.2 Topologie propos ee pour la communication entre robots Les deux topologies evoqu ees doivent, bien entendu, pouvoir coexister et les m ecanismes de QdS impl ement es pour chacune des m ethodes dacc` es ne doivent pas se perturber, mais au contraire garantir leurs propri et es respectives sur lensemble du r eseau.
1.2.5
D ebit n ecessaire
A premi` ere vue, le d ebit n ecessaire pour notre application est assez faible car les informations issues des capteurs sont g en eralement peu volumineuses, tout au plus quelques octets ` a chaque transfert suscit e 88 Groupe SCSF LATTIS EA4155
par une nouvelle mesure. Cependant, le d ebit n ecessaire peut rapidement augmenter : si les capteurs envoient des informations tr` es fr equemment ; un capteur tr` es sollicit e ou un actionneur n ecessitant d etre inform e en permanence risque de monopoliser le m edium et augmenter consid erablement les besoins en d ebit, si le nombre de capteurs est elev e ; le m edium etant partag e entre toutes les entit es communicantes, plus il y a dentit es, plus le d ebit sur le m edium doit etre important pour satisfaire toutes les communications, si le nombre de robots est important ; m eme remarque que la pr ec edente, les robots partageant le m eme m edium, si le protocole utilis e g en` ere beaucoup dinformations non utiles (en-t ete, etc.) ; typiquement, dans notre application, les donn ees echang ees sont tr` es courtes mais peuvent etre nombreuses et fr equentes. Si la technologie r eseau choisie pr esente un overhead 3 important ou n ecessite l echange de nombreux messages de gestion ou de signalisation, le d ebit n ecessaire sera important, m eme si la charge utile est faible, si lacc` es au m edium est mal organis e ; lacc` es etant multiplex e et les informations v ehicul ees courtes (trames courtes), les occasions dacc` es au m edium seront tr` es fr equentes. Si lacc` es au m edium est mal coordonn e, le ph enom` ene des collisions risque de g en erer de nombreux echecs de transmission et, de ce fait, augmenter les retransmissions, tr` es consommatrices en bande passante (et accessoirement en energie). Il est donc n ecessaire de dimensionner le r eseau en cons equence (nombre de robots et nombre de capteurs par robot limit e comme nous lavons evoqu e plus haut) et de choisir une technologie de transmission pr esentant ` a la fois un protocole simple et peu consommateur de bande passante (ce qui rejoint les attentes dun point de vue energ etique) et une m ethode dacc` es au m edium tr` es performante et adapt ee aux petits paquets dinformations envoy es r eguli` erement. Les analyses de performances pr esent ees dans le chapitre 4 indiqueront des valeurs num eriques de r ef erence, acceptables en terme de latence et de d ebit.
1.2.6
Conclusion
Lapplication typique pr esent ee ici n ecessite nalement un syst` eme de communication sapparentant ` un R a eseau Local Industriel sans l. Les besoins de communication peuvent etre r esum es en quelques points ; le syst` eme propos e doit : 1. pr ef erer la abilit e et la stabilit e` a un d ebit important, 2. mettre en uvre un protocole l eger, 3. proposer des outils pour garantir la remise des donn ees au destinataire, 4. permettre de pr evoir plusieurs classes de tracs (utilisation du m edium, notion de priorit es), 5. conna tre a priori les nuds terminaux potentiels, 6. etre peu consommateur d energie. Dans le chapitre pr ec edent, nous avions pr esent e dans le d etail la norme IEEE 802.15.4/ZigBee qui propose des couches basses tr` es int eressantes au vu de ce que requiert notre application. Nous nous sommes donc tourn es vers cette technologie que nous avons largement modi ee pour pouvoir proposer une nouvelle m ethode dacc` es au m edium totalement d eterministe. De plus, la disponibilit e mat erielle, le co ut tr` es abordable de cette technologie et la possibilit e de pouvoir reprogrammer toute la couche 2 nous ont permis dentrevoir des possibilit e de prototypage r eel tr` es int eressantes dont les r esultats seront expos es dans le chapitre 4.
89
La proposition protocolaire
Nous venons d evoquer les besoins en communication dune application typique de robotique mobile et dans le chapitre pr ec edent, nous avions pr esent e les normes et sp ecications IEEE 802.15.4 et ZigBee ; nous avions alors soulign e que le m ecanisme de r eservation de bande passante (GTS3 ) propos e par lIEEE est int eressant, mais pourrait etre am elior e par la proposition dune m ethode dacc` es au m edium plus orient ee d eterminisme et par lintroduction dune certaine souplesse au niveau des possibilit es de r eservation du m edium sans l. Dans cette partie, nous pr esentons une m ethode dacc` es au m edium totalement d eterministe [VDB 06] [VDB 07] qui permettrait ` a IEEE 802.15.4/ZigBee [IEE2 03] [ZBAL 05] ou ` a dautres technologies WLAN/WPAN de pouvoir etre utilis ees dans le cadre dapplications ` a fortes contraintes temporelles comme lapplication typique qui vient d etre evoqu ee.
2.1
Nouvelles fonctionnalit es propos ees
Avant de d etailler les m ecanismes que nous proposons, listons ci-apr` es les fonctionnalit es que nous ajoutons par rapport ` a lexistant : 1. Dans 802.15.4, seuls les nuds terminaux peuvent demander un GTS pour eux-m emes. Dans notre proposition, un coordinateur peut d ecider dattribuer un GTS ` a nimporte lequel de ses correspondants, m eme si celui-ci nest pas encore associ e` a ce m eme coordinateur. Cette nouvelle fonctionnalit e va permettre de r ealiser des associations d eterministes au r eseau. Nous appellerons par la suite ce GTS attribu e au pr ealable PDS 3 , pour Previously Dedicated Slot. 2. Dans 802.15.4, aucun m ecanisme de communication entre coordinateurs nest pr evu pour garantir que deux GTS ne soient pas attribu es au m eme instant par deux coordinateurs di erents qui cohabitent dans la m eme zone de port ee radio et sur le m eme canal radio. Dans notre proposition, nous proposons un m ecanisme pour emp echer les collisions de GTS entre etoiles di erentes. 3. Dans 802.15.4, les GTS sont plac es dans la CFP3 qui se trouve toujours en n de supertrame. Dans notre proposition, il ny a plus de d elimitation pour la CFP, elle est r epartie, diffuse, dans la supertrame. Les GTS peuvent etre dispos es ` a tout instant dans la supertrame, ce qui va nous permettre doptimiser cette r epartition en tenant compte des GTS attribu es dans les autres etoiles. Comme dans 802.15.4, cette r epartition est indiqu ee ` a tous les nuds terminaux par le coordinateur dans la trame beacon quil envoie syst ematiquement en d ebut de supertrame. 4. Dans 802.15.4, les GTS allou es sont pr esents dans chaque supertrame. Dans notre proposition, chaque GTS peut etre pr esent, au choix, dans toutes les supertrames, dans une supertrame sur deux, une sur quatre ou une sur huit, etc. On parlera de plusieurs niveaux de r eservation not es n, avec, pour le cas de notre etude3 : n = 0, 1, 2 ou 3. La p eriode P des supertrames comprenant ce GTS dun niveau de r eservation n est d enie ainsi : P = 2n Un niveau de r eservation n = 0 r eservera un slot dans chaque supertrame (fr equence la plus elev ee), un niveau n = 1 r eservera un slot toutes les deux supertrames, un niveau n = 2 toutes les quatre supertrames, un niveau n = 3 toutes les huit supertrames (fr equence la plus faible). Ce dernier point va permettre ` a des tracs di erents mais ` a QoS 3 de pouvoir cohabiter au sein dune m eme etoile. En revanche, comme dans la norme initiale, les GTS peuvent toujours occuper plusieurs slots de la m eme supertrame si n ecessaire.
3 Pour des questions de restriction au niveau de limpl ementation, nous avons x e arbitrairement une limite maximum de 8 supertrames, soit quatre niveaux n, mais cette limite peut etre tout ` a fait repouss ee.
90
5. Dans 802.15.4, les GTS sont attribu es pour un nombre limit e de supertrames, la prolongation du bail ne pouvant se faire que par une nouvelle demande, cest ` a dire une reprise compl` ete du processus de requ ete. De plus, comme cette demande est eectu ee par lutilisation du protocole dacc` es au m edium non d eterministe CSMA/CA3 , la continuit e du service d eterministe ne peut etre garantie. Dans notre proposition, les GTS sont allou es sans limite temporelle, jusqu` a la r eception dune demande de rel achement venant du nud terminal concern e ou dune notication de rel achement venant du coordinateur (timeout sur inactivit e, par exemple). 6. Dans 802.15.4, toutes les entit es du r eseau emettent ` a une puissance constante dans le temps. Cette puissance peut etre di erente dun el ement ` a lautre, mais la norme ne pr evoit pas de variation par le protocole. Dans la proposition faite, les puissances d emission peuvent varier dynamiquement pour cr eer articiellement des zones sans collision , cest-` a-dire des zones g eographiques distinctes et identi ees comme susamment eloign ees pour que deux nuds terminaux puissent acc eder au m edium simultan ement sans que la r eception de leurs messages respectifs ne soit alt er ee. Gr ace ` a cette fonctionnalit e, deux coordinateurs identi es comme susamment loin lun de lautre peuvent attribuer deux GTS sur le m eme slot temporel. Ces nouvelles fonctionnalit es etant expos ees, nous allons d etailler leur mise en oeuvre dans la suite de ce chapitre.
2.2
Probl ematique de la cohabitation de plusieurs etoiles sur un m edium commun
Dans le cadre dun r eseau constitu e dune seule etoile, le coordinateur unique est le seul ` a d ecider de lattribution ou non des GTS. Si plusieurs coordinateurs cohabitent dans la m eme zone et occupent le m eme canal, les d ecisions dattribution de GTS doivent etre prises coll egialement. De ce fait, il nest pas possible de consid erer un r eseau ` a plusieurs etoiles comme une simple agr egation d etoiles g er ees individuellement. Dans l etat actuel de 802.15.4, un coordinateur annonce la r epartition des GTS dans sa trame balise : une solution simple consisterait en une ecoute passive pour chaque coordinateur des beacons emis par ses voisins pour eviter dattribuer un GTS ` a linstant o` u un coordinateur voisin a d ej` a attribu e un GTS ` a lun de ses nuds terminaux. De plus, dans notre proposition, nous pr evoyons la possibilit e pour certains GTS de revenir cycliquement toutes les deux, quatre ou huit supertrames. Comme pour lattribution dun GTS classique, cette d ecision doit prendre en compte la charge du r eseau, mais notre proposition implique une vision globale a plus long terme. En eet, plus les GTS sont attribu ` es avec raret e, plus le volume dinformations ` a prendre en compte pour le m ecanisme de r eservation coll egial est important : plus le niveau de r eservation n est elev e, plus la port ee de la vision doit etre grande. Cette fonctionnalit e augmente la complexit e relative de la prise de d ecision coll egiale pour lattribution des GTS car la trame balise nannonce que la r epartition des GTS pour la supertrame qui d ebute, et non pour les suivantes. Les coordinateurs voisins ne peuvent pas conna tre lint egralit e des d ecisions prises en interne du coordinateur, puisquils ne connaissent, au moment de la r eception de la balise, que la r epartition pour la supertrame qui vient de commencer. Il est donc n ecessaire de mettre en place une solution qui emp echera plusieurs coordinateurs dattribuer un m eme slot temporel ` a plusieurs nuds du r eseau. Deux solutions sont envisageables pour palier ` a ce probl` eme. Une premi` ere solution consiste pour chaque coordinateur ` a diuser toute d ecision prise ` a lensemble des voisins, par exemple dans les beacons, que cette d ecision concerne la supertrame en cours ou les suivantes. Ainsi, les voisins sont inform es et peuvent eviter dattribuer des slots r eserv es par dautres coordinateurs. Cette solution a lavantage d etre d ecentralis ee, mais ne r` egle cependant pas deux probl` emes : 1. tous les coordinateurs doivent etre ` a port ee radio les uns des autres,
91
2. d` es leur arriv ee dans le r eseau, les coordinateurs doivent r epartir leurs trames beacons respectives de mani` ere d eterministe pour ne pas cr eer de collisions ni avec les autres tracs etablis sur le r eseau ni avec les autres beacons, ce qui est un probl` eme complexe, surtout pour les phases transitoires dinsertion et de d epart dun coordinateur dans le r eseau mobile. Une seconde solution, qui est celle qui a et e retenue, consiste ` a centraliser toutes les demandes de r eservation du m edium. Les demandes sont achemin ees jusqu` a une entit e sp eciale qui a connaissance de tous les slots r eserv es ` a plus ou moins br` eve ech eance : cette entit e donne son accord et nous evitons alors les collisions de GTS. Si cette station ` a r ole central est ` a port ee radio de tous les coordinateurs, elle peut du m eme coup r egler les probl` emes du coordinateur cach e et de la synchronisation entre coordinateurs, en r epartissant elle-m eme les beacons de tous les coordinateurs. Cette r epartition peut se faire tr` es simplement, sous la forme de plusieurs GTS quelle accorde aux coordinateurs (un GTS par coordinateur) et qui serviront ` a emettre les beacons de ceux-ci sans risquer de provoquer des collisions. Comme nous lavons vu dans le chapitre 2, ZigBee pr evoit dans sa sp ecication une entit e sp eciale, le coordinateur de PAN (ou supercoordinateur ) dont le r ole central est dattribuer des adresses aux nuds qui sins` erent dans le r eseau, dop erer un changement de canal si besoin, etc. Nous avons donc ici retenu cette deuxi` eme solution, qui est certes plus centralis ee mais qui correspond mieux ` a lid ee de base de ZigBee, qui est un r eseau proposant une architecture assez centralis ee. Le supercoordinateur sera donc en mesure de distribuer des GTS d edi es aux beacons des coordinateurs d etoile. Nous appellerons par la suite ces GTS d edi es aux beacons GBS 3 , pour Guaranteed Beacons Slots.
2.3
2.3.1
Etude du protocole mis en uvre

ements du r El eseau, liens et port ees
Comme le proposent 802.15.4 et ZigBee, notre proposition pr evoit trois cat egories de nuds communicants : 1. un supercoordinateur, unique, 2. un coordinateur pour chaque etoile, 3. un ou plusieurs nuds terminaux par etoile. Dans un premier temps, nous consid ererons que le supercoordinateur ne fait que supercoordonner , bien quil puisse lui aussi g erer sa propre etoile et ses nuds terminaux comme un coordinateur normal. Le r eseau compte deux types de liens de communication : 1. un premier type entre le supercoordinateur et ses coordinateurs, 2. un second type entre les coordinateurs et leurs nuds terminaux, dialogues r ealis es au sein de chaque etoile. La topologie propos ee implique des port ees minimales qui sont d enies ainsi : 1. Les coordinateurs d etoiles doivent etre ` a port ee du supercoordinateur, 2. Les nuds terminaux doivent etre ` a port ee de leur coordinateur, La premi` ere hypoth` ese r` egle le probl` eme du coordinateur cach e mais contraint fortement le syst` eme de communication radio. Nous serons certainement amen es ` a proposer ult erieurement une am elioration du protocole pour parvenir ` a une solution moins contraignante4 .
4 Nous avons vu dans le chapitre 2 que certains modules ZigBee comme les XBeePRO de MaxStream [MAXS] permettent datteindre des port ees tr` es importantes (1,6 km en champ libre) ; cette hypoth` ese nest donc pas si contraignante dans la r ealit e dune otte de robots coop erents eloign es tout au plus de quelques dizaines de m` etres. . .
92
La topologie propos ee et les port ees minimales sont repr esent ees sur la gure 3.3. Bien entendu, les port ees radio peuvent etre plus etendues ; ici, seules les port ees minimales et n ecessaires au bon fonctionnement du protocole ont et e repr esent ees.
ements du r Fig. 3.3 El eseau, liens et port ees minimales pour le bon fonctionnement du protocole
2.3.2
Organisation temporelle de lacc` es au m edium
Dans notre proposition, nous conservons la notion de supertrame. Celle-ci permet de num eroter les slots et permet une synchronisation de toutes les entit es de notre r eseau. De plus, le m ecanisme de r eservation du m edium m eme sil comporte quelques failles que nous nous proposons de combler sappuie avantageusement sur le principe de supertrame. Dans notre proposition, la supertrame compte toujours 16 slots et commence toujours par une trame balise qui occupe le premier slot. En revanche, dans 802.15.4, chaque coordinateur d ebute sa supertrame d` es quil le souhaite ; chaque coordinateur etant ind ependant sur le plan de la synchronisation, il ny a aucune raison quelles soient synchrones : des collisions de beacons sont donc probables (cf. chapitre 2, section 2.4.6, page 76). Dans notre proposition, seul le supercoordinateur est habilit e` a choisir le moment o` u la supertrame d ebute. De plus, il ny a plus quune supertrame pour tout le r eseau car tous les coordinateurs sont synchronis es. Nous appelons superbeacon le Beacon emis par le supercoordinateur ; le superbeacon occupe syst ematiquement le slot 0 de chaque supertrame. Les beacons normaux (ceux emis par les coordinateurs d etoile) sont plac es par le supercoordinateur dans les GBS. Pour les nuds terminaux dune etoile, la supertrame ne commence pas sur le slot 0 pour se nir sur le slot 15, mais commence sur le slot i pour se terminer sur le slot i - 1. La gure 3.4 illustre une r epartition des beacons via les GBS pour plusieurs coordinateurs dans une etoile. Ici, la supertrame du coordinateur 1 commence au slot 4 et se termine au slot 3 suivant. Le fait de m elanger les supertrames de chaque coordinateur dans la supertrame du supercoordinateur (au lieu de les faire se succ eder dans le temps) permet aux nuds terminaux de pouvoir emettre des messages ` a des intervalles de temps plus rapproch es, favorisant ainsi les transports dinformations qui n ecessitent une faible latence de transmission. Pour que les beacons puissent etre dius es sans risquer dentrer en collision avec un autre message, les slots quils occupent leur sont d edi es (GTS montants) par le supercoordinateur comme nous lavions Adrien van den Bossche 93
evoqu e dans la partie 2.2. Cest le supercoordinateur qui choisit la valeur de i pour chaque coordinateur. Ainsi, comme nous lavons propos e dans la section pr ec edente, le supercoordinateur peut r epartir les emissions des beacons dans la supertrame, par exemple en la divisant en parts egales comme dans le cas de la gure 3.4. Dans ce cas illustr e, i (1) = 4, i (2) = 8 et i (3) = 12 (1, 2 et 3 etant les num eros de 3 coordinateurs pr esents dans le r eseau).
Fig. 3.4 R epartition des beacons au sein de la supertrame Le fait de centraliser la r epartition des beacons dans le supercoordinateur peut en m eme temps r egler le probl` eme du coordinateur cach e ainsi que lentr ee d eterministe dun coordinateur dans le r eseau, comme nous allons le voir plus bas dans le paragraphe 2.3.4.
2.3.3
M ecanisme de demande de r eservation du m edium
Pour pouvoir accorder un GTS ` a lun de ses nuds terminaux, un coordinateur doit dabord envoyer une requ ete au supercoordinateur et obtenir une r eponse positive. Seul le supercoordinateur a une vision exhaustive de la r epartition du m edium pour les 2nM AX supertrames ` a venir (dans notre cas, 2nM AX vaut 8). Compte tenu de nos objectifs en terme de d eterminisme pour lacc` es au m edium, la requ ete de demande de r eservation envoy ee par un coordinateur au supercoordinateur doit etre egalement emise sur le m edium de mani` ere d eterministe (toute la cha ne doit etre d eterministe pour que le r esultat soit d eterministe !). Pour ce faire, les dialogues entre le supercoordinateur et les coordinateurs prennent place dans des slots d ej` a attribu es par le supercoordinateur pour chacun de ses coordinateurs : les GBS. La r eutilisation des slots d edi es aux beacons permet d economiser loccupation du m edium, il nest pas n ecessaire dallouer un slot suppl ementaire aux coordinateurs pour dialoguer avec le supercoordinateur puisquils poss` edent d ej` a un tel slot. Dans notre proposition, les messages GTS.requests seront inclus dans le champ data de la trame Beacon au lieu d etre emis via une trame MAC ` a part. La sp ecication de ce proc ed e dencapsulation sera d ecrite dans la partie 2.4 de ce chapitre.
2.3.4
Allocations au pr ealable : arriv ees d eterministes dans le r eseau
Nos objectifs en terme dacc` es d eterministe au m edium impliquent que toutes les op erations r ealis ees sur le r eseau soient faites de mani` ere d eterministe. Notre proposition pr evoit donc une possibilit e de r eservation de slots au pr ealable , pour certains nuds, cest-` a-dire avant m eme que ces nuds soient associ es au r eseau ou quils aient demand e des ressources. Cette fonctionnalit e est indispensable pour garantir les propri et es d eterministes de notre r eseau pendant toutes les phases de son fonctionnement. Elle est rendue possible car le r eseau consid er e est petit et il est possible de conna tre toutes les entit es potentielles et de leur aecter manuellement et a priori une adresse avant la phase de cr eation de ce WPAN. Gr ace ` a cette fonctionnalit e, le supercoordinateur peut, d` es sa mise en fonction (cest-` a-dire d` es le d ebut de la cr eation du r eseau), r eserver quelques slots pour certains nuds, par exemple pour les coordinateurs attendus ou des nuds critiques. Cette r eservation se concr etise par lattribution de GBS 94 Groupe SCSF LATTIS EA4155
ou GTS montants ` a un nud avant son arriv ee dans le r eseau. Cette attribution au pr ealable peut se faire avec un niveau n M AX (la fr equence de r eservation la plus faible, un GBS/GTS toutes les huit supertrames) ce qui laisse la possibilit e au nud concern e de pouvoir emettre de fa con d eterministe une trame dassociation quelque temps apr` es son r eveil, tout en minimisant les pertes de bande passante dans lattente de larriv ee de ce nud. A titre dexemple, pour BO 3 = 3, cest-` a-dire un intervalle interbeacon de 122,88 ms, une r eservation au pr ealable avec un niveau n = 3 permet de pratiquer larriv ee d eterministe dun certain nud toutes les 983,04 ms (soit environ toutes les secondes5 ) pour seulement 1/128ime (soit 0,78%) de la bande passante perdue, ce qui est relativement faible. Le graphique de la gure 3.5 donne les p eriodes de cycles d eterministes et la bande passante perdue en fonction du niveau de r eservation nP DS (0, 1, 2 ou 3) et pour di erentes valeurs de BO. Notons que la part de bande passante perdue ne d epend pas du param` etre BO.
Fig. 3.5 P eriodes des cycles d eterministes en fonction du niveau de r eservation du PDS Le graphique de la gure 3.5 constitue un abaque int eressant pour lutilisateur d esirant dimensionner le r eseau en fonction dun cahier des charges imposant une certaine latence de transmission.
2.3.5
Gestion des acquittements
Dans notre proposition, la gestion des acquittements reste similaire ` a ce que propose le standard IEEE 802.15.4. L emetteur dune trame positionne ou non le bit ACK_request dans chaque trame emise. A la r eception, si le bit est positionn e, le r ecepteur doit acquitter en envoyant une trame dacquittement. Le temps inter-trames s eparant la trame ` a acquitter et lacquittement nest pas le m eme dans toutes les situations. Deux cas se pr esentent : 1. si la trame est envoy ee dans le cadre dun acc` es au m edium d eterministe, la transmission de lacquittement doit se faire apr` es un temps de aTurnaroundTime symboles (12 symboles, soit 192 s) apr` es la r eception du dernier symbole re cu comme le d enit le standard 802.15.4 pour les trames envoy ees dans un GTS, 2. si la trame est envoy ee dans le cadre dun acc` es au m edium al eatoire, la transmission de lacquittement doit se faire au d ebut du slot CSMA/CA suivant (l` a encore, comme 802.15.4 le pr evoit).
5 Bien entendu, rien nemp eche ce nud de tenter une association le plus t ot possible en suivant la m ethode classique en mode best-eort, comme la norme actuelle le permet.
95
Dans tous les cas, l emetteur consid` ere quune trame non acquitt ee en moins de macAckWaitDuration symboles (54 symboles, soit 864 s) constitue un echec et doit etre retransmise l emetteur a droit ` a MaxFrameRetries (3) tentatives. Comme nous lavons vu dans le chapitre pr ec edent (chapitre 2, section 2.3.3.4, page 68), la trame dacquittement est tr` es simple (en-t ete MAC et num ero de s equence de la trame acquitt ee) et ne permet dacquitter quune seule trame ` a la fois (Send and wait ). De plus, seules les trames unicast de type Donn ees et Commandes MAC peuvent etre acquitt ees. En revanche, ` a la di erence de ce que propose le standard 802.15.4 et an minimiser les acc` es d eterministes au m edium, notamment entre entit es de niveaux di erents, nous proposons dencapsuler certains messages de gestion MAC dans les trames balises. De ce fait, ces messages encapsul es ne sont plus acquitt es et, sils sont perdus, entra nent une latence dans le traitement de la requ ete quils portent car il ne peuvent etre retransmis imm ediatement6 . Cette latence introduite sera lobjet dune etude de performances dans le chapitre suivant.
2.3.6
Gestion et diusion des informations de r eservation
Nous lavons vu plus haut, nous avons choisi une architecture centralis ee o` u le supercoordinateur est le seul nud habilit e` a attribuer des PDS/GBS/GTS. De ce fait, tous les messages de demande de r eservation de m edium (GTS.request) remontent jusqu` a lui. Dans le cadre strict de 802.15.4, non seulement lattribution et la gestion des GTS sont deux t aches locales ` a l etoile mais les GTS, sil y en a, sont pr esents dans chaque supertrame. De ce fait, la r eponse a la demande GTS.request est contenue dans le champ des descripteurs de GTS (GTS descriptor ) qui ` se trouve dans chaque trame beacon : Si un descripteur de GTS portant ladresse du nud demandeur est pr esent, le GTS a bien et e attribu e : la requ ete a donc et e honor ee, Si le beacon ne contient aucun descripteur de GTS avec ladresse du nud demandeur, le GTS na pu etre attribu e : la requ ete na donc pas et e honor ee. Dans la mesure o` u dans notre proposition, les GTS restent p eriodiques mais ne se retrouvent pas forc ement dans toutes les supertrames (nGT S > 0), la r eponse ` a une demande de GTS sous forme dun descripteur de GTS dans le superbeacon qui suit la demande ne peut etre satisfaisante car si le GTS est eectivement attribu e, mais bien plus tard (cest-` a-dire si nGT S est grand), le nud demandeur nobtiendra sa r eponse quau d ebut de la supertrame contenant son premier GTS, ce qui pose un gros probl` eme de latence, surtout pour les nuds critiques. Il serait pr ef erable que la r eponse soit imm ediate, quelle soit positive ou n egative. Nous proposons donc de sp ecier un nouveau message (GTS.response) qui pourra etre envoy e imm ediatement par le supercoordinateur et conrmer si le GTS a et e ou non attribu e, et avec quel niveau de r eservation n. De plus, dans la mesure o` u, dans notre proposition, les demandes de GTS sont relay ees par les coordinateurs jusquau supercoordinateur, la pr esence dun message GTS.response facilitera la communication de bout en bout du r eseau. La structure de ce message sera sp eci ee plus loin dans la partie 2.4 de ce chapitre.
2.3.7
Un exemple de demande de r eservation du m edium
Dans cette partie, nous proposons dillustrer le d eroulement temporel du dialogue protocolaire n ecessaire pour lassociation d eterministe dun nud terminal au r eseau. Lexemple porte sur un r eseau dont la topologie est repr esent ee gure 3.6. Ce r eseau est minimaliste, il ne comprend quun nud terminal, son coordinateur et le supercoordinateur du r eseau. Le d eroulement temporel du dialogue protocolaire
6 Pr ecisons ici quun message de gestion MAC se voit acquitt e simplement pour conrmer quil a et e bien re cu par le destinataire. En aucun cas, lacquittement constitue une r eponse favorable ` a la requ ete eectu ee.
96
Fig. 3.6 Topologie du r eseau mis en place pour lexemple
est illustr e par la gure 3.7. Lobjectif ici est dillustrer l echange des messages n ecessaire pour quun nud terminal obtienne un GTS, et ce, de mani` ere totalement d eterministe, y compris dans sa phase de connexion (association) au r eseau. A l etat initial, les trois el ements du r eseau se connaissent , cest ` a dire que des adresses ont et e attribu ees an de permettre aux di erents nuds de pouvoir r ealiser une entr ee d eterministe sur le r eseau. Dans cet exemple, le supercoordinateur a ladresse 0, le coordinateur ladresse 1 et le nud terminal ladresse 2. Le supercoordinateur et le coordinateur sont synchronis es, ils s echangent des beacons r eguli` erement, ` a chaque supertrame (nGBS = 0). En revanche, bien quil soit connu de son coordinateur et du supercoordinateur, le nud terminal nest pas encore r eveill e. Cependant, lapplicatif pr esent dans le supercoordinateur sait que ce nud terminal est li e` a une fonction critique ; il lui a donc attribu e un PDS qui revient, cycliquement, avec un niveau 3 (nP DS = 3, donc toutes les 8 supertrames). Sur la gure 3.7, les ` eches repr esentent les messages echang es entre un nud source et un nud destination (pointe de la ` eche). Dans la marge de droite, les messages et leur contenu (entre parenth` eses) sont sp eci es dans un formalisme dont la syntaxe est pr ecis ee ci dessous. Cette syntaxe varie dun type de message ` a lautre. Dans lexemple illustr e, nous allons rencontrer quatre sortes de messages : 1. Les demandes de PDS/GBS/GTS : elles sont envoy ees par un nud terminal ou un coordinateur et envoy ees ` a leur entit e p` ere. Elles contiennent simplement le niveau de ressource demand e n. Par exemple, le message GTS_req(level 0) indiquera que le message est une demande de PDS/GBS/GTS et que linitiateur de ce message souhaiterait obtenir un PDS/GBS/GTS de niveau n = 0. Ces messages sont relay es par les coordinateurs en etant encapsul es dans leurs beacons (voir plus bas). 2. Les r eponses aux demandes de PDS/GBS/GTS : elles sont envoy ees en r eponse ` a un GTS_req() par le supercoordinateur et relay ees par les coordinateurs. Elles indiquent le niveau du PDS/GBS/GTS attribu e. Par exemple, le message GTS_resp(level 0) indique dun PDS/GBS/GTS de niveau 0 a et e attribu e7 . Les r eponses aux demandes de PDS/GBS/GTS sont syst ematiquement encapsul ees dans le superbeacon ou le beacon. 3. Les beacons ou superbeacon (m eme syntaxe) : ils contiennent la liste des PDS/GBS/GTS attribu es pour la supertrame en cours (GTS descriptors ). Dans lexemple illustr e, un PDS/GBS/GTS attribu e est not e ainsi : <slot>:<adresse>. Si le beacon doit annoncer lattribution de plusieurs PDS/GBS/GTS, ceux-ci sont alors s epar es par des virgules. Par exemple, le message Superbeacon (8:1,6:2) indiquera que le message transmis est de type beacon et que deux PDS/GBS/GTS ont et e attribu es pour la supertrame qui d ebute ; le premier PDS/GBS/GTS se trouve sur le slot no 8 et est d edi e au nud dadresse 1, le second PDS/GBS/GTS se trouve sur le slot no 6 et est
7 Le
PDS/GBS/GTS est attribu e au destinataire du message, le message etant relay e.
97
Fig. 3.7 Un exemple de d eroulement du protocole 98 Groupe SCSF LATTIS EA4155
d edi e au nud dadresse 2. Comme on la vu plus haut, les beacons peuvent egalement encapsuler dautres messages dans le cadre dun relai de trame ; dans ce cas, le message relay e est indiqu e entre crochets et ladresse du destinataire est indiqu ee dans les crochets : par exemple, le message Beacon(10:2,[2:GTS_resp(level 0)]) indique que le slot no 10 est d edi e au nud dadresse 2, mais aussi quun message de type r eponse ` a la demande dun PDS/GBS/GTS ` a destination du nud 2 doit etre relay e par le coordinateur correspondant. 4. Les donn ees : les donn ees ne comportent pas de param` etres sp eciaux. Pendant tout le dialogue, le supercoordinateur diusera les superbeacons sur tous les slots 0 alors que le coordinateur diusera ses beacons sur tous les slots 8 (nGBS = 0) ; on retrouve cette r epartition dans la premi` ere supertrame de la gure, o` u les beacons constituent lunique trac pendant cette premi` ere p eriode. Le coordinateur sait que son GBS se trouve au slot 8 car le superbeacon lindique par le message Superbeacon(8:1) Pour r epondre ` a nos objectifs en terme de d eterminisme, cest-` a-dire pour pouvoir pratiquer une demande de ressource d eterministe, un PDS de niveau (nP DS = 3) a donc et e allou e au nud terminal, selon le principe de lallocation au pr ealable vu plus haut. Ce slot r eserv e revient donc toutes les huit supertrames (nP DS = 3) et gr ace ` a ce slot d edi e, le nud terminal peut prendre possession du m edium de mani` ere d eterministe, par exemple pour dire quil est maintenant r eveill e et eventuellement demander un ou plusieurs GTS. Au d ebut de notre exemple, le nud terminal vient de se r eveiller. Il reste en r eception pour rechercher le beacon de son coordinateur ; une fois le beacon identi e et interpr et e, le nud terminal est synchronis e et peut passer en mode suivi de beacon (r eception du beacon, interpr etation, puis veille) jusqu` a recevoir un beacon lui indiquant la pr esence de son PDS. Son nP DS etant de 3, il attend au plus 8 supertrames8 . Le PDS avait et e positionn e bien auparavant par le supercoordinateur : puisquil na pas re cu de message de d esallocation du PDS par le supercoordinateur, le coordinateur du nud terminal sait que le PDS se trouvera au cours de la seconde supertrame de la gure. Ce PDS est donc annonc e dans le beacon du coordinateur, via le message Beacon(6:2). Le nud terminal etant en mode suivi de beacon, il apprend alors quil pourra b en ecier dun acc` es d eterministe au prochain slot no 6. Quand arrive le slot no 6, le nud terminal emet une demande de ressources de niveau 0 par le message GTS_req(level 0). Ce message est re cu par le coordinateur qui le relaie au supercoordinateur dans le beacon suivant (proc ed e dencapsulation du message dans le beacon). Le supercoordinateur re coit la requ ete, la traite et retourne une r eponse dans le superbeacon suivant Superbeacon(8:1,10:2,[2:GTS_resp (level 0)]). A son tour, le coordinateur relaie cette r eponse au nud terminal dans le beacon qui suit via le message Beacon(10:2,[2:GTS_resp(level 0)]). Le nud terminal prend alors connaissance de la r eponse et peut (ou non, si la r eponse est n egative) utiliser les ressources quil a demand ees. Dans le cas de lexemple, la r eponse est positive et le nud terminal obtient un GTS de niveau 0 (pr esence dans toutes les supertrames ` a venir).
2.3.8
Une politique dacc` es d eterministe par d efaut
Dans notre topologie, nous avons suppos e que dune part, les coordinateurs doivent tous etre ` a port ee radio du supercoordinateur et dautre part, que les nuds terminaux doivent etre ` a port ee radio de leur coordinateur. En revanche, les coordinateurs ne sont pas oblig es d etre ` a port ee les uns des autres9 et les nuds terminaux ne sont pas oblig es d etre ` a l ecoute du supercoordinateur. Cette derni` ere hypoth` ese concernant les nuds terminaux se justie amplement dun point de vue energ etique : conform ement ` a ce qui est propos e dans la norme 802.15.4, le nud simple, contraint energ etiquement, suit un cycle de fonctionnement adapt e qui limite sa consommation energ etique : il se r eveille, ecoute le beacon de son
8 Cas le plus d efavorable : en eet, il peut aussi le trouver imm ediatement ; le temps n ecessaire d epend de linstant de r eveil ! 9 Nous avons en eet vu plus haut que le probl` eme du coordinateur cach e est r egl e par le supercoordinateur qui rappelle dans tous ses beacons la r epartition temporelle qui est faite dans la supertrame qui commence.
99
coordinateur, utilise le m edium si n ecessaire, puis se rendort. Dun point de vue energ etique, un double suivi de beacon (beacon et superbeacon) serait tr` es mauvais et entra nerait des pertes energ etiques non n egligeables. Les consid erations qui viennent d etre expos ees soul` event un probl` eme concernant le temps de diusion des informations sur la r epartition temporelle du m edium. La n ecessit e de relayer linformation dans la structure ` a trois niveaux (supercoordinateur, coordinateur, nud terminal) et la r epartition dans le temps des beacons au sein de la supertrame entra nent un temps de propagation non n egligeable avant que tous les nuds du r eseau aient connaissance de cette r epartition. En eet, les nuds terminaux du r eseau doivent attendre le beacon de leur coordinateur pour avoir connaissance de la r epartition temporelle du m edium pour la supertrame qui d ebute ` a la r eception de ce beacon. Or, dans notre modication, nous avons supprim e la notion de CAP3 et de CFP, si bien quun slot non annonc e comme r eserv e pourrait etre suppos e comme librement utilisable dans le cadre dun acc` es en mode best-eort. Il est bien evident que ce raccourci ne doit pas etre fait sous peine dentra ner lutilisation en mode al eatoire dun slot r eserv e dans une autre etoile, et ceci en toute bonne foi. Notre r eseau se voit donc dans lobligation dappliquer par d efaut une politique dacc` es au m edium de type d eterministe, cest-` a-dire que tout slot non renseign e est a priori r eserv e et non d edi e au mode best eort, comme cest le cas avec 802.15.4. Le coordinateur dune etoile devra donc rappeler dans chacune de ces balises quels sont les slots r eserv es pour ses nuds terminaux, quels sont les slots libres mais inutilisables car r eserv es dans une etoile voisine, et enn quels sont les slots utilisables via CSMA/CA. Chaque slot devra entrer dans une de ces trois cat egories, ou ` a d efaut, etre consid er e comme non utilisable (deuxi` eme cat egorie).
2.3.9
Optimisation de lacc` es au m edium : attribution de GTS simultan es
Un des probl` emes majeurs de notre m ethode dacc` es est loptimisation du d ebit oert, comme dans toute m ethode dacc` es, en particulier celles bas ees sur TDMA3 . An de permettre un d ebit plus important, nous proposons de mettre en place un dispositif protocolaire permettant aux coordinateurs de pouvoir attribuer un GTS dans le m eme slot temporel quun autre GTS d ej` a attribu e par un autre coordinateur, dans une autre etoile, seulement si ces deux etoiles sont susamment eloign ees lune de lautre . Cette fonctionnalit e va permettre la r eutilisation des slots temporels pour permettre au r eseau de prendre en charge plus de tracs. Nous appellerons par la suite ces GTS simultan es SGTS3 , pour Simultaneous GTS .
2.3.9.1
Le principe
Pour pouvoir r ealiser un acc` es au m edium simultan e sans cr eer de collision, il est n ecessaire que le destinataire dun message ne soit pas g en e par les autres emissions simultan ees, cest ` a dire que lensemble des signaux tiers ne perturbent pas le signal que lon souhaite recevoir. En pratique, les modulations utilis ees dans les transmissions num eriques se pr etent assez bien ` a cette pratique, il sut pour un r ecepteur que l energie re cue des perturbateurs soit inf erieure ` a celle re cue de l emetteur souhait e, en tenant compte dune certaine marge. Une s erie de mesures r ealis ees sur notre r eseau prototype nous a permis de mettre en evidence les conditions de r eception pour pouvoir pratiquer deux emissions simultan ees sans entra ner de collision. Ces mesures seront pr esent ees dans le chapitre 4 (cf. paragraphe 4.3.2.3 du chapitre 4, page 139).
2.3.9.2
N ecessit e dune n egociation protocolaire
Dans le cadre de notre m ethode dacc` es d eterministe, laectation dun SGTS doit faire lobjet dune n egociation an de ne pas rompre avec le d eterminisme de la m ethode dacc` es. En eet, si le concept 100 Groupe SCSF LATTIS EA4155
de GTS permet le d eterminisme par une garantie dabsence de collisions, lintroduction des SGTS ne doit pas aaiblir les m ecanismes pr esent es jusque l` a. Par ailleurs, la n egociation est n ecessaire car les propri et es relatives ` a la couche physique (puissances emises, sensibilit es des r ecepteurs, bruit per cu, etc.) et aux antennes (rayonnement, omnidirectivit e, gain, etc.) ne permettent pas de supposer la sym etrie des transmissions : si un nud A re coit faiblement les transmissions dun autre nud B, il serait une erreur de supposer que B re coit A avec la m eme faiblesse. Illustrons lid ee de cette n egociation par un exemple : consid erons deux coordinateurs A1, B1 et deux nuds A2, B2. A2 est rattach e` a A1 et B2 est rattach e` a B1. La topologie du r eseau ainsi form e est repr esent ee dans la gure 3.8. A1 re coit des messages emis par A2 dans un GTS d edi e` a A2, B1 re coit des messages emis par B2 dans un GTS d edi e` a B2.
Fig. 3.8 Topologie d ecole du r eseau illustrant la n egociation dun SGTS Le principe de la n egociation protocolaire est le suivant : 1. Le coordinateur A1 constate que le signal emis par le nud B2 est re cu tr` es faiblement, voire inaudible pour lui. Le GTS d edi e` a B2 pourrait donc etre r eutilis e par A2 et devenir un SGTS commun aux deux nuds A2 et B2. Le coordinateur A1 va donc demander au destinataire des messages de B2 cest ` a dire B1 comment celui-ci re coit les messages en provenance de A2 ; cette demande est eectu ee via le message SGTS.request(A2,B2). 2. Le coordinateur B1 re coit cette demande et ecoute alors A2 ; il compare la force des signaux re cus de A2 et B2 et renvoie une r eponse ` a A1 par le message SGTS.response(A2,B2). Si la r eponse est favorable, les deux GTS peuvent etre chang es en SGTS (deux fois plus de d ebit oert), ou regroup es en un m eme SGTS (m eme d ebit oert mais le m edium est moins sollicit e). Si la r eponse est d efavorable, A1 peut soit d ecider den rester l` a, soit demander ` a A2 de diminuer sa puissance d emission et relancer le processus de n egociation avec B1. Ce principe est illustr e par la gure 3.9. Notons que les conclusions de la n egociation ne sont valables que sur un temps tr` es court car les conditions de r eception peuvent evoluer ` a tout instant, surtout si les nuds concern es par le SGTS sont mobiles. Il faudra veiller ` a ren egocier r eguli` erement le SGTS pour la continuit e du service d eterministe. En pratique, nous pourrions favoriser les n egociations de SGTS en bloquant les emissions de nuds terminaux ` a faible puissance, ou tout du moins ` a une puissance minimale pour assurer une bonne communication avec leur coordinateur. De m eme, les messages envoy es par les coordinateurs ` a leurs propres nuds terminaux peuvent eux aussi se faire ` a faible puissance : les coordinateurs peuvent n egocier des SGTS entre eux. Nous discuterons de cette eventualit e dans le chapitre 4, ` a la lumi` ere des r esultats des mesures pratiqu ees sur notre r eseau prototype.
101
Fig. 3.9 Principe de la n egociation protocolaire dun SGTS
2.3.9.3
Application ` a notre topologie
Dans le cadre de notre topologie, le principe de la n egociation reste le m eme. Cependant, comme la gestion des ressources d eterministes est con ee au supercoordinateur, la n egociation des SGTS doit etre valid ee par ce nud. De plus, les contraintes li ees ` a la topologie du r eseau font quun nud ne peut pas toujours sadresser directement ` a un autre nud. La gure 3.11 illustre le d eroulement temporel de la n egociation dun SGTS avec le relayage de la n egociation par le supercoordinateur du r eseau. Dans cet exemple, le Coordinateur 2 n egocie un SGTS commun ` a (Noeud 1, Noeud 2) avec le Coordinateur 1, alors que les deux coordinateurs ne sont pas ` a port ee radio lun de lautre. La r eponse de la n egociation est donn ee par le supercoordinateur dans le message SGTS.indication. La gure 3.10 illustre la topologie de ce r eseau.
Fig. 3.10 Topologie du r eseau pour la n egociation dun SGTS
102
Fig. 3.11 Principe de la n egociation dun SGTS dans le cadre de notre topologie
103
2.4
Impl ementation du protocole : int egration dans une pile IEEE 802.15.4
La gestion de la couche MAC doit etre modi ee pour pouvoir impl ementer les nouvelles fonctionnalit es propos ees. La structure de certains messages doit etre modi ee, de nouveaux messages sont cr e es et de nouvelles primitives vont etre propos ees ` a la liste existante. Les modications suivantes sont propos ees sur les messages : Dune mani` ere g en erale, lintroduction des fonctionnalit es li ees au d eterminisme et aux niveaux de r eservation n va introduire une modication de la structure des messages relatifs ` a lassociation au r eseau et ` a la gestion des GTS. De nouveaux champs devront etre ajout es dans les messages existants (association.request, association.response, GTS.request) pour permettre les associations d eterministes et les demandes de GTS avec un niveau de r eservation n = 0. Dans la mesure o` u les GTS (idem PDS, GBS, SGTS) peuvent avoir une fr equence inf erieure ` a une supertrame (une sur deux, une sur quatre, etc.), il est n ecessaire de pr evoir un message de r eponse ` a la requ ete GTS.request. Dans la norme actuelle, ce message nest pas n ecessaire car la r eponse est donn ee imm ediatement par le coordinateur dans le beacon suivant (il contient/ne contient pas le GTS r eclam e). Dans notre proposition, nous pr evoyons lintroduction dun message GTS.response an de donner imm ediatement une r eponse au nud demandeur, m eme si le GTS demand e avec un niveau 3 sera annonc e 7 beacons plus tard . De plus, dans notre topologie a plusieurs niveaux (nuds terminaux coordinateur, coordinateurs supercoordinateur), il est ` n ecessaire de pr evoir un message de r eponse pour les dialogues entre supercoordinateur et coordinateurs. Le protocole pour la n egociation des SGTS n ecessite lui aussi lintroduction de nouveaux messages pour le dialogue entre les coordinateurs concern es par la n egociation. Deux nouveaux messages SGTS.request et SGTS.response doivent etre introduits pour la r ealisation du dialogue. De m eme que pour les messages, certaines primitives vont etre modi ees et dautres vont etre cr e ees : Les primitives MLME-ASSOCIATE.request, MLME-ASSOCIATE.indication, MLME-ASSOCIATE.response, MLME-ASSOCIATE.confirm, MLME-GTS.request, MLME-GTS.indication, MLME-GTS.confirm, MLME-COMM-STATUS.indication
doivent etre modi ees pour prendre en compte le c ot e totalement d eterministe de la m ethode dacc` es et les niveaux de r eservation n des GTS, PDS, GBS et SGTS. Une primitive MLME-GTS.response doit etre introduite pour la g en eration du message GTS.response. Quatre primitives relatives ` a la gestion des SGTS sont propos ees : MLME-SGTS.request, MLMESGTS.indication, MLME-SGTS.response et MLME-SGTS.confirm. Ces quatre primitives seront appel ees pour la g en eration des messages relatifs ` a la n egociation des SGTS entre deux coordinateurs. Toutes ces modications n ecessitent lintroduction de champs suppl ementaires dans les messages de niveau MAC de 802.15.4. Nous ne d etaillerons pas plus ces modications : ce travail de d eveloppement sort du cadre de cette th` ese et sera pr esent e en perspectives. 104 Groupe SCSF LATTIS EA4155
Conclusion
Conclusion
Le protocole qui vient d etre propos e r epond aux crit` eres enonc es en d ebut de chapitre. Il propose une m ethode dacc` es totalement d eterministe (totalement car m eme les phases dentr ee et de sortie du r eseau peuvent se faire de mani` ere d eterministe) tout en assouplissant le m ecanisme de gestion des GTS, d ej` a pr esents dans la norme IEEE 802.15.4. Cependant, toutes les propositions faites dans ce chapitre doivent faire lobjet dune validation. Le chapitre 4 pr esente cette ultime etape et les r esultats qualitatifs et quantitatifs qui en ont et e tir es. Plusieurs etudes ont et e r ealis ees ` a cette occasion utilisant les R eseaux de P etri, la simulation et le prototypage.
105
106
[IEE2 03] LAN-MAN Standards Committee of the IEEE Computer Society 802.15.4 IEEE Standard for Information technology, Part 15.4 : Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specications for Low-Rate Wireless Personal Area Networks (LR-WPANs) IEEEStd 802.15.4-2003 (2003) [IEE2 03] LAN-MAN Standards Committee of the IEEE Computer Society 802.15.4 IEEE Standard for Information technology, Part 15.4 : Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specications for Low-Rate Wireless Personal Area Networks (LR-WPANs) IEEEStd 802.15.4-2003 (2003) [LLI2 06] J.F. Llibre, P. Pinel et E. Campo Quel choix de source d energie pour rendre un syst` eme communicant autonome ? XIIieme Colloque National de la Recherche dans les IUT, Brest, France (2006) [THOM 05] J.P. Thomesse Fieldbus Technology and Industrial Automation 10th IEEE Conference on Emerging Technologies and Factory Automation (ETFA 2005), Catania, Italie (Septembre 2005) [VAL 05] T. Val et G. Juanole La Qualit e de Service dans les r eseaux sans l Ecole d et e Temps R eel (ETR05), Nancy, France (Septembre 2005) [VDB 06] A. van den Bossche, T. Val et E. Campo Proposition of a full deterministic medium access method for wireless network in a robotic application 63rd IEEE Vehicular Technology Conference (VTC-2006-Spring), Melbourne, Australie (Mai 2006) [VDB 07] A. van den Bossche, T. Val et E. Campo Une m ethode dacc` es totalement d eterministe pour un r eseau personnel sans l 8ieme congr` es de lEcole Doctorale Syst` emes de Toulouse (EDSYS07), Albi, France (Mai 2007) [ZBAL 05] ZigBee Alliance ZigBee Specication ZigBee Document 053474r06, version 1.0 (2005)
108
Chapitre 4
Mod elisation, validation et prototypage du protocole

Apr` es la pr esentation dun etat de lart (chapitre 1), du r eseau IEEE 802.15.4/ZigBee et de lidentication de ses faiblesses (chapitre 2), nous avons propos e, dans le chapitre 3, une s erie dam eliorations pour ce standard transposables ` a tout LP-WPAN. Dans ce chapitre 4, nous proposons de valider nos propositions par di erentes m ethodes compl ementaires.
1 2 Introduction : une d emarche de validation multi-outils . . . . . . . . . . . 111 Mod elisation et validation formelle du protocole . . . . . . . . . . . . . . 112 2.1 Loutil R eseaux de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 2.2 Pr esentation du mod` ele propos e . . . . . . . . . . . . . . . . . . . . . . . . . 112 2.2.1 Algorithme g en eral d eduit du protocole . . . . . . . . . . . . . . . . 112 2.2.2 Un mod` ele de type P` ere /Fils . . . . . . . . . . . . . . . . . . . . . . 114 2.2.3 Le mod` ele R eseaux de Petri . . . . . . . . . . . . . . . . . . . . . . 115 2.2.3.1 Etude du processus p` ere . . . . . . . . . . . . . . . . . . . . 116 2.2.3.2 Etude du processus ls . . . . . . . . . . . . . . . . . . . . 116 2.3 Validation formelle du mod` ele et analyse des r esultats . . . . . . . . . . . . . 116 2.3.1 Pr esentation de loutil TINA . . . . . . . . . . . . . . . . . . . . . . 116 2.3.2 Analyse des r esultats . . . . . . . . . . . . . . . . . . . . . . . . . . 117 2.4 Conclusion de l etude de validation formelle . . . . . . . . . . . . . . . . . . . 117 Simulation : outils et r esultats . . . . . . . . . . . . . . . . . . . . . . . . . 117 3.1 D eveloppement dun outil de simulation . . . . . . . . . . . . . . . . . . . . . 117 3.1.1 Pr esentation de loutil . . . . . . . . . . . . . . . . . . . . . . . . . . 118 3.1.1.1 M ecanisme impl ement e et simul e . . . . . . . . . . . . . . . 118 3.1.1.2 Fonctionnement du simulateur d evelopp e . . . . . . . . . . 119 3.1.1.3 Utilisation du simulateur : descriptif de la topologie et exploitation des donn ees . . . . . . . . . . . . . . . . . . . . . 119 3.1.1.4 Param` etres x es pour la simulation . . . . . . . . . . . . . 120 3.1.2 Analyse des r esultats obtenus . . . . . . . . . . . . . . . . . . . . . . 121 3.1.2.1 Etude de lassociation d eterministe dun coordinateur . . . 121 3.1.2.2 Etude de lassociation d eterministe dun nud . . . . . . . 123 3.2 Les travaux r ealis es sous NS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.2.1 Pr esentation de loutil . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.2.2 Les mod` eles 802.15.4 / ZigBee existants sous NS2 . . . . . . . . . . 125 3.2.3 Un r esultat obtenu avec NS2 : d ebit utile dans la CAP avec CSMA/CA126 3.3 Conclusion sur les travaux de simulation . . . . . . . . . . . . . . . . . . . . . 127 Prototype et m etrologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
CHAPITRE 4. MODELISATION, VALIDATION ET PROTOTYPAGE DU PROTOCOLE
4.1
4.2 4.3
4.4
Pr esentation de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Les plateformes IEEE 802.15.4/ZigBee existantes . . . . . . . . . . . 4.1.2 Modication du rmware existant . . . . . . . . . . . . . . . . . . . R ealisation doutils de tests et de mesures . . . . . . . . . . . . . . . . . . . . Conception et r ealisation dune pile prototype . . . . . . . . . . . . . . . . . . 4.3.1 Evaluation des performances de la pile prototyp ee . . . . . . . . . . 4.3.1.1 Evaluation de la sensibilit e du r ecepteur . . . . . . . . . . . 4.3.1.2 Evaluation du temps de traitement dun paquet . . . . . . 4.3.1.3 D ebit utile maximum . . . . . . . . . . . . . . . . . . . . . 4.3.1.4 Evaluation de la qualit e de la synchronisation entre un coordinateur et ses nuds . . . . . . . . . . . . . . . . . . . 4.3.1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Validation de notre proposition par prototypage . . . . . . . . . . . 4.3.2.1 Evaluation de la qualit e de la synchronisation entre le supercoordinateur et ses nuds . . . . . . . . . . . . . . . . 4.3.2.2 Capacit e maximale dun slot . . . . . . . . . . . . . . . . . 4.3.2.3 Validation du concept de SGTS . . . . . . . . . . . . . . . 4.3.3 Conclusion sur les mesures r ealis ees sur le prototype . . . . . . . . . Applications de d emonstration . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Capteur de ligne ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Passerelle IP/ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Flotte de robots ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 Bilan sur les applications de d emonstration . . . . . . . . . . . . . .
127 127 129 130 131 131 131 132 133 134 135 136 136 137 139 142 142 143 144 144 145
110
Introduction : une d emarche de validation multi-outils
Introduction : une d emarche de validation multi-outils

(comme dans tout r eseau industriel de capteurs)
Les r` egles protocolaires d ecrites dans le chapitre pr ec edent n ecessitent d etre valid ees, ` a la fois qualitativement et quantitativement. Dans ce double objectif, nous avons r ealis e plusieurs travaux de v erications et danalyse des performances. Tout dabord, le s equencement du protocole a et e mod elis e par R eseaux de Petri puis valid e formellement gr ace ` a des outils associ es, an de prouver quil ne soure daucun blocage et que son ex ecution se cantonne bien ` a ce qui a et e pr evu. Cette premi` ere etude est pr esent ee dans la section 2 Mod elisation et validation formelle du protocole de ce dernier chapitre. Ensuite, le m ecanisme dassociation d eterministe utilisant les PDS3 a et e simul e dans le but de conrmer les performances temporelles qui avaient et e d etermin ees th eoriquement et pr esent ees dans la section 2.3.4 du chapitre 3. Un simulateur logiciel sp ecique a et e d evelopp e pour loccasion. Cette etude, ainsi que des travaux eectu es sur le logiciel NS2, sont pr esent es dans la section 3 Simulation : outils et r esultats de ce chapitre 4. Enn, la m ethode dacc` es a et e impl ement ee sur des v eritables nuds et une analyse de performances r eelles sur prototype a et e r ealis ee. Le concept novateur mais sensible de SGTS evoqu e dans la partie 2.3.9 du chapitre 3 a lui aussi et e valid e par une s erie de mesures physiques et radio r ealis ees sur ce r eseau prototype. Cette etude fait lobjet de la section 4 Prototype et m etrologie de ce chapitre 4. Le tableau 4.1 r esume les di erents points qui ont et e valid es par lune de ces trois m ethodes compl ementaires et qui seront abord es dans ce chapitre.
ements valid Tab. 4.1 El es par chaque m ethode utilis ee Il est int eressant de noter que lensemble des contributions propos ees dun point de vue th eorique dans cette th` ese a et e trait e, que ce soit par validation formelle, par simulation ou par prototypage. Chaque etude est compl ementaire car ces trois m ethodes ne peuvent traiter lensemble des propositions faites dans notre contribution. Il aurait et e int eressant de traiter, quand cela est possible, chaque point par deux ou trois techniques di erentes. Ceci na pas et e r ealis e faute de temps, mais sera evoqu e comme perspective int eressante en conclusion de la th` ese. Pour nir, la section 4.4 pr esente les di erents projets qui ont et e men es pendant la th` ese et rendus Adrien van den Bossche 111
possibles par le travail r ealis e sur ZigBee, sur IEEE 802.15.4, sur la nouvelle couche MAC et plus particuli` erement sur le prototypage r eel.
Mod elisation et validation formelle du protocole
Cette premi` ere etape de validation pr evoit de valider formellement le s equencement du protocole, cest ` a dire de montrer par des m ethodes analytiques que lalgorithme propos e se d eroule toujours comme que nous lavons pr evu. Cette validation formelle est impossible ` a r ealiser par des m ethodes de simulation car elle n ecessiterait de rejouer une innit e de sc enarios ; seules les m ethodes formelles peuvent d emontrer ce type de propri et e. Le but de cette etape est donc dassurer que, pour chaque ex ecution du protocole, il nexiste aucun cas de blocage (arr et pur et simple du d eroulement de lalgorithme et bouclage inni) ou de divergence (n ecessit e dune m emoire innie). Cette premi` ere etape est incontournable car il est n ecessaire de valider ces propri et es qualitatives avant de pouvoir analyser quantitativement le prototype, que ce soit par simulation et/ou par prototypage. En eet, si le mod` ele sourait dun quelconque blocage, l etude par simulation toute enti` ere serait discr edit ee.
2.1
Loutil R eseaux de Petri
La technique des R eseaux de Petri [BRAM 83] [MERL 76] a et e mise au point dans les ann ees 60 par Carl Maria Petri. Les RdP constituent une technique de mod elisation de syst` emes ` a variables dentr ees, de sorties et d etats discrets dont le mod` ele peut- etre repr esent e sous forme dun graphe. Les R eseaux de Petri, et plus sp ecialement les Grafcets [MERC 06] qui en sont un cas particulier, sont populaires du fait de laccessibilit e et de la lisibilit e de leur forme graphique qui rend compr ehensible un syst` eme mod elis e m eme pour une personne peu quali ee. Cependant, les R eseaux de Petri nen restent pas moins un outil math ematique tr` es puissant. Plusieurs variantes bas ees sur les fondamentaux de Carl Maria Petri ont et e propos ees par la suite : les R eseaux de Petri Temporis es [ATAM 94], les R eseaux de Petri Stochastiques [FLOR 85], les R eseaux de Petri Temporis es Stochastiques [MARS 85]. . . Ces variantes introduisent des grandeurs et des m ecanismes additionnels (notions temporelles, probabilistes, etc.) qui permettent la mod elisation de ph enom` enes impossibles ` a mod eliser par les R eseaux de Petri originaux. Concernant nos travaux, le mod` ele propos e utilise les R eseaux de Petri simples.
2.2
2.2.1
Pr esentation du mod` ele propos e

Algorithme g en eral d eduit du protocole
Le s equencement du protocole propos e dans le chapitre 3, cest ` a dire l echange des messages entre les di erentes entit es du r eseau, peut se mod eliser de di erentes mani` eres, selon le formalisme choisi et les objectifs attendus. Quelque soit le formalisme choisi, le principe g en eral de la m ethode dacc` es propos ee est le suivant : 1. attente de son slot d eterministe (GTS, SGTS ou PDS si non encore associ e), 2. emission de la demande dans le slot d eterministe, 3. attente de la r eponse, qui peut etre largement di er ee si le niveau de r eservation n est elev e. Dans un premier temps, ce s equencement g en eral a simplement et e repr esent e sous forme algorithmique. A titre dexemple, le s equencement dune association d eterministe au r eseau (par utilisation des 112 Groupe SCSF LATTIS EA4155
PDS) est repr esent e sur la gure 4.1.
Fig. 4.1 S equencement du protocole pour une demande dassociation dun nud au r eseau Lalgorithme repr esent e illustre le comportement de tout nud du r eseau coordinateur ou nud terminal1 . Il reprend exactement ce qui avait et e d ecrit dans le chapitre 3 : 1. le nud se r eveille, il attend de recevoir le beacon de son entit e sup erieure, 2. le beacon re cu permet au nud de se synchroniser sur son entit e sup erieure et dentrer en mode suivi de beacon, cest ` a dire la mise en veille rapide et le r eveil automatique avant chaque beacon. Le nud attend alors le beacon annon cant son PDS. Suivant le niveau de r eservation nP DS , ce beacon est plus ou moins fr equent, 3. le beacon re cu doit contenir des informations sur le PDS, le nud patiente alors jusqu` a cet instant, 4. le nud utilise son PDS pour emettre sa demande dassociation (association.request) ` a son entit e sup erieure. Si la trame est re cue sans erreur, lentit e sup erieure renvoie un acquittement de niveau 2, signiant que la demande a bien et e re cue (lacquittement ne constitue pas une r eponse
1 Le supercoordinateur na pas de phase dassociation puisquil est le premier ` a emettre. En revanche, dans le cadre dune cr eation compl` ete du r eseau, le supercoordinateur nest pas n ecessairement le premier nud ` a se r eveiller. Dans ce cas, le r eseau ne peut pas se former de mani` ere d eterministe, cest ` a dire born e dans le temps. Lensemble du r eseau est oblig e dattendre la r eception des premiers superbeacons pour d emarrer la phase dassociation d eterministe. Eventuellement, si le premier coordinateur eveill e ne re coit aucun superbeacon dans une certaine fen etre temporelle, il peut d ecider de devenir lui-m eme supercoordinateur ; cette fonctionnalit e orient ee r eseaux spontan es pourra etre discut ee dans les perspectives de la th` ese.
113
favorable). 5. le nud attend la r eponse (association.confirm) qui est annonc ee dans le beacon suivant. Si la r eponse est re cue et favorable, le nud est accept e dans le r eseau. Notons que lalgorithme qui vient d etre comment e concerne bien la proc edure dassociation au r eseau, mais la succession des etapes (synchronisation, attente du PDS, emission de la requ ete puis attente de la conrmation dans le beacon suivant) reste la m eme pour envoyer des donn ees, demander plus de ressources d eterministes, notier un d epart du r eseau, etc. Les messages echang es sont di erents mais la structure du dialogue reste la m eme.
2.2.2
Un mod` ele de type P` ere /Fils
La m ethode dacc` es que nous proposons sarticule autour dune topologie hi erarchique ` a trois niveaux dentit es2 , comme nous lindiquions dans la section 2.3.1 du chapitre 3. La gure 4.2 illustre une topologie typique de notre r eseau.
ements du r Fig. 4.2 El eseau et liens entre ces el ements Le r eseau est constitu e: dun unique supercoordinateur (SC), dun ou plusieurs coordinateurs (C1, C2 et C3), chacun ma tre de son etoile, de z ero, un ou plusieurs nuds par etoile (N1, N2, N3, N4, N5, N6 et N7). La description de la structure du r eseau ( el ements et liens entre ces el ements) nous permet d etablir une relation de type p` ere /ls entre le supercoordinateur et le(s) coordinateur(s) dune part, mais aussi entre un coordinateur et son (ses) nud(s) rattach e(s). En eet, dans un cas comme dans lautre, le p` ere diuse ses beacons sur lesquels le ls se synchronise et attend son PDS/GBS/GTS quil peut utiliser librement. si le ls est un coordinateur, il pourra utiliser son GBS pour diuser lui-m eme un beacon et remonter une requ ete au supercoordinateur, si le ls est un nud, il pourra utiliser son GTS pour demander plus de ressource ou envoyer une donn ee.
2 Nous
pourrions g en eraliser cette structure ` a n niveaux, mais ce nest pas lobjet de cette partie.
114
Dun point de vue structurel, la relation entre le supercoordinateur et les coordinateurs est la m eme que celle entre un coordinateur et ses nuds. La seule di erence se situe sur le plan temporel : les requ etes en lien avec le d eterministe de lacc` es au m edium (association, demande de GTS, n egociation de SGTS) doivent etre achemin ees jusquau supercoordinateur ; de ce fait, un d elai suppl ementaire est introduit dans le cas dune communication nud/supercoordinateur car linformation doit etre relay ee par le coordinateur. Dans le cas r eel, la relation entre les trois types de nuds impose, pour le coordinateur, un fonctionnement s equentiel p` ere puis ls. En eet, une fois associ e au r eseau (donc au supercoordinateur), le coordinateur diuse ses beacons et se comporte avec ses nuds de la m eme mani` ere que le supercoordinateur se comporte avec les coordinateurs.
2.2.3
Le mod` ele R eseaux de Petri
La gure 4.3 repr esente le R eseau de Petri elabor e pour mod eliser le comportement du protocole dans la phase dassociation d eterministe au r eseau. On retrouve les deux processus : le p` ere, ` a gauche et le ls, ` a droite. Les transitions dispos ees entre les deux servent ` a les synchroniser. Ces transitions repr esentent l eventuelle activit e sur le m edium radio.
Fig. 4.3 Repr esentation du mod` ele R eseau de Petri
115
2.2.3.1
Etude du processus p` ere
Le processus p` ere peut etre dans 3 etats : inactif, en emission de beacon, en traitement de requ ete. Dans tous les cas, l emission des trames beacons est r eguli` ere ; dans ce mod` ele non temporis e, les beacons sont emis tant que le ls na pas de requ ete ` a envoyer (pr esence de larc inhibiteur sur la transition Top_Beacon). Dans la r ealit e, l emission des beacons est d eclench ee par un timer dont la p eriode d epend du param` etre BO de IEEE 802.15.4 (cf. paragraphe 2.3.1.2 du chapitre 2). Lorsque quun beacon est emis, deux cas peuvent se pr esenter : soit le ls attend ce beacon (un jeton est pr esent dans la place Beacon_attendu) ; ` a la r eception de cette balise, le ls peut poursuivre son s equencement. On parle alors dune diusion de beacon utile, soit le ls nattend pas de beacon (absence de jeton dans la place Beacon_attendu) ; larc inhibiteur pr esent sur la transition Diffusion_dun_beacon_pour_rien permet au p` ere de poursuivre m eme si le ls na pas besoin de ce beacon. On parle alors dune diusion de beacon inutile. Etude du processus ls
2.2.3.2
Le comportement du processus ls suit exactement lalgorithme qui a et e pr esent e plus haut sur lorganigramme de la gure 4.1 (r eveil et attente du beacon annon cant le PDS, attente du PDS, envoi de la demande dassociation, attente de la r eponse). Seule une transition RESET a et e ajout ee pour permettre la r einitialisation du processus ls d` es que lassociation est nalis ee. Sans cette transition, le R eseau de Petri nest pas vivant, cest-` a-dire quil pr esente un caract` ere bloquant ne permettant pas une validation formelle.
2.3
2.3.1
Validation formelle du mod` ele et analyse des r esultats

Pr esentation de loutil TINA
Le mod` ele R eseau de Petri propos e a et e valid e par le logiciel TINA [BERT 04] [TINA]. TINA (TIme petri Net Analyzer ) est une plateforme logicielle pour l edition et lanalyse des R eseaux de Petri temporis es (Time Petri Nets ). Elle est d evelopp ee et maintenue par le groupe OLC (Outils Logiciels pour la Communication) [OLC] du LAAS/CNRS (Laboratoire dAnalyse et dArchitecture des Syst` emes) de Toulouse [LAAS]. Ce logiciel est egalement utilis e au laboratoire ICARE-LATTIS par un doctorant en relation avec le LAAS [KHOU 06]. TINA est un outil puissant qui permet la v erication de nombreux aspects des R eseaux de Petri (aspects born e, blocage, r einitialisation ). Il sappuie sur les propri et es intrins` eques des RdP et propose notamment une fonctionnalit e de validation formelle qui apporte la preuve math ematique que la propri et e etudi ee est v eri ee avec un niveau de conance de 100%. Les fonctionnalit es de TINA permettent de r ealiser une etude temporelle du mod` ele par lutilisation des R eseaux de Petri Temporis es, fonctionnalit e que nous nutiliserons cependant pas ici. Avant dutiliser TINA, dautres outils logiciels en rapport avec les RdP ont et e mis en uvre, notamment HPSim [HPSI] de H. Anschuetz. Cependant, TINA a et e retenu pour ses capacit es danalyses formelles des RdP.
116
Simulation : outils et r esultats
2.3.2
Analyse des r esultats
TINA nous a permis de valider les propri et es suivantes de notre mod` ele RdP : Aspect Born e : cette propri et e concerne le nombre ni d etats de marquage des places du RdP. Cet aspect doit etre le premier ` a etre v eri e sans quoi la validation formelle des autres aspects na aucun sens. Laspect non born e se caract erise par un nombre inni de jetons dans au moins une des places du RdP : il signie que le mod` ele diverge ou que le syst` eme impl ement e n ecessitera une quantit e de ressources anormalement elev ee (m emoire, temps CPU, etc.). Aspect Vivant : cet aspect permet de d eceler les portions de code mort, cest ` a dire labsence de vivacit e de certaines places et/ou le blocage de certaines transitions du R eseau de Petri, pour tout marquage initial et accessible du r eseau. Labsence de vivacit e permet de mettre en evidence des portions de code qui ne sont jamais ex ecut ees (donc de relever les erreurs de mod elisation) et des situations o` u le syst` eme mod elis e risque de bloquer. Aspect R einitialisable : la r einitialisation du syst` eme permet de retrouver un etat initial (marquage initial) en partant de nimporte quel etat de son fonctionnement. Cet aspect est fondamental dans la validation des syst` emes de type automate qui pr esentent un fonctionnement cyclique.
Ces trois aspects de notre mod` ele ont et e valid es avec succ` es par TINA.
2.4
Conclusion de l etude de validation formelle
La validation formelle du s equencement constitue une premi` ere etape indispensable ` a la d emarche de validation globale du protocole. Gr ace a ` cette premi` ere etude, nous avons d emontr e par une m ethode formelle que lalgorithme que nous proposons ne pr esente aucun d efaut de s equencement. D` es lors que notre mod` ele semble correct sur le plan qualitatif, nous allons maintenant pouvoir simuler son d eroulement et etudier les performances temporelles qui en d ecoule. Ces r esultats ont et e obtenus par simulation et sont pr esent es dans la section suivante.
Cette partie pr esente les travaux que nous avons eectu es par simulation. Un outil logiciel sp ecique a et e d evelopp e pendant la th` ese ; son d eveloppement et les r esultats obtenus sont d evelopp es dans une premi` ere partie. Des travaux men es sur le simulateur NS2 seront evoqu es dans une seconde partie.
3.1
D eveloppement dun outil de simulation
Apr` es la validation formelle du s equencement du protocole dacc` es d eterministe propos ee par les R eseaux de Petri, nous avons con cu un simulateur logiciel impl ementant lalgorithme de distribution des GBS/GTS, algorithme prenant en compte les p eriodes dattente impos ees par les cycles pr evus par notre protocole. Gr ace ` a cette fonctionnalit e, le simulateur peut d elivrer des r esultats sur la latence engendr ee par la m ethode dacc` es au m edium et permet ainsi l etude des performances temporelles de la m ethode dacc` es propos ee. Adrien van den Bossche 117
3.1.1
Pr esentation de loutil
Le logiciel de simulation propos e impl emente dune part lalgorithme de distribution des PDS, GBS et GTS (qui, en r ealit e, sera plac e dans le supercoordinateur) et dautre part le syst` eme dannonce de cette distribution par cascade de beacons. Il a et e programm e en langage C et fonctionne sur une plateforme GNU/Linux. Son but est d evaluer les performances temporelles dun r eseau utilisant uniquement la m ethode dacc` es d eterministe (cest ` a dire uniquement les PDS/GBS/GTS aucun echange de donn ees en CSMA/CA). Les performances temporelles d eduites de cette etude peuvent etre consid er ees comme le minimum garanti, les nuds pouvant obtenir des retours plus rapides sils pratiquent egalement des acc` es au m edium avec contention, mais alors sans garantie. Il est ` a noter que le simulateur pr esent e ici etablit des communications qui se basent sur une couche physique id eale : notre simulateur nintroduit ni d elai de propagation, ni perte de paquets, ni erreurs de transmission. Nous insistons ici sur le fait que le but de cette etude nest pas la simulation totale de la solution propos ee, mais simplement une simulation de lalgorithme de distribution et de r epartition des temps de parole sur le m edium et des temps de latence pour le transport des donn ees qui en d ecoule.
3.1.1.1
M ecanisme impl ement e et simul e
Le m ecanisme impl ement e dans le simulateur est volontairement tr` es proche du mod` ele qui avait et e valid e par utilisation des R eseaux de Petri. Il inclut la structure ` a trois niveaux (supercoordinateur, coordinateur, nud) et ajoute la notion temporelle qui va permettre lobtention de param` etres de performances. Lalgorithme impl ement e est le suivant : A t = 0, le Supercoordinateur est mis en fonctionnement. Il conna t les besoins temporels des nuds consid er es comme critiques, cest-` a-dire quil sait quun nud A doit pouvoir prendre la parole au moins toutes les 100 ms (n ecessit e impos ee par lapplication), un nud B au moins toutes les 400 ms, etc. Il pr epare alors une r epartition des PDS pour les 2nM AX supertrames ` a venir3 de mani` ere ` a ce que chaque nud puisse acc eder au m edium selon ses besoins et demander son association au r eseau de mani` ere d eterministe. Notons ici que tant quaucune demande de ressource d eterministe nest re cue, cette r epartition est conserv ee, ind eniment. Une fois la r epartition des PDS eectu ee (qui est instantan ee dans la simulation), le Supercoordinateur commence la diusion r eguli` ere des superbeacons. Les nuds, quils soient coordinateurs ou nuds terminaux, se r eveillent ` a un instant t tir e al eatoirement. D` es leur r eveil, les nuds cherchent ` a se synchroniser sur les balises de leur p` ere (superbeacons pour les coordinateurs, beacons de leur coordinateur pour les nuds terminaux). Si le p` ere nest pas encore r eveill e, le ls attend son r eveil. A la r eception du premier beacon emis par le p` ere, le ls est synchronis e et entre dans le mode suivi de beacon permettant l economie d energie (r eveil juste avant la r eception du beacon, ecoute, traitement puis somnolence jusquau beacon suivant.). Le ls ecoute chaque beacon jusqu` a entendre celui qui annonce son PDS. La fr equence du PDS d epend du nP DS associ e` a ce nud. Tant que son PDS nest pas annonc e, le ls reste en suivi de beacon et ne demande pas ` a sassocier4 . A ce stade, il na toujours pas emis le moindre message sur le m edium. A la r eception de la balise emise par son p` ere annon cant son PDS, le ls lutilise pour annoncer
2nM AX supertrames constituent la vision maximale du supercoordinateur. restriction est li ee ` a lobjectif de cette etude qui nautorise que lutilisation des slots d eterministes. Dans la r ealit e, un nud peut demander ` a sassocier imm ediatement par le biais dun acc` es au m edium avec contention, mais, encore une fois, sans garantie.
4 Cette 3 Les
118
son r eveil. Il demande alors lassociation au r eseau par un message de type Association_Request. Dans ce message, le ls peut demander ` a garder le m eme niveau de d eterminisme (nGT S = nP DS ), ou bien demander un niveau di erent (il demande alors un nouveau nGT S qui pourra etre refus e par le supercoordinateur si la capacit e du r eseau ne le permet pas). Si le ls est un coordinateur, la demande est re cue directement par le supercoordinateur. De plus, les acc` es d eterministes seront utilis es pour la diusion de ses beacons : on parlera alors plut ot de nGBS et non de nGT S . Si le ls est un nud terminal, la demande est re cue par le coordinateur du nud, qui relait alors cette requ ete au supercoordinateur (introduction dun d elai suppl ementaire qui sera quanti e dans la partie 3.1.2.2). Le supercoordinateur re coit la demande dassociation au r eseau, directement (demande dun coordinateur) ou indirectement (demande dun nud relay ee par son coordinateur). Il prend en compte cette demande, confronte la valeur nGT S ou nGBS demand ee avec la capacit e restante du r eseau et modie (ou non) en cons equence la r epartition quil avait pr epar ee au d epart. Il communique sa r eponse dans le superbeacon suivant. Le nud demandeur re coit la r eponse (directement si cest un coordinateur ou indirectement, par son coordinateur, si cest un nud terminal). Si cette r eponse est positive : si le le nud est un coordinateur et sil a obtenu le GBS demand e, il commence alors ` a diuser ses propres beacons. Si certains de ses propres nuds etaient en attente de ces beacons, ils sont alors synchronis es et attendent ` a leur tour leur PDS, si le nud est un nud terminal et sil a obtenu le GTS demand e, il utilise chaque GTS pour envoyer une trame de donn ees quelconque.
3.1.1.2
Fonctionnement du simulateur d evelopp e
Le simulateur d evelopp e en Langage C sarticule tr` es simplement autour dune boucle innie et dune structure switch/case. Chaque etat evoqu e ci-dessus est cod e dans un case et le passage dun etat ` a lautre se fait quand les conditions de passage sont remplies. Chaque nud est repr esent e dans la m emoire par une variable contenant son etat. Au d ebut du programme, un tableau de nuds est initialis e avec tous les etats ` a 0, le simulateur fonctionne avec un seul processus qui simule le fonctionnement de tous les nuds du r eseau. Laspect temporel est g er e par une variable globale ` a tous les nuds. Pour chaque nouvel instant, le comportement de chaque nud est trait e et le passage dun etat ` a un autre est test e. Lorsque tous les nuds ont et e trait es, la variable temporelle est incr ement ee dun pas.
3.1.1.3
Utilisation du simulateur : descriptif de la topologie et exploitation des donn ees
Avant de pouvoir utiliser le simulateur, la topologie du r eseau et le besoin de chaque nud doivent etre d ecrits dans un chier qui sera ensuite lu par le simulateur. La structure de ce chier est simple : chaque ligne d ecrit un nouveau nud et contient tous les param` etres caract erisant un nud : 1. adresse, 2. type (coordinateur/nud terminal), 3. adresse du p` ere, Adrien van den Bossche 119
4. le niveau de r eservation du m edium au pr ealable (nP DS ), 5. le niveau de r eservation une fois associ e (nGBS si le nud est un coordinateur ou nGT S si cest un nud terminal). Au cours de la simulation, chaque ev` enement est report e sur l ecran ou dans un chier de trace. Si la r epartition des PDS, GBS, GTS evolue au cours du temps, le simulateur ache cette nouvelle r epartition sous forme de matrice, comme sur la gure 4.4. Cette repr esentation matricielle permet de voir rapidement comment le supercoordinateur a r eparti lensemble des slots. Cette matrice se lit ainsi : chaque colonne repr esente lun des 16 slots de la supertrame IEEE 802.15.4, chaque ligne repr esente lune des 2nM AX supertrames ` a venir. Dans notre cas, nous avons x en` a 3, soit une vision de 8 supertrames. chaque el ement de la matrice repr esente donc lun des 16 2nM AX slots ` a venir, si le slot nest pas aect e pour un acc` es d eterministe (CAP), un point est repr esent e, si le slot est aect e` a un nud, ladresse du nud est indiqu ee, si le slot aect e est un GBS, ladresse du nud est not ee entre {accolades}. *** 0 [ 1 [ 2 [ 3 [ 4 [ 5 [ 6 [ 7 [ Ressources {1} 31 {1} . {1} . {1} . {1} 31 {1} . {1} . {1} . matrix at t = 7372800 *** . . {3} . . . . . {3} . . . . . {3} . . . . . {3} . . . . . {3} . . . . . {3} . . . . . {3} . . . . . {3} . . .
. . . . . . . .
. . . . . . . .
. 21 . 21 . 21 . 21
. . . . . . . .
{2} {2} {2} {2} {2} {2} {2} {2}
. . . . . . . .
. . . . . . . .
. . . . . . . .
] ] ] ] ] ] ] ]
Fig. 4.4 Exemple dune r epartition de PDS/GBS/GTS sous forme matricielle D` es lors, on peut d ecoder la matrice repr esent ee par la gure 4.4 ainsi : tous les slots 0 sont occup es par le nud 1 (supercoordinateur) (nGBS = 0), les slots 1 de la premi` ere et de la quatri` eme supertrame sont occup es par le nud 31 (nGT S = 2), tous les slots 4 sont occup es par le nud 3 qui est un coordinateur (nGBS = 0), les slots 10 des supertrames 1, 3, 5 et 7 sont occup ees par le nud 21 (nGT S = 1), et enn tous les slots 12 sont occup es par le nud 2 qui est un coordinateur (nGBS = 0).
Lorsque tous les nuds qui avaient et e d eclar es sont dans l etat associ e , le programme de simulation se termine et retourne la dur ee n ecessaire ` a lassociation pour chaque nud du r eseau. Ces valeurs retourn ees vont permettre l etude de la dur ee n ecessaire ` a lassociation d eterministe dun nud du r eseau, que nous allons pr esenter dans la section suivante.
3.1.1.4
Param` etres x es pour la simulation
Dans le cadre des travaux de simulation, certaines grandeurs, pourtant ajustables dans le programme de simulation, ont et e g ees. Ces valeurs, ainsi que les justications pour les avoir g ees, sont indiqu ees ci-apr` es : conform ement ` a ce qui est pr econis e par la norme IEEE 802.15.4, la dur ee el ementaire dun slot a et e x ee ` a 2BO 960 s, de m eme, toujours dapr` es la norme IEEE 802.15.4, notre supertrame conserve une longueur de 16 slots, 120 Groupe SCSF LATTIS EA4155
nmax a et e x e` a 3, soit une vision de 8 supertrames pour le supercoordinateur, BO a et e x e` a 3 dapr` es les premiers r esultats obtenus par prototypage, comme cela sera justi e dans la section 4.3.2.2. Bien entendu, ces valeurs (constantes C, variables globales) peuvent etre modi ees facilement dans le simulateur, m eme si elles ne sont pas modiables directement par le chier de conguration.
3.1.2
Analyse des r esultats obtenus
Cette section pr esente les r esultats obtenus gr ace ` a notre simulateur. Dans un premier temps, nous nous int eresserons ` a la phase dassociation d eterministe au r eseau dun coordinateur, et plus pr ecis ement a la dur ` ee n ecessaire ` a laboutissement de cette etape de cr eation du r eseau. Dans un second temps, nous nous int eresserons ` a la phase dassociation d eterministe dun nud.
3.1.2.1
Etude de lassociation d eterministe dun coordinateur
Cette premi` ere s erie de mesures met en evidence les performances temporelles de notre r eseau simul e dans la phase dassociation au r eseau dun coordinateur. Les etapes ` a valider sont les suivantes : r eveil et synchronisation sur les superbeacons, attente du PDS, envoi de la demande dassociation et dun GBS puis attente de la r eponse du supercoordinateur. Une premi` ere s erie de simulation a et e eectu ee et les r esultats sont repr esent es sur la gure 4.5.
Fig. 4.5 Repr esentation des fen etres temporelles pour lassociation d eterministe dun coordinateur (pour BO = 3)
La gure 4.5 repr esente les di erentes fen etres de temps pour lassociation au r eseau dun coordinateur, pour plusieurs valeurs de nP DS (0 nP DS 3). Notons que ce graphe a et e obtenu gr ace ` a la simulation de 2000 cr eations de r eseau constitu e dun supercoordinateur et de 3 coordinateurs (soit 6000 mesures de temps dassociation), pour un Beacon Order (BO) de 3 (soit une emission de superbeacon toutes les 122,88 ms). Sur la gure 4.5, laxe des abscisses repr esente le temps n ecessaire ` a lassociation Adrien van den Bossche 121
d eterministe dun coordinateur. Ce temps est d ecoup e en intervalles car le syst` eme est temporellement discret compte tenu du d ecoupage en slots temporels, une demande dassociation ne peut se faire qu` a certains instants. Laxe des ordonn ees repr esente la proportion dassociations r ealis ees sur chaque tranche temporelle. Bien entendu, plus nP DS est grand (cest-` a-dire plus la fr equence des slots r eserv es au pr ealable est faible), plus la plage temporelle sur laquelle les associations sont r eparties est large. A la vue de ces r esultats, nous pouvons constater plusieurs points : tout dabord, nous sommes bien ici en pr esence dune m ethode dassociation d eterministe car 100% des demandes dassociation au r eseau obtiennent une r eponse quelle soit positive ou n egative en un temps qui a une borne maximale : il est possible pour un coordinateur, ` a partir du moment o` u il entre sur le r eseau, d etre certain quil obtiendra une r eponse sur son association en moins de TACmax millisecondes (Temps dAssociation dun Coordinateur MAXimum ), valeur qui d epend des param` etres BO et nP DS , selon la formule : TACmax = Tslot 16 2BO (2nP DS + 1) o` u Tslot est la dur ee el ementaire dun slot, soit 960 s pour un slot PHY2450 de 802.15.4 ; la p eriodicit e de la diusion des superbeacons est alors de Tslot 16 2BO = 15, 36 ms 2BO Dapr` es cette formule, et par exemple, pour BO = 3 (comme cest le cas sur la gure 4.5), un niveau de r eservation nP DS = 0 permettra ` a un coordinateur denvoyer sa demande dassociation en moins de 122,88 ms apr` es r eception du superbeacon, un niveau 1 en moins de 245,76 ms, un niveau 2 en moins de 491,52 ms et un niveau de 3 en moins de 983,04 ms. Ces valeurs limites avaient et e evoqu ees th eoriquement dans la section 2.3.4 du chapitre 3 (cf. page 94). La simulation conrme ce qui avait et e d etermin e math ematiquement. A la vue de ces r esultats, on peut aussi constater que globalement, la distribution des temps dassociation est uniforme, comme on pouvait sy attendre, dans la mesure o` u, dune part le protocole ne privil egie pas lallocation au pr ealable de certains slots, et dautre part, dans notre simulation, linstant de r eveil des nuds suit une distribution uniforme et asynchrone vis-` a-vis de lhorloge du r eseau . Il ny a donc aucune raison que certains slots soient privil egi es. Enn, on note quaucune association de coordinateur naboutit en moins de 130,56 ms ; ceci etait attendu car le processus dassociation au r eseau dun coordinateur n ecessite une dur ee dau moins 17 slots pour aboutir, quelque soit la valeur du nP DS . En eet, dans le meilleur des cas, un coordinateur se r eveillera juste avant l emission du superbeacon annon cant son PDS, lutilisera, et se saura associ e au r eseau ` a la r eception du superbeacon suivant. On notera que si cette dur ee minimum TACmin (Temps dAssociation dun Coordinateur MINimum ) ne d epend pas de nP DS , en revanche, elle est directement fonction de BO ; dans notre cas o` u BO = 3, une dur ee de 17 slots vaut 130,56 ms comme on le d eduit de la formule : TACmin = Tslot 17 2BO Cette premi` ere etude concernant lassociation d eterministe dun coordinateur au r eseau nous permet donc de conclure sur la propri et e suivante : gr ace ` a la m ethode dacc` es que nous proposons, lassociation au r eseau d eterministe dun coordinateur est possible et r epartie uniform ement, et ce, dans une fen etre temporelle born ee TAC d enie comme suit : 17 Tslot 2BO TAC 16 Tslot 2BO (2nP DS + 1) ce qui est impossible ` a borner en CSMA/CA. 122 Groupe SCSF LATTIS EA4155
3.1.2.2
Etude de lassociation d eterministe dun nud
A pr esent, nous nous int eressons ` a lassociation d eterministe dun nud. La principale di erence entre lassociation d eterministe dun nud et celle dun coordinateur est le retard engendr e par le fait que la demande dassociation n ecessite d etre relay ee par le coordinateur du nud, puisque le nud ne peut envoyer directement sa requ ete au supercoordinateur. De plus, l etape de synchronisation du coordinateur sur le supercoordinateur doit avoir abouti avec succ` es. Comme dans le paragraphe pr ec edent, nous etudions cette phase pour plusieurs niveaux de r eservation, mais pour cette etude, il est n ecessaire de di erencier le niveau de r eservation des PDS du nud (nP DS ) du niveau de r eservation des GBS du coordinateur (nGBS ). En eet, dans ce cas, les param` etres a prendre en compte sont plus nombreux. ` Le r eseau simul e est constitu e ainsi : 1 supercoordinateur diusant ses superbeacons dans chaque supertrame, 4 coordinateurs diusant leurs beacons dans chaque supertrame (nGBS = 0), 4 nuds, chacun rattach es ` a un coordinateur, qui se voient aect es un niveau de r eservation pr ealable variable, compris entre 0 et 3 (nP DS = 0, 1, 2 ou 3). Le simulateur ainsi param etr e donne les r esultats repr esent es dans le graphique de la gure 4.6. Ce graphique repr esente les di erentes fen etres de temps pour lassociation au r eseau dun nud, pour nP DS = 0, 1, 2 ou 3. Ce r esultat a et e obtenu gr ace ` a la simulation de 21000 associations de nuds, pour un BO de 3 (soit une emission de superbeacon toutes les 122,88 ms). Laxe des ordonn ees repr esente la proportion des associations nalis ees en un temps indiqu e en abscisse.
Fig. 4.6 Repr esentation des fen etres temporelles pour lassociation d eterministe dun nud terminal (pour BO = 3 et nGBS = 0)
Linterpr etation des r esultats de simulation nous permet de tirer plusieurs conclusions. Tout dabord, l` a encore, nous sommes bien en pr esence dune m ethode dassociation au r eseau d eterministe car 100% des nuds obtiennent une r eponse, quelle soit positive ou n egative, dans une fen etre de temps d etermin ee et born ee. La taille de cette fen etre temporelle d epend des param` etres temporels du r eseau : pour une certaine valeur nP DS et une valeur nGBS de 0 (le coordinateur du nud diuse un beacon dans chaque Adrien van den Bossche 123
supertrame), les associations sont r ealis ees en un maximum de 2nP DS + 1 supertrames. Temporellement, si nous consid erons alors le param` etre BO, par exemple BO = 3 comme cest le cas pour le graphe de la gure 4.6 (une supertrame toutes les 122,88 ms), nous pouvons armer que 100% des associations seront r ealis ees en un temps maximal TAN max (Temps dAssociation dun Noeud MAXimum ) qui suit la loi : TAN max = Tslot 16 2BO (2nP DS + 1) Cette equation peut etre g en eralis ee pour toute valeur de nGBS selon : TAN max = Tslot 16 2BO (2nP DS + 2nGBS ) Cette g en eralisation est conrm ee par le graphe de la gure 4.7 qui repr esente les r esultats temporels de 1800 cr eations dun r eseau constitu e dun supercoordinateur et de 3 coordinateurs, chacun ayant un nud. Pour cette simulation, nGBS est x e` a 1 (soit une diusion de beacons toutes les 2 supertrames) et nP DS varie entre 1, 2 et 3.
Fig. 4.7 Repr esentation des fen etres temporelles pour lassociation d eterministe dun nud terminal (pour BO = 3 et nGBS = 1) Une seconde remarque concerne la dur ee minimale dune association au r eseau. En eet, sur le graphe de la gure 4.6, nous pouvons constater quaucune demande dassociation nest concr etis ee en moins de 245,76 ms. Nous pouvons egalement constater que cette valeur ne d epend pas de la valeur de nP DS . De m eme, sur la gure 4.7, aucune association nest concr etis ee en moins de 491,52 ms. Ceci sexplique par le fait que le m ecanisme dassociation dun nud n ecessite au moins la transmission de trois beacons par son coordinateur, comme le dialogue protocolaire limplique (rappel) : 1. 2. 3. 4. le nud attend de recevoir un premier beacon de son coordinateur qui annonce son PDS, a la r ` eception de ce beacon, le nud attend son PDS, au moment du PDS, le nud emet sa demande dassociation au r eseau, le coordinateur r eceptionne cette demande, la r epercute au supercoordinateur lors de l emission dun second beacon, Groupe SCSF LATTIS EA4155
124
5. le supercoordinateur communique son approbation / d esapprobation dans le superbeacon qui suit, 6. le coordinateur relaie la r eponse dans un troisi` eme beacon et le nud sait alors sil est associ e ou non. De ce fait, le d elai minimal pour lassociation d eterministe dun nud TN Amin d epend uniquement des param` etres BO et nGBS selon la loi : TAN min = Tslot 16 2BO+nGBS +1 Enn, cette etude par la simulation nous montre que, comme dans le cas de lassociation du coordinateur, la r epartition temporelle au sein de cette fen etre est uniforme, car le protocole, dans cette version, ne privil egie pas certains cr eneaux temporels par rapport ` a dautres. Cette seconde etude sur lassociation d eterministe dun nud au r eseau nous permet donc de conclure sur la loi suivante : gr ace ` a la m ethode dacc` es que nous proposons, lassociation au r eseau d eterministe dun nud est possible et r epartie uniform ement, et ce, dans une fen etre temporelle born ee TAN selon la formule : Tslot 16 2BO+nGBS +1 TAN Tslot 16 2BO (2nP DS + 2nGBS ) ce qui, encore une fois, est impossible a ` borner avec une m ethode dacc` es bas ee sur CSMA/CA.
3.2
3.2.1
Les travaux r ealis es sous NS2

Pr esentation de loutil
NS (Network Simulator ) [NS] est un simulateur ` a ev` enements discrets destin e aux travaux de recherche sur les r eseaux. Il permet la simulation dune grande diversit e de protocoles ` a tous les niveaux dune pile protocolaire (protocoles de niveau r eseau et transport comme TCP/IP, protocoles de routage et de multicast, . . .). Il permet la simulation dun grand nombre de r eseaux locaux et/ou etendus, laires ou sans l. Le projet NS a et e lanc e en 1989 comme une variante du simulateur REAL network simulator. Comme de nombreux projets ouverts, il evolue au gr e des contributions de ses utilisateurs. Il a ni par simposer, depuis quelques ann ees, comme une r ef erence dans le domaine de la simulation des r eseaux. La grande di erence entre NS et ses principaux concurrents (OPNET [OPNE], Qualnet [QUAL 02] [QUAL]) est quil est totalement Open Source et gratuit. NS nen reste pas moins un outil soutenu par des acteurs puissants de la recherche, comme le DARPA, Sun, Xerox, UCB, USC/ISI [VINT 95], le CNRS fran cais. . . Le projet NS propose un ensemble de logiciels pour la simulation des r eseaux : le moteur de simulation NS2 en est l el ement central ; il g en` ere des chiers trace qui doivent etre interpr et es pour en extraire les r esultats. Dautres outils comme NAM (Network Animator ) permettent une exploitation plus visuelle et conviviale des r esultats de simulation.
3.2.2
Les mod` eles 802.15.4 / ZigBee existants sous NS2
Lorsque nous avons d ebut e nos travaux de th` ese, seul un mod` ele IEEE 802.15.4 / ZigBee [SAMS], [ZHEN 04], [ZHEN 06] existait pour NS2 et avait et e publi e. Ce mod` ele a et e d evelopp e par J. Zheng and Myung J. Lee du d epartement Electrical Engineering de lUniversit e City College de New York en Adrien van den Bossche 125
collaboration avec SAMSUNG. Il a dabord et e publi e sous forme de patch de NS2 avant d etre int egr e dans la distribution ocielle ` a partir de la version 2.28. Il proposait la plupart des fonctionnalit es d ecrites dans le draft D18 [IEE3 03] qui a pr ec ed e la norme actuelle. En revanche, parmi les m ecanismes non impl ement es se trouvaient notamment la gestion des GTS, ce qui, de notre point de vue, constituait un manque important. Un autre mod` ele r ealis e par G. Lu de l equipe ANRG (Autonomous Networks Research Group ) de lUniversit e Southern California de Los Angeles [GANG 04] avait aussi et e d evelopp e mais de mani` ere bien plus sommaire, car nimpl ementant que la partie CAP de la MAC de 802.15.4. Durant la th` ese, nous avons tent e de compl eter en vain le mod` ele de J. Zheng. Par manque de documentation et dexp erience sur la programmation de ce mod` ele sous NS2, limpl ementation de la gestion des GTS etape pr eliminaire n ecessaire pour pouvoir comparer notre proposition ` a lexistant na pu etre nalis ee. Cependant, bien que les mod` eles existants soient incomplets sur la partie CFP/GTS de IEEE 802.15.4, il nous a sembl e int eressant de reprendre ici quelques r esultats obtenus par lutilisation de NS2 sur la partie CAP et CSMA/CA. Ces r esultats pourront etre ensuite compar es avec les performances de notre m ethode dacc` es d eterministe (cf. 4.3.2.2).
3.2.3
Un r esultat obtenu avec NS2 : d ebit utile dans la CAP avec CSMA/CA
Cette etude, initi ee par [GANG 04], a et e r ealis ee par la simulation dun r eseau de 49 noeuds r epartis uniform ement sur un terrain de 7 x 7, tous espac es de 4 m, le coordinateur du r eseau se trouvant au milieu. La port ee etant x ee ` a 16 m, tous les noeuds sont ` a port ee du coordinateur mais tous ne se trouvent pas dans le m eme domaine de diusion5 . Les param` etres temporels de la supertrame sont BO = 0 et SO = 0 (pas de somnolence cyclique), les paquets de donn ees ont une taille de 50 octets et les beacons, 24 octets. L etude porte sur deux cas : une unique source (pas de collisions possibles) ou 20 sources. Les r esultats sont visibles sur la gure 4.8.
Fig. 4.8 D ebit utile avec CSMA/CA dans un r eseau 802.15.4 avec beacons Sur cette gure, nous pouvons constater que, pour une unique source, le d ebit utile maximum est de
CSMA/CA impl ement e dans 802.15.4 ne pr evoit pas de RTS/CTS. Cette remarque est importante dans le cadre dune etude de d ebit car lorsque deux noeuds trop lointains contactent en m eme temps le coordinateur, la collision est in evitable sans RTS/CTS.
5 Le
126
Prototype et m etrologie
38 kbits/s. Ce d ebit est tr` es inf erieur au d ebit bande de base de 250 kbits/s, ceci etant d u` a la pr esence des temps inter-trames, des backos et des acquittements. Dans le cas de l etude portant sur 20 sources, on retrouve bien la courbe en cloche typique de CSMA/CA, le maximum du d ebit utile etant de 32 kbits/s pour une sollicitation de 70 kbits/s globale au r eseau. Au del` a, les performances diminuent fortement, ce qui ne sera pas le cas dans le cadre de notre m ethode dacc` es d eterministe, comme nous le verrons plus tard dans la section 4.3.2.2 !
3.3
Conclusion sur les travaux de simulation
La conception du simulateur et lanalyse des r esultats nous ont permis dobtenir les premiers param` etres temporels de performances dun r eseau mettant en uvre la m ethode dacc` es que nous proposons, sp eciquement dans les phases critiques que sont lassociation au r eseau et la demande de ressources d eterministes. Bien entendu, le simulateur que nous avons d evelopp e nest pas complet ; comme nous lavions pr ecis e au d ebut de cette partie, en particulier, il ne consid` ere pas les erreurs sur le m edium. Cependant, les r esultats que nous obtenons gr ace ` a notre simulateur sont prometteurs car le syst` eme simul e pr esente bien les caract eristiques, en terme de d eterminisme, que nous attendions. La m ethode dacc` es, si nous la consid erons ind ependamment de tout le reste du syst` eme de communication, ne soure daucun blocage et semble temporellement tr` es ecace. Le d eterminisme attendu est bien pr esent, car toute demande eectu ee par un nud du r eseau, du point de vue de la r epartition des acc` es concurrents sur le m edium, obtient une r eponse dans un temps imparti. Suite ` a lorientation du travail de la th` ese et ` a labsence de maturit e sur les mod` eles existant (NS2), nous avons d ecid e de ne pas consacrer plus de temps ` a l etude par simulation ; ` a d efaut de le simuler, un travail plus n mettant en oeuvre un m edium r eel a et e avantageusement r ealis e par un prototype mat eriel et des m etrologies avanc ees. Ce travail est expos e dans la section suivante.
La partie prototypage constitue le troisi` eme volet de la validation de nos propositions. Cette partie vient compl eter les deux pr ec edentes en ajoutant les aspects imparfaits de la transmission, les caract eristiques intrins` eques du mat eriel et du logiciel et la port ee radio limit ee de nos transceivers. De plus, de part les activit es applicatives et p edagogiques du laboratoire, laspect prototypage constituait, d` es le d epart, un objectif incontournable. Nous nous sommes donc naturellement tourn es vers la r ealisation dun prototype mat eriel, tout dabord pour valider la faisabilit e de notre proposition et en evaluer les performances r eelles puis pour pr esenter un prototype fonctionnel de d emonstration.
4.1
4.1.1
Pr esentation de lexistant
Les plateformes IEEE 802.15.4/ZigBee existantes
Le d ebut de la th` ese (octobre 2004) a co ncid e avec la commercialisation des premiers kits de d eveloppement ZigBee et IEEE 802.15.4. Durant toute la p eriode d etude, il y a toujours eu deux principales (majeures) solutions propos ees par les industriels : La solution Chipcon, tout dabord bas ee sur un microcontr oleur Microchip, puis derni` erement associ e` a un microcontr oleur Texas Instrument,
127
La solution Freescale, dabord bas ee sur un microcontr oleur Motorola 68HC089S, puis derni` erement int egr ee sur un composant monochip du m eme fabricant. Tous les travaux de prototypage elabor es pendant la th` ese ont utilis e la seconde solution. Nous disposions dun contact dexcellente qualit e chez Freescale, ` a Toulouse, ce qui nous a largement permis de gagner en ecacit e. Nous avons et e amen es ` a travailler sur plusieurs plateformes de la famille Freescale : des cartes de d eveloppement (13192-SARD, premi` ere g en eration), des modules compacts (ZigBee Reference Design, ZRD01), des cartes de d eveloppement (13213-SRB et 13213-NCB, seconde g en eration).
Fig. 4.9 Quelques plateformes IEEE 802.15.4/ZigBee de Freescale Ces trois plateformes mat erielles sont equivalentes sur le plan de la m emoire (64 ko) et du CPU (8 bits, cadenc e par le module radio). Elles disposent toutes dun port s erie (RS-232 et/ou USB), dun port de programmation BDM3 (port de programmation d edi e) pour le t el echargement du rmware et de plusieurs GPIO3 tout ou rien et analogiques. Les composants de la carte (microcontr oleur, modem) fonctionnent sur une large plage dalimentation (entre 2 et 3,6 volt) pour pouvoir utiliser aussi bien 2 piles alcalines (3,2 volt) que des accus NiCd ou NiMh en n de vie (moins de 2,3 volt). Les plateformes Freescale de premi` ere g en eration etaient equip ees de deux chips : le microcontr oleur 8 bits (classique, de type MC9S08GT60) et le modem radio 2,4 GHz (MC13192, d evelopp e sp eciquement par Freescale pour equiper les nuds ZigBee). Dans le cadre de cette solution, le microcontr oleur est cadenc e par le modem qui peut ainsi g erer le mode somnolence ; le modem inclut un timer de tr` es faible consommation, unique composant au travail dans ce mode. La derni` ere g en eration de plateformes Freescale est, quant ` a elle, monochip : le MC13213 renferme sous un m eme bo tier plastique un microcontr oleur 8 bits et un modem radio equivalent au MC13192, permettant ainsi au constructeur de proposer une solution plus compacte. Le modem 2,4 GHz est charg e de l emission et de la r eception des paquets de niveau physique 6 , calcul du CRC inclus (aussi bien ` a l emission qu` a la r eception). Le modem communique avec le microcontr oleur via un bus SPI ; pour r ealiser cette communication, deux modes sont envisageables : avec le mode packet, les donn ees transitent sous forme de bloc et sont tamponn ees dans le modem avant emission sur le m edium ou avant envoi au microcontr oleur, ce qui implique, dans un sens comme dans lautre, que toutes les donn ees ont et e re cues par le modem avant de pouvoir les traiter. Ce mode est le plus simple ` a mettre en uvre mais induit une certaine latence proportionnelle a la longueur du paquet ` emis/re cu. avec le mode stream, les donn ees transitent au l de leau . En emission, le microcontr oleur signale au modem quune nouvelle trame de n octets va etre envoy ee et le modem commence ` a
6 Nous avions vu dans le second chapitre que cest par ce terme que 802.15.4 d enit une quantit e dinformations transmises au niveau physique, bien que cet emploi constitue un non sens du point de vue de lOSI !
128
emettre le pr eambule, le fanion de d epart et la longueur n. Le microcontr oleur envoie ensuite les donn ees sur le bus SPI qui sont imm ediatement envoy ees sur le m edium. En r eception, lop eration est la m eme. Le mode stream est plus complexe ` a mettre en uvre et induit une charge CPU plus importante ; en revanche, il induit une latence tr` es faible et constante (elle ne d epend pas de la longueur de la trame re cue). Le bus SPI permet egalement au microcontr oleur de congurer le modem MC13192 (changement de canal, choix de lune des 18 puissances d emission possibles, conguration du timer ` a faible consommation, etc.) ou de linterroger ( energie sur le m edium, puissance de la derni` ere trame re cue, etc.).
4.1.2
Modication du rmware existant
Au niveau logiciel, les plateformes Freescale sont programmables via le port BDM ou via le port s erie si le module dispose dun bootloader Le bootloader est un micrologiciel ex ecut e ` a chaque d emarrage du microcontr oleur qui permet notamment de asher lEEPROM sans port sp ecique.. Toute la m emoire du microcontr oleur peut etre reprogramm ee : le programmeur dispose dune grande libert e pour d evelopper des applications qui peuvent interagir directement au niveau r eseau, voire au niveau MAC, comme cest le cas pour notre prototype7 . Freescale fournit trois solutions logicielles pour le programmeur (dans les derni` eres versions des kits de d eveloppement, Freescale parle de Code Bases ) pour d evelopper des applications communicantes : SMAC (Simple Medium Access Control ) est la solution la plus simple. Elle propose un jeu de primitives tr` es simpli e pour permettre le d eveloppement rapide dapplications communicantes propri etaires. Les applications bas ees sur SMAC ont une compatibilit e 802.15.4/ZigBee au niveau de la couche physique, mais pas n ecessairement aux niveaux sup erieurs (formats des messages, m ecanismes impl ement es). Cette solution propos ee par Freescale est gratuite et utilise tr` es peu de ressources m emoire et CPU (lensemble du code de la pile SMAC tient sur 4 ko de m emoire). IEEE 802.15.4 propose lensemble des fonctionnalit es pr evues par le standard du m eme nom (couches physique et liaison ). Nous verrons plus bas que, contrairement ` a ce quannonce le constructeur, toutes les primitives d enies par lIEEE nont pas et e impl ement ees par Freescale du moins, ` a lheure o` u ces lignes ont et e ecrites ce qui nous a pos e quelques probl` emes lors du d eveloppement du prototype. Comme SMAC, la pile 802.15.4 est elle aussi gratuite. La pile RFD tient sur 18 ko de m emoire et la pile FFD sur 40 ko. La solution ZigBee permet au programmeur de d evelopper une solution r eseau dont la pile a et e certi ee par la ZigBee alliance. Toute la pile est fournie, compl` ete, sous forme de librairies. Le d eveloppeur na plus qu` a d evelopper le ou les prols correspondant ` a son application. A la di erence de SMAC et 802.15.4, lutilisation de la pile ZigBee est payante. La licence co ute environ $1000 pour une version avec librairies et $50.000 pour une version open source. Au cours des travaux de prototypage r ealis es pendant la th` ese, nous avons rencontr e des dicult es pour modier la pile IEEE 802.15.4 fournie par Freescale. Gr ace ` a C. Zarader de Freescale Toulouse, nous avions pu obtenir le code de la pile 802.15.4 et nous avons entrepris une importante modication de la pile existante pour impl ementer nos propositions et permettre la r ealisation du prototype. Malheureusement, nous avons constat e que la partie sur les GTS n etait pas op erationnelle. De plus, le code r ealis e par Freescale etant tr` es compact et fortement optimis e, il etait dicile de le modier, m eme l eg` erement. Nous avons nalement d ecid e de baser notre prototype sur la pile SMAC, en d eveloppant les fonctionnalit es de 802.15.4 dont nous avions besoin pour le prototype (g en eration de beacons et synchronisation, envoi/r eception de trames de gestion et de donn ees, etc.). Dans nos perspectives, nous pr evoyons le
7 Cette particularit e constitue une grande originalit e dans le monde des r eseaux, o` u, g en eralement, il est impossible de reprogrammer int egralement une couche MAC, du moins sur du mat eriel non sp eciquement d esign e` a cet usage.
129
d eveloppement dun nouveau prototype plus complet.
4.2
R ealisation doutils de tests et de mesures
Pour r ealiser les mesures sur le prototype, nous avons exploit e plusieurs fonctionnalit es mat erielles et logicielles de la plateforme et r ealis e plusieurs outils. Pour les mesures ` a caract` ere temporel internes au module, nous avons utilis e lun des timer du composant, permettant ainsi de dater des ev` enements. Les r esultats des mesures sont envoy es sur le port s erie puis exploit es, en di er e, sur un PC par un logiciel sp ecique d evelopp e` a cet eet. Pour les mesures temporelles mettant en jeu plusieurs modules, nous avons utilis e les GPIO parall` eles du microcontr oleur : en assignant chaque ev` enement ` a un bit de GPIO et par utilisation conjointe dun analyseur d etat logique temporis e, nous disposions alors dun outil de mesure temporel tr` es performant et ind ependant de notre m ethode de synchronisation globale aux modules (ce qui nous a dailleurs permis de l evaluer cf. paragraphe 4.3.1.4). Pour les mesures sur le m edium radio, nous avons r ealis e deux outils d` es le d ebut de nos travaux : un module ZigBee espion, cest-` a-dire un r ecepteur, bloqu e sur un canal, qui envoie sur son port s erie le contenu de toute trame re cue sur la radio ; il est egalement dot e dun syst` eme de datation dune pr ecision de 64 s et dun indicateur de puissance du signal re cu dune pr ecision de 0,5 dBm. Chaque trame re cue se voit associ es son instant de r eception et sa puissance de r eception. un analyseur de trames sur PC, facilement adaptable au rythme des modications que nous apportions sur le protocole. Bien entendu, ces deux outils fonctionnaient ensemble lancement dune capture avec lespion et stockage des donn ees arrivant sur le port s erie du PC, puis interpr etation et visualisation des trames captur ees gr ace ` a lanalyseur de trames (comme illustr e gure 4.10).
Fig. 4.10 Utilisation conjointe du module espion et de lanalyseur de trames
Ces outils nous ont permis de faire les tests et les mesures n ecessaires ` a la validation de notre pile prototype qui sont d etaill es dans la section suivante. 130 Groupe SCSF LATTIS EA4155
4.3
4.3.1
Conception et r ealisation dune pile prototype

Evaluation des performances de la pile prototyp ee
Tout au long du d eveloppement du prototype, nous avons cherch e` a caract eriser nement les performances de notre r ealisation, depuis le mat eriel et le logiciel de base utilis e pour la r ealisation, jusqu` a la validation de nos propositions. Cette section pr esente les r esultats des di erentes mesures qui ont et e r ealis ees pendant le prototypage de notre pile protocolaire : sensibilit e du r ecepteur et taux derreur trame typique, temps de traitement typique par paquet, d ebit utile et qualit e du m ecanisme de synchronisation des noeuds par beacons. Evaluation de la sensibilit e du r ecepteur
4.3.1.1
Le but de cette premi` ere s erie de mesures est d evaluer la sensibilit e du r ecepteur 2,4 GHz pr esent dans le MC13192 et d evaluer le taux de perte de trame typique dans le cadre dune utilisation id eale, cest-` a-dire sans perturbation electromagn etique et sans acc` es au m edium concurrent (probabilit e de collisions nulle). Cette s erie de mesures a et e r ealis ee dans la chambre an echo que 8 de lIUT de Blagnac. Un programme de test se basant sur la pile SMAC a et e d evelopp e et pr` es de 30000 trames index ees ont et e transmises pour r ealiser cette s erie de mesures. La fonctionnalit e dajustement de la puissance d emission a et e utilis ee pour permettre d evaluer la sensibilit e du r ecepteur sur une large plage depuis des conditions de r eception tr` es confortables (< -30 dBm) aux conditions limites donn ees par le constructeur (-95 dBm). Les r esultats sont pr esent es sur la gure 4.11.
Fig. 4.11 Evaluation de la proportion de trames perdues en fonction de la puissance du signal re cu
8 Une chambre an echo que est une pi` ece etanche sur le plan electromagn etique et dont le rev etement int erieur supprime les r eexions sur les parois. Cest un lieu quasi id eal pour ce type de mesures car il permet de saranchir des nombreuses sources de rayonnement et de perturbations, notamment dans la bande des 2,4 GHz (points dacc` es WiFi et Bluetooth, fours ` a micro-ondes, etc.).
131
Les r esultats de cette etude permettent de montrer que, m eme dans un environnement id eal du point de vue des couches physique et liaison (pas de perturbations electromagn etiques, pas de m ethode dacc` es), la transmission nest pas exempte derreurs, y compris dans des conditions de r eception excellentes (quelques pertes constat ees dans des conditions meilleures que -50 dBm). Il est int eressant de constater ici que, m eme si nos travaux proposent une m ethode dacc` es au m edium d eterministe, les erreurs introduites au niveau de la couche physique sont, elles, in evitables ` a notre niveau et doivent etre prises en compte. Nous pouvons egalement noter ici que les r esultats de cette etude pourraient permettre lam elioration du simulateur pr esent e plus haut dans la partie 3 par lintroduction derreurs de transmission bas ees sur cette s erie de mesures. Cette etude sera enonc ee dans les perspectives.
4.3.1.2
Evaluation du temps de traitement dun paquet
Le but de cette seconde s erie de mesures est de quantier le temps n ecessaire au traitement complet dun paquet par la pile SMAC, cest-` a-dire la dur ee entre le moment o` u la demande d emission est eectu ee sur un premier module, jusqu` a linstant o` u les donn ees ont et e re cues et sont disponibles dans la m emoire dun second module. Nous avons vu plus haut que SMAC utilise le mode packet pour la communication entre le microcontr oleur et le modem radio ; en plus du temps de s erialisation important d u au faible d ebit sur le m edium radio, le temps de transfert dun paquet de donn ees de la m emoire vers le modem par le bus SPI est a priori non n egligeable, comme indiqu e sur la gure 4.12. Le d elai de transmission global doit etre quanti e.
Fig. 4.12 Illustration des d elais engendr es sur toute la transmission avec SMAC et le mode packet Lint er et de cette s erie de mesures est triple : 1. evaluer la latence de transmission dun message quelconque, et plus particuli` erement celle dun beacon pour aner la proc edure de synchronisation des noeuds, 2. evaluer la latence minimale et le d ebit utile maximal pour une transmission utilisant nos transceivers, 3. par extrapolation, evaluer la capacit e dun slot, cest ` a dire le volume de donn ees maximum transmissibles pendant cette portion temporelle. Pour r ealiser cette s erie de mesures, nous avons mis en uvre deux nuds bas es sur la pile SMAC. Le premier nud est programm e pour envoyer des trames de longueurs di erentes9 toutes les 10 ms. Les trames sont emises directement, sans m ethode dacc` es, comme elles le seraient dans un GTS. Juste avant
9 Cest ` a dire ici une variation du nombre doctets utiles, soit, puisque nous sommes au niveau physique, une variation de la longueur du PSDU.
132
la transmission dune nouvelle trame, le nud emetteur inverse lune de ses GPIO. Le second nud est, quant ` a lui, bloqu e en r eception ; ` a chaque trame re cue, il inverse lui aussi lune de ses GPIO. Gr ace ` a un analyseur d etat logique temporis e, la di erence de temps est mesur ee et stock ee. Les r esultats de cette s erie de mesures sont repr esent es gure 4.13.
Fig. 4.13 Mesure du d elai total (temps de traitement et de transmission) en fonction de la longueur utile du paquet transmis (PSDU)
La gure 4.13 nous indique que quelque soit le volume de donn ees transmis, un d elai denviron 300 s est constat e, auquel viennent sajouter 64 s par octet transmis. Le temps de traitement Ttraitement (en ms) dun paquet de longueur l (en octets) avec SMAC peut donc etre mod elis e par lexpression math ematique suivante10 : Ttraitement =
l 8 125
+ 0, 3
A priori, le d elai initial denviron 300 s est in evitable car d u au pr eambule et ` a len-t ete PHY de 802.15.4 qui ont une longueur cumul ee de 56 bits, soit 224 s ` a 250 kbits/s. En revanche, la pente de la droite de la gure 4.13 est de 64 s par octet, alors qu` a 250 kbits/s, le temps de s erialisation dun octet est de 32 s, et non 64 s. Ce temps excessif est probablement d u au transfert de donn ees par le bus SPI qui doit avoir re cu int egralement un paquet avant de pouvoir l emettre sur la radio (c ot e emetteur) o` u de lenvoyer au microcontr oleur (c ot e r ecepteur) comme lillustrait la gure 4.12. La m eme s erie de mesures devra etre eectu ee en mode stream pour conrmer cette hypoth` ese mais, dans le cadre du prototype pr esent e bas e sur SMAC, et donc, sur le mode packet nous consid ererons ces performances mesur ees.
4.3.1.3
D ebit utile maximum
La s erie de mesures pr esent ee dans la section pr ec edente montre que les performances de SMAC en terme de d ebit sont relativement faibles. Cependant, compte tenu du temps du traitement dun paquet, il est possible, par extrapolation, de d eduire le nombre maximum de paquets traitables par seconde, soit le d ebit utile maximum, en fonction de la longueur du paquet (si les paquets sont envoy es les uns ` a la suite des autres, toujours sans m ethode dacc` es et sans acquittement). Cette evaluation est repr esent ee
10 Cette formule sera utilis ee plus bas pour calibrer la synchronisation du r eseau par les beacons dans le mode suivi de beacon. Nous aborderons ce point plus loin dans la section 4.3.1.4.
133
par le graphe de la gure 4.14. Comme nous pouvons le voir sur ce graphe, le d ebit utile maximum dune transmission r ealis ee avec notre dispositif bas e sur SMAC est de 120 kbits/s, soit un peu moins de la moiti e du d ebit bande de base.
Fig. 4.14 Evaluation du d ebit utile maximal en fonction de la longueur du paquet transmis
4.3.1.4
Evaluation de la qualit e de la synchronisation entre un coordinateur et ses nuds
Toujours dans le but d evaluer la qualit e de notre pile prototype, nous avons cherch e` a evaluer la qualit e de la synchronisation des nuds. En eet, dans le cadre de notre proposition, les el ements de type ls (cf. section 2.2.2 de ce chapitre) se synchronisent sur les el ements de type p` ere ` a la r eception des trames beacons. La synchronisation permet ainsi le d ecoupage du temps en slots temporels qui sont ensuite allou es aux di erents el ements du r eseau pour les acc` es d eterministes. Ce d ecoupage temporel exige donc une excellente synchronisation des nuds sur leur coordinateur car si la synchronisation est m ediocre, les performances du r eseau seront globalement moins bonnes : les slots ne sont pas synchrones pour tous les nuds : apparition dun risque de collisions en bordure des GTS, le suivi de beacon nest pas optimum : consommation d energie accrue. Pour notre pile prototype, nous avons impl ement e le mode suivi de beacons en etant confront e au probl` eme du temps de traitement variable en fonction de la taille du paquet transmis, comme cela a et e evalu e dans la section 4.3.1.2 de ce chapitre. Pour simplier la r ealisation de la synchronisation, nous avons impl ement e une diusion de beacon de taille constante (30 octets), bien que la norme 802.15.4 pr evoit que les beacons puissent etre de longueur variable. Nous avons ensuite calibr e le timer utilis e pour le suivi de beacons gr ace ` a la formule etablie dans la section 4.3.1.2. Une fois cette partie du prototype d evelopp ee, nous avons cherch e` a quantier la gigue r esiduelle, cest ` a dire limperfection de la synchronisation. Tout dabord, la gigue a et e mesur ee entre deux nuds dune m eme etoile, comme lillustre la gure 4.16 : un m eme coordinateur envoie des beacons ` a deux de ses propre nuds N1 et N2, lui-m eme etant synchronis e par les superbeacons quil re coit du supercoordinateur. La resynchronisation des nuds se fait donc ` a chaque r eception de beacon, soit toutes les 122 ms (BO = 3). La gure 4.16 illustre les r esultats typiques obtenus pour cette s erie de mesures. Sur cette gure, laxe des abscisses repr esente la 134 Groupe SCSF LATTIS EA4155
Fig. 4.15 Topologie pour la mesure de la gigue de synchronisation pour deux nuds dune m eme etoile
di erence de synchronisation dun nud par rapport ` a lautre. Laxe des ordonn ees repr esente le nombre doccurrences des mesures pour la di erence donn ee en abscisses. Gr ace ` a cette s erie de mesures, nous pouvons constater que la synchronisation est tr` es correcte si lon ram` ene les valeurs mesur ees au temps bit sur le m edium de (4 s) et ` a la longueur du pr eambule (40 bits) n ecessaire ` a la synchronisation du r ecepteur : le temps moyen (sur lensemble des mesures) est de 160 ns, 95% des occurences sont inf erieures a 16 s et la gigue est uniform ` ement r epartie (tant en avance quen retard dun nud ` a lautre). Parmi les 5% des occurences qui expriment une di erence de synchronisation sup erieure ` a 16 s (laire noire sur la gure 4.16), la plus forte valeur mesur ee est 27 s (soit pr` es de 7 temps bit ` a 250 kbits/s).
Fig. 4.16 Quantication de la gigue de synchronisation pour deux nuds dune m eme etoile
4.3.1.5
Conclusion
Ces premi` eres mesures relatives au mat eriel et ` a la pile SMAC montrent que cette solution de programmation nest pas parfaite mais pr esente lavantage d etre simple et exible. Il est tout ` a fait possible, pour le programmeur, dintervenir au niveau MAC dans des conditions int eressantes. De plus, les d efauts etant maintenant identi es, le d eveloppement de la pile prototype peut etre abord e avec s er enit e. Les r esultats qui suivent portent sp eciquement sur nos propositions concernant la m ethode dacc` es totalement d eterministe. Adrien van den Bossche 135
4.3.2
Validation de notre proposition par prototypage
Cette partie pr esente les etudes qui ont et e men ees sur le r eseau prototype utilisant la m ethode dacc` es d eterministe, les points valid es ici constitant une originalit e par rapport au r eseau 802.15.4 existant. Dans cette partie, on sattachera ` a mettre en evidence la qualit e de la synchronisation ` a plusieurs niveaux, le d ebit oert maximal et la faisabilit e des SGTS. Evaluation de la qualit e de la synchronisation entre le supercoordinateur et ses
4.3.2.1 nuds
Apr` es avoir mesur e la qualit e de la synchronisation entre deux nuds dune m eme etoile dans le paragraphe 4.3.1.4, nous avons cherch e ` a quantier la gigue entre deux nuds d etoiles di erentes. La topologie du r eseau utilis e pour cette mesure est repr esent ee par la gure 4.17. Pour ce nouveau cas, les deux nuds etudi es sont synchronis es par deux coordinateurs di erents, qui sont eux-m emes synchronis es par le supercoordinateur : nous sommes donc en pr esence dune synchronisation relay ee (sur deux niveaux), la gigue devrait etre th eoriquement plus importante puisque la synchronisation des nuds cumule lerreur des deux coordinateurs.
Fig. 4.17 Topologie pour la mesure de la gigue de synchronisation pour deux nuds de deux etoiles di erentes
La gure 4.18 donne un exemple de r esultats obtenus pour cette nouvelle s erie de mesures. Si on les compare aux r esultats concernant la synchronisation dune etoile, on constate queectivement, la gigue est plus importante mais reste tout de m eme acceptable puisque 95% des mesures eectu ees rapporte une di erence de synchronisation inf erieure ` a 23 s et que la plus grande valeur mesur ee est 38 s. En revanche, et cest un d etail plus important, la gigue nest pas uniform ement r epartie : sur lensemble des mesures pratiqu ees, on constate que lun des deux nuds est plus souvent en avance que lautre. Cette s erie de mesure r ev` ele probablement un probl` eme mineur dans la proc edure de synchronisation qui devra etre an ee ; en revanche, nous verrons plus bas que cette asym etrie dans la synchronisation nous a permis de mettre en evidence leet de capture dans le cadre des SGTS.
136
Fig. 4.18 Quantication de la gigue de synchronisation pour deux nuds de deux etoiles di erentes
4.3.2.2
Capacit e maximale dun slot
Comme nous lavons vu largement jusquici, notre proposition conserve le concept de slot d eni par 802.15.4. Il serait donc int eressant, dans le cadre de nos travaux, de d eterminer la capacit e maximale dun slot (cest-` a-dire le nombre maximal doctets, voire le nombre maximal de trames transmissibles dans un slot). Si ce slot est un GTS, il devient alors possible de quantier le d ebit garanti par la m ethode dacc` es, cest-` a-dire le volume de donn ees transmises dans un GTS, ramen e` a la seconde. Connaissant pr ecis ement, pour un noeud de notre r eseau prototype, le temps de traitement global dun paquet11 (r esultats pr esent es dans le paragraphe 4.3.1.2), il est possible, par extrapolation, d evaluer la capacit e dun slot en fonction du param` etre BO et du niveau de r eservation n de ce slot (nGT S , nP DS ou nGBS ). Cependant, pour evaluer la capacit e dun slot, il est n ecessaire de consid erer deux cas, avec ou sans acquittement contenu dans le slot12 . Dans le premier cas, il est n ecessaire de consid erer le temps de traitement de la trame dacquittement en plus du temps de traitement de la trame envoy ee. Nous avons vu dans le chapitre 2, section 2.3.3.4 (page 68) que la trame dacquittement 802.15.4 a une longueur de 5 octets, soit, dapr` es les mesures r ealis ees plus haut, un temps de traitement de 620 s. Nous avons vu egalement dans le chapitre 3, section 2.3.5 (page 95) quun temps intertrame de 192 s devait etre respect e. Connaissant toutes ces donn ees temporelles, il est possible de d eterminer la capacit e maximale dun slot avec ou sans acquittement, en fonction des param` etres BO et n. Le graphe de la gure 4.19 illustre ces r esultats. Cette etude nous permet de constater quavec notre prototype, il nest pas possible denvisager un r eseau o` u BO = 0. En eet, pour cette valeur, un slot na pas la capacit e n ecessaire pour lenvoi dune trame, m eme tr` es petite, et son acquittement. Le BO minimal, pour notre r eseau prototype, sera donc de 1. De plus, nous pouvons constater que la valeur BO = 3 donne des r esultats int eressants car elle permet un d ebit proche du maximum, tout en permettant une dur ee de supertrame assez courte (122 ms, donc une latence globale faible, comme montr e par la simulation). Cette valeur, qui pr esente un compromis int eressant, a et e retenue pour notre r eseau prototype, et, par la m eme occasion, pour les travaux de simulation qui ont et e expos es plus haut dans la section 3.1.
: envoi au modem, transmission sur lair puis r eception le slot est un GTS, il sera utilis e pour envoyer des trames de donn ees, qui devront etre acquitt ees. Si le slot est un GBS, il nest pas n ecessaire de pr evoir ce temps additionnel puisque les beacons, comme toutes trames dius ees, ne sont pas acquitt es.
12 Si 11 cest-` a-dire
137
Fig. 4.19 Evaluation du d ebit utile maximal pour un slot d eterministe, en fonction du niveau de BO et du niveau de r eservation n
Cette etude par extrapolation permet egalement de comparer la m ethode dacc` es au m edium d eterministe sur le plan du d ebit, avec le CSMA/CA utilis e dans la CAP (cf. l etude de performances r ealis ee avec NS2 sur le d ebit utile maximal en fonction de la charge globale du r eseau, partie 3.2.3). A titre de comparaison, si nous aectons un nombre croissant de GTS (sans d epasser la limite aMinCAPlength, cf. chapitre 2, paragraphe 2.3.1.2), nous pouvons obtenir des r esultats qui seront comparables. La gure 4.20 illustre ces r esultats, et peut- etre compar ee aux performances obtenues avec CSMA/CA (gure 4.8, page 126) avec BO = 0. Comme nous pouvons le voir sur le graphe de la gure 4.20, si la charge globale du r eseau augmente, les performances du r eseau ne s ecroulent pas, comme cest in evitablement le cas pour le CSMA/CA. Lacc` es au m edium d eterministe permet bel et bien de garantir une certaine bande passante qui ne d epend alors que du nombre de GTS allou es, de leur fr equence nGT S et de la p eriodicit e des beacons BO. Nous pouvons egalement noter que les performances evoqu ees ici ne tiennent pas compte de la possibilit e dattribuer un GTS simultan ement ` a deux noeuds di erents (concept de SGTS, qui sera lobjet du paragraphe suivant) ; avec cette fonctionnalit e, les performances devraient etre encore meilleures.
138
Fig. 4.20 Evaluation du d ebit maximum oert en fonction de la charge globale du r eseau .
4.3.2.3
Validation du concept de SGTS
Dans le chapitre 3, nous avions evoqu e la possibilit e daecter un m eme slot temporel ` a deux nuds di erents, ceci dans le but de palier l eventuelle raret e des slots, tout en conservant laspect d eterministe de la m ethode dacc` es. Nous avions d esign e ce slot partag e SGTS , pour Simultaneous GTS. La mise en uvre de cette fonctionnalit e repose sur lhypoth` ese que deux emetteurs peuvent acc eder au m edium en m eme temps si et seulement si aucun des r ecepteurs nest d erang e par l emetteur perturbateur . Dans la pratique, nous avons limit e le probl` eme ` a deux couples de nuds emetteurs/r ecepteurs13 . Il reste ` a prouver que cette fonctionnalit e peut etre r eellement mise en uvre et ` a trouver les conditions de faisabilit e. Pour r ealiser cette etude, nous avons repris la topologie de la gure 4.17, compos ee de cinq nuds, tous ` a port ee les uns des autres : un un un un un supercoordinateur (SC), premier coordinateur (C1), second coordinateur (C2), premier nud (N1) li e` a C1, second nud (N2) li e` a C2.
An de d eterminer les conditions limites de lutilisation simultan ee du m edium, nous avons impl ement e le protocole de mesure suivant, dont la succession des messages est illustr ee gure 4.21 : 1. chaque nouvelle supertrame d ebute normalement par un superbeacon emis par SC sur le slot 0. Les coordinateurs C1 et C2 se synchronisent, 2. C1 emet son beacon sur le slot 1. Le nud N1 se synchronise, 3. C2 emet son beacon sur le slot 2. Le nud N2 se synchronise,
13 qui sont forc ement dans deux etoiles di erentes puisquau sein dune etoile, toutes les communications passent par le coordinateur. . .
139
4. N1 emet une trame de donn ees quelconques destin ees ` a C1 dans le slot 3. C1 r eceptionne la trame et prend note de la puissance avec laquelle il a re cu le signal venant de son nud. Si C2 re coit le signal emis par N1, il note egalement la puissance du signal re cue, 5. N2 emet une trame de donn ees quelconques destin ees ` a C2 dans le slot 4. Comme C1 dans le slot pr ec edant, C2 r eceptionne la trame et prend note de la puissance re cue. Si C1 re coit le signal emis par N2, il note aussi la puissance re cue, 6. N1 et N2 emettent en m eme temps, dans le slot 5, une trame destin ee ` a leurs coordinateurs respectifs. Les coordinateurs envoient alors un accus e de r eception sur leur port s erie ainsi que la di erence des puissances re cues. Un accus e positif signie que la trame attendue a et e re cue ; un accus e n egatif signie la r eception dun signal incoh erent ou de la trame emise par lautre nud. Sur un PC, le r esultat de chaque mesure est enregistr e. 7. pour nir, N1 et N2 utilisent le temps restant avant la prochaine supertrame pour faire varier leur puissance d emission permettant d etendre la plage des mesures.
Fig. 4.21 Succession des messages echang es sur le m edium dans le protocole de test pour la faisabilit e des SGTS Cette s erie de mesures a egalement et e r ealis ee dans la chambre an echo que. Pr` es de 30000 emissions simultan ees ont et e r ealis ees. Les r esultats sont visibles sur la gure 4.22. Sur ce graphe, laxe des abscisses repr esente la di erence du signal re cu une puissance positive signie que le coordinateur a re cu le signal emis par N1 avec plus de force que celui re cu de N2 tandis que laxe des ordonn ees repr esente le taux des trames re cues correctement. Deux courbes sont repr esent ees : une premi` ere pour le coordinateur C1 cherchant ` a recevoir le message de N1 et une seconde pour le coordinateur C2 cherchant a recevoir le message de N2. ` Les r esultats de cette s erie de mesures en labsence de bruit prouvent que le principe de SGTS est tout ` a fait envisageable dans les conditions qui ont et e celles de la mesure : dans la situation des tests, une zone denviron 10 dB seulement doit etre evit ee ; en dehors de cette zone, on peut consid erer que deux acc` es simultan es sur le m edium ne perturbent pas la bonne r eception des deux r ecepteurs. Ces r esultats devront certes etre confront es ` a une situation r eelle (hors de la chambre an echo que) dans laquelle le bruit electromagn etique peut etre important : la marge de 10 dB devra alors etre augment ee, si possible de fa con adaptative en fonction du rapport signal sur bruit.
140
Fig. 4.22 Taux de trames r eceptionn ees correctement en fonction du rapport de puissances re cues
Cependant, il est int eressant de constater que les deux courbes de la gure 4.22 sont l eg` erement d ecal ees vers la gauche par rapport ` a ce qui etait naturellement attendu ; en eet, les deux courbes se croisent ` a une valeur de -3 dB, ce qui est surprenant. Deux hypoth` eses ont et e avanc ees : soit la mesure manque de pr ecision (impr ecision de loutil de mesure, mauvaise manipulation ou mauvaises conditions), soit la mesure est tr` es pr ecise et rel` eve un eet int eressant qui permet ` a lun des nuds d etre favoris e par rapport ` a lautre : il est re cu correctement par le r ecepteur, m eme si lautre emetteur est re cu avec un signal plus puissant (jusqu` a 3 dB plus fort). Nous avons refait de nombreuses mesures, mais le ph enom` ene constat e etait toujours pr esent. Nous avons donc suppos e que nous mesurions un ph enom` ene r eel et non un artefact. Nous avons alors repris l etude de la synchronisation pr esent ee plus haut dans la section 4.3.1.4 et constat e que le nud favoris e dans le cadre de cette etude (N1) est celui qui dispose, en moyenne, dune l eg` ere avance dans le dispositif de synchronisation. A ce stade, l etude nous permettrait davancer lhypoth` ese suivante : si lon souhaite emettre deux trames en m eme temps (contention), et que lune est en r ealit e l eg` erement en avance par rapport ` a lautre, la premi` ere transmise a le plus de chance d etre re cue correctement, m eme si la seconde est re cue avec plus de puissance (jusqu` a 3 dB plus fort). Il semblerait que nous ayons mis en evidence un eet de capture : les emetteurs n emettant pas strictement sur la m eme fr equence, en cas d emission concurrentes, le r ecepteur reste synchronis e sur l emetteur qui a commenc e` a emettre en premier. An de conrmer cette hypoth` ese, nous avons repris le r eseau prototype en modiant le protocole de mani` ere ` a ce que les deux nuds en concurrence soient synchronis es sur le m eme coordinateur. Les r esultats de cette s erie de mesures sont pr esent es sur le graphe de la gure 4.23 et conrment que, dans le cas dune synchronisation ne favorisant aucun des deux nuds, la simultan eit e de lacc` es au m edium ne favorise aucun des nuds. Adrien van den Bossche 141
Fig. 4.23 Taux de trames r eceptionn ees correctement en fonction du rapport de puissances re cues
4.3.3
Conclusion sur les mesures r ealis ees sur le prototype
Les di erentes etudes r ealis ees sur le r eseau prototype utilisant la m ethode dacc` es d eterministe donnent des r esultats encourageants : Les concepts de synchronisation ` a plusieurs niveaux et SGTS, dicilement validables par simulation, et encore moins par R eseaux de Petri, ont et e valid es avec succ` es gr ace au prototypage. Nous avons pu constater ` a cette occasion que les SGTS sont tout ` a fait impl ementables en tenant compte dune marge relativement faible. Nous notons egalement que la synchronisation par cascade de beacons augmente consid erablement la gigue de synchronisation. Une structure etendue ` a n niveaux, qui sera evoqu ee en perspectives de cette th` ese, risque donc dintroduire des dicult es a ce niveau. ` La s erie de mesures sur le temps de traitement dun paquet nous a permis, par extrapolation, d etablir les performances de notre m ethode dacc` es en terme de d ebit, et ce, en nous basant sur des mesures issues du prototypage. Gr ace ` a cette evaluation, il est possible d etablir des abaques liant les param` etres temporels BO et nGT S avec le d ebit minimum garanti par la couche MAC. Enn, les autres mesures ont permis dapprocher nement les performances li ees a ` la partie radio du composant Freescale utilis e pour le r eseau prototype (caract erisation de la sensibilit e du r ecepteur, taux de trame perdues typique, etc.).
4.4
Applications de d emonstration
Comme cela a et e evoqu e plus haut, laspect prototypage de la th` ese a et e d evelopp e dans le but de valider certaines propri et es de la proposition, mais aussi par int er et p edagogique et d emonstratif. Le prototypage et la manipulation du mat eriel IEEE 802.15.4 / ZigBee a donc donn e lieu ` a de nombreux projets parall` element ` a ces travaux de recherche. Ces projets nont, bien s ur, pas un int er et direct ` a une quelconque contribution de recherche mais ils sinscrivent dans un cursus de formation (stages, projets tuteur es) et il nous para t important de les evoquer ici. 142 Groupe SCSF LATTIS EA4155
4.4.1
Capteur de ligne ZigBee
Le premier projet a et e men e au laboratoire ICARE au cours de l et e 2005 par Mathieu Gerbe, un etudiant de seconde ann ee DUT GTR (d esormais DUT R eseaux et T el ecoms ) de lIUT de Clermont Ferrand. Le but du stage [GERB 05] etait de mettre en uvre un robot Evolution Robotics ER1 [EVOL] et de l equiper de deux noeuds IEEE 802.15.4, constituant ainsi une plateforme op erationnelle robotique de test et de d eveloppement. Ce projet est egalement li e` a une collaboration de recherche entre le LIMOS (Laboratoire dInformatique, de Mod elisation et dOptimisation des Syst` emes ) et ICARE sur le projet de recherche Wi-Bot [VDB3 05]. Dans ce projet, lunit e de commande du robot (PC portable) etait dot ee dun nud faisant oce de coordinateur. Nous avions egalement d evelopp e un capteur optique dont le but etait lidentication dune ligne au sol ; ce capteur etait lui aussi pourvu dun nud ZigBee pour communiquer ses informations au coordinateur. La topologie ainsi cr e ee etait la topologie interne au robot evoqu ee dans le d ebut du chapitre 3. La gure 4.24 repr esente le robot et son capteur.
Fig. 4.24 Le robot ER1, le capteur infrarouge et le coordinateur (module ZigBee ICARE)
Fig. 4.25 R ealisations de modules ZigBee ICARE Ce premier projet a egalement permis de r ealiser plusieurs cartes ZigBee bas ees sur des composants Freescale. Dans le but de pouvoir r eutiliser facilement les modules ZigBee pour une autre application, Adrien van den Bossche 143
une solution carte m` ere / carte lle a et e d evelopp ee. Deux versions de carte m` ere ont et e r ealis ees : une pour les capteurs (nud terminal) et une avec un port RS232 (coordinateur). De m eme, deux versions de carte lle ont et e r ealis ees : une premi` ere avec antenne imprim ee et une seconde avec un connecteur (type SMA) pour lutilisation dune antenne externe. Ces r ealisations sont repr esent ees sur la gure 4.25 et ont egalement servi pour la phase de prototypage de la m ethode dacc` es d eterministe de notre th` ese. Une documentation technique [VDB2 05] a et e r edig ee ` a la suite de la r ealisation de ces cartes.
4.4.2
Passerelle IP/ZigBee
Un projet de passerelle IP/ZigBee a et e con e durant lann ee 2006/2007 ` a des etudiants de seconde ann ee DUT R&T de lIUT de Blagnac dans le cadre des projets tuteur es. Le but etait le d eveloppement dun dispositif autonome et ind ependant de tout ordinateur pour permettre l echange de donn ees entre les deux r eseaux, et ce, ` a un niveau applicatif. La passerelle IP/ZigBee sera ensuite int egr ee dans le r eseau de robots pour permettre la t el ecommande et le monitoring des appareils mobiles. La partie mat erielle, constitu ee dune carte WiFi Compact Flash (et de son support impl ementant une pile IP et un port RS232) et dun module ZigBee ICARE, a et e r ealis ee par les etudiants [BETH 07]. La gure 4.26 repr esente la carte r ealis ee. La partie logicielle fera lobjet dun projet tuteur e lann ee prochaine.
Fig. 4.26 Passerelle IP/ZigBee
4.4.3
Flotte de robots ZigBee
Le dernier projet autour de 802.15.4/ZigBee a et e propos e au printemps 2007 ` a des el` eves-ing enieurs RT de lINSA de Toulouse suite au rapprochement du LESIA et dICARE dans le LATTIS3 . Le th` eme etait directement dans la continuit e de celui du capteur de ligne ZigBee : il sagissait d equiper une otte de plusieurs robots Evolution Robotics ER1 de nuds ZigBee (un coordinateur et un ` a deux capteurs par robot) et, par l` a m eme, de constituer une plateforme op erationnelle pour le d eploiement futur dun r eseau ` a Qualit e de Service (gr ace ` a la m ethode dacc` es d eterministe) appliqu e` a une otte de robots mobiles. Les deux robots evoluaient sur un m eme parcours en suivant une ligne au sol comme illustr e gure 4.27. Lun des robots etait equip e dun capteur dobstacle (sonar ultrason) qui lui permettait de sarr eter si un obstacle etait d etect e, et de demander ` a lautre robot, via ZigBee, de sarr eter egalement. Dun point de vue r eseau, ces capteurs constituaient des sources dinformations critiques sur le plan temporel, r epondant ainsi ` a nos exigences quant ` a la mise en uvre dune plateforme applicative de test pour notre m ethode dacc` es d eterministe. Ce projet inclut un niveau r eseau (au sens OSI) plus abouti dans la mesure o` u les communications entre les robots n ecessitent la mise en uvre dun protocole de routage. A ce titre, la couche r eseau de ZigBee incluant AODV, a et e impl ement ee et test ee par les etudiants. Le projet est en cours de nalisation. 144 Groupe SCSF LATTIS EA4155
Fig. 4.27 Les deux robots suiveurs de ligne et le r eseau form e
4.4.4
Bilan sur les applications de d emonstration
Les projets r ealis es autour de 802.15.4 et ZigBee, outre laspect p edagogique, nous ont permis de r ealiser des plateformes mat erielles que nous avons pu utiliser, par la suite, comme nuds du r eseau prototyp e. De plus, les sujets propos es ont permis louverture vers des domaines dapplications autres que lunique champ de la robotique pr esent e en d ebut de chapitre 3. De nouvelles applications telles que la surveillance denvironnements ` a risque (bateaux, centrales), n ecessitant un syst` eme de communication industriel sans l ` a fortes contraintes temporelles et ` a QoS, sont d` es lors envisageables et seront mises en uvre dans un projet de bien plus grande envergure avec plusieurs partenaires universitaires et industriels sur le plan national.
145
146
[ATAM 94] Y. Atamna R eseaux de Petri temporis es stochastiques et bien form es : d enition, analyse et application aux syst` emes distribu es temps r eel Doctorat de lUniversit e Paul Sabatier, Toulouse, France (1994) [BERT 04] B. Berthomieu, P.O. Ribet et F. Vernadat The tool TINA - Construction of Abstract State Spaces for Petri Nets and Time Petri Nets International Journal of Production Research, Vol. 42, no 14, (Juillet 2004) [BETH 07] J. Bethmont et P. Pommier R ealisation dune passerelle IP/ZigBee Rapport de projet tuteur e, equipe ICARE, Blagnac (Mars 2007) [BRAM 83] G.W. Brams R eseaux de Petri : th eorie et pratique Masson, Paris (1983) [EVOL] Le site web de Evolution Robotics http ://www.evolution.com/er1/what overview.masn [FLOR 85] G. Florin R eseaux de Petri stochastiques : th eorie et m ethode de calcul Doctorat de lUniversit e Pierre et Marie Curie Paris VI, Paris, France (1985) [GANG 04] Gang Lu, Bhaskar Krishnamachari et Cauligi S. Raghavendra Performance evaluation of the IEEE 802.15.4 MAC for Low-Rate Low-Power Wireless Networks Workshop on Energy-Ecient Wireless Communications and Networks (EWCN 04), IEEE International Performance Computing and Communications Conference (IPCCC), Phoenix, Arizona, USA (Avril 2004) [GERB 05] M. Gerbe R ealisation dun capteur sans l communicant par ZigBee Rapport de stage, equipe ICARE, Blagnac (Juin 2005) [HPSI] Le site web du logiciel http ://www.winpesim.de danimation de RdP HPSim, de H. Anschuetz
[IEE3 03] IEEE Computer Society IEEE 802.15.4/D18, Draft Standard : Low Rate Wireless Personal Area Networks (F evrier 2003) [KHOU 06] T. Khoutaif et G. Juanole Formal modelling and evaluation of the data transfer phase of the ACL links on the WPAN Bluetooth 11th International Conference on Emerging Technologies and Factory Automation (ETFA2006), Prague, R epublique Tch` eque (Septembre 2006) [LAAS] Le site web du LAAS http ://www.laas.fr [MARS 85] M.A. Marsan, G. Balbo, A. Bobbio, G. Chiola, G. Conte et A. Cumani On Petri Nets with Stochastic Timing International Workshop on Timed Petri Nets (INTPN85), Turin, Italie (Juillet 1985) [MAUR 05] R. Maurice Contribution ` a la m ethodologie de conception syst` eme : application ` a la r ealisation dun microsyst` eme multicapteurs communicant pour le g enie civil Doctorat de lInstitut National Polytechnique de Toulouse, Rapport LAAS no 05646, Toulouse, France (2005) [MERC 06] J.J. Mercier Computers II : S equence apr` es s equence, Introduction aux Grafcets chapitre 3.2, Collection Technosup, Ellipses (2006) [MERL 76] P.M. Merlin Recoverability of communication protocols, implication of a theorical study IEEE Transaction on Communications, 24(9) :1036-1043 (1976) [NS] Le site web de Network Simulator (NS) http ://www.isi.edu/nsnam/ns [OLC] Le site web du groupe OLC http ://www2.laas.fr/laas/1-4286-Groupe-OLC.php
[OPNE] Le site web dOPNET http ://www.opnet.com [PETR 06] M. Petrova, J. Riihijarvi, P. Mahonen et S. Labella Performance Study of IEEE 802.15.4 Using Measurements and Simulations IEEE Wireless Communications and Networking Conference (WCNC06), vol. 1, pp : 487- 492, Las Vegas, Nevada, USA (Avril 2006) [QUAL 02] Scalable Network Technologies Speed & Scalability : Requirements for Industrial Strength Network Simulators Qualnet White Paper (2002) [QUAL] Le site web de Qualnet http ://www.scalable-networks.com [SAMS] Samsung/CUNY NS2 simulator for 802.15.4 http ://www-ee.ccny.cuny.edu/zheng/pub [TINA] Le site web de TINA http ://www.laas.fr/tina [VDB2 05] A. van den Bossche et M. Gerbe Les modules IEEE 802.15.4 ICARE Documentation technique illustr ee, document interne ICARE (Juin 2005) [VDB3 05] A. van den Bossche IEEE 802.15.4 / ZigBee : un r eseau sans l ` a faible consommation energ etique 2iemes rencontres des Sciences et Technologies de lInformation (ASTI2005), Aubi` ere, France (Octobre 2005) [VINT 95] The NS Manual (formerly NS Notes and Documentation) par les contributeurs du projet VINT UC Berkeley, LBL, USC/ISI, and Xerox PARC (1995) [ZHEN 04] J. Zheng et M. J. Lee Will IEEE 802.15.4 make ubiquitous networking a reality ? : A discussion on a potential low power, low bit rate standard IEEE Communications Magazine, vol. 27, no. 6, pp. 23-29 (2004) [ZHEN 06] J. Zheng et M. J. Lee A comprehensive performance study of IEEE 802.15.4 Sensor Network Operations, IEEE Press, Wiley Interscience, chapitre 4, pp. 218-237 (2006).
148
Conclusion et perspectives
Conclusion g en erale
Aujourdhui, la grande majorit e des technologies de WLAN/WPAN pr esentes sur le march e ne permet pas de mettre en uvre des r eseaux adapt es aux transports dinformations ` a fortes contraintes temporelles. La plupart des normes de r eseaux sans l traitent la probl ematique de la m ethode dacc` es au m edium en se basant sur des d elais al eatoires quil est impossible de borner. De plus, quelque soit la technologie de transmission mise en uvre (et m eme dans des conditions quasi id eales), la couche physique est imparfaite car elle introduit des erreurs qui doivent etre corrig ees par les couches sup erieures. Dans le cadre dun r eseau transportant des informations contraintes temporellement, ces erreurs peuvent engendrer des d elais de transmission importants et retarder lacheminement dun message. Il est donc n ecessaire de pouvoir les borner et travailler avec des m ethodes et des protocoles qui nintroduisent pas, en plus, des ph enom` enes al eatoires. An de limiter fortement ces d elais, il nous a paru n ecessaire de consid erer que lincertitude temporelle cumul ee introduite par chaque couche doit etre n egligeable devant lincertitude introduite par la couche physique qui, elle, restera pour le moment, impr evisible et non able. Dans le premier chapitre sur l etat de lart des technologies de r eseaux sans l et de Qualit e de Service, nous avons pr esent e plusieurs normes et protocoles existants. Nous avons conclu sur la r eelle n ecessit e dintroduire des fonctionnalit es de QoS au niveau le plus bas de la pile protocolaire pour pouvoir assurer la Qualit e de Service globale sur tout le r eseau. Sans une gestion ne de la QoS ` a chaque niveau de la pile OSI, laccumulation des incertitudes aboutit ` a un r eseau globalement non able sur le plan temporel et dont le comportement est dicilement pr evisible. En particulier, lun des principes fondamentaux de la Qualit e de Service est le contr ole de ladmission ; or ce dispositif n ecessite une connaissance tr` es juste de la capacit e du r eseau ` a tout instant et il est donc important que les couches les plus basses informent les processus g erant la QoS de cette capacit e, si possible en temps r eel. De plus, consid erant que le m edium imparfait constitue l el ement le moins able de lensemble des constituants du r eseau, il est alors tr` es regrettable de constater quun message re cu correctement au niveau de la couche physique soit d etruit par une couche sup erieure par exemple parce que le r eseau est satur e. Dans une pile protocolaire, au dessus de la couche physique, le premier el ement susceptible dintroduire des incertitudes est lalgorithme de la m ethode dacc` es au m edium. Dans le but de r eduire les incertitudes provoqu ees par les couches 2 et sup erieures, nous avons et e amen e ` a nous rapprocher des m ethodes dacc` es au m edium pr esentant un caract` ere non al eatoire. Plusieurs technologies pr esentent de telles possibilit es : HiperLAN/2, 802.15.1, 802.11 PCF, 802.11e, 802.15.4 GTS, mais tous ces algorithmes reposent tout de m eme sur des demandes elles-m emes eectu ees en mode al eatoire, ce qui ne permet pas de garantir ` a 100% les temps de r eponse, par exemple si le r eseau est satur e. Notre proposition a donc tent e de proposer une solution ` a ce probl` eme. Dans le second chapitre, nous avons pr esent e les normes et sp ecications des technologies de r eseaux personnels sans l IEEE 802.15.4 et ZigBee sur lesquelles se sont bas es nos travaux. Outre laspect novateur de cette technologie la sortie des premiers modules a co ncid e avec le d ebut de nos travaux les possibilit e oertes de reprogrammation totale de la couche MAC nous ont permis dentrevoir des possibilit es de prototypage et, donc, des r esultats de performances r eels. De plus, nos travaux etant
Conclusion
destin es ` a des applications de r eseaux sans l industriels autonomes, laspect faible consommation de cette technologie nous a dautant plus encourag e. De plus, l etude de cette technologie nous a permis didentier un certain nombre de faiblesses pour des applications de transport dinformations ` a fortes contraintes temporelles. En eet, comme dautres technologies pr esent ees dans le premier chapitre, IEEE 802.15.4 propose une m ethode dacc` es avec contention bas ee sur CSMA/CA et une m ethode dacc` es sans contention bas ee sur le principe de slots r eserv es (GTS). Si les GTS permettent ` a quelques nuds privil egi es qui en font la demande d etre temporairement epargn es par le ph enom` ene des collisions, le protocole de demande de GTS passe par le mode avec contention, ce qui ne permet pas dassurer avec certitude que lobtention dun ou plusieurs GTS peut se faire dans une p eriode temporelle born ee. Par extension, nous avons relev e quaucun m ecanisme de gestion du r eseau (association, d esassociation, demande indirecte de donn ees, demande de renouvellement de GTS, etc.) ne peut se faire de fa con d eterministe. Une etude ne de la gestion de lacc` es au m edium dans le cadre de IEEE 802.15.4 nous a permis de proposer six grandes am eliorations dans le protocole, pr esent ees dans le chapitre 3. Ces am eliorations sont les suivantes : 1. possibilit e de pratiquer des entr ees d eterministes dans le r eseau, 2. cr eation dun protocole entre coordinateurs pour eviter les collisions de GTS, 3. suppression d elimitation entre CAP/CFP, 4. plusieurs niveaux de GTS cr e es, pour plusieurs classes de services, 5. continuit e du service d eterministe, 6. possibilit e dallouer deux GTS sur le m eme slot sans risque de perturbation (SGTS). Ces propositions ont fait lobjet de plusieurs analyses dont les r esultats ont et e expos es et comment es dans le quatri` eme chapitre de cette th` ese. Dans le but de pouvoir valider de fa con ad equate les di erents aspects de nos propositions, nous avons utilis e trois m ethodes de validations compl ementaires : les R eseaux de P etri pour la validation par des m ethodes formelles de laspect s equencement de la m ethode dacc` es, la simulation pour lanalyse des performances temporelles dans la phase dassociation d eterministe au r eseau, le prototypage pour l evaluation du d ebit garanti par la m ethode dacc` es, la qualit e de la synchronisation sur cascade de beacons ainsi que la validation du principe de SGTS. Chaque contribution propos ee a et e trait ee par lune de ces trois m ethodes : ces trois etudes compl ementaires nous ont permis dapprocher la phase de validation par trois directions di erentes, enrichissant ainsi nos r esultats et nos conclusions. Ainsi, nous avons mod elis e lalgorithme propos e pour la m ethode dacc` es par les R eseaux de P etri et test e ce mod` ele avec le logiciel TINA qui propose des fonctionnalit es de validation formelle. Nous avons pu constater que notre mod` ele ne sourait daucun d efaut de s equencement ; nous lavons alors impl ement e dans un simulateur logiciel en nous focalisant sp eciquement sur la phase dassociation au r eseau, le simulateur ajoutant laspect temporel pour lobtention des param` etres de performances. Nous avons constat e que la m ethode dacc` es pr esente bien le caract` ere d eterministe car toute demande suscit ee par un nud du r eseau obtient une r eponse en un temps born e (minimum et maximum). Parall` element aux travaux de simulation, nous avons men e une etude bas ee sur un r eseau prototype impl ementant la m ethode dacc` es d eterministe. Nous avons cherch e, dans un premier temps, ` a evaluer les caract eristiques intrins` eques du mat eriel et du logiciel nous servant de base de travail. A ce titre, la sensibilit e du r ecepteur, le temps n ecessaire au traitement dun paquet sans m ethode dacc` es et la qualit e de la synchronisation par beacons ont et e evalu es de mani` ere ` a conna tre pr ecis ement les performances basiques du mat eriel utilis e pour la r ealisation de notre r eseau prototype. Dans un second temps, les fonctionnalit es SGTS et synchronisation par cascades de beacons ont et e valid es. Une evaluation 150 Groupe SCSF LATTIS EA4155
Conclusion
du d ebit garanti par la m ethode dacc` es a aussi et e r ealis ee. La partie prototypage a elle aussi donn e des r esultats encourageants : la synchronisation sur plusieurs niveaux de beacons permet de garder une synchronisation tr` es correcte et la possibilit e de pratiquer des acc` es simultan es au m edium sans risque de collisions a et e prouv ee. Leet de capture a pu etre mis en evidence et les conditions n ecessaires ` a lattribution dun SGTS ont et e d etermin ees. Le r eseau prototype est ` a ce jour op erationnel et la m ethode dacc` es d eterministe ore les propri et es attendues et des performances int eressantes. Le r eseau est capable de fournir des garanties sur le d ebit et la latence au niveau de la m ethode dacc` es. Concr` etement, en xant les param` etres temporels intrins` eques du r eseau, lutilisateur peut rapidement, a ` partir des abaques obtenus et pr esent es dans le chapitre 4, d eterminer le d ebit minimum et la latence maximum quil est en mesure dattendre de la m ethode dacc` es.
Perspectives
A partir des r esultats obtenus dans ce travail, nous d egageons des perspectives de recherches nombreuses et vari ees. Certaines doivent etre consid er ees ` a court terme et dautres permettront de sengager sur des travaux de recherche plus ambitieux ` a long terme. Comme nous lavons souvent evoqu e pr ec edemment, un point important serait de pouvoir assurer la transversalit e de la gestion de la Qualit e de Service au travers de toute la pile protocolaire, et plus particuli` erement avec la couche directement sup erieure, la couche r eseau. Un jeu de primitives devra alors etre cr e e et pris en charge par la ou les couches sup erieures, y compris par un protocole de routage incluant une gestion de la QoS. Les param` etres du r eseau pourraient alors etre x es automatiquement par ce processus en fonction des besoins de lapplicatif vis-` a-vis des nuds du r eseau. Enn, la couche MAC, en tant que premier t emoin de lactivit e du m edium, pourrait remonter des informations sur son utilisation et sur les ressources libres. Ces informations pourraient etre collect ees aussi bien sur le supercoordinateur que sur les coordinateurs ou les nuds terminaux du r eseau, permettant ainsi au protocole de routage dajuster nement ses directives. Au niveau de la topologie et du protocole de gestion de lacc` es au m edium, il serait int eressant de pouvoir etendre notre r eseau sur une zone g eographique plus importante ; la m ethode dacc` es propos ee repose sur lhypoth` ese que tous les coordinateurs sont ` a port ee radio du supercoordinateur ; dans cette hypoth` ese, la synchronisation dun coordinateur est directe et le r eseau ne poss` ede que deux niveaux de liens (supercoordinateur-coordinateur et coordinateur-nud). Il serait donc int eressant de pouvoir mettre en uvre des topologies moins restrictives, comme par exemple rattacher un coordinateur ` a un autre coordinateur si le premier nest pas ` a port ee du supercoordinateur. Une structure g en eralisable a n niveaux serait alors envisageable, plus exible et plus apte ` ` a r esoudre des probl` emes r eels. Nous pourrions facilement permettre cette extension en utilisant la n egociation de SGTS, support simple et op erationnel pour permettre la n egociation de slots pour des nuds tr` es eloign es. Reste cependant ` a r egler le probl` eme de la synchronisation qui, avec le protocole tr` es simple utilis e actuellement, se d egrade fortement ` a chaque saut (dapr` es les r esultats issus du prototypage). La conception dun syst` eme de synchronisation plus pr ecis, par exemple par adaptation dun protocole existant comme NTP (Network Time Protocol ) pourrait permettre de r eduire consid erablement la gigue de synchronisation sur le r eseau global. Concernant la phase de cr eation du r eseau, nous avons vu que le m ecanisme dassociation d eterministe n ecessite que le supercoordinateur soit le premier nud eveill e. Dans l etat actuel de la proposition, un coordinateur qui se r eveille ecoute le m edium ind eniment jusqu` a recevoir un superbeacon, et donc, doit attendre le r eveil du supercoordinateur pour commencer ` a diuser ses propres beacons et contacter ses propres nuds terminaux. Une perspective int eressante serait de pr evoir un m ecanisme permettant l election du supercoordinateur, si toutefois lapplication le permet. Bien entendu, cette election ne devrait en aucun cas aaiblir le c ot e d eterministe de la phase de cr eation du r eseau. Concernant la abilisation de la couche physique, une perspective int eressante serait la mise en uvre Adrien van den Bossche 151
Conclusion
de codes correcteurs en dessous de la couche MAC (codes de Hamming, codes convolutionnels, turbocodes, Reed Salomon, FEC, etc.). Cette modication est tout ` a fait envisageable sur nos nuds prototypes car le calcul du CRC peut etre d esactiv e sur les modules 802.15.4 que nous utilisons. Ainsi, il est possible dacc eder aux donn ees re cues sans tenir compte du CRC, ce qui rend possible cette perspective sur le plan pratique. Au niveau des travaux de simulation, il serait int eressant de pouvoir impl ementer la m ethode dacc` es dans un simulateur proposant des fonctionnalit es de mod elisation de la couche physique. Les r esultats de cette op eration seraient tr` es int eressants pour entrevoir la capacit e du r eseau ` a passer ` a l echelle op eration a priori tr` es d elicate ` a r ealiser par prototypage. De plus, en reprenant la perspective de vaste etendue du r eseau, l etude par simulation constituerait, l` a aussi, un bon moyen de xer les port ees de chaque nud pour un r eseau etendu sur une grande zone g eographique. Dans un premier temps, un mod` ele bas e sur les extensions sans l du logiciel NS2 serait envisageable, incluant un protocole de gestion ne de la synchronisation. Concernant laspect prototypage, des mesures sur le d elai engendr e par lassociation d eterministe des nuds au r eseau pourraient etre r ealis ees pour confronter les r esultats obtenus par simulation. Des mesures concernant le d elai dacheminement dun message de donn ees en fonction du nombre de sauts devront egalement faire lobjet dune campagne de mesures, les performances temporelles nayant et e etablies que par simulation et pour la phase particuli` ere et originale de lassociation d eterministe au r eseau. Dune mani` ere g en erale, il serait bon de pouvoir comparer, quand cela est possible, les di erentes m ethodes de validation mises en uvre durant la th` ese (R eseaux de P etri, simulation et prototypage). Par exemple, le mod` ele R eseaux de P etri d evelopp e pourrait etre am elior e et se voir ajouter une fonctionnalit e temporelle par utilisation des R eseaux de P etri Temporis es (Timed Petri Nets ) ; les r esultats obtenus par ce nouveau mod` ele plus complet pourraient alors etre compar es directement aux r esultats issus des travaux de simulation. Laspect energ etique pourrait lui aussi faire lobjet dune analyse int eressante. Dans le cadre de notre r eseau prototype, nous navons pas pu mettre en uvre la fonctionnalit e de mise en veille rapide des nuds terminaux. Cet aspect pourrait donc aussi etre etudi e, dans un premier temps par simulation gr ace ` a une modication du simulateur existant pour la prise en charge de laspect energ etique, comme cela a et e fait pour laspect temporel. Dans un deuxi` eme temps, cette etude pourrait etre poursuivie par limpl ementation de la fonction de mise en veille rapide en mode suivi de beacon sur le r eseau prototype. Une campagne de mesures par prototypage r eel pourrait alors etre r ealis ee et les r esultats pourraient etre compar es ` a ceux obtenus par simulation. Enn, une perspective int eressante serait la mise en uvre de la m ethode dacc` es au m edium d eterministe sur la plateforme de robots pr esent ee dans le chapitre 3. Cette plateforme est actuellement en cours d elaboration et pourrait constituer une application de test concr` ete et r eelle. De toutes les perspectives evoqu ees ci-dessus, plusieurs font d ej` a lobjet de travaux de th` ese au laboratoire. Dautres sont maintenant li ees ` a un projet de recherche national auquel nous participons. Pour les perspectives restantes, nous esp erons que cette th` ese orira une source dinspiration ` a de futurs travaux doctoraux auxquels nous aimerions vivement contribuer.
152
Bibliographie g en erale
[APOS 96] C. Apostolas, R. Tafazolli et B.G. Evans Comparison between elimination yield non pre-emptive prioritymultiple access (EY-NPMA) and dynamic TDMA (D-TDMA) 7th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRCapos96) vol 2, issue 15-18 Oct 1996 pp 663-667 (1996) [ARCE] Le site web de lARCEP (Autorit e de R egulation des Communications Electroniques et des Postes) http ://www.arcep.fr [ATAM 94] Y. Atamna R eseaux de Petri temporis es stochastiques et bien form es : d enition, analyse et application aux syst` emes distribu es temps r eel Doctorat de lUniversit e Paul Sabatier, Toulouse, France (1994) [BADI 04] H. Badis et K. Al Agha QOLSR Multi-path Routing for Mobile Ad Hoc Networks Based on Multiple Metrics 59th IEEE Vehicular Technology Conference (IEEE VTC04-Spring), Milan, Italie (Mai 2004) [BERT 04] B. Berthomieu, P.O. Ribet et F. Vernadat The tool TINA - Construction of Abstract State Spaces for Petri Nets and Time Petri Nets International Journal of Production Research, Vol. 42, no 14, (Juillet 2004) [BETH 07] J. Bethmont et P. Pommier R ealisation dune passerelle IP/ZigBee Rapport de projet tuteur e, equipe ICARE, Blagnac (Mars 2007) [BOUY 97] E. Bouyer et E. Horlait Bandwidth Management and Reservation over Shared Media Segundo Semin ario Franco-Brasileiro em Sistemas Inform aticos Distribu dos (SFBSID97), Fortaleza, Brazil (1997) [BOUZ 03] A. Bouzoualegh, T. Val, F. Peyrard et E. Campo Study of the Characteristics Needed for Underwater Acoustic Networks 7th WSEAS International Conference on Circuits, Systems, Communications and Computers (CSCC2003), Corfu, Grece (Juillet 2003) [BRAM 83] G.W. Brams R eseaux de Petri : th eorie et pratique Masson, Paris (1983) [CALL 02] E. Callaway, P. Gorday, L. Hester, J.A. Gutierrez, M. Naeve, B.Heile et V. Bahl Home Networking with IEEE 802.15.4 : a developing standard for low-rate wireless personal area networks IEEE Communications Magazine vol. 40, no. 8, pp 70-77 (Ao ut 2002) [CAPP 02] Communaut e dagglom eration Pau Pyr en ees Pau Broadband Country (large bande pour tous) Dossier de pr esentation (F evrier 2002) [CHIC 05] O. Chicheportiche Airbus passe ` a la VoIP avec France T el ecom http ://www.silicon.fr/fr/silicon/news/2005/07/12/airbus-passe-voip-france-telecom
[CHOI 03] S. Choi, J. del Prado, S. Shankar et S. Mangold IEEE 802.11e Contention-Based Channel Access (EDCF) Performance Evaluation IEEE International Conference on Communications (ICC03) vol.2, pp 1151-1156 (Mai 2003) [CULL 04] D. Culler, D. Estrin et M. Srivastava Overview of Sensor Networks IEEE Computer vol.37, issue 8 (Ao ut 2004) [DESG 03] G. Desgeorges R eseaux haut d ebit et r eseaux sans l Cours ding enieur ESEO, sp ecialit e R&T (2003)
ne rale Bibliographie ge
[ELHO 04] S. El Homsi, E. Campo, T. Val et J.J. Mercier Utilisation de la technologie Bluetooth pour la transmission de donn ees num eriques dans les applications ` a contraintes temporelles vari ees Congr` es des doctorants de lEcole Doctorale de G enie Electrique, Electronique et T el ecommunications (GEET), Supaero, Toulouse (Mars 2004) [ETS1 06] ETSI Project Broadband Radio Access Networks Broadband Radio Access Networks (BRAN) : HiperMAN Physical (PHY) Layer ETSI Technical Specication ETSI TS 102 177 V1.3.1 (F evrier 2006) [ETS2 06] ETSI Project Broadband Radio Access Networks Broadband Radio Access Networks (BRAN) : HiperMAN Data Link Control (DLC) Layer ETSI Technical Specication ETSI TS 102 178 V1.3.2 (Mars 2006) [ETSI 00] ETSI Project Broadband Radio Access Networks Broadband Radio Access Networks (BRAN) : HiperLAN Type 2 System Overview ETSI Technical report ETSI TR 101 683 V1.1.1 (F evrier 2000) [ETSI] Le site web de lETSI (European Telecommunications Standards Institute ) http ://www.etsi.org [EVOL] Le site web de Evolution Robotics http ://www.evolution.com/er1/what overview.masn [FLOR 85] G. Florin R eseaux de Petri stochastiques : th eorie et m ethode de calcul Doctorat de lUniversit e Pierre et Marie Curie Paris VI, Paris, France (1985) [FON] Le mouvement Fon http ://www.fon.com [FRAN 06] J. Francomme, G. Mercier et T. Val A simple method for guaranteed deadline of periodic messages in 802.15.4 cluster cells for automation control applications IEEE International Conference on Emerging Technologies and Factory Automation (ETFA2006), Prague. Czech Republic (Septembre 2006) [FRE1 04] Freescale Semiconductor ZigBee / IEEE 802.15.4 Freescale solution Technology General Information (2004) [FRE2 04] Freescale Semiconductor ZigBee Reference Disign (ZRD01) documentation & applications notes (2004) [FRE3 04] Freescale Semiconductor MC13192 Reference Manual (2004) [FRE4 04] Freescale Semiconductor 802.15.4 MAC/PHY Software Users Guide (2004) [GANG 04] Gang Lu, Bhaskar Krishnamachari et Cauligi S. Raghavendra Performance evaluation of the IEEE 802.15.4 MAC for Low-Rate Low-Power Wireless Networks Workshop on Energy-Ecient Wireless Communications and Networks (EWCN 04), IEEE International Performance Computing and Communications Conference (IPCCC), Phoenix, Arizona, USA (Avril 2004) [GARC 02] J.A. Garc a-Mac as, F. Rousseau, G. Berger-Sabbatel, L. Toumi et A. Duda Di erenciation des services sur les r eseaux sans-l 802.11 9ieme Colloque Francophone sur lIng enierie des Protocoles (CFIP2002), Montr eal, Quebec (Mai 2002) [GERB 05] M. Gerbe R ealisation dun capteur sans l communicant par ZigBee Rapport de stage, equipe ICARE, Blagnac (Juin 2005) [GOLD 01] M. Goldhammer ETSI BRAN HiperMAN Liaison Report 2001-11-08 [GUIL 05] C. Guilleminot, L. Andrieux et J.J. Mercier A contribution to a virtual prototyping for a spread spectrum telecommunication system using VHDL-AMS BMAS05, San Jose, Californie, USA (Septembre 2005) [HOWE 87] D.A. Howe Ku-band Satellite Two-Way Timing Using a Very Small Aperture Terminal (VSAT) 41st Annual Symposium on Frequency Control pp 149-160 (1987) [HOYM 01] C. Hoymann, M. P uttner et I. Forkel The HiperMAN Standard - a Performance Analysis [HPSI] Le site web du logiciel danimation de RdP HPSim, de H. Anschuetz http ://www.winpesim.de [IEE1 02] LAN-MAN Standards Committee of the IEEE Computer Society 802.15.1 IEEE Standard for Information technology, Part 15.1 : Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specications for Wireless Personal Area Networks (WPANS) IEEE Std 802.15.12002 (2002) 154 Groupe SCSF LATTIS EA4155
[IEE1 03] LAN-MAN Standards Committee of the IEEE Computer Society 802.15.3 IEEE Standard for Information technology, specic requirements part 15.3 : Wireless Medium Access Control (MAC) and Physical Layer (PHY) specications for high rate wireless personal area networks (WPANs) IEEE Std 802.15.3-2003 (2003) [IEE1 04] IEEE Computer Society and IEEE Microwave Theory and Techniques Society 802.16 IEEE Standard for Local and metropolitan area networks part 16 : Air Interface for Fixed Broadband Wireless Access Systems IEEE Std 802.16-2004 (Octobre 2004) [IEE1 05] LAN-MAN Standards Committee of the IEEE Computer Society 802.11 IEEE Standard for Information technology, Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Amendment : Medium Access Control (MAC) Quality of Service (QoS) Enhancements IEEE (2005) [IEE1 99] LAN-MAN Standards Committee of the IEEE Computer Society 802.11 IEEE Standard for Information technology, Specic Requirements Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications IEEE standard 8802-11 (1999) [IEE2 03] LAN-MAN Standards Committee of the IEEE Computer Society 802.15.4 IEEE Standard for Information technology, Part 15.4 : Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specications for Low-Rate Wireless Personal Area Networks (LR-WPANs) IEEEStd 802.15.4-2003 (2003) [IEE3 03] IEEE Computer Society IEEE 802.15.4/D18, Draft Standard : Low Rate Wireless Personal Area Networks (F evrier 2003) [IEEE] Le site web du comit e de standardisation IEEE 802 (IEEE 802 LAN/MAN Standards Committee ) http ://www.ieee802.org [IRDA] Le site web de IrDA (Infrared Data Association ) http ://irda.org [KHOU 05] T. Khoutaif et F. Peyrard Performances evaluation of the asynchronous Bluetooth links in a real time environment IEEE Personal Wireless Communications (PWC2005), Colmar, France (Ao ut 2005) [KHOU 06] T. Khoutaif et G. Juanole Formal modelling and evaluation of the data transfer phase of the ACL links on the WPAN Bluetooth 11th International Conference on Emerging Technologies and Factory Automation (ETFA2006), Prague, R epublique Tch` eque (Septembre 2006) [LAAS] Le site web du LAAS http ://www.laas.fr [LEPA 91] F. Lepage Les R eseaux Locaux Industriels - Principes illustr es par des exemples Hermes (1991) [LLI1 06] J.F. Llibre, P. Pinel et E. Campo Dimensionnement dun g en erateur photo volta que pour un syst` eme communicant autonome XIIieme Colloque National de la Recherche dans les IUT, Brest, France (2006) [LLI2 06] J.F. Llibre, P. Pinel et E. Campo Quel choix de source d energie pour rendre un syst` eme communicant autonome ? XIIieme Colloque National de la Recherche dans les IUT, Brest, France (2006) [MARS 85] M.A. Marsan, G. Balbo, A. Bobbio, G. Chiola, G. Conte et A. Cumani On Petri Nets with Stochastic Timing International Workshop on Timed Petri Nets (INTPN85), Turin, Italie (Juillet 1985) [MAUR 05] R. Maurice Contribution ` a la m ethodologie de conception syst` eme : application ` a la r ealisation dun microsyst` eme multicapteurs communicant pour le g enie civil Doctorat de lInstitut National Polytechnique de Toulouse, Rapport LAAS no 05646, Toulouse, France (2005) [MAXS] Le site web de MaxStream http ://www.maxstream.net [MERC 03] A. Mercier, P. Minet et L. Georges Introducing QoS support in Bluetooth Piconetwith a Class-Based EDF Scheduling Rapport de recherche de lINRIA RR-5054 (D ecembre 2003) [MERC 04] G. Mercier Un r eseau sans l faible consommation : IEEE 802.15.4 (alias ZigBee) (2004) [MERC 06] J.J. Mercier Computers II : S equence apr` es s equence, Introduction aux Grafcets chapitre 3.2, Collection Technosup, Ellipses (2006) Adrien van den Bossche 155
[MERL 76] P.M. Merlin Recoverability of communication protocols, implication of a theorical study IEEE Transaction on Communications, 24(9) :1036-1043 (1976) [MICH 05] F. Michaut et F. Lepage Adaptation des applications distribu ees ` a la qualit e de service du r eseau de communication Ecole d et e temps r eel 2005 (ETR05) Nancy, France (Septembre 2005) [MUHL 02] P. Muhlethaler 802.11 et les r eseaux sans l Eyrolles (2002) [NIC1 98] K. Nichols, S. Blake, F. Baker et D. Black Denition of the Dierentiated Services Field (DS Field) in the IPv4 and IPv6 Headers RFC 2474, IETF Network Working Group (Decembre 1998) [NIC2 98] K. Nichols, S. Blake, F. Baker et D. Black An Architecture for Dierentiated Service RFC 2475, IETF Network Working Group (Decembre 1998) [NS] Le site web de Network Simulator (NS) http ://www.isi.edu/nsnam/ns [OLC] Le site web du groupe OLC http ://www2.laas.fr/laas/1-4286-Groupe-OLC.php [OPNE] Le site web dOPNET http ://www.opnet.com [PERK 97] C. Perkins et E. Royer Ad-hoc on-demand distance vector routing MILCOM97 (Novembre 1997) [PETR 06] M. Petrova, J. Riihijarvi, P. Mahonen et S. Labella Performance Study of IEEE 802.15.4 Using Measurements and Simulations IEEE Wireless Communications and Networking Conference (WCNC06), vol. 1, pp : 487- 492, Las Vegas, Nevada, USA (Avril 2006) [PUJO 95] G. Pujolle Les r eseaux Eyrolles (1995) [QUAL 02] Scalable Network Technologies Speed & Scalability : Requirements for Industrial Strength Network Simulators Qualnet White Paper (2002) [QUAL] Le site web de Qualnet http ://www.scalable-networks.com [RAN] Le web ring des RAN (Rural Area Network ) http ://ran.vaour.net/webring [SAMS] Samsung/CUNY NS2 simulator for 802.15.4 http ://www-ee.ccny.cuny.edu/zheng/pub [SIMP 05] D. Simplot-Ryl Real-time aspects in Wireless Sensor Networks Ecole dEt e Temps R eel 2005 (ETR05), Nancy, France (Septembre 2005) [SMER 04] S.A. Smerzi, G. Girlando, T. Copani et G. Palmisano A Ku-band monolithic receiver for DVB-S applications IEEE Communications Magazine, vol.42 issue 8, pp 132-139 (Ao ut 2004) [THOM 05] J.P. Thomesse Fieldbus Technology and Industrial Automation 10th IEEE Conference on Emerging Technologies and Factory Automation (ETFA 2005), Catania, Italie (Septembre 2005) [TINA] Le site web de TINA http ://www.laas.fr/tina [TSF] Le site web de lassociation Toulouse Sans Fil http ://www.toulouse-sans-l.net [VAL 05] T. Val et G. Juanole La Qualit e de Service dans les r eseaux sans l Ecole d et e Temps R eel (ETR05), Nancy, France (Septembre 2005) [VAND 01] M. van der Zee et G. Heijenk Quality of Service in Bluetooth Networking 10/0362FCP NB 102 88 Uen (Janvier 2001) [VDB 06] A. van den Bossche, T. Val et E. Campo Proposition of a full deterministic medium access method for wireless network in a robotic application 63rd IEEE Vehicular Technology Conference (VTC-2006-Spring), Melbourne, Australie (Mai 2006) [VDB 07] A. van den Bossche, T. Val et E. Campo Une m ethode dacc` es totalement d eterministe pour un r eseau personnel sans l 8ieme congr` es de lEcole Doctorale Syst` emes de Toulouse (EDSYS07), Albi, France (Mai 2007) [VDB1 05] A. van den Bossche, T. Val et E. Campo M etrologie pour lanalyse comparative des performances temporelles des liens Bluetooth IEEE Sciences of Electronic, Technologies of Information and Telecommunication (SETIT2005), Sousse, Tunisie (Mars 2005) [VDB2 05] A. van den Bossche et M. Gerbe Les modules IEEE 802.15.4 ICARE Documentation technique illustr ee, document interne ICARE (Juin 2005) 156 Groupe SCSF LATTIS EA4155
[VDB3 05] A. van den Bossche IEEE 802.15.4 / ZigBee : un r eseau sans l ` a faible consommation energ etique 2iemes rencontres des Sciences et Technologies de lInformation (ASTI2005), Aubi` ere, France (Octobre 2005) [VINT 95] The NS Manual (formerly NS Notes and Documentation) par les contributeurs du projet VINT UC Berkeley, LBL, USC/ISI, and Xerox PARC (1995) [WEI 02] A. Wei et S. Boumerdassi Support de la QoS dans les r eseaux 802.11 Rapport scientique CEDRIC No 401 (2002) [WEIN 97] J. Weinmiller, M. Schl ager, A. Festag et A. Wolisz Performance Study of Access Control in Wireless LANs - IEEE 802.11 DFWMAC and ETSI RES 10 HiperLAN Mobile Networks and Applications, vol.2, pp 55-67 (1997) [WROC 97] J. Wroclawski The Use of RSVP with IETF Integrated Services RFC 2210, IETF Network Working Group (Septembre 1997) [XU 02] K. Xu, M. Gerla et S. Bae How eective is the IEEE 802.11 RTS/CTS handshake in ad hoc networks IEEE Global Telecommunications Conference (GLOBECOM02) vol.1, pp 72-76 (Novembre 2002) [YU 04] J. Yu IEEE 802.11e QoS for Wireless LAN : A Research Direction Multimedia Networking Research Laboratory (MNLAB) Networking Seminar (D ecembre 2003) [ZBAL 05] ZigBee Alliance ZigBee Specication ZigBee Document 053474r06, version 1.0 (2005) [ZBAL] Le site web de la ZigBee Alliance www.zigbee.org [ZHEN 04] J. Zheng et M. J. Lee Will IEEE 802.15.4 make ubiquitous networking a reality ? : A discussion on a potential low power, low bit rate standard IEEE Communications Magazine, vol. 27, no. 6, pp. 23-29 (2004) [ZHEN 06] J. Zheng et M. J. Lee A comprehensive performance study of IEEE 802.15.4 Sensor Network Operations, IEEE Press, Wiley Interscience, chapitre 4, pp. 218-237 (2006).
157
158
Glossaire
16QAM, 16-ary Quadrature Amplitude Modulation 64QAM, 64-ary Quadrature Amplitude Modulation AES, Advanced Encryption Standard AFH, Adaptive Frequency Hopping : Technique de saut de fr equence evitant les canaux encombr es AIFS, Arbitration Inter-Frame Spacing AODV, Ad hoc On Demand Distance Vector ARCEP, Autorit e de R egulation des Communications Electroniques et des Postes ART, Autorit e de R egulation des T el ecommunications ASP, Application Support Package ATM, Asynchronous Transfer Mode ARQ, Automatic Repeat reQuest BDM, Background Debug Mode BER, Bit Error Rate : taux derreur bit BI, Beacon Interval BLR, Boucle Locale Radio BO, Beacon Order BPSK, Binary Phase Shift Keying BSN, Beacon Sequence Number CAP, Contention Access Period CCA, Clear Channel Assessment CCK, Complementary Code Keying CDMA, Code Division Multiple Access CFP, Contention Free Period CSMA/CA, Carrier Sense Multiple Access with Colision Avoidance CSMA/CD, Carrier Sense Multiple Access with Carrier Detect CTS, Clear To Send CTS, Clear To Send : Pr et ` a recevoir lenvoi. Terminologie emprunt ee ` a RS232. Voir aussi RTS. DECT Digital Enhanced Cordless Telephone DIFS, Distributed Inter-Frame Spacing DSL, Digital Suscriber Line DSN, Data Sequence Number DSSS, Direct Sequence Spread Spectrum DVB, Digital Video Broadcasting DVB-S, Digital Video Broadcasting - Satellite DVB-T, Digital Video Broadcasting - Terrestrial EDGE, Enhanced Data Rates for GSM Evolution ED, Energy Detection EY-NPMA, Elimination Yeld Non-preemptive Priority Multiple Access FCS, Frame Check Sequence FDD, Frequency Division Duplexing FDMA, Frequency Division Multiple Access FEC, Forward Error Correction FFD, Full Fonction Device
Glossaire
FHSS, Frequency Hopping Spread Spectrum FSK, Frequency Shift Keying FTTH, Fiber To The Home GBS, Guaranteed Beacon Slot GFSK Gaussian Frequency Shift Keying GMSK, Gaussian Minimum Shift Keying GPIO, General Purpose Input/Output GPRS, General Packet Radio Service GTS, Guaranteed Time Slot IEEE, Institute of Electrical and Electronics Engineers IP, Internet Protocol ISO, International Organizationfor Standardization L2CAP, Logical Link Control and Adaptation Layer Protocol LAN, Local Area Network : R eseau local LATTIS, LAboratoire Toulousain des Technologies et de lIng enierie des Syst` emes LIFS, Long Inter-Frame Spacing LLC, Logical Link Control LMDS, Local Multipoint Distribution Service LP-WPAN, Low Power Wireless Personnal Area Network LQI, Link Quality Indication MAC, Medium Access Control MAN, Metropolitan Area Network : R eseau m etropolitain MCPS, MAC Common Part Sublayer MCPS-SAP, MAC Common Part Sublayer Service Access Point MIMO Multiple Input/Multiple Output MLME-SAP, Network Layer Management Entity Service Access Point MLME, Network Layer Management Entity MPDU, MAC-level Protocol Data Unit : unit e de donn ees du protocole de niveau Liaison NAV, Network Allocation Vector NHLE, Next Higher Level Entity NIB, Network-layer Information Base NLDE-SAP, Network Layer Data Entity Service Access Point NLDE, Network Layer Data Entity NLME, Network Layer Management Entity NPDU, NWK-level Protocol Data Unit : unit e de donn ees du protocole de niveau R eseau OFDM, Orthogonal Frequency Division Multiplexing OLSR, Optimized Link State Routing Protocol O-QPSK, Orthogonal-Quadrature Phase Shift Keying Overhead : surplus de donn ees non-utiles pourtant n ecessaires PAN, Personal Area Network : R eseau personnel PDS, Previously Dedicated Slot PDU, Protocol Data Unit : unit e de donn ees du protocole PIFS, Point Cooordination Inter-Frame Spacing PN-code, Pseudo Noise code : code pseudo al eatoire PPDU, PHY-level Protocol Data Unit : unit e de donn ees du protocole de niveau Physique QdS, QoS, Qualit e de Service, Quality of Service QPSK, Quadrature Phase Shift Keying RFD, Reduced Fonction Device RTS, Request To Send : Demande denvoi. Terminologie emprunt ee ` a RS232. Voir aussi CTS. SAP, Service Access Point : point dacc` es de service SDU, Service Data Unit : unit e de donn ees de service SIFS, Short Inter-Frame Spacing SNR, Signal-to-Noise Ration : rapport signal sur bruit SO, Superframe Order SGTS, Simultaneous Guaranteed Time Slot SSCS, Service Specic Convergence Sublayer (IEEE 802.15.4)
160
Glossaire
TDD, Time Division Duplexing TDMA, Frequency Division Multiple Access TKIP Temporal Key Integrity Protocol UMTS, Universal Mobile Telecommunications System VSAT, Very Small Aperture Terminal WAN, Wide Area Network : R eseau etendu WEP, Wired Equivallent Privacy WLAN, Wireless Local Area Network : R eseau local sans l WMAN, Wireless Metropolitan Area Network : R eseau m etropolitain sans l WPA2 Wi-Fi Protected Access WPAN, Wireless Personal Area Network : R eseau personnel sans l WWAN, Wireless Wide Area Network : R eseau etendu sans l xDSL, voir DSL ZC, ZigBee Coordinator ZDO, ZigBee Device Object ZED, ZigBee End Device ZR, ZigBee Router
161
Table des figures
162
Table des gures

1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 Di erents types de r eseaux sans l et port ees typiques . . . . . . . . . . . . . . . . . . . Topologie Infrastructure de 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topologie Ad-hoc de 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topologie point ` a point de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topologie Piconet de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topologie Scatternet de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le principe de lUltra Wide Band : utilisation du spectre radio fr equence . . . . . . . . . Illustration du protocole RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proc ed e de multiplexage / d emultiplexage pour la cohabitation de plusieurs tracs sur le m eme canal de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 19 19 23 23 23 24 31
33 35 35 36 36 38 38 39
1.10 Illustration de CSMA/CA si le m edium est initialement libre . . . . . . . . . . . . . . . 1.11 Illustration de CSMA/CA si le m edium est initialement occup e . . . . . . . . . . . . . . 1.12 Topologie pr esentant deux terminaux mutuellement cach es . . . . . . . . . . . . . . . . . 1.13 D eroulement de lacc` es au m edium par la m ethode CSMA/CA . . . . . . . . . . . . . . 1.14 D eroulement dun acc` es au m edium r eussi par la m ethode EY-NPMA . . . . . . . . . . 1.15 D eroulement dun acc` es au m edium par la m ethode EY-NPMA ayant echou e . . . . . . 1.16 La supertrame HiperLAN/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.17 D eroulement temporel dune p eriode dacc` es sans contention dans le cadre de 802.11 PCF 41 2.1 2.2 2.3 2.4 2.5 Graphe des etats dun modem 802.15.4 (source Freescale) . . . . . . . . . . . . . . . . Repr esentation de la topologie en etoile . . . . . . . . . . . . . . . . . . . . . . . . . . . Repr esentation de la topologie point ` a point . . . . . . . . . . . . . . . . . . . . . . . . . Le principe g en erique de lencapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication respectant le protocole normalis e . . . . . . . . . . . . . . . . . . . . . . 54 55 55 58 58
Table des figures
2.6 2.7 2.8
La pile protocolaire 802.15.4 / ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principe dinterfa cage entre couches et SAP pour ZigBee . . . . . . . . . . . . . . . . . . Rapport entre BER et SNR pour diverses technologies de transmission sans l (source IEEE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure du paquet de niveau physique . . . . . . . . . . . . . . . . . . . . . . . . . . .
59 60
62 63 64 65 68 69 69 69 71 72 72
2.9
2.10 Principe du transfert de donn ees dans une etoile . . . . . . . . . . . . . . . . . . . . . . 2.11 Repr esentation dune supertrame IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 2.12 Structure de la trame balise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13 Structure de la trame de donn ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.14 Structure de la trame dacquittement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15 Structure de la trame de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16 Exemple de cr eation du r eseau ZigBee en arbre . . . . . . . . . . . . . . . . . . . . . . . 2.17 Exemple de topologie maill ee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.18 Structure de la couche r eseau propos ee par ZigBee . . . . . . . . . . . . . . . . . . . . .
2.19 Illustration de la hi erarchie des adresses dans le cadre de ladressage automatique en arbre 74 2.20 Structure du paquet de niveau r eseau et encapsulation dans une trame de donn ees 802.15.4 76 2.21 Les messages GTS.request peuvent entrer en collision avec le reste du trac CSMA/CA 2.22 Le service garanti (GTS) ne peut etre maintenu de mani` ere d eterministe . . . . . . . . . 2.23 Un GTS inutilis e constitue une perte de bande passante non r eutilisable . . . . . . . . . 2.24 Plusieurs coordinateurs attribuant des GTS peuvent provoquer des collisions de GTS 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 . 77 78 79 79 88 88 93 94 95 97 98
Topologie propos ee pour la communication interne au robot . . . . . . . . . . . . . . . . Topologie propos ee pour la communication entre robots . . . . . . . . . . . . . . . . . . ements du r El eseau, liens et port ees minimales pour le bon fonctionnement du protocole R epartition des beacons au sein de la supertrame . . . . . . . . . . . . . . . . . . . . . . P eriodes des cycles d eterministes en fonction du niveau de r eservation du PDS . . . . . Topologie du r eseau mis en place pour lexemple . . . . . . . . . . . . . . . . . . . . . . Un exemple de d eroulement du protocole . . . . . . . . . . . . . . . . . . . . . . . . . .
Topologie d ecole du r eseau illustrant la n egociation dun SGTS . . . . . . . . . . . . . . 101 Principe de la n egociation protocolaire dun SGTS . . . . . . . . . . . . . . . . . . . . . 102
3.10 Topologie du r eseau pour la n egociation dun SGTS . . . . . . . . . . . . . . . . . . . . 102 3.11 Principe de la n egociation dun SGTS dans le cadre de notre topologie . . . . . . . . . . 103 164 Groupe SCSF LATTIS EA4155
Table des figures
4.1 4.2 4.3 4.4 4.5
S equencement du protocole pour une demande dassociation dun nud au r eseau
. . . 113
ements du r El eseau et liens entre ces el ements . . . . . . . . . . . . . . . . . . . . . . . . 114 Repr esentation du mod` ele R eseau de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Exemple dune r epartition de PDS/GBS/GTS sous forme matricielle . . . . . . . . . . . 120 Repr esentation des fen etres temporelles pour lassociation d eterministe dun coordinateur (pour BO = 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Repr esentation des fen etres temporelles pour lassociation d eterministe dun nud terminal (pour BO = 3 et nGBS = 0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Repr esentation des fen etres temporelles pour lassociation d eterministe dun nud terminal (pour BO = 3 et nGBS = 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 D ebit utile avec CSMA/CA dans un r eseau 802.15.4 avec beacons . . . . . . . . . . . . . 126 Quelques plateformes IEEE 802.15.4/ZigBee de Freescale . . . . . . . . . . . . . . . . 128
4.6
4.7
4.8 4.9
4.10 Utilisation conjointe du module espion et de lanalyseur de trames . . . . . . . . . . . . 130 4.11 Evaluation de la proportion de trames perdues en fonction de la puissance du signal re cu 131 4.12 Illustration des d elais engendr es sur toute la transmission avec SMAC et le mode packet 132
4.13 Mesure du d elai total (temps de traitement et de transmission) en fonction de la longueur utile du paquet transmis (PSDU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 4.14 Evaluation du d ebit utile maximal en fonction de la longueur du paquet transmis . . . . 134 4.15 Topologie pour la mesure de la gigue de synchronisation pour deux nuds dune m eme etoile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 4.16 Quantication de la gigue de synchronisation pour deux nuds dune m eme etoile . . . 135 4.17 Topologie pour la mesure de la gigue de synchronisation pour deux nuds de deux etoiles di erentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 4.18 Quantication de la gigue de synchronisation pour deux nuds de deux etoiles di erentes 137 4.19 Evaluation du d ebit utile maximal pour un slot d eterministe, en fonction du niveau de BO et du niveau de r eservation n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 4.20 Evaluation du d ebit maximum oert en fonction de la charge globale du r eseau . . . . . 139 4.21 Succession des messages echang es sur le m edium dans le protocole de test pour la faisabilit e des SGTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 4.22 Taux de trames r eceptionn ees correctement en fonction du rapport de puissances re cues 4.23 Taux de trames r eceptionn ees correctement en fonction du rapport de puissances re cues 141 142
4.24 Le robot ER1, le capteur infrarouge et le coordinateur (module ZigBee ICARE) . . . . . 143 4.25 R ealisations de modules ZigBee ICARE . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 4.26 Passerelle IP/ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Adrien van den Bossche 165
Table des figures
4.27 Les deux robots suiveurs de ligne et le r eseau form e . . . . . . . . . . . . . . . . . . . . . 145
166
Liste des tableaux

2.1 Consommation typique dun modem 802.15.4 avec temps de basculement entre chaque etat (source Freescale) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caract eristiques des deux couches physiques propos ees (PHY868/915 et PHY2450) . . . Structure de la table de routage dun nud ZigBee . . . . . . . . . . . . . . . . . . . . .
54 61 75
2.2 2.3 4.1
ements valid El es par chaque m ethode utilis ee . . . . . . . . . . . . . . . . . . . . . . . . 111
Proposition dune nouvelle mthode daccs dterministe pour un rseau personnel sans fil fortes contraintes temporelles
Aujourdhui, les technologies de rseaux sans fil (WLAN/WPAN) prsentes sur le march sont nombreuses et globalement complmentaires. Cependant, trop peu dentre elles proposent de relles garanties sur la remise de messages dans un temps born alors que ces exigences sont fondamentales dans le cadre dune utilisation de type industriel. Dans le cadre de nos travaux, nous proposons une nouvelle couche MAC entirement dterministe pour un rseau sans fil personnel basse consommation (LP-WPAN) IEEE 802.15.4 prsentant des garanties sur le plan temporel. Tout dabord, un tat de lart est effectu sur les principaux rseaux sans fil existants, les mcanismes de gestion de la Qualit de Service et les mthodes daccs gnralement utilises. Nous prsentons ensuite la technologie IEEE 802.15.4/ZigBee sur laquelle sont bass nos travaux. Cette tude approfondie nous a permis didentifier certaines imperfections au niveau de la mthode daccs par rapport aux contraintes temporelles. Nous proposons de combler ces lacunes par la cration dune couche MAC entirement dterministe dont nous prsentons les caractristiques et les nouvelles fonctionnalits. Plusieurs mthodes complmentaires ont t utilises pour valider nos propositions : Rseaux de Petri, simulation et prototypage rel. Les rsultats obtenus et les analyses de ces trois tudes sont exposs.
Proposition of a new determinist medium access method for a wireless personal area network with hard temporal constraints
Today, wireless network technologies (WLAN/WPAN) available on the market are numerous and complementary. Nevertheless, none of these technologies present some real guaranties on message delivery within a bounded delay. However, this kind of constraint is a recurrent need in the industrial communication application context. To solve this problem, our research work proposes an original full deterministic MAC layer for an IEEE 802.15.4 Low-Power Wireless Personal Area Network. We first present a state of the art on principal wireless network standards and technologies, Quality of Service protocols and commonly used Medium Access Control mechanisms. Then, we present the IEEE 802.15.4/ZigBee wireless technology which is used as a basis for our works. This study has enabled us to identify weakness on 802.15.4 Medium Access Control, in particular for highly time-constrained data transports. Our research works propose to solve these identified weaknesses by proposing an original full deterministic medium access method. Several validation methods/tools were used: Petrinets, simulation and prototyping. Obtained results are then exposed and discussed.

These Adrien Van Den Bossche

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

These Adrien Van Den Bossche

Uploaded by

Copyright:

Available Formats

LABORATOIRE LATTIS EA 4155 Groupe SCSF

Systmes Communicants Sans Fil

Prsent par Monsieur Adrien VAN DEN BOSSCHE

Groupe SCSF LATTIS EA4155

Table des mati` eres

` TABLE DES MATIERES

Groupe SCSF LATTIS EA4155

` TABLE DES MATIERES

Groupe SCSF LATTIS EA4155

Adrien van den Bossche

Groupe SCSF LATTIS EA4155

Les r eseaux sans l et la Qualit e de Service

DE SERVICE CHAPITRE 1. LES RESEAUX SANS FIL ET LA QUALITE

Groupe SCSF LATTIS EA4155

Etat de lart des technologies de r eseaux sans l

Etat de lart des technologies de r eseaux sans l

Classication des technologies r eseaux

Fig. 1.1 Di erents types de r eseaux sans l et port ees typiques

DE SERVICE CHAPITRE 1. LES RESEAUX SANS FIL ET LA QUALITE

Les r eseaux sans l etendus (WWAN)

Les r eseaux sans l m etropolitains (WMAN)

La Boucle Locale Radio (BLR)

Groupe SCSF LATTIS EA4155

Etat de lart des technologies de r eseaux sans l

ETSI HiperMAN / IEEE 802.16, WiMAX

Adrien van den Bossche

DE SERVICE CHAPITRE 1. LES RESEAUX SANS FIL ET LA QUALITE

IEEE 802.20, Mobile Broadband Wireless Access (MWBA)

Les r eseaux locaux sans l (WLAN)

Etat de lart des technologies de r eseaux sans l

HiperLAN/1 (HIgh PERformance LAN, premi` ere version)

HiperLAN/2 (HIgh PERformance LAN, seconde version)

parlera plut ot de relais de trames, puisque ce processus se situe au niveau 2 OSI.

Adrien van den Bossche

DE SERVICE CHAPITRE 1. LES RESEAUX SANS FIL ET LA QUALITE

IEEE 802.11, WiFi

Dans le cadre de 802.11, deux topologies sont possibles aujourdhui5 :

Groupe SCSF LATTIS EA4155

Etat de lart des technologies de r eseaux sans l

Fig. 1.3 Topologie Ad-hoc de 802.11

Les evolutions de 802.11

Adrien van den Bossche

DE SERVICE CHAPITRE 1. LES RESEAUX SANS FIL ET LA QUALITE

Groupe SCSF LATTIS EA4155

Etat de lart des technologies de r eseaux sans l

Les r eseaux personnels sans l (WPAN)

Adrien van den Bossche

DE SERVICE CHAPITRE 1. LES RESEAUX SANS FIL ET LA QUALITE

IEEE 802.15.1, Bluetooth

Groupe SCSF LATTIS EA4155

Etat de lart des technologies de r eseaux sans l

Fig. 1.4 Topologie point ` a point de Bluetooth

Fig. 1.5 Topologie Piconet de Bluetooth

Fig. 1.6 Topologie Scatternet de Bluetooth

Adrien van den Bossche

DE SERVICE CHAPITRE 1. LES RESEAUX SANS FIL ET LA QUALITE

IEEE 802.15.3, Ultra Wide Band (UWB)

Etat de lart des technologies de r eseaux sans l

IEEE 802.15.4, ZigBee

Les r eseaux de capteurs (WSN)

DE SERVICE CHAPITRE 1. LES RESEAUX SANS FIL ET LA QUALITE

La Qualit e de Service dans les r eseaux

QoS vs. Surdimensionnement

Groupe SCSF LATTIS EA4155