Protocoles de communication représentés

Dans la section 2.1.2, nous avons considéré que les protocoles de communication usuel-lement utilisés dans les réseaux de capteurs urbains pouvait se classer en deux catégories. Nous pouvons cependant affiner le modèle en y ajoutant une troisième catégorie dédiée aux signaux très étalés. Cette nouvelle catégorie ne change pas les conclusions de l’étude de la plage dynamique (voir section 2.1), puisque celle-ci a été faite à partir des sensibilités des différents protocoles de communication : le fait d’étaler davantage les signaux n’entraîne pas le besoin d’une meilleure sensibilité de l’architecture de réception, puisque le signal pourra être démodulé même avec un SNR négatif.

Les trois familles de protocoles que nous pouvons considérer sont les suivantes : — bande étroite : largeur de canal de 50 kHz, pas d’étalement, modulation FSK

— bande intermédiaire : largeur de canal de 200 kHz, signaux étalés avec un faible facteur d’étalement, modulation FSK

— large bande : largeur de canal allant jusqu’à 1 MHz, signaux étalés avec un haut facteur d’étalement, modulation BPSK ou O-QPSK

Chaque application n’employant qu’un seul protocole de communication, ces protocoles sont répartis de la manière suivante :

— bande étroite : télérelève de compteur (eau, gaz et électricité), gestion de l’éclairage public et gestion des déchets

— bande intermédiaire : alertes et surveillance de la pollution, irrigation, gestion des vélos en libre-service

— large bande : gestion des places de parking

Les applications utilisant une bande étroite sont celles qui n’ont généralement pas be-soin d’une sensibilité très basse (ce qui ne signifie pas qu’il est impossible de recevoir ces signaux avec une très faible puissance). Celles en bande intermédiaire peuvent faire face à des conditions de propagations moins bonnes (irrigation, gestion des vélos en libre-service) ou doivent assurer un faible taux de pertes de données (alertes de pollution). Enfin, celles utilisant une large bande font face à des conditions de propagation difficiles : les capteurs de place de parking sont généralement légèrement enterrés, et souvent situés sous les voitures.

Chapitre 5. Comparaison des deux architectures proposées et expérimentations Application ^{Nombre de} capteurs Taille de la donnée (octets) Périodicité (émissions par jour) Largeur de canal

Gestion des places de parking 1000 100 24 1 MHz

Gestion des vélos en libre-service 20 50 96 200 kHz

Gestion de l’éclairage public 4 20000 1 50 kHz

Gestion des déchets 10 50 24 50 kHz

Surveillance de la pollution 1 1000 24 200 kHz

Alertes de pollution 1 5000 96 200 kHz

TABLE5.7 – Répartition des capteurs par application dans le deuxième scénario d’émission

Les deux scénarios d’émission étant maintenant définis, ils sont résumés sur les Tables 5.6 et 5.7. Pour établir ces scénarios, nous avons fait les hypothèses suivantes :

— on peut considérer une répartition des nœuds générique localement : on fait alors l’hypothèse que la répartition des nœuds varie peu par exemple entre deux zones résidentielles d’une ville à l’autre

— l’ensemble des protocoles de communication utilisés dans les réseaux de capteurs urbains peuvent se classer dans trois familles : à bande étroite, à bande intermédiaire et à large bande

— pour chaque application, la même famille de protocole de communication est utilisée Les nœuds décrits dans les Tables 5.6 et 5.7 seront implémentés sur les 22 USRP de la plateforme CorteXlab. Bien entendu, ils ne peuvent pas être directement implémentés avec un nœud par USRP : plusieurs nœuds seront implémentés par USRP afin d’atteindre le millier de capteurs décrits par les scénarios 1 et 2. Les sorties des chaînes d’émission étant stockées dans des fichiers avant d’être rejouées par les USRP, cela ne pose pas de problème de respect du temps réel. Le paramètre de la puissance totale émise par USRP est toutefois important : celle-ci étant limitée, plusieurs signaux forts ne pourront pas être émis en même temps. Ce fait sera à prendre en compte lors de l’implémentation des scénarios sur la plateforme CorteXlab.

