Projet ANR-Verso 2008 UBIS «User centric»: ubiquité et Intégration de Services

Transcription

1 Projet ANR-Verso 2008 UBIS «User centric»: ubiquité et Intégration de Services 1 / 34

2 Auteurs : Participants : Version : N. Simoni, R. Nassar, H. Alaoui. Soulimani, S. Kessal V2 Date : 9/2011 Historique du Document Version Date Modifications V1 7/2011 R. NASSAR V2 9/2011 N. SIMONI & H. ALAOUI Mots clés NGN, NGS, Middleware, gestion de QoS, Mobilité, Hétérogénéité, user-centric, personnalisation de services, composition dynamique de services, agrégation de service, composants de service de gestion. 2 / 34

3 Table des matières 1 INTRODUCTION DEROULEMENT D UNE SESSION UBIS Ouverture de la session de services : Personnalisation des services Initiation de la session de services: SIP + INVITE Processus de la Création du VPSN : Consommation des services (provisioning) Agent de QoS de la ressource service Autogestion de la ressource service Mécanisme de gestion de la file d attente GESTION DE LA SESSION USER-CENTRIC BASEE QOS HANDOVER SEMANTIQUE POUR UNE CONTINUITE DE SERVICE SANS COUTURE DANS L ENVIRONNEMENT AMBIANT Introduction Scénario selon des zones ambiantes Concept du Handover Sémantique Initiateur du Handover Décideur du Handover Exécuteur du Handover Conclusion : Handover Sémantique MODELE ARCHITECTURAL : COUCHE SERVICE AVEC UNE APPROCHE SOA/EDA NGN/NGS MIDDLEWARE : COUCHE SERVICE Le bus d interconnexion SEIB Les services de base et les services exposables CONCLUSION / 34

4 Table des Illustrations Figure 1 : Création d une session de service... 7 Figure 2 : Structure du message SIP+ INVITE... 8 Figure 3 : Diagramme de séquence de la création du VPSN Figure 4 : Transaction Figure 5 : Resource Service et exemple de Mutualisation de requêtes Figure 6 : Autogestion par l Agent QoS et VSC Figure 7: Mécanisme de gestion de la file d attente Figure 8: autogestion (VSC, VQC) Figure 9 : Structure du message SIP+ NOTIFY Figure 10: scénario NGN/NGS Figure 11 : Les ressources dans la zone ambiante Figure 12 : Scénario de Handover au niveau service Figure 13 : Déclencheur dans l Infoware Figure 14 : Initiation du handover sémantique Figure 15 : Décision du handover sémantique Figure 16 : Exécution du handover sémantique Figure 18: Modèle Middleware Figure 19: NGN/NGS Middleware Architecture Figure 20: SEIB - Composition et Agrégation de services / 34

5 1 Introduction Nous pouvons résumer notre positionnement en disant que l évolution des réseaux vers le NGN, induit l évolution des services. Etant monolithiques, verticales et fortement liées aux réseaux et à leurs technologies, les architectures de services existantes ne peuvent pas répondre aux exigences à venir. Pour cette raison, nous cherchons à concevoir une architecture de services qui débloque les verrous suivants : Défis NGN : la mobilité, l hétérogénéité et l approche user-centric. Défis NGS : la convergence de services (Telco, Web, IT), la personnalisation des services selon les besoins et les préférences de l utilisateur (au niveau fonctionnel et nonfonctionnel, c.à.d. QoS), et l horizontalité de la couche service. Défis Session : Garantir la convergence entre les contextes NGS et NGN afin de fournir une session unique et continue pour chaque utilisateur, tout en tenant compte de sa QoS demandée de bout-en-bout ainsi que de son contexte ambiant. Rappelons que pour faire sauter les deux premiers verrous, une réingénierie d architecture accompagnée par une réingénierie de services est nécessaire. En effet, l ISO définit le service comme «une prestation composable qui doit être source de valeur pour le consommateur et le fournisseur». En se basant sur cette définition, toute architecture qui désire structurer les services de futur (NGS) doit obligatoirement supporter une composition dynamique de services. Cette composition doit être horizontale pour dépasser les problèmes de l approche «client/serveur», et personnalisable pour tenir compte du contexte user-centric. Pour atteindre ce but, nous avons proposé un modèle architectural combinant deux types d architectures : l approche SOA et l approche EDA (Event Driven Architecture). Ainsi les composants de services deviennent des vrais automates accessibles après n importe quel événement, ils seront non seulement réutilisables, interopérables et autonomes comme dans le cas de SOA, mais aussi : Mutualisables : cette caractéristique consiste à partager, simultanément et entre plusieurs demandeurs, les ressources qu un service peut fournir. Ceci permet d optimiser l utilisation de ces ressources. Le fait d avoir des services mutualisables exige d éliminer les contraintes liées à la conservation de l état du service (activation, désactivation, etc.) ou à des données particulières de la part des utilisateurs. Ceci n est possible que si les services sont Stateless. Pour avoir cette propriété, un service doit réaliser des tâches génériques pour tous les clients sans prendre en compte leurs contextes et sans maintenir leurs données spécifiques. Cette caractéristique favorise le remplacement dynamique d un service par un autre dans une composition de service à couplage lâche. Interconnectés : cette caractéristique vient s ajouter à l Interopérabilité et garantit ainsi l Interfonctionnement entre plusieurs composants de services afin de créer un service global. Cette approche permet la coopération des composants de services tout en évitant les conflits de traitement et de deadlocks. L interconnexion entre les services amène à définir des interfaces et des liens génériques. Auto-gérables : cette caractéristique se manifeste par la capacité de l'agent QoS, intégré au composant qui surveille et contrôle ses propres paramètres de QoS tout en vérifiant si son comportement est conforme à celui négocié dans le contrat de QoS préétabli. Pour le défi de la Session unique et continue nous allons d'abord d'écrire le déroulement d'une session UBIS (), puis spécifier sa gestion () pour identifier les différents types de composants dont on a besoin. C'est ainsi, qu'on aura des composants de bases (traduction des composants exposables), des composants de gestion et des composants de signalisation. Ces différents composants seront soit simples, soit complexes, mais ils respecteront tous, le modèle de service que nous avons défini. 5 / 34

