Décideur du handover sémantique

Le rôle de décideur du handover sémantique consiste à prendre les décisions de rem- placement des Initiated-SH Services par d'autres services qui sont ubiquitaires et qui appartiennent à la zone ambiante de l'utilisateur. Comme le montre la Figure 8.12, le décideur diérencie deux types de décisions possibles pour le handover sémantique :

 Décision d'un handover sémantique intra-fournisseur : elle est prise quand, pour un Initiated-SH Service donné, il y a au moins un service ubiquitaire qui ap- partient à son fournisseur et qui couvre, selon sa zone de couverture, la nouvelle localisation géographique du terminal. Il faut noter que ce service ubiquitaire peut appartenir à diérentes plates-formes de ce même fournisseur. An de supporter cette décision de handover sémantique intra-fournisseur, le décideur utilise pour chaque Initiated-SH Service la communauté virtuelle VSC-U&P qui lui corres- pond. Cette communauté déjà créée contient l'ensemble des Intra-SP Ubiquitous Services qui sont ubiquitaires à cet Initiated-SH Service et qui sont aussi oerts par son propre fournisseur.

 Décision d'un handover sémantique inter-fournisseurs : elle est prise quand, pour un Initiated-SH Service donné, deux conditions sont vériées : la première consiste que le décideur n'a trouvé aucun Intra-SP Ubiquitous Service qui couvre la nou- velle localisation géographique du terminal ; et la seconde consiste que le décideur

a trouvé au moins un service ubiquitaire qui appartient à un autre fournisseur et qui couvre, selon sa zone de couverture, la nouvelle localisation géographique du terminal. An de supporter cette décision de handover sémantique inter- fournisseurs, le décideur utilise pour chaque Initiated-SH Service la communauté virtuelle Inner VSC-U&L qui lui correspond. L'usage de cette communauté déjà créée est avantageux, puisqu'elle contient l'ensemble des Inter-SP Ubiquitous Ser- vices qui sont multi-fournisseurs, ubiquitaires à cet Initiated-SH Service, et qui appartiennent à sa zone d'entourage. Ainsi, quand le terminal sort de la zone de couverture de l'Initiated-SH Service, c'est plus probable de trouver, parmi ces Inter-SP Ubiquitous Service qui se trouvent dans son entourage, un service dont la zone de couverture contient la nouvelle localisation du terminal.

Normalement, un fournisseur de services préfère un handover sémantique intra- fournisseur, car il lui permet d'éviter de passer par un autre fournisseur et de payer à ce dernier l'utilisation d'un de ses services ubiquitaires. Par conséquent, dans notre proposition, nous favorisons le handover sémantique intra-fournisseur par rapport au handover sémantique inter-fournisseurs. Pour ce faire, nous proposons un nouveau ser- vice de gestion, dénommé Intra Service Provider Semantic Handover Service (Intra- SP SHS), qui intervient en premier an de décider s'il y a un handover sémantique intra-fournisseur ou non. Par conséquent, c'est l'Intra-SP SHS qui reçoit l'évènement, Semantic Handover Initiation, qui est envoyé par l'initiateur. Comme le montre la Fi- gure 8.12, le processus fonctionnel du service Intra-SP SHS correspond à la séquence suivante d'opérations :

 Opération 1 : Pour chaque Initiated-SH Service, l'Intra-SP SHS récupère de l'Infoware la liste des identiants des Intra-SP Ubiquitous Services, notés {SEi,j,P x:

seulement j varie}, ainsi que leurs zones de couvertures, notées {CZi,j,P x : seule-

ment j varie}. Dans ce but, les prols de l'Initiated-SH Service et de sa VSC-U&P correspondante sont utilisés.

 Opération 2 : Ensuite, l'Intra-SP SHS compare, pour chaque Initiated-SH Ser- vice, la localisation géographique (L,l) du terminal aux diérentes zones de cou- vertures {CZi,j,P x} des Intra-SP Ubiquitous Services. Par conséquent, deux cas

sont possibles. Le premier cas aura lieu quand (L,l) appartient au moins à une zone de couverture. Dans ce cas, l'Intra-SP SHS considère une décision d'un han- dover sémantique intra-fournisseur pour cet Initiated-SH Service. Par conséquent, il choisit arbitrairement un des services dont la zone de couverture contient (L,l), et il l'ajoute à la liste des Intra-SP Handover Counterpart Services qui corres- pondent à la liste des remplaçants ubiquitaires intra-fournisseur. De plus, il ajoute l' Initiated-SH Service à la liste des Intra-SP Handover-Enabled Services qui vont subir le remplacement intra-fournisseur. Au contraire, le deuxième cas possible aura lieu quand, pour un Initiated-SH Service donné, (L,l) n'appartient à aucune des zones de couverture des Intra-SP Ubiquitous Services. Par conséquent, il n'y a pas de handover sémantique intra-fournisseur. Cependant, une décision d'un han- dover sémantique inter-fournisseurs est toujours possible. Pour cela, l'ensemble des Initiated-SH Services qui vérient le deuxième cas sont ajoutés à la liste des

