Exercices du chapitre "Communication"

Technologies de communication sans fil (portée et débit)

Exercice 1

Situez les technologies BLE, Wi-Fi et Zigbee dans le diagramme ci-dessous. Indiquez également à quelles technologies peuvent correspondre le point jaune et le point bleu ?

Solution

Technologies de communication sans fil (applications)

Exercice 2

Complétez le tableau suivant afin de spécifier quelle technologie est adaptée à différents cas d’utilisation. Indiquez par un un scénario parfaitement adapté, par un les scénarios totalement inadaptés et par un les scénarios partiellement adaptés.

Cas d’utilisation	BLE	ZigBee	Wi-Fi	NFC
Contrôle à distance
Paiements sécurisés
Localisation
Verrouillage
Santé et fitness

Solution

Cas d’utilisation	BLE	ZigBee	Wi-Fi	NFC
Contrôle à distance
Paiements sécurisées
Localisation
Verrouillage
Santé et fitness

Technologie BLE

Exercice 3

Énoncez les différents types de paquets d’advertising. Expliquez les propriétés de ces paquets et les scénarios pour lesquels ils peuvent être utilisés.

Solution

Les différents types de paquets d’advertising sont donnés dans la figure [BLE PDU types]. Les propriétés des paquets sont affichés dans la table des propriétés affichée ci-dessus. Les scénarios d’utilisation sont :

ADV_IND (ou Connectable undirected advertising) : un périphérique comme un traceur d’activités ou une montre connectée qui veut indiquer sa présence à un smartphone, afin que celui-ci puisse établir une connexion.
ADV_DIRECT_IND (ou Connectable directed advertising) : un périphérique dont la connexion avec un central vient d’être perdue et qui veut permettre à celui-ci de rétablir rapidement la connexion.
ADV_NONCONN_IND (ou Non-connectable undirected advertising) : un broadcaster qui veut diffuser des informations à tous les observers qui sont à portée.
ADV_SCAN_IND (ou Scannable undirected advertising) : un broadcaster qui peut ainsi diffuser le double de données utiles vers les observers.
SCAN_REQ : envoyé par un observer ou un central qui souhaite obtenir un paquet SCAN_RSP du broadcaster/périphérique qui a émis un paquet de type ADV_SCAN_IND/ADV_IND.
SCAN_RSP : envoyé par un broadcaster/périphérique qui avait émis au préalable une paquet de type ADV_SCAN_IND/_ADV_IND, en réponse à un paquet _SCAN_REQ reçu.
CONNECT_REQ : envoyé par un central qui a reçu un paquet d’advertising ADV_IND ou ADV_DIRECT_IND afin d’établir une connexion avec celui-ci.

MQTT et topics

Exercice 4

Concevez des topics pour les applications suivantes:

Station météo connectée
Contrôle d’une habitation (domotique)
Messagerie de type WhatsApp

Expérimenter la technologie MQTT

Exercice 5