6 2 Déroulement d une session UBIS Une session UBIS se déroule en trois étapes : l ouverture de la session de service pour une personnalisation par composition du service ( 2.1), l initiation de la session de services ( 2.2) et la création du VPSN ( 2.3) et consommation des ressources ( 2.4). 2.1 Ouverture de la session de services : Personnalisation des services Lorsque l utilisateur est autorisé à ouvrir sa session UBIS, il compose à travers une IHM «Interface Homme Machine» des services exposables hétérogènes en fonction de ses besoins (fonctionnel et non-fonctionnel (QoS)) qui va utiliser durant sa session. La sélection des services exposables se fait soit à partir du catalogue des services {SExp α, SExp β} stockés dans le profile utilisateur ou bien par la découverte des services existants dans l environnement de l utilisateur {SExp γ} (Figure 1). Durant la phase de la découverte des services, on prend en considération les informations de géolocalisation de l utilisateur (longitude : LO, latitude : LA) pour favoriser les services localisés dans le réseau ambiant de l utilisateur afin de lui offrir des services avec une valeur ajoutée de son environnement. Les informations de géolocalisation sont obtenues en utilisant un terminal localisé par le biais du GPS, WIFI, GSM, IP ou bien autres techniques. Les informations de géolocalisation obtenues sont stockées dans le terminal ou bien dans le serveur de services. Ensuite, le terminal génère le Workflow avec la composition des services exposables {SExp provider1, SExp provider2, SExp provider3}, la logique de service et également la localisation de l utilisateur pour initier la session UBIS de l utilisateur. Ces informations sont envoyées via le protocole de signalisation SIP+ en passant par IMS à la plate-forme des services pour leur traitement. Il convient de mentionner qu avant l ouverture de la session de services, il nous faut ouvrir les autres sessions (d accès et réseaux). A cette occasion, on sollicite le moteur SSO (qui a évolué en SecurityWare) pour la phase d identification et d authentification. Pour l autorisation au niveau des platesformes, le moteur SSO génère un «ID-VPDN». Pour les composants de service, le moteur SSO génère un identifiant de session et un identifiant de VPSN «ID-VPSN» image unique de la session de services de l utilisateur. 2.2 Initiation de la session de services: SIP + INVITE Aujourd hui, IMS initie le processus de la création des sessions à travers les invitations du protocole SIP. En effet, SIP transporte les descriptions media via le protocole SDP (Session Description Protocol). Ces descriptions permettent au participant de la session une négociation des paramètres media pour assurer le media delivery. On note que le media delivery utilise un ensemble de mécanismes visant à fournir une mesure précise des paramètres de QoS au niveau réseau, ce qui améliore la prestation du «service réseau» durant la session multimédia. Par conséquent, le media delivery s appuie sur la gestion de la QoS pour le transfert d un flux media à partir d un point A à un point B. Par contre si le point A est changé en raison de la mobilité du terminal ou bien de l utilisateur cela peut provoquer une éventuelle interruption de la délivrance du service, la QoS du réseau doit être resignifiée et celle des composants de service doit être prise en compte. 6 / 34

7 Figure 1 : Création d une session de service Notre principal objectif est d'améliorer la prestation de services «service delivery» pour fournir des services personnalisés à l'utilisateur sans couture selon ses exigences et ses préférences durant la mobilité de la session et cela indépendamment de la localisation, du terminal ou du réseau d'accès. Prenant en considération le contexte ambiant de l'utilisateur, le système doit fournir à l utilisateur le service demandé avec le niveau de la QoS exigé et assurer la continuité de service en fonction de ses préférences quel que soit le contexte. Par conséquent le service doit être maintenu avec la même qualité de service, même si l un des points A ou B change. Pour ce faire, nous avons proposé une extension de la portée du protocole SIP existant, au niveau service de l architecture pour lui offrir un service adapté à ses besoins et à son contexte ambiant. Le protocole étendu est nommé SIP+. L intérêt majeur d avoir un protocole SIP+ est de permettre une négociation de la qualité de service pour chaque service demandé par l utilisateur pendant la phase d initiation de la session user-centric. Pour réaliser le service delivery, nous proposons le protocole de signalisation SIP+ qui peut être utiliser pour établir, modifier ou bien terminer des sessions user-centric avec les informations relatives aux aspects fonctionnels et non-fonctionnelles des services. Le protocole SIP+ permet de contrôler la création du VPSN pendant la phase d établissement de session via le message SIP+ INVITE, de gérer le VPSN pendant la phase d exploitation via le message SIP+ NOTIFY et également de libérer les ressources du VPSN via le message SIP+ BYE. 7 / 34

8 Le traitement de l'initiation de la session de service est lancé par la plate-forme de services suite à la réception du message SIP + INVITE qui contient toutes les informations concernant la localisation de l utilisateur et également la composition des services exposables qui vont éventuellement participer à la session «user centric». Elles sont introduites dans le «Body» du message SIP+ NVITE. Le corps du message SIP+ INVITE contient donc principalement la logique des services, elle définit la liste des transactions des services exposable et leur ordre d'exécution au cours de la session user-centric provider2, provider3}. Il contient également une description de la QoS (SLA) de chaque sexp demandée par l utilisateur. En particulier, les exigences de l'utilisateur sont décrites pour chaque Sexp en fonction du modèle OoS défini précédemment selon les quatre critères de QoS (Disponibilité, délai, fiabilité et capacité). A la réception de ce message, le ServiceWare, va traduire les services exposables en services de base et va compléter le VPSN. L autorisation des composants de service résidant sur cette plateforme devra être opérée par son agent policy. 2.3 Processus de la Création du VPSN : Figure 2 : Structure du message SIP+ INVITE Pour atteindre une gestion et un contrôle automatisés et distribués de la qualité de service au niveau service de l architecture, nous allons appliquer notre vision de SOA basée sur des 8 / 34

