• 20 hours
  • Hard

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 12/12/19

Trouvez et interrogez des objets

Log in or subscribe for free to enjoy all this course has to offer!

Protocoles et IoT

Pour transporter l’information, un protocole de communication est nécessaire pour que les différentes entités se mettent en accord sur les moyens d’échange.

HTTP : Hyper Text Transfer Protocol

Le protocole HTTP, bien connu pour naviguer sur le Web, est utilisé dans l’IoT. Ce dernier se base sur la couche réseau TCP et est dit connecté, c’est-à-dire qu’il maintient une connexion entre les deux entités. De plus, il définit des opérations telles que GET, POST, PUT, DELETE qui permettent de caractériser le but de la requête en cours. Il est combiné avec une URI qui détermine à quelle ressource on souhaite envoyer sa requête. On a aussi des headers qui permettent, par un système clé/valeur, de donner des options à la requête que l’on est en train de faire.

CoAP : Constraint Application Protocol

Un deuxième protocole utilisé est CoAP pour Constraint Application Protocol. Ce protocole ne se base pas sur TCP, mais UDP pour ne pas être connecté. Cela a pour avantage de moins surcharger le réseau, mais ne fournit pas autant de fiabilité que TCP. Cette fiabilité est tout de même assurée par le protocole CoAP. Il fournit lui aussi 4 opérations pour spécifier les requêtes, ainsi qu’une URI.

MQTT : Message Queue Telemetry Transport

Comparé aux deux premiers protocoles qui sont orientés requête/réponse, le troisième protocole utilisé par le standard oneM2M, MQTT, est basé sur un système publier/souscrire. Cela signifie qu’un client s’inscrit à des sujets, et des producteurs de contenus vont publier des données sur ces sujets. Ainsi, ce protocole permet de transmettre une information à de nombreux utilisateurs en même temps, comme une valeur de température. En revanche, un médiateur (broker en anglais) doit être utilisé pour gérer l’inscription et la publication sur les objets. De plus, le système d’opération n’est pas présent en MQTT.

Ces trois protocoles permettent ainsi de réaliser la communication entre l’utilisateur et une plateforme oneM2M.

Cela passe par une notion d’adressage qui permet à une requête de viser une ressource en particulier pour la récupérer, la mettre à jour ou la supprimer, par exemple.

Adressage

Dans le standard oneM2M, il existe 2 types d’adresses qui sont utilisés pour représenter une ressource. Que l’on utilise l’un ou l’autre amène forcément à la même donnée. Nous allons voir ce que représentent ces adresses avec les deux types d’adressage : un hiérarchique, basé sur le nom des ressources ; un non-hiérarchique, basé sur des identifiants uniques.

L’adressage hiérarchique
Le premier système d’adressage est l’adressage hiérarchique. Le patron est le suivant :

/~/<cse-id>/<cse-name>/<resource-name>

On retrouve d’abord un tilde, qui est spécifique à oneM2M, puis le CSE-ID. Cet identifiant est unique au CSE auquel on s’adresse et est souvent donné par le système. Le CSE-Name correspond au nom de la ressource représentant le CSE auquel on s’adresse. Enfin, la partie finale du patron correspond à la suite des noms de ressources de manière hiérarchique, séparés par des slashs. Ainsi, on peut facilement construire cette URI en connaissant la hiérarchie des ressources.

Un exemple d’URI hiérarchique est :

/~/in-cse/in-name/AE_1/DATA

L’adressage non hiérarchique
Le deuxième système d’adressage est non hiérarchique ou plat. Il est plus court et permet de limiter la taille de la requête, mais ne reflète pas la hiérarchie des ressources. Il est basé sur un attribut des ressources, le « resource-id ». Ce dernier est court et unique dans le système. Il est généré automatiquement par la plateforme oneM2M à la création de la ressource.

Le patron de système d’adressage est :

/~/<cse-id>/<resource-id>

Ainsi, la même ressource que dans l’exemple précédent peut être aussi adressée par l’URI suivante :

/~/in-cse/cnt-456789321

Notion de Point d’accès

L’attribut Point of Access

Une fois l’URI de la ressource construite, on peut envoyer la requête à la plateforme grâce à un protocole de communication. Mais une instance de plateforme peut ne pas supporter tous les protocoles cités précédemment. Pour connaître les différents points d’accès disponibles, un attribut nommé PoA, pour Point of Access, liste les différents protocoles avec les adresses et ports accessibles. Un utilisateur ou un programme peut ainsi savoir comment accéder à un réseau oneM2M et par quels protocoles.

Un PoA est donné de la façon suivante :

<protocole>://<ip>:<port>

On peut avoir, par exemple :

http://mon-nom-de-domaine.com:8080

ou encore :

coap://mon-nom-de-domaine.com:5683

La notion de redirection

De plus, un utilisateur ou un programme n’a à connaître qu’un seul point d’entrée dans le réseau oneM2M. En effet, un mécanisme de redirection est mis en place par le standard. Cela signifie qu’une plateforme oneM2M recevant une requête qui ne lui est pas directement destinée va rediriger celle-ci vers le bon nœud destinataire.

Ainsi, si on envoie une requête GET vers l’IN-CSE, mais qui pointe vers une ressource du MN-CSE, comme on peut le voir sur la figure suivante, la plateforme va s’occuper de rediriger la requête vers le MN-CSE.

Figure 1 - Exemple de redirection d'un client HTTP visant le MN-CSE en envoyant sa requête à l'IN-CSE

On constate même que la redirection peut se faire en CoAP si nécessaire, car le MN-CSE peut n’avoir que le CoAP comme protocole de communication. Il va ensuite répondre à l’IN-CSE avec le contenu qui sera lui-même redirigé vers le client.

Example of certificate of achievement
Example of certificate of achievement