Avoir une autogestion de la QoS

Implémentation

Dans cette partie, nous présentons un scénario (§VI.1) qui illustre un cas d’usage de la personnalisation des services et qui montre l’utilité d’avoir une autogestion de la QoS, basée sur un agent de QoS dans un contexte ubiquitaire, au cours de la mobilité de la session. Puis dans (§ VI.2), nous détaillons notre plate-forme de développement et de tests UBIS, qui est utilisée pour le développement des services applicatifs ainsi que ceux de gestion que nous avons proposé pour gérer la création et la modification de la session UBIS. Dans cette section, nous utilisons un cas d’usage pour démontrer l’utilité de l’ensemble de nos propositions. Le scenario suivant illustre le cas où un utilisateur souhaite personnaliser ses services pour chercher un bien immobilier à acheter dans sa zone géographique. Lorsque l’utilisateur est en train de se déplacer, il va utiliser le composant FIND pour rechercher des biens immobiliers en fonction de sa position géographique (Longitude, Latitude). Cette recherche est effectuée dans la zone ambiante de l’utilisateur qui est limitée par un rayon R. Ensuite le composant de service «Location» est utilisé pour obtenir les coordonnées GPS pour chaque bien immobilier. Ensuite il utilise Google Maps pour localiser le bien sur une carte, et après il utilise le composant de service «GET» pour voir le profil détaillé de chaque bien sélectionné (la nature, la superficie, le prix, l’adresse). Et finalement, il va utiliser le service «Banking» pour d’une part demander un prêt d’achat et une assurance pour le bien qu’il a choisi, et d’autre part pour effectuer, le paiement sécurisé en ligne.

Au cours de l’exploitation, la performance de  » FIND@Habitat » se détériore et ne peut pas fournir la qualité de service requise par l’utilisateur. Par conséquent, « FIND@Habitat » doit être remplacé par un composant de service FIND ubiquitaire. FIND@HABITAT envoie un évènement de notification «Out contrat» via le message SIP+ Notify à tous les membres de sa communauté VSC pour traiter son changement. Il existe toujours des composants ubiquitaires fournis par d’autres fournisseurs tels que FIND@Century21. Pour tester la performance de nos propositions, nous avons fait tourner ce scénario dans un premier temps avec des composants de service sans l’agent QoS (BSC), et dans un second temps avec des composants de service autonomiques (ASC). Nous mentionnons que si un des quatre critères de QoS se dégrade au cours de la session de l’utilisateur, il faut procéder au changement du composant de service parce que tous les critères de QoS sont nécessaires pour maintenir la QoS globale du composant de service.

Durant la session de l’utilisateur, l’agent QoS du composant de service ASC_FIND@Habitat détecte une dégradation de la QoS dans le critère de la Fiabilité (R1min = 0, 8 à T=8ms). Il invoque la communauté VSC pour procéder à son changement par un composant de service équivalent ASC_FIND@Century21. La performance de la QoS est meilleure grâce au QoS-agent parce qu’il évite une dégradation complète de la QoS d’un composant de service et maintient le «service delivery» Pour mettre en place le projet UBIS, nous disposons d’une plate-forme UBIS qui nous permet de démontrer la faisabilité de l’ensemble de nos propositions et les tests des cas d’usages. La plate-forme est développée selon la structure de l’architecture UBIS, elle est structurée en fonctions des quatre niveaux de visibilité: Utilisateur, Terminal, Réseau et Service. Réseau de transport : nous nous appuyons sur la solution VIRTUOR qui propose des machines physiques supportant plusieurs entités virtuelles de différents types comme les routeurs IPv4, IPv6, point d’accès virtuel, serveur SIP etc. Cette solution offre la possibilité de mettre en place plusieurs réseaux virtuels, spécifiques aux applications supportées, qui sont vus de la part des utilisateurs comme des réseaux physiques distincts.