9 composants de service génériques, mutualisables, stateless, et autogérables. Un composant de service peut rendre un service de type usage, contrôle ou gestion Dans notre approche, chaque service exposable est composé d un ensemble de composants de service de base «BSC» de type usage. En outre, la session de service est créée en définissant la chaine logique des composants de services exécutables de type usage «BSC». Cette chaine logique constitue le VPSN (Virtual Private network). Ces BSCs seront classés selon les transactions définies par l utilisateur au moment de l ouverture de la session de service. Le scénario que nous allons décrire se base sur une configuration où nous avons qu une seule plate-forme de service. Dans le cas où nous aurions plusieurs plates-formes de service (le terminal pourrait en être une), la création du VPSN est partagée, chacune des plates-formes le complétant avec les services dont elle a la responsabilité. On rappelle que l ID-VPSN est géré par le SecurityWare. La composition de service permet l interopérabilité, l interaction et la coopération entre différentes capacités des composants de service c.-à-d. l aspect fonctionnel et non fonctionnel du service pour enrichir le service pour l utilisateur. Durant la session user-centric, chaque composant de service participant à cette session s autogère. Cette solution permet une décentralisation et une automatisation du contrôle et de la gestion au niveau service durant le mouvement. L intérêt de cette solution est de détecter la défaillance au bon moment durant les changements (mobilité, préférences, dégradation) et également de permettre d approvisionner et de réapprovisionner les ressources services sans causer une interruption durant l usage des services grâce aux VSC (communauté des services ubiquitaires fonctionnellement et QoS équivalent). Pour créer le VPSN en se basant sur les informations envoyées via le SIP+ INVITE, on utilise les composants de service de type gestion «Management Service Components : MSC» afin d assurer la création et la maintenance du VPSN dans la plate-forme de service. Notre conception est basée sur un ensemble d interactions entre des MSC avec des interfaces en couplage lâche facilitant l interaction et l interopérabilité pour créer et maintenir la table VPSN. En effet, le processus de création est basé sur cinq MSCs () - Retriever_SIP RMSC : extrait les informations contenues dans le Body SIP+ INVITE - Translator TMSC : traduit le workflow des services exposables et le SLA en composants de service exécutables avec la QoS demandée. On mentionne que la combinaison des fonctions des composants de service et leur QoS permet d assurer les besoins des utilisateurs. - Filter FMSC : trouve la combinaison logique) selon la liste des ID-BSC limité par un cercle avec un rayon Я et un centre {LO, LA} qui correspond à la position géographiques de l utilisateur au moment de l établissement de la session pour offrir des services selon le contexte ambiant de l utilisateur. - Attach_VPSN AMSC : ajoute l ID-VPSN au profile du composant de service. Un composant de service peut être mutualisé entre plusieurs VPSN. Donc l AMSC vérifie la QoS statistique en se basant sur les valeurs de conception pour contrôler l attachement d un composant de service à un nouveau VPSN. - Maintenance VPSN MMSC : ajoute les informations du composant de service logique) à la table VPSN. Durant la session de service, le MMSC maintient le VPSN en mettant à jour la table VPSN dans le cas où la QoS est dégradée. Il assure le remplacement des informations du composant de service dégradé par celle d un autre composant qui est fonctionnellement et QoS équivalent. 9 / 34

10 La création du VPSN représente les différentes étapes pour créer la «table VPSN». En effet, la table VPSN contient la chaine logique de tous les composants de service BSC qui assurent la fonction des services exposables avec la QoS requise. Le processus de la création est lancé par la plate-forme de service après avoir reçu le message SIP+ INVITE à travers IMS. Premièrement, le RMSC extrait les informations à partir du corps du message SIP+ INVITE. Deuxièmement, le TMSC est invoqué pour traduire le workflow des services exposables en une liste de BSC exécutables avec les critères de QoS requis : {SExpα=BSC1.1+BSC1.2, SExpβ=BSC2.1+BSC2.2+BSC2.3, SExpγ =BSC3.1}. Le résultat est la liste des BSCs avec la QoS offerte adéquate. Troisièmement, le FMSC est invoqué pour trouver la combinaison pour chaque BSC selon la position géographique de l utilisateur pour gagner en terme de temps de réponse durant la phase opérationnelle parce qu il existe plusieurs BSC ubiquitaires qui sont déployés dans différentes plates-formes. Initialement, la recherche est effectuée dans la zone ambiante de l utilisateur qui est limitée par un rayon R et le résultat est envoyé par la suite à l AMSC. Si la recherche n aboutit pas, on incrémente le rayon R jusqu'à ce qu on trouve le BSC qui réponde au besoin de l utilisateur. Ensuite l AMSC utilise le résultat obtenu pour vérifier les capacités statistiques de chaque BSC de la liste pour joindre le VPSN. Si le résultat est positive, l AMSC ajoute l ID-VPSN au profile du BSC dans la base de connaissance «INFOWARE». Ensuite, l infoware envoie un évènement à l MMSC pour ajouter le BSC sélectionné à la table VPSN. Finalement, la table VPSN est créée et elle contient la chaine logique de tous les BSC et leur ordre d exécution. Le diagramme de Séquence ci-dessous représente les différentes interactions entre l utilisateur, les composants de service de type gestion et l infoware. 10 / 34

11 Figure 3 : Diagramme de séquence de la création du VPSN A la fin de ce processus nous avons pré provisionné nos composants de service par le double attachement (SE/VPSN et VPSN/SE) sans réserver effectivement les ressources. Le provisioning se fait au moment de la consommation des services. 2.4 Consommation des services (provisioning) La consommation des services au cours de la session user-centric se fait en fonction des transactions (Figure 4), définies par l utilisateur au moment de l ouverture de la session. Une transaction permet l exécution d une sélection d un ensemble de services exposables. En effet, durant la transaction l utilisateur envoie sa requête de consommation des services selon sa logique de service. 11 / 34

