Diagramme de séquence et diagramme Use case

Le diagramme de séquence qui traduit l’échange des messages entre le collecteur mobile et le chef de cluster, présentés dans un ordre chronologique, est décrit sur la Figure 4-12.

• INVITE : Ce message est utilisé par le collecteur pour inviter un chef de cluster présent

dans son voisinage à initier une connexion de session. Ce message est de type diffusion et est constitué des champs suivants : (champ type, identifiant du collecteur).

• SESSION_PARAM_Client : Ce message est envoyé par le collecteur au chef de cluster.

Ce message contient les paramètres de session. Ce message est de type unicast et il est composé des champs : (Champ type, identifiant du collecteur, identifiant du chef de cluster, durée de la session, etc). Le champ type prend la valeur 0 lorsque le message envoyé est de type ouverture de session. Et prend la valeur un lorsqu’il est de type reprise e session.

• SESSION_PARAM_Server : Ce message envoyé par le chef de cluster au collecteur,

correspond à un accusé de réception du message INVITE et par conséquent une acceptation d’ouverture de session avec le collecteur mobile. Ce message est de type unicast et il contient les paramètres de session. Les champs le constituant sont : (Champ type, identifiant du collecteur, identifiant du chef de cluster, position du chef de cluster, la liste des nœuds membres du cluster, la position du nœud le plus éloigné du chef de cluster).

• SENT_DATA : Ce message est envoyé par le chef de cluster. Ce message est de type

unicast. Et il est constitué des champs suivants : (Champ type, identifiant du collecteur, identifiant du chef de cluster, valeur moyenne des valeurs mesurées au niveau du cluster).

• Error_Notification : Ce message de notification est envoyé en cas erreur.

• CLOSE_SESSION : Ce message est envoyé par le chef de cluster pour fermer une session

Les deux acteurs principaux sont le collecteur mobile et le chef de cluster visité. Le collecteur en se déplaçant envoie un message INVITE permettant d’inviter un chef de cluster à initier une session. Et dès réception d’un message de type SESSION_PARAM_Server provenant d’un chef de cluster, le collecteur mobile lance la procédure de test des relations d’héritage.

La procédure commence par tester l’existence d’une relation de type équivalence totale. Si elle existe alors le collecteur envoie au chef de cluster un message de type SESSION_PARAM_Client.. Ce message contient les paramètres de session. Le chef de cluster accuse la réception de ce message par un message SENT_DATA contenant la moyenne des valeurs mesurées au niveau de son cluster. Et ferme la session avec le collecteur mobile par l’envoi du message CLOSE_SESSION.

Sinon, Le processus de détection de présence des relations d’héritage teste l’existence d’une relation d’équivalence partielle. Si oui alors le collecteur envoie le message SESSION_PARAM_Client.de type reprise de session. A la réception de ce message, le chef de cluster répond avec le message

SENT_DATA contenant la donnée et ferme la session par l’envoi du message CLOSE_SESSION.

Si aucun type de relation n’est trouvé, le collecteur envoi au chef de cluster visité un message

SESSION_PARAM_Client de type création de session. Le chef de cluster après réception de ce

message lui envoie le message de données SENT_DATA contenant la donnée et ferme la session par l’envoi du message CLOSE_SESSION.

Sur la Figure 4-13, nous présentons le diagramme de cas d’utilisation. Ce diagramme modélise les fonctionnalités et services offerts de notre système. Il décrit les fonctions effectuées par les deux acteurs à savoir le collecteur mobile et le chef de cluster.

Ainsi, le chef de cluster participe à la fonction d’accrochage au collecteur et à la fonction de communication des données de session. Alors que le collecteur mobile réalise les taches de gestion de sessions qui englobe la création, la suppression, le maintien et le transfert de sessions. Un service de gestion de mobilité est offert au collecteur mobile. Ce service permet la définition de type de la trajectoire (statique, dynamique ou hybride) et la détermination du circuit de visite que le collecteur mobile peut emprunter. Ce circuit de visite est déterminé sur la base des informations de sessions et le graphe construit par le collecteur mobile.

4.5.3.6 Algorithmes:

Dans cette section nous présentons les algorithmes correspondants aux deux régimes initial et permanent de la collecte des données décrits plus haut.

Algorithme 6 /* Algorithme du régime initial */

Tant que fin parcours régime initial =faux faire # parcours défini selon la trajectoire de type spirale

d’Archimède#

Envoi du message INVITE

Réception du message SESSION_PARAM_SERVER Mesure du SNR

Si SNR est dans l’intervalle de confiance alors

Enregistrement des informations obtenues dans la table_position_CH Création de la table des CHs<->Id_sessions<-> données

Récupération / Création de l’Id_session

Mise à jour de la table des CHs<->Id_sessions<-> données

Fin Si Fin tant que

Algorithme 7 /* Algorithme du régime permanent de collecte des données */

Tant que fin parcours du régime permanent =vrai faire # parcours défini selon la trajectoire calculée

selon le graphe obtenu dans le régime initial # Envoi du message INVITE

Réception du message SESSION_PARAM_SERVER Mesure du SNR

Si SNR est dans l’intervalle de confiance alors

Enregistrement des informations obtenues dans la table_position_CH Création de la table des CHs<->Id_sessions<-> données

Récupération / Création de l’Id_session

Mise à jour de la table des CHs<->Id_sessions<-> données Calcul de la trajectoire suivant le graphe obtenu

Fin Si Fin tant que

Algorithme 8 /* Algorithme exécuté par un nœud capteur à la réception du message INVITE Si état du nœud = chef de cluster alors