Installez un client MQTT sur votre PC. Je vous recommande MQTT Explorer pour commencer, mais vous pouvez installer des outils en ligne de commande (https://hivemq.github.io/mqtt-cli/, https://mosquitto.org/download/)
Par groupe de deux, choisissez un broker de test (par exemple test.mosquitto.org) ainsi qu’un topic (par exemple heiafr/isc-id-2/group/1/msg)
Le premier étudiant se prépare à recevoir les messages (par exemple en s’abonnant à heiafr/isc-id-2/#)¹
Le second étudiant publie un message dans le topic choisi

Défi : Envoyer “I Love Embedded Systems” sur le topic heiafr/isc/edu/<student name>/msg en remplaçant <student name> par votre nom

MQTT et encodage de la taille d’un paquet

Exercice 6

Comment est codée la taille pour un paquet de 1700 Bytes ?

Solution

a4 0d (\(13 \cdot 128 + 36\))

MQTT et décodage de la taille d’un paquet

Exercice 7

Écrivez le pseudo-code de la méthode qui permet de décoder une taille d’un paquet.

Solution

multiplier = 1
value = 0
do
    encodedByte = 'next byte from stream'
    value += (encodedByte AND 127) * multiplier
    if (multiplier > 128*128*128)
        throw Error(Malformed Remaining Length)
    multiplier *= 128
while ((encodedByte AND 128) != 0)

Port utilisé par MQTT

Exercice 8

Quel est le numéro de port utilisé par défaut par MQTT ?

Solution

1883

Analyse de traffic MQTT

Exercice Exercices du chapitre “Communication”/9

Démarrez “Wireshark” sur votre PC, capturez les paquets MQTT et publiez un message de plus de 128 Bytes vers un broker. Étudiez la capture regardez comment est codée la taille du paquet.

Faites le codage à la main et vérifiez que vous obtenez la même chose

Solution

if=/dev/urandom bs=1 count=1672 | \
  mosquitto_pub -h test.mosquitto.org \
  -t heiafr/isc-2rs/group/1/msg -s

Expérimenter la technologie CoAP

Exercice 10

Installez coap-cli comme une command line interface pour CoAP. Les instructions pour l’installation sont disponibles sur CoAP-CLI. L’utilisation de coap-cli nécessite l’installation de node.js.
Après installation de l’outil, vous pouvez taper
```
coap --version
```
L’exécution devrait se passer sans problème et le texte de la version de l’outil devrait s’afficher (par ex. 0.11.1).
Vous pouvez ensuite faire votre premier appel à un serveur CoAP en tapant
```
coap get coap://californium.eclipseprojects.io:5683
```
Le code de la réponse devrait être 2.05 (réponse Content à une requête GET) et le contenu devrait être un texte générique décrivant le serveur. Le message affiché dans la console est composé du code de la réponse, suivi du payload du message. Afin de comprendre le format exact du message (y.c. des options), vous devez utilisez Wireshark.
CoAP réalise un mécanisme de découverte des ressources disponibles sur un serveur. Afin d’obtenir les ressources, il faut interroger la resource “.well-known/core”.
```
coap get coap://californium.eclipseprojects.io:5683/.well-known/core
```
Le code de la réponse devrait être 2.05 (réponse Content à une requête GET) et le payload devrait être une description des ressources disponibles dans le CoRE Link Format.
Choisissez la ressource « multi-format » et observez le trafic à l’aide de WireShark (vous pouvez filtrer le trafic avec le mot clé “coap”). Veuillez noter que le contenu de la réponse est une version textuelle des propriétés du message CoAP.
```
coap get coap://californium.eclipseprojects.io:5683/multi-format
```
Cette ressource peut délivrer des réponses au format “text/plain” ou “application/xml”. Comme la requête ne précise pas le contenu accepté, la réponse du serveur indique le code 2.05 (cela pourrait être 4.06). Le payload de la réponse est dans le Content-format “text/plain”, mais la réponse indique toutefois que l’option “Accept” de la requête est “-1”.
Afin d’ajouter le format accepté de la réponse, la requête doit ajouter une option CoAP Accept. L’option est l’option 17 et la valeur du media-type accepté peut être soit 0x00 (“text/plain”) ou 0x29 (“application/xml”) :
```
coap --coap-option 17,0x00 get coap://californium.eclipseprojects.io:5683/multi-format
```
Testez les deux formats (0x00 et 0x29), observez le contenu des requêtes et réponses à l’aide de Wireshark.
Par défaut, les requêtes effectuées sont des requête CON. Cela signifie que le MID de la requête et de le quittance (ou de la réponse piggybacked) doivent correspondre. Vérifiez ce comportement avec Wireshark.

Effectuez une requête NON et observez le trafic :

coap --non-confirmable --coap-option 17,0x00 get coap://californium.eclipseprojects.io:5683/multi-format

Afin de bien comprendre la notion de réponse piggybacked, effectuez une requête sur la ressource “separate” qui délivre la quittance et la réponse dans deux messages différents :
```
coap get coap://californium.eclipseprojects.io:5683/separate
```
Dans toutes les requêtes faites jusque-là, observez les valeurs des MID et des tokens des requêtes et des réponses.

CoAP et encodage des numéros d’options

Exercice Exercices du chapitre “Communication”/11

Répondez aux questions suivantes:

Dans l’encodage des numéros d’options, pourquoi avoir utilisé 13 et 14 et non 14 et 15 ?
A quoi sert alors la valeur 15 ?
Quel est l’intérêt de l’encodage par delta ?

Solution

La valeur 15 est utilisé comme marker pour détecter le début du payload (et donc la fin des options). Si la valeur 15 était aussi utilisé pour le delta dans l’encodage des numéros d’options, il ne serait pas possible de distinguer entre un marker et un delta.
L’encodage par delta permet d’encoder le numéro et la taille de l’option avec le minimum de bytes en fonction de la taille des deux champs, tout en étant très facile à coder et décoder.

Message CoAP

Exercice 12

Un message CoAP contient les options suivantes. Expliquer toutes les options contenues dans ce message avec leur valeur et leur signification. Calculer la taille totale des options.

Coap Option Example — Example d’options pour un message CoAP

Solution

Les options du message sont (dans l’ordre) :

option avec le nombre 11 et taille 7: Uri-Path, valeur “example“
option avec le nombre 11 et taille 4: Uri-Path, valeur “post“
option avec le nombre 12 et taille 0: Content-Format, valeur 0 = “text/plain“
option avec le nombre 60 et taille 2: Size1, valeur = 300

Les options occupent 18 octets.

Traffic CoAP

Exercice 13

Poursuivez le premier exercice permettant d’analyser le traffic CoAP afin de comprendre et d’analyser d’autres options, sur la base de la description des ressources obtenue dans l’exercice précédent :

“Uri-Path” : formulez une requête contenant au moins deux options répétées “Uri-Path”.
“Uri-Query” : formulez une requête contenant au moins deux options répétées “Uri-Query”.
Formulez une requête afin de créer une ressource “large-create” avec un body content au format “application/json”. Observez la réponse et comprenez la signification de l’option “Location-Path”. Formulez une requête afin d’obtenir une représentation de la ressource que vous venez de créer.

Solution

“Uri-Path” :

coap get coap://californium.eclipseprojects.io:5683/path/sub1

“Uri-Query” :

coap get "coap://californium.eclipseprojects.io:5683/query?sub1=1&sub2=1"

Creation :

coap post --coap-option 12,0x00 --payload "This is a test" coap://californium.eclipseprojects.io:5683/large-create

La réponse contient deux options “location-path”, qui spécifient le chemin de la ressource créée. Exemple pour obtenir la ressource :

coap --coap-option 17,0x00 get coap://californium.eclipseprojects.io:5683/large-create/1

Traffic CoAP et observation

Exercice 14

Poursuivez l’exercice précédent permettant d’analyser le traffic CoAP afin de comprendre le mécanisme d’observation :

Choisissez la ressource “obs” et effectuez une requête d’observation sur cette ressource. Observez les messages transmis dans Wireshark, en particulier le contenu des options “observe”.
Faîtes de même avec la ressource “obs-non”. Observez les différences en rapport avec la ressource “obs”.

Solution

“obs” :
```
coap --coap-option 17,0x00 --observe get coap://californium.eclipseprojects.io:5683/obs
```
Un message CON est envoyé à un intervalle de 5 secondes du serveur vers le client. Le client quittance le message avec un message vide.
“non-obs” :
```
coap --coap-option 17,0x00 --observe get coap://californium.eclipseprojects.io:5683/obs-non
```
Un message NON est envoyé à un intervalle de 5 secondes du serveur vers le client. Le client ne quittance pas. A intervalle régulier, le serveur envoie un message CON afin de vérifier si le client est toujours présent. Si le client interrompt la réception des messages, le serveur va envoyer plusieurs messages CON (y compris quelques retransmissions), puis il cessera d’envoyer des messages.

Avec MQTT Explorer, lorsque vous configurez la connexion, vous devez cliquer sur “ADVANCED” et configurer l’abonnement (Subscription) ↩