12 La consommation de service se traduit par la réservation réelle des ressources (provisioning) pendant la phase de l exploitation grâce à l'agent QoS ( 2.4.1) et de son autogestion ( 2.4.2) ainsi que les mécanismes de gestion de la file d attente ( 2.4.3) Agent de QoS de la ressource service Figure 4 : Transaction. Pendant l Usage, nous avons une réservation dynamique des ressources sélectionnées dans le VPSN (phase de Pré-Provisioning) selon leur QoS Courante. Notre ressource service étant mutualisée entre plusieurs requêtes, nous devons l allouer dynamiquement selon sa QoS Courante afin d optimiser son utilisation. Cette QoS agrège les quatre critères de notre modèle de QoS (Disponibilité, Fiabilité, Délai et Capacité). Pour gérer cette mutualisation nous proposons d associer une File d attente à chaque élément de service qui contiendra toutes les requêtes acceptées par ce BSC. On mentionne que la ressource service comme toutes les ressources contient un agent QoS. Disponibilité/Accessibilité : qui représente le taux de requêtes non acceptées par le BSC. Pour maximiser la disponibilité du BSC, nous déployons un nombre d éléments ubiquitaires pour couvrir la demande (Dimensionnement), et les files d attentes assurent le respect des SLA pour chaque requête. Fiabilité : qui représente le taux d'erreurs des requêtes adressées au BSC. Capacité : qui représente la capacité de traitement moyenne durant une unité de temps. Délai : qui représente le temps de traitement moyen. Pendant l Usage, les requêtes acceptées par un BSC selon la QoS demandée sont insérées dans sa file d attente. L avantage de notre proposition est que nous prenons en compte tous les critères de QoS durant l usage (Figure 5). 12 / 34

13 Figure 5 : Resource Service et exemple de Mutualisation de requêtes Autogestion de la ressource service L'Agent QoS que nous avons intégré, permet de contrôler la QoS courante du BSC et dans le cas où cette QoS se dégrade, il sera remplacé dans les sessions actives (VPSNs actifs) par un autre BSC ubiquitaire. Pour gérer cette ubiquité, nous utilisons le concept des VSC (Virtual Service Community). Chaque BSC fait partie d une VSC regroupant un certain nombre d éléments fonctionnellement et QoS équivalents. L Agent QoS compare la valeur courante de QoS du BSC à sa valeur seuil (à ne pas dépasser). Dans le cas où cette valeur reste inférieure à la valeur seuil il notifie par un «IN Contrat» les autres éléments de service de sa VSC. Dans le cas où cette valeur est supérieure à la valeur seuil, il notifie par un «OUT Contrat» les autres membres de sa communauté (Figure 6) afin qu il soit remplacé dans les sessions actives. Cette notification peut se faire ou bien en multicast vers tous les membres de la communauté et le choix du remplaçant se fera par le premier qui répond au BSC dégradé ou en peer-to-peer, chacun notifiant son voisin. Figure 6 : Autogestion par l Agent QoS et VSC Puisque chaque BSC fait partie d une VSC et possède sa propre file d attente, nous proposons de gérer ces files d attentes appartenant aux BSC ubiquitaires (même VSC) dans des communautés de files d attente ubiquitaires (Virtual Queue Communities : VQC). Ces VQCs nous permettent de maintenir le SLA de chaque requête dans la file d attente. L avantage des VSCs étant de maintenir la QoS du BSC dans tous les VPSNs actifs, l avantage d avoir ces VQC est de pouvoir envoyer immédiatement les requêtes non servies par le BSC vers la file d attente disponible et ayant la capacité de recevoir cette requête (respect des SLAs des requêtes). Ainsi, ces deux concepts de VSC et de VQC nous permettent d avoir une autogestion permettant de maintenir la QoS et d anticiper les violations des SLAs. Dans ce qui suit, nous allons détailler le mécanisme de gestion de la QoS au niveau de la file d attente Mécanisme de gestion de la file d attente Nous avons intégré pour chaque file d attente un Agent QoS qui contrôle la QoS de la file selon les quatre critères de QoS en terme de : 13 / 34

14 Disponibilité/Accessibilité : elle représente le taux de requêtes rejetées par la file. Pour maximiser la disponibilité de la file, nous déployons un nombre de files ubiquitaires pour couvrir la demande (Dimensionnement). Fiabilité : elle représente le taux d'erreurs généré par la file. Capacité : elle représente la taille de la file. Délai : il représente le temps d attente moyen pour chaque requête. L Agent QoS de la File d attente permet d assurer le respect des délais des requêtes dans la file. Car toutes les requêtes dans la file d attente ont une QoS de bout en bout à respecter et un délai à ne pas dépasser. Si le délai d attente dans la file dépasse un délai seuil, la requête sera envoyée vers une file ubiquitaire qui peut satisfaire cette requête. Cet Agent contrôle le temps d attente des requêtes et dans le cas où il détecte un «Out Contrat» il notifie le VQC qui va exécuter son algorithme afin d envoyer celle dont le délai va expirer vers une autre file ubiquitaire. Le mécanisme de gestion (Figure 7) est comme suit : L agent QoS de la file d attente contrôle dynamiquement la QoS de la file en comparant la valeur courante à la valeur seuil à ne pas dépasser (ces valeurs dépendent fortement du délai d attente des requêtes). La QoS de la file dépend de la QoS du BSC. Par exemple si le BSC traite dans un délai moyen donné et une capacité d un nombre de requêtes par unité de temps, ces valeurs vont nous déduire le temps d attente moyen pour chaque (requête) dans la file. Dans le cas où la valeur courante dépasse la valeur seuil (signifiant qu une requête a pris plus de temps de traitement par exemple générant un retard d attente pour la requête suivante dans la file), l agent QoS va notifier le «VQC Management» par un Out contrat. Le «VQC Management» va déclencher son algorithme de gestion et calculer l estimation du temps que va passer toutes les requêtes qui sont provisionnées après cette requête qui a pris du retard. Il va ainsi décider lesquelles risquent d expirer. Le «VQC Maintenance» interagit avec notre base informationnelle «INFOWARE» afin de trouver une file d attente ubiquitaire disponible (VQC Profile) pour chaque requête sélectionnée (ID_Request, ID_VPSN de la requête). Pour chaque ID d une requête sélectionnée comme risquant de ne pas maintenir son SLA, le VQC envoie toutes celles ayant le même VPSN_ID vers une même file d attente ayant la capacité de prendre ces requêtes. Ceci est nécessaire car dans une file d attente nous pouvons avoir plusieurs requêtes d un même utilisateur (même VPSN) et nous devons garder la traçabilité de la session et de la transaction. 14 / 34

