• Aucun résultat trouvé

Chapitre 3 : LoWCA (Exemple d’application cible)

3.3. Connaissance et information atomique

Le mécanisme de routage proposé dans cette thématique exploite la mobilité des nœuds en permettant à des stations mobiles d’entrer en contact avec d’autres stations fixes ou mobiles afin de collecter, transmettre et de colporter leur connaissance vers un point de collecte. Rappelons que la notion de connaissance citée ici fait référence à une collection d’événements de contact pouvant être manipulés. En effet, l’information atomique (événement de contact) représente l’enregistrement qu’une station est à portée d’une autre. Chaque nœud du réseau quelque soit son type diffuse périodiquement son identité pour signaler sa présence. Ce procédé donne la possibilité à un nœud de détecter la présence d’un ou plusieurs partenaires lorsque ce ou ces derniers sont à portée. On dit que les nœuds sont en contact. Lorsqu’une station détecte la présence d’une autre station à portée, une structure de donnée appelée événement de contact est créée à la suite de cette rencontre. Cet événement représente de ce fait l’information atomique du processus de colportage. Durant la période de contact, les nœuds peuvent échanger leur connaissance afin de contribuer au processus de colportage des informations requises par l’application. Le format générique d’un événement de contact et un exemple d’instanciation (les tailles en octets des différents champs) sont illustrés dans la figure 42.

88

Figure 42 : Format générique d’un événement de contact.

Le choix des tailles en octets des différents champs est basé sur la volonté de minimiser les ressources consommées (capacité mémoire, faible débit, …etc.). Cette information atomique est néanmoins structurée en trois parties : l’identification du contact, sa durée et un champ applicatif dont l’usage va dépendre de la finalité de l’application. Le couple (IdA, IdB) des identifiants (Id) des deux entités A et B à portée réciproque n’est pas une façon d’identifier un contact car ces deux entités A et B peuvent se croiser plusieurs fois. Il a donc été décidé que l’entité qui crée le contact lui attribue un numéro de séquence, ce qui garantit l’unicité au problème du modulo du numéro de séquence près. La structure d’un événement de contact a pour notre application générique une taille fixe de 12 octets et sa composition détaillée est la suivante :

 My ID (2 octets) : cet identifiant est unique, il est renseigné par l’adresse courte du nœud générateur de l’événement de contact.

 Numéro de séquence (1 octet) : le numéro de séquence est généré par l’entité qui crée l’événement. L’unicité de cet événement est garantie par le couple (MyID, Numéro de séquence).

 ID partenaire (2 octets) : ce champ identifie le partenaire du nœud générateur.

 Heure arrivée (3 octets) : le début de contact est mémorisé dans le champ Heure arrivée.

 Heure départ (3 octets) : la fin d’un contact représente la rupture du lien radio entre les deux entités. Cette information est sauvegardée dans la partie Heure départ de la structure. Les deux informations d’arrivée et de départ sont enregistrées en dixièmes de seconde pour notre application générique.

 Champ applicatif (1 octet) : ce champ est réservé aux besoins de l’application ou pour une utilisation future.

Remarquons qu’un contact génère naturellement deux événements de contact duaux (A, B, N°SeqA) et (B, A N°SeqB).

89

3.3.1. Evénement de contact complet

La fin d’un contact est causée par la perte du lien entre un nœud et son partenaire. A cet instant, chacune des deux stations enregistre l’heure à partir de laquelle elle ne reçoit plus aucune trame de ce partenaire. Ensuite, elle insère cette information dans le champ heure départ de l’événement de contact qui initialement, lors d’un début de contact, a une valeur égale à 0. Dans ce cas, on parle d’événement de contact fini ou complet lorsque ce champ est complété en fin de contact. Dans la figure 43, un exemple d’un contact entre deux entités est donné pour montrer la manière dont les événements de contacts finis sont complétés.

Figure 43 : Exemple de création d’événements de contact complets.

Dans la première partie de la figure 43 (t1), les deux nœuds sont en contact et créent un événement de contact pour enregistrer cette rencontre avec une heure de départ nulle. A cet instant, ces événements sont appelés événements incomplets ou en cours. On note qu’un décalage peut exister concernant les heures d’arrivée (10 pour le mobile A et 10.1 pour le mobile B), cela est dû :

 A la dérive des horloges de nœuds impliqués dans le contact.

 Au fait que la détection de la trame de signalement du partenaire A par le partenaire B et réciproquement ne sont pas des événements synchrones.

Lorsque le contact est rompu (figure 43, t2), les stations complètent alors leur événement de contact avec l’heure locale de la dernière trame reçue (13.2 pour A et 13.5 pour B).

90

3.3.2. Evénement de contact incomplet

L’utilité des événements de contact incomplets appelés également événements de contact en cours dans un processus de colportage est d’indiquer, lors d’un échange quelconque entre deux ou plusieurs entités, qu’un contact est en cours et n’est pas encore fini. Cette information peut avoir un impact considérable pour des applications de localisation a posteriori. Pour mieux comprendre cet enjeu, prenons l’exemple de la figure 44 pour lequel un nœud passe à proximité d’un contact entre deux autres stations. Lors de son passage, le mobile B récupère une partie de la connaissance du mobile A et de la balise C1, de plus, il récupère aussi l’information que ces deux entités sont en contact. Si on suppose maintenant que le mobile A reste bloqué dans une mine et que seul le mobile B a permis que cet événement de contact (C1 avec A)soit rapporter au collecteur, cette donnée sera indispensable pour localiser le mobile A a posteriori.

Figure 44 : Echange de contact incomplet.

3.4. Stratégies de diffusion