Le tableau ci-dessous compare les solutions middleware citées.
Table 4.1.
Comparaison entre les solutions middleware citées.
Disponibilité du code Filtrage Control d’accès Sécurité
UBIWARE
_ _ + _
GSN
_ + + +
Virtus
_ + + +
LinkSmart
+ + _ +
Où, les signes - et + signifient supporté et non supporté respectivement.
3.1.2. La solution SensorMAP
Une application populaire du modèle est présentée dans SensorMap [46] de Microsoft. Etant fondé sur un modèle à proxy multiples, SensorMap fournit une interface cartographique des capteurs déployés dans une zone géographique, comme présenté dans la figure ci-dessous. Il offre des outils pour la sélection et l’interaction avec les capteurs et de visualisation de leurs données qui peuvent être de types variés (température dans le lieu où se trouve le capteur, une image, …). Dans les requêtes des clients, les capteurs sont indexés par leurs types ou positions géographiques. Bien évidemment, l’accès aux capteurs définis dans la cartographie est soumis à des règles d’authentification et de control d’accès.
68
Figure 4.2. SensorMap : Interface utilisateur, fournit la facilité de zoom, des cartes routières, des
images satellitaires et un mode de vue 3D [46].
L’intégration des réseaux de capteurs à l’IoT par l’intermédiaire d’un proxy est une approche plus ou moins intuitive. Elle permettant aux nœuds capteurs de joindre l’Internet tout en maintenant les protocoles de communication propriétaires et de communiquer indirectement avec des hôtes externes qui adoptent des standards de communication basés IP. Etant isolés du monde de l’Internet, les nœuds capteurs intégrés à l’IoT suivant cette solution se retrouvent implicitement protégés contre les menaces transportées sur la connexion Internet. Cependant, l’intégration par proxy est sensible aux pannes du fait que le proxy (ou l’ensemble des proxys) est la seule entité connectée à Internet dans le RCSF. De plus, cette approche est généralement jugée inappropriée compte tenu des aspirations et des exigences applicatives de l’Internet du futur qui demandent à ce que les capteurs soient des hôtes réels de l’Internet et que les solutions d’intégration répondent aux recommandations en termes de standardisation, d’interopérabilité et surtout d’ubiquité de la connexion Internet.
3.2. Modèle d’intégration par adoption du standard TCP/IP
Au lieu d’utiliser des solutions propriétaires développées en ad hoc pour les réseaux de capteurs, empêchant la communication directe entre capteurs et hôtes réguliers et même entre capteurs dans différents RCSFs connectés à Internet. L’alternative consiste plutôt en la standardisation et l’unification de la manière suivant laquelle on intègre les réseaux de capteurs à l’Internet. Dans ce contexte, la tendance actuelle se dirige vers l’extension de l’architecture de communication basée sur le standard TCP/IP aux RCSFs. L’adoption du modèle TCP/IP par les réseaux de capteurs est une approche à la fois audacieuse et prometteuse car d’une part elle va rendre les RCSFs des réseaux tout à fait IP avec tout ce que cela porte comme avantages. De l’autre part, elle invite les capteurs (reconnus par leurs limitations en termes de ressources) à accepter des protocoles et des mécanismes qui avaient été initialement développés pour fonctionner sur des réseaux IP beaucoup
69
moins contraints. Tels protocoles sont pratiquement onéreux en termes d’espace occupé, des traitements induits et d’énergie consommée. Donc, la projection du standard TCP/IP tel qu’il est sur les réseaux de capteurs est quasiment impossible. Pour cette raison, l’IETF (Internet EngineeringTask Force) et certaines alliances (comme IPSO) ont déjà pris l’initiative d’adapter les standards de communication fondés sur IP, et même de développer de nouveaux mécanismes qui en sont inspirés, et qui seraient alertés des contraintes des réseaux de capteurs dans la nouvelle génération de l’Internet (l’Internet des objets).
Notons à ce propos que dans cette architecture d’intégration, le réseau de capteurs est entièrement ouvert sur Internet et les nœuds capteurs deviennent des hôtes réels de l’Internet, adressables, et ayant les mêmes concessions qu’un hôte ordinaire. Aussi, la station de base devient un routeur IP dirigeant le trafic depuis et vers les réseaux de capteurs. Ainsi, les communications entre les capteurs et les autres hôtes sur Internet (que ce soit d’autres capteurs connectés de la même façon, ou encore des hôtes ordinaires) se réalisent d’une manière directe et de bout-en-bout. L’interopérabilité est davantage assurée et les recommandations de l’Internet des objets en matière d’ubiquité de l’information, l’accessibilité et l’interactivité des objets seront bien remplies.
Trois groupes de recherches de l’IETF se sont concentrés sur le développement des mécanismes allégés et compatibles avec le standard TCP/IP qui sont destinés aux réseaux de capteurs basés sur la technologie IEEE 802.15.4, dans l’IoT. IL s’agit alors de 6LoWPAN (IPv6 over Low power Wireless
Personal Area Networks) [47], RoLL (Routing over Low power and Lossy networks) [48] et CoRE
(Constrained RESTful Environments) [49]. 6LoWPAN et RoLL se focalisent sur la couche réseau, tandis que le groupe CoRE s’occupe de la couche application. Comme le montre la figure suivante.
Figure 4.3. Orientation des groupes de recherche de l’IETF chargés de l’intégration basée IP des RCSFs.
3.2.1. Aperçu sur le standard IEEE 802.15.4
La technologie IEEE 802.15.4 [50], déjà introduite dans le chapitre 1, spécifie la couche physique et la sous couche MAC pour les réseaux LR-WPAN (Low-Rate Wireless Personal Area Networks) du fait qu’elle (la technologie) réponde mieux à leurs exigences en termes de faible consommation d’énergie, faible débit des dispositifs. Etant reconnu par son faible cout et sa moindre consommation
La couche application La couche transport La couche réseau La couche liaison La couche physique CoRE 6LoWPAN + RoLL