15 Figure 7: Mécanisme de gestion de la file d attente Dans la Figure 8, nous avons un exemple où la requête «Req3» est dans la file d attente de l élément de service BSC5.5 car sa QoS accepte cette requête. La file contient aussi trois autres requêtes (Req0, Req1 et Req2). Pendant l Usage, la requête «Req0» va prendre plus de temps de traitement sur le BSC5.5 que ne prévoit la moyenne. Ceci est dû, par exemple, à un grand nombre de données à traiter ou à des accès plus long vers les bases données et non pas à un dysfonctionnement du BSC (sinon l'agent QoS du nœud l'aurait signalé et c est aux VSC de gérer cette dégradation). L agent QoS de la file d attente va notifier le VQC d un «Out contrat» afin de contrôler le temps d attente de chaque requête dans la file. Dans ce scénario, le temps d attente de la requête «Req1» va dépasser le temps d attente moyen, le VQC_Management va déclencher son algorithme de calcul. Ainsi le VQC trouve que «Req3» risque de dépasser son temps d attente dans cette file et prend la décision d envoyer cette requête vers une file d attente qui répond à sa demande. Dans cet exemple la requête est envoyée vers la file d attente de BSC / 34

16 Figure 8: autogestion (VSC, VQC) 3 Gestion de la session User-centric basée QoS Dans de nombreuses situations, notamment lors de la mobilité, un composant de service de base qui est en cours d exécution durant une session de service ne peut pas continuer à fonctionner normalement ou bien à satisfaire les besoins des utilisateurs en termes de QoS. C'est la raison pour laquelle nous résolvons un tel problème en proposant des mécanismes pour adapter parfaitement la session de service de l'utilisateur contre toute détérioration de QoS causée par la mobilité. Pour ce faire, nous avons automatisé et distribué le contrôle et la gestion au niveau du service. Comme nous venons de le décrire ci-dessus, l'autogestion de la qualité de service est assurée par chaque composant de service de base qui participe à la session de service de l'utilisateur. En fait, nous rappelons que notre vision de gestion est basée sur un agent de QoS intégré dans chaque BSC et un autre dans la file d'attente associée. C'est le message NOTIFY du protocole SIP qui est utilisé : «IN Contract» et «Out contract». La Figure 9 représente la structure d'un message SIP+ NOTIFY utilisé pour gérer la session de service. Les champs utiles dans l en-tête du message SIP+ NOTIFY qui sont utilisés pour notifier l'état de QoS (IN / OUT contrat) d un composant de service en cours d exécution sont les suivants: - Allow-Events: il permet la notification des événements concernant le contrat de qualité de service (IN/OUT contract) - Event: Ce champ est utilisé pour envoyer l état de qualité de service (IN Contract /Out Contract) d un composant de service 16 / 34

17 Figure 9 : Structure du message SIP+ NOTIFY Nous allons décrire un scénario qui montre la gestion automatisée de la session de service de l'utilisateur en fonction des différents types de mobilité. Tout d abord, nous supposons que lorsque l'utilisateur (point A) est à la maison (emplacement: {LO, LA}), il veut une chaîne de service contenant Sexp α, Sexp β et Sexp γ (Figure 1). La composition de services basés sur les besoins des utilisateurs (pré-provisioning) est: BSC1.1 + BSC1.2 +BSC2.1 + BSC2.2+ BSC2.3 + BSC3.1. Au cours de l'exploitation (Figure 10), la performance du BSC2.2 (point B) se détériore et ne peut pas fournir la QoS nécessaire au SExp β. Par conséquent BSC2.2 envoie un SIP+ NOTIFY message en multicast à tous les membres de sa communauté VSC pour procéder à son remplacement. Il existe toujours des candidats pour remplacer ce BSC2.2 défaillant. Une fois que la communauté VSC trouve le BSC2.2 de remplacement (point B ') sur une autre plateforme, il invoque le composant de gestion MMSC en envoyant un message contenant les informations suivantes : logique BSC 2,2 et l'id-vpsn afin de mettre à jour la table du VPSN. Ensuite, la connexion est transférée du BSC2.2 à BSC2.2 (provisionnement dynamique). Puis l'utilisateur (point A) se déplace (mobilité du terminal) et quand il arrive à son bureau (point A '), il change son terminal PDA PC (la mobilité de l utilisateur). Dans ce cas, en raison du changement de l'emplacement du point A {LO, LA} au point A '{LO, LA'} et le changement du terminal PDA PC, les composants de service de base BSC1.1 BSC1.2 ne peuvent plus satisfaire les exigences de l'utilisateur. Par conséquent, le système doit assurer leur remplacement par de nouveaux services BSC4.1 + BSC4.2 adaptés au nouveau terminal de l utilisateur. Par conséquent, nous obtenons après la mobilité un re-provisioning dynamique: BSC2.1+BSC2.2'+BSC2.3+BSC3.1+BSC4.1+BSC4.2. Finalement, la session de service de l'utilisateur est maintenue et la prestation de services est effectuée. Il convient de mentionner que tous ces changements sont transparents pour l'utilisateur et ils sont effectués automatiquement par le système au cours de la session user-centric. 17 / 34

18 Figure 10: scénario NGN/NGS 4 Handover Sémantique pour une continuité de service sans couture dans l environnement ambiant Nous allons présenter dans cette section le même concept de changement de composant de service lors de la mobilité, mais en utilisant un autre critère que celui de la dégradation de QoS. En effet, dans l'internet du Futur, il est prévu de partager la toile en zones ambiantes. C'est cette composante qui jouera un rôle important dans la stratégie des nouveaux écosystèmes et que nous allons prendre comme critère. Après une introduction (4.1), nous décrivons un scénario (4.2) sous l'angle de cette composante de zone ambiante pour ensuite décrire ce mécanisme que nous avons dénommé "Handover Sémantique" (4.3). 4.1 Introduction La mobilité est l un des challenges que nous avons identifié dans le nouveau contexte NGN/NGS. Nous avons précédemment comment gérer cette mobilité par la QoS. Le concept utilisé est les communautés d intérêts nommés VSCs, où chaque élément de service appartient à une VSC regroupant des ESs fonctionnellement et QoS équivalents, ainsi dans le cas où la QoS d un ES se dégrade la gestion des VSCs permet de changer l ES par un autre fonctionnellement et QoS équivalents. Tout ceci permet de maintenir la QoS offerte par l élément de service, mais afin d optimiser le partage de valeur, toute ressource ambiante équipement, réseau ou service dans la localisation de l utilisateur peut être utilisée. La mobilité engendre un changement de localisation qui nécessite déjà une adaptation au niveau du réseau d accès et du réseau cœur apportée par les solutions de Handover Réseau selon la zone ambiante dans laquelle se trouve l utilisateur. Ce Handover permettra de maintenir la QoS 18 / 34

