Annexes
Le standard IEEE 802.15.4
IEEE 802.15.4 est un nouveau standard qui définit les spécifications de la couche physique et la sous-couche MAC pour les réseaux personnels sans fil à faible débit (Low Rate Wireless Personal Area Networks (LR-WPAN’s)) entre autre les réseaux de capteurs. L’objectif de ce standard est d’assurer une faible consommation d’énergie pour les nœuds interconnectés (capteurs…), une interconnexion sans fil à faible coût et un faible débit ne dépassant pas les 250 Kbits/s [ZHE 04].
Pourquoi un nouveau standard pour les réseaux sans fil ?
L’augmentation du débit dans les séries du standard IEEE 802.11 paraît très nette (initialement, IEEE 802.11 offrait des débits allant de 1 à 2 Mbits/s et actuellement les standards IEEE 802.11a et IEEE 802.11g offrent jusqu’à 54 Mbits/s).
Bluetooth (IEEE 802.15.1) quant à lui, est le premier standard conçu pour les applications à faible débit dans les réseaux personnels sans fil (WPAN). Malgré le succès de cette technologie sur le marché, il s’est avéré qu’elle a des inconvénients :
- manque de flexibilité dans ses topologies.
- complexité (les efforts de bluetooth à couvrir le maximum d’applications possibles et offrir
une meilleure QoS ont diminué sa simplicité) qui l’a rendu cher et inapproprié pour
certaines simples applications à faible consommation d’énergie..
- problème de scalabilité dans les topologies pair à pair de Bluetooth (scatternet).
Les inconvénients de Bluetooth cités précédemment, l’apparition de périphériques de haute qualité à faible coût et l’émergence de nouvelles applications ont mené au développement de deux nouvelles générations de réseaux WPAN qui sont :
- les réseaux WPAN à haut débit IEEE 802.15.3a connu sous le nom de Ultra WideBand
(UWB) ou HR-WPAN’s.
- les réseaux WPAN à faible débit IEEE 802.15.4 [ZHE 04].
Spécificités de IEEE 802.15.4
Il se distingue des autres standards de réseaux sans fil par plusieurs spécificités telles que son faible débit, sa faible consommation d’énergie, son faible coût, sa capacité de s’auto-organiser, sa flexibilité, sa faible portée de transmission…
Domaines d’applications
Les spécificités de la norme IEEE 802.15.4 lui ont permis de supporter des applications qui sont inappropriés pour d’autres standards.
Avec la possibilité de connecter de simples périphériques variés au réseau, IEEE 802.15.4
a permis à l’utilisateur plus que jamais une interconnexion ubiquitaire.
Parmi les applications utilisés grâce à ce standard, on peut citer :
-
Monitoring (suivi) : santé, environnement, surveillance…
-
Automatisation et contrôle : entreprise, maison…
-
Divertissement : jeux éducatifs, jouets intéractifs… [ZHE 04]
Vue d’ensemble du standard IEEE 802.15.4
- Les topologies supportées :
On trouve deux types de topologies réseau supportés par ce standard:
-
la topologie en étoile à un saut ou « one hop-star » utilisée lorsque la portée des communications ne dépasse pas les 10m.
-
la topologie pair à pair à multi-sauts ou « multihop peer-to-peer » utilisée lorsque la portée des communications dépasse les 10m. [ZHE 04]
- L’adressage :
Un noeud dans un réseau LR-WPAN peut utiliser deux types d’adresses :
-
Une adresse IEEE à 64bits.
-
Une adresse à 16bits.
Un réseau 802.15.4 peut supporter jusqu’à 216 périphériques interconnectés [ZHE 04].
- Bandes de fréquences et Débit :
Les liaisons sans fil dans un réseau IEEE 802.15.4 opèrent dans trois bandes de fréquences ISM (à licences libres) :
- 2.4GHz partagée en 16 canaux et offrant un débit de 250Kbits/s.
- 915MHz (Amérique du nord) partagée en 10 canaux et offrant un débit de 40Kbits/s.
- 868MHz (europe) à un seul canal et offrant un débit de 200Kbits/s (20Ksym/s).
=> IEEE 802.15.4 opère sur 27 canaux qui lui sont alloués [ZHE 04].
- Flexibilité et économie d’énergie :
Les différents débits possibles dans ce standard offrent aux applications un meilleur choix en terme de coût et d’économie d’énergie.
Exemple : 250Kbits/s est un débit nécessaire lorsque les nœuds interconnectés sont des périphériques informatiques. Cependant, pour le cas d’une application de réseau de capteurs (ou de smart tags, cosumer electronics), un débit de 20Kbits/s satisfait amplement les besoins de l’application [ZHE 04].
Notion de « Supertrame »
Le standard IEEE 802.15.4 utilise la méthode Slotted CSMA-CA qui elle même utilise des “supertrames”; Celle ci sont définies par le coordinateur, et ont pour principal avantage de permettre la synchronisation de l’ensemble des éléments entre eux, et ainsi d’économiser l’énergie de chacun des noeuds du réseau. Les supertrames sont tout d’abord divisées en deux parties :
Une partie active et une partie inactive; durant la partie inactive le coordinateur n’interagit pas avec le réseau et se place en mode veille. Chaque supertrame commence par un beacon qui est envoyé par le coordinateur du réseau, et qui permet la synchronisation entre les noeuds et le coordinateur.
Le « beacon » est immédiatement suivi par une zone appelée “Contention Access Period” (CAP), qui permet à chaque élément du réseau d’envoyer ou de recevoir des trames de commandes et de données.
L’accès au canal durant la période CAP suit le mécanisme CSMA-CA : l’émetteur écoute le canal pendant une durée aléatoirement tirée (algorithme de backoff) puis émet si le canal est libre.
Une autre zone optionnelle disponible dans la supertrame (CFP) est utilisée pour les transmissions nécessitant de la qualité de service. Le CFP est divisé en slots, dont le coordinateur
gère l’allocation en fonction des besoins. Une station qui se voit attribuer un slot est assurée qu’aucune autre station ne transmettra durant cette période.
L’allocation d’un slot fait suite à une négociation entre un noeud et le coordinateur. Si la négociation aboutit, le coordinateur informe le noeud en plaçant une information (stream index) dans le prochain beacon (l’algorithme d’allocation n’est pas défini dans le standard).
Le mode de communication utilisant les supertrames garantit un très faible taux utilisation des ressources (souvent inférieur à 10%), car les noeuds formant le réseau ont un temps de veille garanti très long (les noeuds ne sont actifs que durant la période CAP).
En conclusion ce mode de communication est l’un des plus économiques qui soit au niveau de la sauvegarde de l’énergie de chacun des éléments du réseau [DEL 05].
Figure A : Structure d’une « supertrame » [DEL 05]
Les modifications apportées aux fichiers du modèle de simulation
Pour que le simulateur OMNET++ puisse prendre en charge la solution qu’on a proposé, certains fichiers sources auxquels l’implémentation de Sensor-MAC fait appel, doivent être modifiés :
-----------------------------------------------------------------------------------------------------------------
Le fichier Sensor-MAC.h :
class Sensor-MAC : public BasicMac {
Module_class_Members (Sensor-MAC, BasicMac, 0) ;
protected :
double passive_preamble_time ; //variable qui va recevoir la valeur du préambule
// à l’état d’écoute passive.
double total_preamble_time ; //variable qui va recevoir la valeur du préambule
//total selon l’état du nœud capteur.
…
void startContending (int time) //commencer la contention du canal pendant « time »
…
------------------------------------------------------------------------------------------------------------------------
Le fichier Sensor-MAC.cc :
------------------------------------------------------------------------------------------------------------------------
#define SYNC_CONTEND_TIME 5
#define RTS_CONTEND_TIME 5
#define CTS_CONTEND_TIME 5
#define DATA_CONTEND_TIME 5
#define TIMEOUT_WFACK 5
#define TIMEOUT_WFDATA 5
#define TIMEOUT_WFCTS 5
...
Define_Module_Like (Sensor-MAC, Mac ) ;
void Sensor-MAC : : init ( )
{
...
passive_preamble_time = par(“mac1”) / 2 ; // la variable « passive_preamble_time » est //initialisée à une valeur égale au (1/2) de la longueur de la période d’écoute de Sensor-MAC
total_preamble_time = 3 * passive_preamble_time ; // la variable « total_preamble_time » est
//initialisée au triple de la valeur de la longueur de la période d’écoute passive dans Sensor-//MACp
total_frame_time = par (“mac2”) ;
sleep_time = total_frame_time – passive_preamble_time ;
…
}
void SMac : : txFrame ( )
{…
assert (nav_state == NAV_STATE_CLEAR)
if (rssi ( ) > 0.5)
{…
setinternalTimeout (passive_preamble_time)
setIdle ( ) ;
return ;
}
else {
switch (proto_state) {
case PROTO_STATE_CONTEND :
switch (next_state) {
case PROTO_STATE_SEND_SYNC :
startContending (SYNC_CONTEND_TIME) ;
setinternalTimeout (passive_preamble_time) ;
sendSync ( ) ;
break ;
case PROTO_STATE_SEND_RTS :
startContending (RTS_CONTEND_TIME)
setinternalTimeout (total_preamble_time) ;
sendRts ( ) ;
proto_state = PROTO_STATE_WFCTS ;
setProtocolTimeout (TIMEOUT_WFCTS) ;
break ;
case PROTO_STATE_SEND_DATA :
startContending (DATA_CONTEND_TIME) ;
setinternalTimeout (total_preamble_time) ;
sendData ( ) ;
break ;
case PROTO_STATE_SEND_CTS :
sendCts ( ) ;
proto_state = PROTO_STATE_WFDATA ;
setProtocolTimeout (TIMEOUT_WFDATA) ;
break ;
}
break ;
case PROTO_STATE_SEND_DATA :
sendData ( ) ;
proto_state = PROTO_STATE_WFACK ;
setProtocolTimeout (TIMEOUT_WFACK) ;
break ;
case PROTO_STATE_SEND_ACK :
sendAck ( ) ;
} break ;
} return ;
}
...
void SMac : : rxFrame (Packet * msg)
{ ...
if (sched_state == SCHED_STATE_SLEEP)
return ;
else
if (rssi < 0.5) {
setinternalTimeout (passive_preamble_time) }
else
switch (PKT_KIND (msg)) {
case KIND_SYNC :
setinternalTimeout (passive_preamble_time) ;
receiveSync (msg) ;
break ;
case KIND_RTS :
setinternalTimeout (total_preamble_time) ;
receiveRts (msg) ;
break ;
case KIND_CTS :
receiveCts (msg) ;
break ;
case KIND_DATA :
if (msg -> local_to != -1) {
receiveData (msg) }
else
setinternalTimeout (total_preamble_time) ;
receiveData (msg) ;
break ;
case KIND_ACK :
receiveAck (msg) ;
break ;
…
}
Projet de fin d’études 2005/2006
Dostları ilə paylaş: