• Aucun résultat trouvé

5 Comparaison des deux architectures proposées et expérimentations

Chapitre 5. Comparaison des deux architectures proposées et expérimentations

5.2 Expérimentation avec CorteXlab

5.2.3 Dynamicité des signaux

On cherche maintenant à évaluer la robustesse de l’architecture à deux antennes en termes de dynamicité. En effet, une latence existe lors de la reconfiguration de l’architecture à deux antennes lorsqu’un signal fort apparaît ou disparaît. Celle-ci est principalement due, comme nous l’avons vu dans la section 4.3.3, au temps de mesure de la fréquence du signal fort.

Afin d’évaluer en pratique le nombre de bits perdus à cause de cette latence, nous avons établi plusieurs scénarios d’émission avec deux signaux, dans lesquels un signal fort apparaît ou disparaît en présence d’un signal faible. Le signal fort est émis avec une largeur de canal de 50 kHz, tandis que le signal faible est émis avec une largeur de canal de 200 kHz (ce qui permet de se conformer aux hypothèses faites dans la conception de l’architecture à deux antennes). Les différents scénarios que nous avons établis sont présentés sur la Table 5.3. Dans chacun d’entre eux, on part d’un état initial pour évaluer l’impact d’un changement amenant à un état final. Ce changement peut être soit l’apparition, soit la disparition d’un signal.

La robustesse de l’architecture se mesure au nombre de bits perdus lors de ce changement. Afin de garantir que tous les bits erronés à la réception soient dus à la reconfiguration de l’architecture à deux antennes, les signaux sont tous émis avec une puissance suffisamment haute pour que leur TEB soit nul sans reconfiguration de l’architecture.

Les scénarios 1 et 2 permettent d’évaluer le nombre de bits perdus lors de la reconfiguration de l’architecture dans les cas de l’apparition ou de la disparition du signal fort. Dans le scénario 3, le signal fort apparaît pendant le préambule du signal faible : on cherche à évaluer l’incidence de ce cas sur la synchronisation. Enfin, dans le scénario 4 le signal faible n’apparaît pas pendant la reconfiguration de l’architecture. Il permet de confirmer la bonne réception des paquets lorsque l’architecture est configurée de manière à réduire la plage dynamique.

Un premier test est fait suivant le protocole suivi dans la section 5.2.2.3 (voir Figure 5.10). La puissance (et donc le SNR) des signaux restera cette fois-ci la même pendant toutes les expérimentations sur la dynamicité. La puissance du signal fort est de Pmax− 10 dB tandis

Chapitre 5. Comparaison des deux architectures proposées et expérimentations

Scénario Signaux présents à l’état initial

Signaux présents

à l’état final Remarques

1 faible faible, fort Apparition du signal fort

2 faible, fort faible Disparition du signal fort

3 aucun faible, fort Apparition du signal fort pendant

le préambule du signal faible

4 fort faible, fort Apparition du signal faible

pendant le signal fort

TABLE5.3 – Scénarios conçus pour tester la robustesse de l’architecture à deux antennes à la dynamicité des signaux. Chacun évalue l’impact d’un seul changement dans la configuration des signaux. L’état initial décrit les signaux présents avant ce changement, et l’état final décrit ceux présents après ce changement.

que celle du signal faible est de Pmax− 30 dB. Cette plage dynamique de 20 dB est faible par rapport à celle considérée dans le reste de ce manuscrit : elle est choisie par rapport à la sensibilité du récepteur de VSA, dont le CAN ne permet bien évidemment pas d’absorber une plage dynamique de 100 dB. À cela s’ajoute la nécessité de transmettre les deux signaux avec une forte puissance afin de garantir que les erreurs détectées soient dues à la reconfiguration de l’architecture, et non au bruit.

Le critère évalué est maintenant le nombre de bits erronés par paquet. Les acquisitions du signal sont donc dimensionnées pour favoriser le nombre de paquets reçus. Elles se font sur une durée de 200 ms, soit sur 20 paquets de 548 bits. Avec 6 acquisitions pour chaque scénario, on garantit entre 114 et 120 paquets reçus par scénario. Cela représente entre 62 472 et 65 760 bits reçus.

Les résultats des expérimentations sur la robustesse en dynamicité de l’architecture sont donnés en Table 5.4. Le nombre de paquets reçus désigne le nombre de paquets sur lesquels on a pu se synchroniser pour décoder la donnée. Comme nous l’avons mentionné précédemment, lorsque l’acquisition des signaux avec VSA débute en milieu de paquet, celui-ci est perdu. Ce cas ne rentre pas en compte dans le taux de paquets non détectés, puisqu’il n’est pas dû aux performances de l’architecture elle-même. Le nombre de bits erronés (sur les paquets détectés uniquement) est également donné, ainsi que la moyenne du nombre de bits erronés par paquet.