19 demandée par l utilisateur mais ne peut pas assurer dans la plupart des cas une continuité de service sans couture. Afin d assurer la continuité de service pendant la mobilité nous proposons donc d avoir en plus du Handover au niveau réseau d accès et réseau cœur, un Handover au niveau service. Ce Handover nommé Handover Sémantique va permettre de changer d éléments de service dans la session de l utilisateur par zones ambiantes. Le changement de l élément de service peut être dû au changement de localisation, au changement de terminal ou au changement du contexte ambiant (par exemple les préférences d un opérateur ou d un prix de l ES par rapport au contexte). Dans ce qui suit nous allons présenter comment fonctionne le Handover Sémantique en l illustrant d abord par un scénario. 4.2 Scénario selon des zones ambiantes Sur la Figure 12, nous avons un utilisateur qui a initialisé sa session dans sa maison, composé de trois éléments de service (Création de VPSN1) : SE1b =Mail, SE5a=VoD et SE6a=VoIP, sur son ordinateur. L accès aux services se fait par un réseau d accès DSL et un réseau cœur IP. VPSN1 = SE1b, SE5a et SE6a. Cet utilisateur se trouve dans une zone géographique délimitée par un rayon R1 par rapport à sa position géographique (Longitude et Latitude). Zone1 = User_Longitude1, User_Latitude1 et R1. Cet utilisateur est nomade et peut changer de localisation, changer de terminal ou de préférences. Notre but est qu en plus du Handover qui se fait au niveau du réseau d accès et du réseau cœur d effectuer un Handover au niveau service qui se déclencherait suite à certains événements reçus. Pour les éléments de service, nous avons des éléments de service ubiquitaires déployés dans différentes zones ambiantes (Figure 11). Ces ESs peuvent être de différents opérateurs, leurs prix peuvent différer d une zone de localisation à une autre et l autorisation d accès à ces services peut différer d un utilisateur à un autre. 19 / 34

20 Figure 11 : Les ressources dans la zone ambiante Cas 1 (Mobilité de l utilisateur): Cet utilisateur décide de sortir et va basculer sa session sur un autre terminal, par exemple sur son iphone. L adaptation pour le réseau d accès et le réseau cœur se fait et la session est accessible ainsi par le réseau d accès UMTS et le réseau cœur IP. Pour le Handover au niveau Service, nous allons remplacer l élément de service SE5a (VoD) par un autre élément de service équivalent sur le iphone et accessible par l UMTS dans cette zone ambiante (Zone1), ainsi le Service de Gestion du Handover Sémantique (SHS1) qui se trouve sur la même plate-forme (SP1) que SE5a va le remplacer par SE5d. Le VPSN2 = SE1b, SE5d et SE6a. Cas 2 (Mobilité du terminal) : L utilisateur veut rejoindre son bureau et se déplace donc avec son terminal. Ainsi, le Handover au niveau du réseau d accès et du réseau cœur est déclenché suivant cette mobilité. Le Handover au niveau du réseau d accès se fait selon la couverture de sa 3G, quand le signal s affaiblit dans une zone de localisation, le réseau va basculer sur un autre point d accès. Pour effectuer un Handover au niveau service, nous considérons les déplacements de l utilisateur par zone ambiante d un rayon R1. Donc le Handover Sémantique se déclenche une fois que le terminal de l utilisateur s est déplacé d un rayon R1 ce qui veut dire qu il a changé de zone. Notre but est qu une fois que l'utilisateur rentre dans la nouvelle zone ambiante (déplacement d un rayon R1 par rapport à sa position), un Handover est effectué au niveau des éléments de service qui ne sont pas localisés dans la nouvelle zone ambiante de l utilisateur. 20 / 34

21 Ainsi, pour l élément de service SE1b qui se trouve sur la plate-forme de service SP4, le SHS qui se trouve dans cette même plate-forme (SHS4) va regarder si cet ES est dans la nouvelle zone ambiante de l utilisateur, dans ce cas là il ne fait rien, dans le cas contraire il va rechercher des éléments de service ubiquitaires (fonctionnellement et QoS équivalents) dans la nouvelle zone ambiante afin d effectuer le Handover. Dans notre exemple, le SHS4 va sélectionner SE1e pour remplacer SE1b. Pour SE5d, c est le SHS1 qui se trouve sur la plate-forme SP1 qui va décider de son Handover et va sélectionner SE5c pour le remplacer dans cette nouvelle zone. Le SHS5 qui se trouve sur la même plate-forme que SE6a va décider de ne pas effectuer de Handover sur lui car il se trouve dans la même zone ambiante que l utilisateur. Ainsi, la session (VPSN) de l utilisateur dans la nouvelle zone ambiante est composée des éléments de service SE1e, SE5c et SE6a. VPSN3 = SE1e, SE5c et SE6a. Zone2 = User_Longitude2, User_Latitude2 et R1. Cas 3 (Préférences de l utilisateur par rapport au contexte ambiant) : L utilisateur va sélectionner et ajouter de nouveaux ESs ou remplacer des ESs par d autres (découverts dans cette nouvelle zone) à sa session (VPSN) par rapport au contexte ambiant dans lequel il se trouve, dans l exemple nous avons un nouvel élément de service (SE2c) découvert dans la zone ambiante Zone3, ajouté au VPSN de l utilisateur et le remplacement (Handover Sémantique) de l élément de service SE1e par SE1g pris chez un autre opérateur qui permet de ne pas payer plus cher (Préférence de l utilisateur prise en compte) dans cette zone de localisation (Zone3). Après le Handover effectué par SHS2 pour remplacer SE1e par SE1g, le VPSN4 de l utilisateur est composé de SE5c, SE6a, SE2c et SE1g. VPSN4 = SE5c, SE6a, SE2c et SE1g. Zone3 = User_Longitud3, User_Latitude3 et R1. 21 / 34