Inter-SP Possible-Handover Services qui sont susceptibles de subir un handover sémantique inter-fournisseurs.

 Opération 3 : Pour le premier cas, l'Intra-SP SHS notie l'exécuteur du hando- ver sémantique en envoyant l'évènement Intra-SP Semantic Handover Decision. Ce dernier contient l'identiant de l'utilisateur, la liste des Intra-SP Handover- Enabled Services, la liste des Intra-SP Handover Counterpart Services relatifs, ainsi que la liste de leurs Intra-SP Handover Counterpart Providers. Ces der- niers correspondent à une liste de Px, puisque nous sommes dans le cas d'un

handover sémantique intra-fournisseur, ce qui implique que nous avons le même fournisseur Px. Pour le deuxième cas, une décision d'un handover sémantique

intra-fournisseur n'est pas prise. Par contre, une décision d'un handover séman- tique inter-fournisseurs est toujours possible. Pour cela, l'Intra-SP SHS notie un autre acteur, dénommé Inter Service Providers Semantic Handover Service (Inter-SP SHS), en envoyant la notication, No Intra-SP Semantic Handover Notication. Cette dernière contient l'identiant de l'utilisateur, sa localisation géographique, ainsi que la liste des Inter-SP Possible-Handover Services.

Après avoir expliqué le processus fonctionnel exécuté par l'Intra-SP SHS, nous pre- nons le cas où l'Intra-SP SHS prend la décision qu'il n'y a pas de handover sémantique intra-fournisseur, et il envoie la notication, No Intra-SP Semantic Handover Noti- cation, vers l'Inter-SP SHS. Ce dernier il a pour rôle de décider s'il y a un handover sémantique inter-fournisseurs ou non. Comme le montre la Figure 8.12, le processus fonctionnel du service Inter-SP SHS correspond à la séquence suivante d'opérations :

 Opération 1 : Pour chaque Inter-SP Possible-Handover Service, l'Inter-SP SHS récupère de l'Infoware la liste des identiants des Inter-SP Ubiquitous Services, notés {SEi,j,P k: j et k varient, avec Pk6=Px}, ainsi que leurs zones de couvertures,

notées {CZi,j,P k : j et k varient, avec Pk 6= Px}. Dans ce but, les prols de

l'Inter-SP Possible-Handover Service et de l'Inner VSC-U&L correspondante sont utilisés.

 Opération 2 : Ensuite, l'Inter-SP SHS compare, pour chaque Inter-SP Possible- Handover Service, la localisation géographique (L,l) du terminal aux diérentes zones de couvertures {CZi,j,P k} des Inter-SP Ubiquitous Services. Par consé-

quent, deux cas sont possibles. Le premier cas aura lieu quand (L,l) appartient au moins à une zone de couverture. Dans ce cas, l'Inter-SP SHS considère une décision d'un handover sémantique inter-fournisseurs pour cet Inter-SP Possible- Handover Service. Par conséquent, il choisit arbitrairement un des services dont la zone de couverture contient (L,l), et il l'ajoute à la liste des Inter-SP Han- dover Counterpart Services qui correspondent à la liste des remplaçants ubiqui- taires inter-fournisseurs. De plus, il ajoute l'identiant du fournisseur, qui ore le service choisi, à la liste des Inter-SP Handover Counterpart Providers. Enn, il ajoute l'Inter-SP Possible-Handover Service à la liste des Inter-SP Handover- Enabled Services qui vont subir le remplacement inter-fournisseurs. Au contraire, le deuxième cas possible aura lieu quand, pour un Inter-SP Possible-Handover Service donné, (L,l) n'appartient à aucune des zones de couverture des Inter-

SP Ubiquitous Services. Par conséquent, il n'y a pas de handover sémantique inter-fournisseurs. Par suite, ce service ne subit ni un handover sémantique intra- fournisseur, ni un handover sémantique inter-fournisseurs. Ainsi, ce service est gardé dans le VPSN de l'utilisateur.

 Opération 3 : Pour le premier cas où nous avons une décision d'un handover sémantique inter-fournisseurs, l'Inter-SP SHS notie l'exécuteur du handover sé- mantique en envoyant l'évènement Inter-SP Semantic Handover Decision. Ce der- nier contient l'identiant de l'utilisateur, la liste des Inter-SP Handover-Enabled Services, la liste des Inter-SP Handover Counterpart Services relatifs, ainsi que la liste de leurs Inter-SP Handover Counterpart Providers. Ces derniers corres- pondent à une liste {Pk : k varie, avec Pk 6=Px}.