Impact des objets sur les protocoles de l’Internet

07/06/2013
Auteurs :
Publication REE REE 2013-2 Dossier L'avenir d'Internet
OAI : oai:www.see.asso.fr:1301:2013-2:4377

Résumé

Impact des objets sur les protocoles de l’Internet

Métriques

12
4
461.35 Ko
 application/pdf
bitcache://e96fa76ccdd4c79ab2368c0dd58eccd25046be6a

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1301:2013-2/4377</identifier><creators><creator><creatorName>Yannick Delibie</creatorName></creator><creator><creatorName>Alexander Pelov</creatorName></creator><creator><creatorName>Laurent Toutain</creatorName></creator></creators><titles>
            <title>Impact des objets sur les protocoles de l’Internet</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2013</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Fri 7 Jun 2013</date>
	    <date dateType="Updated">Thu 26 Jan 2017</date>
            <date dateType="Submitted">Fri 13 Jul 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">e96fa76ccdd4c79ab2368c0dd58eccd25046be6a</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>28823</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

36 REE N°2/2013 L'AVENIR D'INTERNET Yannick Delibie1 , Alexander Pelov2 , Laurent Toutain2 Kerlink SA1 , Télécom Bretagne2 Introduction L’Internet des objets est un des secteurs des télécommunications qui devrait voir la plus forte croissance dans les années à venir. Certaines pré- visions évoquent 50 milliards d’objets connectés à l’horizon des années 2020. Mais le terme Internet des objets est quelque peu ambigu. Si l’Internet est une technologie qui a fait ses preuves, elle n’est pas complètement adaptée à la capillarité des ré- seaux connectant les objets. Un effort d’adaptation est nécessaire pour prendre en compte le nombre très important d’objets à gérer, qui ont souvent des contraintes énergétiques fortes et des capacités de traitement limitées. Il faut également intégrer le fait que les informations auxquelles donnent accès ces objets sont parfois de nature intrusive ou qu’une action sur ceux-ci peut avoir des conséquences vitales. Néanmoins le terme d’Internet des objets, reflète l’idée de faire remonter des informations du monde réel (ou de lui transmettre des instructions) vers des (à partir de) systèmes informatiques en utilisant les technologies les plus génériques possibles et en offrant la plus grande interopérabilité afin de mettre en œuvre des services innovants. Elle s’oppose à des approches propriétaires et fermées, même s’il faut, de toute façon, les prendre en considération puisque la durée de vie d’un objet peut être supérieure à une dizaine d’années, alors que les protocoles utilisés dans les réseaux peuvent suivre un cycle d’évolution plus court. Un grand nombre de domaines nouveaux du point de vue du réseau des réseaux sont potentiel- lement concernés par l’Internet des objets. Il fédère les applications liées à la domotique, à la télérelève de compteurs ou plus généralement aux smart grids qui intègrent un plan de commande informatique aux réseaux de distribution électrique, aux réseaux indus- triels en remplacement de protocoles propriétaires, voire aux transports intelligents, aux vêtements intel- ligents, etc. L’Internet des objets peut être aussi vu comme une démocratisation de l’utilisation du réseau, par une diminution drastique des coûts de communica- tion. En effet, même si certains concepts sont dans les esprits depuis des années (comme le distributeur de boissons connecté, le relevé de compteurs à dis- tance, ou la domotique, etc.), le coût du matériel de communication et les transmissions associées annihi- laient tout espoir de succès commercial possible de ces solutions. Approche historique La principale force de l’Internet actuel, que l’on peut appeler Internet des contenus, est d’offrir un écosystème cohérent et ouvert, facilitant l’intercon- nexion des équipements et favorisant la création et le déploiement de nouveaux services. Un retour sur l’histoire d’Internet permet de mieux comprendre pourquoi les protocoles IP (Internet Protocol) se sont imposés face à d’autres protocoles qui semblaient mieux adaptés à leur environnement. Ce phénomène pourrait se reproduire pour l’Internet des objets. Impact des objets sur les protocoles de l’Internet Internet of Things is a new challenge for the network industry; the traditional Internet did not take into consideration new constraints such as protocol energy consumption or code footprint. This article presents the needs for open standards to create innovative services. Architecture and protocols proposed by IETF are then presented. Theses protocols are currently deployed or integrated in some platforms or industry standards. ABSTRACT REE N°2/2013 37 Impact des objets sur les protocoles de l’Internet Les protocoles de la famille IP n’ont jamais été les meilleurs, comparés à des protocoles plus spécifiques. Ainsi dans les an- nées 80, quand IP s’est imposé face à d’autres technologies comme Frame Relay ou ATM, on lui reprochait son principe de Best Effort face à des approches plus sophistiquée permettant d’offrir des classes de services ou une plus grande fiabilité des transmissions. A la même époque, le déploiement d’IP s’est généralisé dans les réseaux d’entreprise au détriment de solu- tions plus facilement administrables comme IPX ou NetBIOS. Il faudra attendre l’arrivée d’IPv6 pour retrouver des concepts comme l’auto-configuration des équipements à partir d’infor- mations diffusées par le réseau. On pourrait multiplier les exemples pour la téléphonie sur IP ou la télévision connectée. Les fonctionnalités offertes par IP sont souvent inférieures à celles offertes par des solu- tions propriétaires ou déployées pour résoudre un problème spécifique. Cependant, l’Internet Protocol s’est imposé, en partie, du fait des progrès techniques qui ont apporté une augmentation des vitesses de transmission et ont contribué à l’amélioration de la qualité de service, mais également parce qu’il était préférable d’avoir un protocole unique réduisant les coûts des équipements. Ceci a favorisé le développement de circuits dédiés facilitant la maintenance et l’administration du réseau. Enfin, le protocole IP a toujours favorisé l’intercon- nexion et permis d’offrir des services de plus en plus évolués exécutables sur un grand nombre de types d’équipements. Cette dernière propriété permet de mettre à profit la loi de Metcalfe où la valeur (c’est-à-dire l’intérêt) d’un réseau varie comme le carré du nombre de ses utilisateurs. Si le protocole d’interconnexion IP (dans sa version initiale IPv4) a permis de simplifier l’interconnexion de différents équipements, les années 90 ont vu une remise en cause de ce modèle. Le succès d’Internet a conduit à une pénurie d’adresses qui ne sera résolue que par la mise en œuvre du protocole IPv6. Des mécanismes comme la traduction d’adresses (NAT)1 ont fait baisser la pression sur la demande de nouvelles adresses, reportant la pénurie visible vers 2015. Les contraintes d’utilisation des réseaux translatés (NAT) sont néanmoins acceptables pour les utilisateurs et les adminis- trateurs. De ce fait, le réseau est devenu très attractif pour les services et les accès aux données. Contrairement à l’Internet des contenus, où tous les mail- lons de la chaîne doivent parler IPv6 pour mettre en œuvre ce protocole, l’Internet des objets propose des architectures où seule une partie des équipements (les capteurs/actionneurs) sont dotés des capacités d’adressage et d’auto-configuration de la nouvelle version du protocole IP. Des passerelles per- 1 Network Address Translation : mécanisme assuré par un équipement d’interconnexion qui permet l’utilisation de préfixes privées, communs. mettront de s’interconnecter facilement avec l’Internet actuel. Nous présenterons dans la suite ces architectures basées sur le concept REST2 . Limites du protocole IP La complexité de l’Internet des objets ne provient pas uniquement de l’accroissement de la taille du réseau. Il peut remettre en question le modèle d’origine où tous les équipe- ments parlent le même langage. En effet, un facteur impor- tant à prendre en compte est la durée de vie des produits qui participent à l’Internet des objets. L’informatique moderne est soumise à une obsolescence rapide des produits et des pro- tocoles. Certains objets peuvent avoir une durée de vie nette- ment plus grande ; un compteur électrique ou d’eau est installé pour au moins 20 ans ; un capteur enfoui dans les murs d’un bâtiment ne peut pas être facilement changé, voire mis à jour. Si l’on veut dès maintenant déployer un Internet des objets, il faudra y intégrer un existant qui ne parle pas encore IP. Il existe aussi des contraintes ignorées par le monde IP. Ainsi la consommation d’énergie n’a pas été prise en compte dans le développement des protocoles ; ceux-ci sont géné- ralement assez bavards et émettent périodiquement des données pour surveiller leur environnement et réagir en cas de panne. Un compteur d’eau ne dispose généralement pas d’une alimentation électrique à proximité, pourtant il doit pouvoir fonctionner quelques dizaines d’années, alimenté par une batterie sans possibilité de la recharger ou de la changer. En règle générale, la transmission et la réception de données sont les processus les plus énergivores. Afin de garantir la durée de fonctionnement de ces équipements, les méca- nismes de transmission de données doivent être autant que possible déterministes. De ce fait, le comportement des piles de protocoles ne doit pas dépendre de leur environnement externe. Il convient donc de bannir les modes de fonction- nement non déterministes, comme par exemple l’établisse- ment de routes ou relais dynamiques ou encore la détection préventive de collision. De par la nature asymétrique des transmissions, la réception est souvent plus consommatrice que l’émission. Car les données étant émises de manière asynchrone, l’ensemble des équipements doivent écouter en permanence le canal pour détecter une transmission. La transmission passe par deux types de topologies : des distances de plusieurs dizaines de kilomètres, les débits sont relativement faibles et le canal doit être très peu char- gé pour limiter la probabilité que plusieurs équipements émettent simultanément et se brouillent mutuellement 2 REpresentional State Transfer : style d’architecture appliquée dans World Wide Web et ses protocoles. 38 REE N°2/2013 L'AVENIR D'INTERNET (collisions). En contrepartie, ces techniques demandent peu de gestion du réseau et le nombre de points d’accès est très réduit pour couvrir une région. Certaines de ces technologies sont unidirectionnelles, des capteurs vers le concentrateur ; servir de relais à l’information. Cette topologie impose la mise en œuvre de protocoles sur l’ensemble de ces nœuds relais pour pouvoir aiguiller les données vers la destination, d’où une consommation de ressources (mémoire, énergie) supplémentaire sur ceux-ci. En contrepartie, elle permet de joindre des équipements non directement accessibles, comme par exemple ceux situés dans un sous-sol et d’ob- tenir des débits plus élevés. La pile protocolaire d’IP n’a jamais pris en compte les contraintes liées à la capacité mémoire nécessaire à sa mise en œuvre. Elle est cependant très faible comparée aux ca- pacités des mémoires des ordinateurs actuels. Par contre, lorsque l’on s’aventure dans le monde des systèmes embar- qués, il faut pouvoir la faire tenir sur quelques dizaines de kilo-octets. La loi de Moore, indiquant que la puissance des processeurs double tous les 18 mois, doit être lue sous un autre angle. Elle va principalement induire une diminution des coûts, indispensable pour un déploiement massif des équipements, plutôt qu’une augmentation des puissances de traitement et des capacités des composants. Protocoles de l’Internet des objets La figure 1 montre la pile protocolaire pour les objets com- municants. Les couches basses, en gris foncé sur le schéma, comme IEEE 802.15.4 (utilisé également par ZigBee) ou Bluetooth sont normalisées par divers organismes comme par exemple l’IEEE. Les protocoles concernant IP, en gris moyen sur le schéma, reposent sur des standards de l’IETF. Les profils applicatifs, en gris clair sur le schéma, sont définis par d’autres organismes comme l’IPSO (IP for Smart Objects). A la base, on trouve les différents protocoles de niveau 2. En plus des protocoles traditionnels comme Ethernet ou Wi-Fi, on trouve des protocoles adaptés au monde des objets com- municants. Il est illusoire de n’avoir qu’une seule technologie de niveau 2. En effet, chaque protocole de niveau 2 possède ses spécificités propres et les besoins couverts ne sont pas les mêmes. Certains services vont demander une portée impor- tante tandis que d’autres nécessiteront un débit plus élevé, ou encore une qualité de service accrue. Sur la figure 1, sont cités à titre d’exemple, IEEE 802.15.43 ou PLC4 , mais d’autres technologies sont possibles, qu’elles soient radioélectriques ou filaires, comme par exemple Blue- tooth Low Energy, Wi-Fi (IEEE 802.11). Une version d’IPv6 adaptée aux réseaux contraints : 6LoWPAN5 Au-dessus de ces technologies de niveau 2 on trouve la pile IPv6 traditionnelle définie dans le RFC 2460 ou une version compressée de celle-ci adaptée aux réseaux contraints appelée 6LoWPAN (RFC 4944 et 6282) [1]. On retrouve ici, un des intérêts d’IP qui est d’offrir une couche d’abstraction entre les applications et les niveaux 2 permet- tant d’uniformiser les développements. IPv6 est choisi car il permet une gestion plus simple des adresses et offre de l’auto-configuration. Si le mode en étoile n’est pas privilégié, soit à cause du peu de débit qu’offre cette technologie, soit à cause de la portée, il faut mettre en place un relayage de l’information émise par un nœud pour qu’elle atteigne son destinataire. 6LoWPAN propose deux modes de fonctionnement qui pré- sentent des similitudes, mais conduisent à des comporte- ments sensiblement différents : mesh-under cache au maximum à la couche IP les particularités d’un réseau mettant en œuvre le relayage. On peut l’assimiler à la création d’un réseau de niveau 2 sous- jacent. 6LoWPAN offre des supports pour les fonctions d’inondation de l’ensemble du réseau pour les messages de diffusion et les en-têtes permettant le relayage de nœud en nœud vers la destination. Par contre la manière de trou- ver ces routes n’est pas spécifiée par le standard ; 3 Protocole défini par l’IEEE pour les réseaux sans fil à bas débit du type LoWPAN (Low Rate Personal Area Network). 4 Power Line Communication : technique de communication par cou- rants porteurs sur le réseau électrique. 5 IPv6 over Low power Wireless Personal Area Networks. Figure 1 : Pile protocolaire définie par l’IETF pour les objets communicants. REE N°2/2013 39 Impact des objets sur les protocoles de l’Internet route-over considère que les nœuds sont des rou- teurs6 ; dans ce cas le réseau va router des adresses plutôt que des préfixes. Les nœuds doivent donc mettre en place un protocole de routage qui est expliqué au paragraphe suivant. Un protocole de routage adapté : RPL7 Les protocoles de routage déjà définis par l’IETF ne conve- naient pas à des réseaux dont les liens ne sont pas stables. Ain- si, le plus simple, RIP est beaucoup trop bavard et ne converge pas rapidement ce qui conduit à la formation de boucles. Les protocoles utilisés dans les cœurs de réseau (OSPF, IS-IS) reposent sur une vision commune de la topologie qui n’est pas compatible avec des liens changeant rapidement d’états. Même, si les protocoles conçus pour les réseaux ad-hoc se rapprochent plus des conditions induites par les liens instables, ils prennent peu en compte les contraintes énergétiques8 . Un nouveau protocole RPL a donc été défini par l’IETF : son acronyme et surtout sa prononciation évoquent une vaguelette (ripple) se propageant sur le réseau. Les principes de RPL se veulent indépendants d’un envi- ronnement particulier. Il n’existe pas un document unique dé- crivant le routage dans ce type de réseau, la figure 2 reprend les standards essentiels. Les fondements algorithmiques et protocolaires de RPL sont décrits dans le RFC 6550. En effet, en étudiant différents types de réseaux et leurs contraintes de routage (listées dans des RFC décrivant des environne- ments spécifiques urbains, industriels, domestiques…), il est apparu que les trafics directs entre les nœuds du réseau ne sont pas majoritaires, donc dans les versions de base du pro- tocole RPL on ne cherchera pas à les optimiser. 6 Il peut exister des nœuds feuilles qui ne participent pas au relayage, mais sont source ou destinataire du trafic. 7 Routing Protocol for Low Power and Lossy Networks. 8 Seule une simplification d’AODV (Ad-hoc On demand Distance Vector), appelée LOAD offre de bonnes performances, mais elle se positionne plutôt pour les architectures mesh-under. Le standard de base (RFC6550) décrit un mécanisme gé- nérique basé sur les DoDAG (Direction Oriented Directed Acy- clic Graph), il s’agit d’une extension de la notion d’arbre dans laquelle plusieurs chemins peuvent mener vers une racine. Le fait d’avoir plusieurs chemins pour atteindre la racine se justifie par la qualité des liens pouvant fluctuer durant la vie du réseau. RPL cherche aussi à réduire le nombre de messages émis. RPL est un protocole pro-actif, c’est-à-dire que les routes vers la racine ou de la racine vers les nœuds sont mises en place avant tout trafic. Il est de la famille des vecteurs de distance, c’est-à-dire qu’une valeur abstraite appelée rang donne la distance d’un nœud par rapport à la racine. Un nœud choisit toujours comme parent(s) les nœuds annon- çant les rangs les plus petits. Quand le réseau est stable, les annonces de routage s’espacent pour permettre de meil- leures performances énergétiques (algorithme trickle). Les fonctions d’objectif permettent d’adapter le comporte- ment générique à un environnement particulier et de préciser plus finement les règles de construction du DoDAG [2]. Une fonction d’objectif peut spécifier le nombre de parents qu’un nœud peut posséder, comment les métriques peuvent être converties en rang. Une fonction d’objectif de base OF0 basée sur la qualité des liens, ainsi qu’une plus complexe (MRHOF) basée sur des métriques comme l’énergie disponible dans les nœuds ont été définies. D’autres fonctions d’objectif pourront l’être pour adapter RPL à un environnement particulier. Prolongement des web objects vers les capteurs : CoAP 9 L’architecture REST est très utilisée dans l’Internet, elle est à la base de services comme le World Wide Web. Elle repose sur des principes très simples qui favorisent l’interconnec- tivité. Le premier principe est le nommage des ressources, celles-ci utilisent un format en mode caractère appelé URI (Universal Resource Identifier). Le deuxième principe est l’utilisation du mode client/ser- veur. Un serveur est celui qui possède la ressource. Avec l’ar- chitecture Web, on a tendance à assimiler un serveur à une machine de taille imposante, mais dans le cas de l’Internet des objets il peut s’agir d’un élément d’une capacité de traite- ment très limitée. Le client est l’équipement qui interagit avec le serveur, l’architecture REST définit quatre interactions : de la primitive GET ; - veur, ceci est fait par une primitive PUT ; 9 CoAP : Constrained Application Protocol. Figure 2 : Standards de l’IETF liés à RPL. 40 REE N°2/2013 L'AVENIR D'INTERNET DELETE. Enfin les réponses aux requêtes peuvent être stockées temporairement sur des relais intermédiaires (également ap- pelés caches) et donc permettent l’utilisation de proxy pour interconnecter deux domaines. Le protocole HTTP est un moyen de mettre en œuvre cette architecture, mais ce protocole est très gourmand en ressources. Il s’appuie sur TCP qui est le protocole de trans- port le plus utilisé sur Internet. Celui-ci permet de fiabiliser les transmissions en détectant les erreurs de transmission et en réémettant les paquets perdus et également de mettre en œuvre un contrôle de flux permettant d’adapter la vitesse de transmission aux capacités du réseau. Malheureusement, ce protocole demande beaucoup de ressources et en particulier de mémoire pour stocker les données en attente de leur acquittement : or, dans l’environnement de l’Internet des ob- jets, les serveurs n’ont généralement de la place en mémoire que pour un seul paquet, rendant sa mise en œuvre ineffi- cace. Le format des en-têtes HTTP est relativement libre, ce qui permet une grande évolutivité, par contre leur traitement demande également des ressources importantes. Le protocole CoAP [3], [4] permet de lever les limitations d’HTTP en milieu contraint tout en assurant une forte com- patibilité avec l’existant. Il est relativement facile de transfor- mer des requêtes HTTP en requêtes CoAP. Un équipement « ancien » connecté à un réseau IPv4 peut très bien deman- der d’accéder à une ressource sur un serveur connecté à un réseau IPv6 et une passerelle assure la traduction entre les deux mondes. Ainsi du côté d’un réseau de capteurs, on peut utiliser la pile protocolaire CoAP/UDP/6LoWPAN pour les propriétés d’auto-configuration d’IPv6 et la faible taille de la pile, et du côte Internet on gardera la pile HTTP/TCP/IPv4 qui est pré- sente sur tous les équipements. Si, par exemple, un iPhone veut connaître la température relevée par un capteur, il en- verra sa requête en HTTP, celle-ci sera transformée en CoAP par une passerelle, et la réponse pourra être stockée pen- dant une durée spécifiée par le capteur dans la passerelle. Si un autre équipement sur Internet demande la même valeur pendant cet intervalle de temps, il ne sera pas nécessaire de propager la requête jusqu’au capteur. CoAP considère ces caches comme des bases de don- nées où les informations pourront être stockées pendant leur période de validité. De cette manière, on rend asynchrone les requêtes du client et le remplissage des caches par les serveurs. Un des rôles des organismes de normalisation est de nommer de manière universelle ces ressources, de leur associer une ontologie définissant sans ambiguïté leur conte- nu (les valeurs mesurées, leurs unités, etc.) ainsi qu’une représentation universelle de ces valeurs. Adoption des protocoles de l’IETF Différents acteurs industriels sont en train d’adopter les architectures conçues par l’IETF. Les travaux de standardisa- tion sont repris par plusieurs organismes ou alliances pour les appliquer à des environnements particuliers. Les principales sont décrites rapidement dans ce chapitre. L’alliance ZigBee a abandonné les profils propriétaires pour des profils standards pour la gestion de l’énergie dans un domicile. Via l’alliance IPSO, des formats de ressources REST sont définis pour gérer des équipements (allumer une lampe, relever un compteur électrique, etc.) afin de permettre une plus grande interopérabilité entre les équipements. L’ETSI a également retenu une architecture basée sur REST pour les communications M2M10 . [5] Son approche est à plus grande échelle car elle vise à utiliser les réseaux de communi- cation actuels 3G, LTE, ... pour collecter des données sur des passerelles favorisant une approche horizontale ; les réseaux sont génériques et indépendants des applications et la pas- serelle sert à la fois au stockage des informations reçues des capteurs via les protocoles de l’IETF ou plus anciens et à la gestion des droits d’accès. Ces familles de protocole se retrouvent aussi dans les architectures de smart grid. Ainsi en France, Linky, le nou- veau compteur intelligent d’ERDF utilise une communica- tion via le réseau de distribution électrique (PLC) dont les caractéristiques sont proches des réseaux IEEE 802.15.4 [6]. Comme sa portée est réduite par rapport à la taille du réseau de distribution, les compteurs doivent servir de relais aux communications. ERDF a choisi un mode de fonctionnement mesh-under. Ces architectures sont également normalisées à l’IEEE (P1901.2) et à l’ITU (G.9955, G.9956). Les marchés industriels des opérateurs de services « éner- gie et fluides » (nommés Utilities), ont adopté récemment ce type d’architecture pour bâtir leurs réseaux de collecte et de contrôle de l’approvisionnement énergétique (électricité, eau, gaz, chaleur). De par les contraintes de durée de vie des équipements terminaux (compteurs communicants), ces opé- rateurs ont fait appel à des technologies de communication radio moyenne portée standards issues du monde industriel : Wireless MBus (CEN/TC 294 - prEN13757-x). Ces protocoles sont mis en œuvre jusqu’au réseau de concentrateurs qui ensuite utilise une architecture REST pour communiquer avec les systèmes d’information. L’ensemble de cette chaîne porte aujourd’hui le nom de AMR (Auto Meter Reading) (figure 3). 10 M2M : Machine to Machine. REE N°2/2013 41 Impact des objets sur les protocoles de l’Internet Les protocoles utilisés à ce jour sont issus des standards défi- nis par les organismes de normalisation internationaux (IEEE, ETSI, 3GPP, CEN, IETF, etc.). La particularité de ce marché ré- side dans le fait que ces solutions appliquent les principes des services d’identification et d’adressage de l’Internet des objets mais en n’utilisant IP que sur une partie du réseau (entre le concentrateur et les serveurs). L’évolution attendue portera sur l’intégration des services de données de bout en bout en rendant les compteurs autonomes sur le réseau, du point de vue du service. Un autre domaine d’application concerne les environne- ments industriels. Il s’agit de commander des processus de fabrication et de remonter des alarmes. L’ISA travaille tradi- tionnellement sur les capteurs/actionneurs dans le monde industriel. Le groupe ISA 100 [7] a défini des standards fondés sur les piles protocolaires de l’IETF et en particulier 6LoWPAN. L’utilisation de capteurs/actionneurs sans fil per- met de facilement les déployer au sein d’un atelier ou d’une machine. Mais si IPv6 peut être utilisé dans les opérations non critiques, pour les opérations critiques ou ayant des exi- gences importantes en matière de temps réel, son utilisation n’est pas recommandée11 . 11 Il est à noter qu’un nouveau groupe de travail 6TSCH est en cours de création à l’IETF. Son but est de permettre à 6LoWPAN de profiter des capacités de réservation de ressources que peuvent proposer des média comme IEEE 802.15.4e. Ceci permettra de garantir des délais de propagation nécessaires aux flux temps réels liés à la gestion de processus industriels. Conclusion Nous sommes aux débuts de l’Internet des objets car il existe encore beaucoup de questions ouvertes. L’écosys- tème doit se structurer. Si de nouveaux acteurs vont ap- paraître pour simplifier l’usage, d’autres disparaîtront faute d’avoir pu évoluer et adopter les standards. Il est possible d’esquisser un parallèle avec l’apparition du Web qui, au milieu des années 90 a révolutionné le réseau Internet. Les premières pages étaient sommaires, composées manuelle- ment, puis sont venues des sociétés comme Facebook qui ont su démocratiser leur usage en proposant de nouveaux services innovants. L’Internet des objets cherche encore ses acteurs. Les mo- dèles économiques sont encore à trouver. Il ne faut pas sous estimer la capacité du protocole IP à s’imposer vue l’importance de la base existante. Il ne faut pas négliger non plus son arrivée en considérant une approche verticale du marché (en privilégiant des services fermés et des protocoles propriétaires) plutôt qu’horizontale où l’inter- connexion induit une baisse des coûts de communication et la création de nouveaux services. D’un point de vue protocolaire, si de nombreux efforts de standardisation ont été accomplis par différents organismes de normalisation, il reste encore beaucoup de chemin à par- courir pour pouvoir exploiter ces réseaux à grande échelle. Les protocoles et les architectures de l’Internet devront en- core évoluer pour prendre en compte les diversités d’accès Figure 3 : Architecture actuelle des chaînes de collecte de compteurs (AMR). 42 REE N°2/2013 L'AVENIR D'INTERNET et de contenus, le très grand nombre d’équipements com- municants et la garantie de confidentialité des données. En plus de ces enjeux technologiques, le principal défi industriel sera de prendre en compte des cycles de vie différents de l’informatique traditionnelle. Bibliographie [1] Z. Shelby, C. Bormann, “6LoWPAN: The Wireless Embedded Internet”, Wiley, 2009. [2] E. Ancilotti, R. Bruno & M. Conti, “The role of the RPL Routing Protocol for Smart Grid Communications”, IEEE Communications Magazine, vol. 51, n°1, January 2013. [3] M. Kovatsch, S. Duquennoy & A. Dunkels, “A Low Power CoAP for Contiki”, IEEE 8th Conference on Mobil Adhoc and Sensor Systems, 2011. [4] C. Bormann, A. Castellani & Z. Shelby, “CoAP: An Application ProtocolforBillionsofTinyNodes”,IEEEInternetComputing, vol. 16, n° 2, pp. 62-67, Mars-Avril 2012. [5] D. Boswarthick, O. Elloumi & O. Hersent, “M2M Communi- cations: A Systems Approach”, Wiley, 2012. [6] J. Higuera, J. Polo, “Standardization for Interoperable Auto- nomous Smart Sensors in the Future Energy Grid System”, Telecommunications Energy Conference (INTELEC), 2011. [7] T. Hasegawa, H. Hayashi, T. Kitai & H. Sasajima, “Industrial Wireless Standardization- Scope and Implementation of ISA SP100 Standard”, Proceedings of SICE Annual Conference, 2011. Yannick Delibie est Directeur technique et stratégique, et co-fon- dateur, de la société Kerlink, spécialisée dans le développement de solution Machine-To-Machine. Il participe activement à la définition du Guide d’application des normes prEN13757 pour le marché français de la télérelève. Il s’attache également à promouvoir les technologies de l’Internet des objets auprès des acteurs industriels du secteur, pour permettre à terme une complète interopérabilité. Alexander Pelov est maître de conférences dans le départe- ment RSM (Réseaux, Sécurité, Multimédia) de Télécom Bretagne. Ces travaux concernent les protocoles réseaux pour les commu- nications M2M, l’efficacité énergétique dans les réseaux sans fil et l’utilisation du smart grid principalement pour les compteurs intel- ligents et les véhicules électriques. Il est docteur en informatique de l’université de Strasbourg depuis 2009. Laurent Toutain est maître de conférences à Télécom Bretagne au sein du département RSM. Il est responsable de l’équipe OCIF (Objets communicants - Internet du Futur) qui se focalise sur les évolutions protocolaire et architecturale de l’Internet liées à la conception de nouveaux services (Smart grid, vêtements intelli- gents,…). Il contribue également aux FabLabs pour l’adoption des protocoles de l’IETF. LES AUTEURS