22 Figure 12 : Scénario de Handover au niveau service Nous définissons ce concept de Handover Sémantique et détaillons son fonctionnement dans la section suivante. 4.3 Concept du Handover Sémantique Par analogie aux Handover dans le réseau d accès et le réseau cœur, nous proposons un Handover au niveau service. Il existe différentes solutions existantes du Handover au niveau réseau et nous avons constaté que nous avions trois rôles principaux dans le processus du Handover réseau, qui sont l Initiateur, le Décideur et l Exécuteur du Handover. Chaque rôle peut être joué par un même ou différents acteurs (BSC, MSC, ). Pour le Handover au niveau service nous avons défini trois rôles : L Initiateur du Handover : représente l entité qui détecte un changement et qui initie le Handover en envoyant une notification d initiation du Handover vers le décideur. 22 / 34

23 Le Décideur du Handover : représente l entité qui reçoit l événement du Handover et qui décide d effectuer un Handover sémantique ou pas en se basant sur les informations récupérées en interagissant avec d autres entités de l architecture. L Exécuteur du Handover : représente l entité qui exécute la décision prise par le décideur. Pour chacun des trois rôles nous définissons des acteurs, ainsi nous avons : Pour le rôle d initiateur, nous avons le Terminal Userware, ou la base informationnelle Infoware qui peut détecter un changement ou un événement nécessitant d effectuer un Handover. Pour le rôle du décideur, nous proposons un service de gestion du Handover Sémantique dénommé : Semantic Handover Service (SHS). Ce Service déclenche le processus du Handover suite à une mobilité du terminal, à une mobilité de l utilisateur ou à un contexte ambiant. Nous proposons de déployer un SHS dans chaque plate-forme de service afin qu il prenne en charge les ESs qui sont déployés dans sa plate-forme. Pour le rôle d Exécuteur, nous avons le service de gestion du VPSN, dénommé le VPSN Maintenance qui s occupe de maintenir la session de l utilisateur qui va exécuter la décision prise par le SHS Initiateur du Handover L initiation du Handover peut être due aux événements suivants : Mobilité du Terminal, Mobilité de l utilisateur ou Préférences de l utilisateur. - Initiation due à une mobilité du terminal Durant la mobilité, l utilisateur se déplace et les informations sur sa position géographique sont envoyées à partir de son terminal vers la base informationnelle qui enregistre ces informations (Figure 13). Quand le réseau détecte ces changements de localisation et qu il constate un affaiblissement du signal de la communication du terminal il initie le Handover au niveau réseau. Dans le réseau, l initiateur du Handover peut être le même acteur que celui qui va décider d effectuer le Handover ou un acteur différent. L initiation du Handover au niveau service se fait selon le déplacement par zone délimitée par la localisation géographique de l utilisateur (sa longitude et sa latitude) et un rayon R x prédéfini par l opérateur. Les informations sur la localisation géographique de l utilisateur (User_Longitude, User_Latitude) sont enregistrées dans sa base informationnelle INFOSPHERE, si ces deux paramètres changent d un Rayon R x, un déclencheur réagit dans l Infosphère qui envoie une notification d un changement de zone vers l INFOWARE : Notify Area Change. Notre base informationnelle INFOWARE est événementielle et inférente. Tout changement dans cette base peut déclencher des changements ou des notifications vers d autres acteurs. La mise à jour (modification) de la localisation de l utilisateur dans son profil (User Profile) va induire un «Déclencheur», dans lequel pour chaque ligne du profil VPSN (chaque Service_ID), il va envoyer une notification vers son SHS_ID (Pris du Service Profile de ce Service_ID) afin d initier le Handover Sémantique : Notify Mobility Handover (User_ID, Location, Service_ID). 23 / 34

24 Figure 13 : Déclencheur dans l Infoware Ainsi le Handover est initié dans chaque SHS qui a la charge d un ou plusieurs Services faisant partie de la session (VPSN) de l utilisateur. Figure 14 : Initiation du handover sémantique - Initiation due à une mobilité de l utilisateur La mobilité de l utilisateur signifie qu il change de terminal. Afin de maintenir la session de l utilisateur durant ce changement, nous avons un basculement de l attachement du VPSN de l ancien terminal vers le nouveau terminal, mais les éléments de service faisant partie de ce VPSN 24 / 34

25 peuvent ne pas être adapté au nouveau terminal ou aux préférences prédéfinies de l utilisateur, pour cela le Handover Sémantique peut être nécessaire pour remplacer des éléments de service par d autres adaptés au contexte ambiant de l utilisateur. Ainsi l événement qui montre une mobilité de l utilisateur est l identification de l utilisateur sur un nouveau terminal et sa requête d attachement sur sa session active (son VPSN). Ces informations sont mises à jour sur l Infosphere (UserProfile) et notifiées vers l Infoware. Ainsi, si nous avons une mise à jour d une identification de l utilisateur sur un nouveau terminal dans l Infoware, cette dernière par inférence va mettre à jour d autres informations appropriées selon l événement reçu et peut déclencher des «déclencheurs» de Handover Sémantique quand c est nécessaire. - Initiation due à un changement de préférences selon le contexte ambiant L utilisateur peut avoir prédéfini des préférences d utilisation des services selon le contexte ambiant dans lequel il se trouve, par exemple, il préfère utiliser un service fourni par un tel opérateur à tel localisation géographique ou dans tel contexte ambiant. Dans ce cas là, le Handover Sémantique est initié quand un tel événement se déclenche pour remplacer l élément de service concerné par celui qui est approprié Décideur du Handover Dans le Handover réseau, le rôle de décideur peut être joué par différents acteurs. Par exemple dans le GSM le rôle de décideur peut être joué soit par le BSC (cas de Handover intra- BSC) ou par le MSC (cas de Handover inter-bsc). Dans notre concept de Handover Sémantique, le rôle de décideur est joué par un seul acteur qui est le SHS dans chaque plate-forme de services. Quand le SHS reçoit une notification d une mobilité du terminal et une liste de services dont il a la charge, il déclenche son processus de préparation de Handover (Figure 15) que nous détaillons dans les étapes suivantes : (a) Le SHS reçoit une notification pour initier le Handover concernant les services dont il a la charge : Notify Handover Initiation (User_ID, User_Longitude, User_Latitude, List of Service_IDs). (b) Le SHS va rechercher dans la zone ambiante de l utilisateur qui est délimitée par sa Latitude et sa Longitude et un Rayon R1 prédéfini, si chaque Service_ID reçu se trouve dans cette zone. Si c est le cas alors il ne fait rien (pas de Handover déclenché). Dans le cas contraire il va déclencher le Handover sémantique : search if Geo-Location of Service_IDs Location (User_Longitude, User_Latitude, R1). (c) Le SHS va interagir avec l INFOWARE afin de lui demander la fonctionnalité et la QoS pour chaque Service_ID qui n est pas dans la zone ambiante (Service Profile). (d) Le SHS va interagir avec le service de gestion de découverte DBS afin de rechercher les services ubiquitaires qui ont la même fonctionnalité et la même QoS pour chaque Service_ID dans la zone fournie (User_Latitude, User_Longitude et R1). (e) Le service de gestion DBS va fournir la liste des ESs ubiquitaires. (f) Le SHS va interagir avec le service de gestion de Présence PBS afin de connaître l état 1 (Disponible, Indisponible, Activable ou Activé) de chaque ES fourni par le DBS. (g) Le SHS va filtrer les services en excluant ceux qui sont indisponibles, puis va choisir pour chaque Service_ID un service ubiquitaire qui peut le remplacer. Le choix peut se faire selon le 1 L'état de SE est défini dans le plan de gestion du SE 25 / 34