On observe que le nombre moyen de bits perdus par paquet est sensiblement le même dans les deux premiers scénarios : 9,09 dans le premier cas et 9,32 dans le second. Cela nous permet d’affirmer que la cause de la reconfiguration de l’architecture (apparition ou disparition du signal fort) n’a pas d’impact sur le nombre de bits perdus. On observe toutefois un écart avec les 25,6 bits qu’il était prévu de perdre dans la section 4.4.4. Une partie de cet écart s’explique très facilement : pendant le temps de reconfiguration, le signal continue à être reçu même s’il n’est pas correctement démodulé. Le signal faible étant mal numérisé, les bits décodés ne correspondent pas à la donnée qu’il transportait. Le caractère aléatoire de ces bits explique cependant que seuls la moitié des bits qui devaient être perdus seront effectivement erronés (soit 12,8 bits). Le reste de l’écart s’explique par un autre facteur : le nombre de 25,6 bits correspond au nombre maximum de bits perdus, comme expliqué dans la section 4.4.4 : il

5.2. Expérimentation avec CorteXlab Scénario Nombre de paquets reçus Taux de paquets non détectés Nombre de bits erronés Nombre de bits erronés par paquet 1 118 0 % 1073 9,09 2 117 0 % 1091 9,32 3 104 12,6 % 949 9,13 4 118 0 % 0 0

TABLE5.4 – Résultats des expérimentations sur la robustesse en dynamicité de l’architecture. Les critères de robustesse sont le nombre de bits erronés par paquet pour tous les scénarios, ainsi que le taux de paquets perdus pour le scénario 3.

correspond au temps d’acquisition du signal nécessaire avant de faire la FFT. En réalité, le signal fort peut généralement être détecté avant ce délai : c’est le cas dès que sa contribution sur le spectre donné par la FFT est suffisante. Le nombre de bits erronés sera donc toujours inférieur à 12,8 bits.

Le troisième scénario nous montre l’impact de l’apparition du signal fort pendant le préambule du signal faible. Les bits perdus se trouvant sur le préambule, la synchronisation est affectée : on obtient un taux de perte de paquets de 12,6 %. Ce chiffre s’explique par le fait que sur les paquets reçus correctement, on observe un nombre moyen de bits erronés de 9,13, ce qui représente 19 % des 48 bits du préambule. Le chiffre de 12,6 % est donné ici à titre indicatif : il peut différer selon la qualité de la synchronisation (qui ne dépend pas de l’architecture à deux antennes). Ce résultat est néanmoins rassurant, puisqu’il signifie que suffisamment peu de bits sont erronés sur le préambule pour que le paquet soit reçu dans la plupart des cas.

Enfin, avec le quatrième scénario, aucun bit n’est erroné lors du test de TEB. C’est bien ce qui était attendu : lorsque le signal fort est atténué par l’architecture, les fréquences des oscillateurs peuvent légèrement varier (ces variations provenant de l’incertitude de la mesure de la fréquence du signal fort). Ces variations de fréquence sont donc sans conséquence sur la démodulation du signal faible.

Cette étude de la robustesse en dynamicité de l’architecture à deux antennes nous permet de conclure que cette architecture est suffisamment robuste à l’apparition ou à la disparition de signaux lorsque celle-ci a lieu simultanément à la réception d’un autre signal. En effet, si environ 9 bits sont perdus sur un paquet de 500 bits de donnée, ceux-ci seront aisément retrouvés à l’aide de l’entrelacement, du codage ou de la redondance mis en œuvre à l’émission (au détriment du temps de traitement). Dans [ETSI 11a], l’ETSI donne la taille des paquets émis par application. Les paquets les plus petits sont de 50 octets (soit 400 bits) dans le cas des capteurs dédiés à la gestion des déchets ou à la gestion des vélos en libre-service. Une perte de 9 bits sur un tel paquet représente une perte de 2,25 % des bits : ils pourront donc être retrouvés en utilisant du codage de canal, de l’étalement ou de l’entrelacement.

Dans le cas où le préambule du signal est affecté par la reconfiguration de l’architecture, le taux de réception des paquets dépend de la synchronisation mise en place. Dans notre cas, nous avons obtenu un taux de pertes de 12,6 % avec un préambule de 48 bits. Ce taux de pertes peut être amélioré en utilisant un préambule de plus grande taille. Ce préambule reste

Chapitre 5. Comparaison des deux architectures proposées et expérimentations Application Nombre de nœuds Périodicité (émissions par jour) Taille de la donnée (octets)

Télérelève de compteurs (eau) 37 500 1 200

Télérelève de compteurs (gaz) 37 500 96 100

Télérelève de compteurs (électricité) 37 500 6 250

Gestion des déchets 100 24 50

Surveillance de la pollution 150 24 1000

Alertes de pollution 20 96 5000

Gestion de l’éclairage public 200 1 20 000

Gestion des places de parking 80 000 24 100

Irrigation 200 2 100

Gestion des vélos en libre-service 500 96 50

TABLE5.5 – Besoins des applications en termes de données émises selon l’ETSI

représentatif de ce qui est rencontré dans les réseaux de capteurs urbains : l’IEEE 802.15.4k utilise par exemple un préambule d’au moins 56 bits dans son mode FSK. En mode DSSS, le préambule est optionnel. Il est donc compris entre 0 et 40 bits (avec un facteur d’étalement d’au moins 16 : un préambule de seulement 8 bits représente donc au moins 128 chips).

Il a été démontré que l’architecture à deux antennes était viable dans tous les cas critiques de réception de signaux. Il reste encore à démontrer son fonctionnement correct en cas réel : dans la suite, nous dimensionnons une expérimentation permettant de faire cela.

5.2.4 Perspective de la simulation d’un réseau de capteurs réel