La répartition des puissances reçues des signaux n’a pas été donnée pour ces scénarios. Celle-ci est en effet difficile à évaluer, puisqu’elle dépend des conditions de propagation des signaux en cas réel. Un travail est donc nécessaire pour trouver une fonction de répartition des puissances reçues qui soit conforme à ce qui est rencontré en cas réel.

5.3 Conclusions

Les deux architectures que nous avons proposées dans les chapitres 3 et 4 ont été compa-rées sur trois critères : la complexité, l’implémentabilité et la préservation de l’intégrité du signal. L’architecture à deux antennes semblant l’approche la plus viable, principalement en termes d’implémentabilité, c’est elle qui a été retenue pour des tests en expérimentations.

Pour effectuer ces expérimentations, une chaîne d’émission des signaux a été implémentée avec GNU Radio pour une émission par USRP. Ces signaux sont ensuite acquis et sauvegardés par VSA, puis leur plage dynamique est diminuée par l’architecture à deux antennes simulée sous ADS. La démodulation est finalement effectuée avec Matlab.

5.3. Conclusions

Des premières acquisitions ont permis de valider le modèle d’expérimentation : en mesu-rant le TEB et le SNR de signaux ayant été émis avec des puissances différentes, nous avons pu obtenir la réponse du TEB en fonction d’E_b/N0dans les conditions d’expérimentation et vérifier qu’elle restait conforme à la réponse théorique. Ce fait validé, la robustesse en dynamicité de l’architecture à deux antennes a été testée.

Cette étude de robustesse aurait pu être menée en simulations ; néanmoins le test en expérimentations a été retenu afin d’une part de privilégier un comportement des signaux plus réaliste, et d’autre part afin d’ouvrir la voie à une autre série future d’expérimentations. Plusieurs scénarios critiques ont été définis. Ces scénarios définissent le moment d’apparition ou de disparition des signaux afin d’évaluer l’incidence du temps de reconfiguration de l’architecture à deux antennes sur le nombre de bits de donnée perdus sur les signaux.

Les résultats de ces expérimentations sont très satisfaisants, puisqu’en moyenne seuls un peu plus de 9 bits sont perdus lors de la reconfiguration de l’architecture. En considérant que la taille des paquets sera en réalité au minimum de 400 bits, ces bits pourront facilement être retrouvés avec des techniques de codage, d’entrelacement ou avec de la redondance. Dans le cas où la reconfiguration de l’architecture a lieu pendant la réception du préambule du signal, le fait qu’il n’y ait que 9 bits erronés permet de s’assurer que la synchronisation s’effectuera correctement dans la plupart des cas, le préambule étant en pratique plus grand. Ces résultats permettent de conclure que l’architecture à deux antennes est suffisamment robuste pour réduire efficacement la plage dynamique des signaux émis dans un réseau de capteurs urbains.

Enfin, des scénarios d’émission représentant les pires cas d’émission dans un réseau de capteurs urbain ont été définis. Ces scénarios seront joués dans la salle CorteXlab afin de simuler la fonctionnement de l’architecture à deux antennes dans un réseau de capteurs réel et de démontrer ainsi que cette architecture peut être implémentée sur une passerelle de collecte. Les deux scénarios définis représentent des déploiements de capteurs dans une zone résidentielle et dans un parking. Les nombres de capteurs couvrant les différentes applications ont été évalués et un type de protocole de communication a été associé à chaque application.

Le travail restant consistera à évaluer les puissances d’émission pour chaque capteur (c’est-à-dire à définir une fonction de répartition des puissances reçues par type de protocole) et à porter ces scénarios sur la plateforme CorteXlab pour pouvoir réaliser cette expérimentation.