26 premier de la liste, celui qui se rapproche le plus dans son intervalle de QoS, celui appartenant à un certain fournisseur ou selon un autre critère prédéfini selon la politique de l opérateur. (h) Une fois le SHS a décidé des services (New Service_IDs) qui vont remplacer ceux pour lesquels il a déclenché le Handover (Old Service_IDs), il va envoyer les deux catégories de services vers l Exécuteur du Handover : Notify VPSN Maintenance (User_ID, List of Old Service_ID, List of New Service_ID). Figure 15 : Décision du handover sémantique Exécuteur du Handover L Exécuteur du Handover peut être le même acteur qui décide du Handover ou un acteur différent. La session de l utilisateur constitue son VPSN et elle est maintenue par un service de gestion qui est le "VPSN Maintenance", ainsi ce dernier constitue notre Exécuteur de Handover (Figure 16). Le rôle du "VPSN Maintenance" est de maintenir tous les services choisis par l utilisateur pour faire partie de sa session, et d adapter ces services dans le cas d une dégradation 26 / 34

27 ou de tout autre changement (mobilité, préférences, ). Le "VPSN Maintenance" reçoit une notification de la part du SHS afin d exécuter le Handover Sémantique. Le "VPSN Maintenance" va attacher chaque nouveau service sélectionné par le SHS. L attachement est effectué en ajoutant les Nouveaux Service_ID dans le VPSN Profile dans l INFOWARE. Une fois l attachement effectué, puis le "VPSN Maintenance" va détacher chaque service remplacé dans le VPSN Profile. Notre base informationnelle n étant pas centralisée, une mise à jour par inférence est réalisée entre les différents fragments d INFOWARE sur les autres plates-formes. Figure 16 : Exécution du handover sémantique Conclusion : Handover Sémantique En plus de la gestion de la mobilité par la QoS proposée, dans cette partie nous avons montré comment gérer la mobilité par zones ambiantes. Pour cela nous avons proposé et spécifié un handover sémantique au niveau service qui permet de changer un élément de service quand l utilisateur s est déplacé d un rayon donné. Par analogie aux concepts du handover au niveau du réseau d accès et du réseau cœur, le handover sémantique proposé est basé sur trois rôles, l initiateur, le décideur et l exécuteur. L initiateur, permet de détecter le déplacement par un rayon donné et d initier donc le handover sémantique. Le décideur (SHS) permet de sélectionner les éléments de service dans la zone délimitée pour le handover de service. L exécuteur, permet d exécuter la décision (choix des ESs déployés dans la zone ambiante) prise par le décideur. En utilisant ce concept de handover sémantique nous pouvons garantir la continuité de services lors des mobilités et d adapter la session de services (VPSN) au nouveau contexte ambiant de l utilisateur, tout en tenant compte de ses préférences fonctionnelles et non-fonctionnelles (critères de QoS). 27 / 34

28 5 Modèle architectural : Couche Service avec une approche SOA/EDA Afin de structurer l ensemble des concepts qui caractérisent notre approche convergente de bout-en-bout, nous allons rappeler les points clés de notre proposition de modèle architectural horizontal qui s appuie sur l approche de Middleware. Cette modélisation favorise l interaction dynamique entre des services distribués et facilite la composition des applications (services globaux) réparties. En effet, notre couche de service (Middleware Figure 17) est structurée en trois parties : Services Exposables SEIB Services de Base Figure 17: Modèle Middleware Le SEIB (Service Elements Interconnection Bus): c est un bus d interconnexion entre plusieurs éléments de services afin de créer des services exposables. Il supporte d une part une composition de services qui est horizontale, dynamique et à couplage lâche (personnalisation de services dans un contexte NGS), et d une autre part une agrégation verticale de tous les composants qui interviennent sur les quatre niveaux de visibilité d une session (utilisateur, équipement, réseau, service). Les Services de Base (en dessous du SEIB): sont un ensemble de services communs à tout le monde. Ils comportent des services IT (facturation, etc.), des services de sécurité (autorisation, etc.) ainsi que des services de gestion de QoS, de mobilité et d hétérogénéité. Par conséquent, cette partie permet de rendre transparent le réseau sousjacent et assure ainsi la convergence NGN/NGS en intégrant des services de bases qui répondent aux défis du contexte NGN. Les Services Exposables (au dessus du SEIB): sont des services applicatifs à valeur marchande. Ils sont normalement créés suite à une composition de services incluant des services de base. Comme leur nom indique, ils seront exposés dans les catalogues des fournisseurs de services et des opérateurs pour que les utilisateurs puissent les sollicités. Il faut noter que suite à notre approche P2P (Peer-to-Peer), un utilisateur peut être lui même un fournisseur de services. Dans le paragraphe suivant, nous présentons d une manière plus explicite et plus détaillée notre modèle architectural, dénommé NGN/NGS Middleware. 28 / 34