Middleware RF²ID (Reliable Framework for Radio Frequency IDentification)

Le middleware RF²ID est conçu de manière à prendre en compte la vulnérabilité de la technologie

notamment la technologie passive. Il a comme objectifs les éléments suivants :

- Rendre le système évolutif et plus fiable (grâce aux lecteurs virtuels).

- Equilibrage de charge entre les composants de traitement lors de la manipulation d’une grande

quantité de données.

- Fluidité et rapidité de circulation des données (haut débit).

- Organisation des données (besoin de trier et d’organiser proprement les données lorsqu’il s’agit

d’un grand volume de données, pour une meilleure réactivité aux requêtes).

Le middleware RF²ID repose sur deux notions principales, à savoir les lecteurs virtuels et les chemins

1.1. Lecteurs virtuels (virtual readers)

Un lecteur virtuel (VR) est un module chargé de gérer un ensemble de lecteurs physiques (PR) se

trouvant dans le même voisinage. Cette notion de VR est aussi utilisée dans d’autres études notamment

dans les travaux de Fagui Liu [45].

Un lecteur RFID est par nature peu fiable (taux de lecture = 70% [7] [8] [9]) ; par conséquent,

l’association de plusieurs lecteurs physiques (PR) est pleinement justifiée pour la minimisation du taux

d’erreurs de lecture.

Dans un lieu où la disposition des lecteurs ne change pas, l’affectation des lecteurs physiques à un

lecteur virtuel donné est réalisée durant la phase d’initialisation. Pour le bon fonctionnement du

système, chaque VR gère en tout cinq listes qui sont comme suit :

- observedTagList : représente la liste de tous les tags détectés par tous les PR associés à ce VR

(existence de données dupliquées).

- receivedTagList : liste des tags détectés après filtrage (receivedTagList = observedTagList +

Filtrage).

- expectedTagList : est la liste des tags attendue par le VR. Elle est envoyée par le VR qui le

précède dans le chemin virtuel ou le Vpath (cette notion de Vpath sera traitée dans le deuxième

point de cette section). Notons que le premier VR dans le chemin ne peut pas gérer cette liste

(expectedTagList = receivedTagList

).

- missingTagList : représente l’ensemble des tags attendus mais non détectés par les PR qui lui

sont associés. On admettra que le VR va recevoir la liste « expectedTagList » de son voisin avant

la constitution de la liste « receivedTagList » afin de pouvoir calculer « missingTagList »

(missingTagList = expectedTagList − receivedTagList).

- spuriousTagList : désigne l’ensemble des tags détectés par les PR mais non attendus

(spuriousTagList = receivedTagList− expectedTagList).

NB : la liste « receivedTagList » du premier VR dans un Vpath deviendra la liste « expectedTagList » pour

tous les autres VR qui appartiennent au même Vpath.

37

1.2. Chemins virtuels (Virtual Paths)

Ce sont des canaux de communication logiques qu’on appelle « Chemins virtuels (Vpaths) ». Ils sont

constitués de plusieurs VR

qui suivent les flux de données afin d’améliorer la fiabilité du système. En

effet, Ahmed Nova [39] [40] a constaté que la nature des flux de données peut aider dans l’organisation

des données. Il s’est donc basé, sur la nature de ces flux pour la création des Vpaths [46].

Le fonctionnement de la plateforme RF

ID est illustré à travers un exemple d’application dans la

figure 29. Il concerne la gestion et l’acheminement des produits dans un entrepôt.

L’entrepôt est divisé en plusieurs zones géographiques. Chacune de ces zones est associée à un

lecteur virtuel (VR) et dispose d’un ensemble de lecteurs PR. Chaque lecteur virtuel couvre une zone qui

s’étale sur plusieurs tapis roulants. Ainsi le VR1 concernera tous les produits qui transitent dans

l’entrepôt (sur tous les tapis) ; par contre le VR3 ne concernera que les produits qui arrivent par la source

B vers la destination C.

La création des chemins virtuels est gérée par les deux serveurs « Path Server » et « Name Server ».

« Path Sever » dispose de tous les chemins virtuels existants. Il sera interrogé par un VR (qui a reçu une

requête de l’application utilisateur

) qui veut créer un Vpath afin de savoir si ce chemin n’existe pas

déjà. Dans le cas où le chemin à créer n’existe pas, Name Server sera interrogé à son tour. Ce dernier

dispose de l’emplacement (cartographie) de tous les VR dans l’entrepôt. Il permet ainsi de retourner une

liste des VR à partir de deux données en paramètres à savoir la source du Vpath et sa destination.

Les lecteurs VR auront aussi à gérer deux paramètres en plus des listes déjà citées. Ces deux

paramètres sont :

- conn

: représente le nombre maximum de messages entrants gérés par le lecteur VR par unité

de temps.

- conn

: désigne le nombre maximum de messages sortants gérés par le VR par unité de temps.

Pour qu’un lecteur VR accepte de participer dans un Vpath, il commence par calculer sa charge

suivant tous les Vpaths auxquels il appartient, et une estimation de la nouvelle charge avec le nouveau

Vpath est calculée. Cette nouvelle charge ne doit pas dépasser conn

et conn

, sinon le VR ne pourra

pas participer à ce nouveau chemin.

17

Un Vpath est constitué de plusieurs lecteurs virtuels (VR) et un VR peut appartenir à plusieurs Vpath.

18

Chaque VR est capable de répondre aux requêtes des applications ou bien de les aiguiller grâce au Vpath vers le VR le plus apte à répondre.

Pour garantir la cohérence des systèmes, les listes créées et échangées entre les VR sont datées. Cela

évite à un VR de comparer sa liste receivedTagList avec une ancienne expectedTagList ou bien avec la

suivante dans le cas où la première a été perdue lors de la transmission ; en d’autres termes, cela permet

d’éviter beaucoup d’erreurs.

Cette architecture est très adaptée pour le suivi des objets, mais aussi pour leur localisation grâce aux

chemins virtuels et à l’utilisation desdites listes par les VR. Ainsi, si un objet se perd lors de son

acheminement, il suffit d’interroger le dernier VR qui a pu le lire, et en utilisant l’atténuation des signaux

des PR

, l’objet perdu pourra être localisé de manière assez précise.