IBTS-77-RP-1000
User centric et E2E QoS
Le principe de «User-centric» signifie que le système complet est à l’écoute des besoins et des préférences de l’utilisateur. Bien que nous puissions penser que cela est toujours le cas, il n’en est rien ! En effet, dans la phase de l’analyse des besoins nous tenons compte, bien sûr, de ceux de l’utilisateur, mais nous concevons et réalisons ensuite des solutions selon d’autres approches. Nous trouvons l’approche «Système-centric» dans laquelle l’utilisateur doit se conformer aux contraintes de traitements du matériel, bien qu’aujourd’hui nous levons ces contraintes avec les machines virtuelles (VM). Nous avons aussi les approches «Réseau-centric» qui impliquent que le réseau soit au centre de l’architecture et conditionne toutes demandes de services. Et enfin, pour la grande majorité des solutions nous trouvons les approches «Application-centric» qui se concentrent sur l’application et la considèrent comme le point focal, avec des architectures « client – serveur ».
Dans une approche «User-centric», l’utilisateur a une accessibilité de service par n’importe quel terminal (Adaptation + préférences), une personnalisation de service par la composition de service dynamique et flexible. Tout ceci durant une unique session, même si les services sont différents. Durant l’usage, cet utilisateur se déplace et personnalise ses services sans aucune limite, ainsi sa session est dynamique avec des services ubiquitaires qui remplacent ceux faisant partie de la session, qui s’ajoutent à la session ou qui changent selon le contexte ambiant, les réseaux d’accès et les terminaux changent aussi durant cette session mobile, pour cela sa QoS E2E (SLA) durant sa session mobile doit être maintenue. Ayant un même modèle appliqué aux différents acteurs (équipement, réseau et services), qui ont des rôles complémentaires nous permet d’assurer la QoS E2E.
Les solutions existantes pour le Déploiement de services
Dans le but d’avoir une gestion efficace du déploiement, les fournisseurs de service doivent déployer leurs services dans la plate-forme qui satisfait à la demande du service et d’avoir assez d’éléments de service ubiquitaires pour satisfaire le SLA des utilisateurs nomades. Le déploiement de service consiste à trouver les ressources disponibles et accessibles, et de déployer et configurer le service sur ces ressources de sorte qu’ils puissent répondre à la QoS désirée. Nous présentons quelques uns des travaux existant dans le déploiement de service.
Projet OPUCE (Open Platform for User-centric service Creation and Execution) [JCY07] : est un projet intégré, 6ème Framework Programme, visant à développer une plateforme complète pour la création, le déploiement et l’exécution des services centrés sur l’utilisateur (User- Centric). L’objectif de la plate-forme OPUCE est de mettre l’utilisateur final au centre du cycle de vie entier d’un service, pour le laisser devenir en même temps le créateur de services personnalisés, leur déployeur, leur gestionnaire et leur consommateur.
Dans OPUCE, le déploiement est basé sur « la description du service » qui contient toutes les données nécessaires pour déployer le service, ainsi le provisioning de service est effectué automatiquement en utilisant la description du service pour spécifier les détails de provisioning pour chaque service.
Avec cette approche, les concepts de service sont redéfinis. Le service est créé par l’utilisateur en orchestrant des services de base créés et déployés par l’opérateur. Ces services de base sont considérés comme des unités fonctionnelles déployées par l’opérateur ou des partenaires autorisés, disponibles dans la plate-forme OPUCE et offertes aux utilisateurs finaux à travers des interfaces web.
Dans ce projet les services sont composés dynamiquement selon le contexte et les préférences de l’utilisateur, par exemple l’utilisateur compose un service mail intelligent qui transmet un mail entrant en fonction de la situation de l’utilisateur et du terminal utilisé, par exemple, si l’utilisateur est en train de conduire, le mail est transmit via un Text-to-Voice, si l’utilisateur n’est pas connecté à son PC de bureau, le service envoie un SMS contenant le sujet du mail et l’expéditeur. Les services de base utilisés ici par l’utilisateur sont un service de messagerie, service SMS et un service Text-to-Voice et un service de contexte utilisateur.
Le déploiement est intéressant du fait qu’il soit basé sur une composition de service dynamique. C’est à dire que la composition peut changer selon les préférences de l’utilisateur et son contexte prédéfini. Mais quand l’utilisateur est mobile, cette composition ne change pas afin de maintenir la QoS demandée. Elle ne se recompose pas suivant les possibilités des zones ambiantes et la prise en compte des services de base proposés par les autres fournisseurs. Alors que les utilisateurs d’aujourd’hui sont mobiles et veulent une assurance de la continuité du service et un maintien de la QoS durant le déplacement. Ce maintien de la QoS ne peut être obtenu que si l’on prend en compte le comportement du service, traduit par sa QoS et de pouvoir dynamiquement changer les services faisant partie de la composition de service par d’autres services ubiquitaires.
Les solutions existantes pour le Provisioning de services
L’un des défis à relever dans le traitement d’une demande utilisateur est la façon d’effectuer une réservation dynamique et efficace des ressources, et de pouvoir s’adapter aux changements de contexte de telle sorte que la QoS offerte peut toujours satisfaire les exigences de l’utilisateur. Le Provisioning de ressources est le processus qui recherche les ressources disponibles et accessibles, les réservent et les affectent afin de répondre aux besoins de la demande en cours. De nombreux travaux de recherche ont été effectués dans le provisioning des ressources réseaux et équipements (Média Delivery).
Dans le contexte NGN/NGS, la QoS est introduite dans tout type d’application et devient de plus en plus importante. Les exigences de l’utilisateur au niveau applicatif sont de plus en plus complexes. Ainsi, la gestion des ressources doit être plus flexible, ce qui fait que le provisioning des équipements et réseaux ne sont plus suffisants et que le provisioning des services est nécessaire pour faire face aux exigences des utilisateurs d’aujourd’hui. Les travaux de recherche ont proposés des approches dans les décisions de provisioning pour permettre aux fournisseurs de service d’effectuer une distribution dynamique des ressources réseaux et équipements entre les services et les SLAs. Cependant, afin d’offrir une continuité de service sans couture et une QoS stable durant tous types de mobilité, il est aussi nécessaire de provisionner les services applicatifs eux mêmes au niveau service, et de maintenir la QoS en la considérant au niveau applicatif. Nous analysons les solutions apportées par le SON et par SOA dans le provisioning des services.
Solutions de provisioning de services apportées par le SON
Afin que l’utilisateur puisse accéder à ses mêmes services par différents réseaux hétérogènes, le Service Overlay Network (SON) [JWK10] a été proposé comme une couche intermédiaire qui fait converger les différents réseaux pour l’accès aux services.
Le SON permet d’apporter des solutions aux problèmes de QoS dans l’internet d’aujourd’hui et de faciliter la création et le déploiement de services à valeur ajoutée comme la VoIP, le VoD ainsi que d’autres services sensibles à la QoS. Le SON achète de la bande passante avec une certaine QoS garantie à partir de domaines de réseaux individuels via un SLA bilatérale pour construire un overlay de Media Delivery de bout en bout au dessus des réseaux de transport de données existants. Via le contrat de service, les utilisateurs payeront directement le SON pour l’utilisation des services fournis par lui.
Ainsi, la solution apportée par le SON permet le provisioning de la QoS pour un service donné dans le réseau comme par exemple la bande passante, mais pas la QoS des composants de service eux mêmes ni celle d’un service Delivery (Mobilité de service, par exemple). Comme les réseaux de données génériques ont des limitations pour supporter certains types de services, SATO (Service-aware Adaptive Transport Overlay) [MS] permet le Provisioning de services à valeur ajoutée en formant un réseau overlay pour le transport de données avec un plan de signalisation et de control séparé. Quand une mobilité se produit, SATO gère une mobilité de session en réorganisant les ressources ambiantes pour adapter la fourniture de service. Cependant, il manque de flexibilité et ne prend pas en compte tous les aspects (critères) de QoS dans la phase de Provisioning. QSON (QoS-aware SON) [MS07] divise SATO en plusieurs sous-réseaux et chacun correspond à un niveau de QoS. Ainsi, la fourniture du service peut assurer une certaine QoS durant la mobilité. Cependant, la granularité du sous-ensemble de QoS équivalent n’est pas assez flexible pour avoir une adaptation dynamique quand une dégradation de QoS se produit. DSON (Dynamic SON) [EKK09] vise à composer une plate-forme de Delivery de services spécifiques dynamiquement avec des composants de service distribués pour un provisioning de service fiable tout en permettant la mobilité et quel que soit la technologie de transport sous-jacente. Une session de services peut être crée dans le DSON et elle peut être gérée dynamiquement. En outre, le DSON est responsable du provisioning de la QoS.
Cependant, la QoS ne peut être adaptée qu’à la couche réseau transport, il est dommage que dans un environnement de plusieurs fournisseurs de service, une QoS de services ubiquitaires n’est pas prise en compte et ne joue pas de rôle dans le provisioning dynamique.
Solutions de provisioning de services apportées par SOA
Le Service Oriented Architecture (SOA) [TP06] permet de composer des services distribués à couplage lâche indépendamment de la localisation. C’est néanmoins une architecture dont la gestion reste verticale et bien que le provisioning des ressources soit basé sur le SLA/QoS, il ne tient pas compte du service applicatif en tant que ressource à part entière.
M. Boniface et al. proposent dans [MB07] un provisioning de services dynamique en utilisant les SLAs pour maximiser l’utilisation des ressources. Trois questions essentielles sont abordées. La première est la fourniture de services multiples avec de multiples SLAs. Le fournisseur de services doit décider la façon de distribuer ou de partager des ressources, ce qui nécessite un système assez complexe. La seconde, est la stratégie de gérer les violations de SLA. Ils ont proposé de déployer dynamiquement les services applicatifs pour anticiper les violations de SLA. La dernière question est le mapping des paramètres de SLA en des paramètres mesurables. Ils proposent une définition de ce mapping et de stocker la définition dans une base globale. Cette solution est basée sur l’évolution prévue des caractéristiques de QoS de l’équipement et du réseau pour anticiper les violations de SLA, mais elle ne tient pas compte de la QoS courante de l’élément de service. L’un des défis à relever pour une gestion efficace des ressources est de pouvoir anticiper les violations de SLA par la surveillance dynamique de la QoS courante de tous les composants du système. X. Li et al. proposent dans [XL08] une plate-forme de gestion de la QoS dirigée par le SLA, qui gère différentes ressources distribuées et s’adapte aux changements dynamiques de la disponibilité des ressources pour répondre aux besoins de QoS des utilisateurs. Le cycle de vie complet inclue la découverte de service, la négociation de QoS, la réservation et l’allocation de ressources, l’assurance et l’adaptation de la QoS. Cependant on ne trouve pas de reprovisioning dynamique pour prendre en compte le contexte NGN/NGS et pour assurer la continuité de service durant la mobilité. S. Chen et al. proposent dans [SC08] un Context-Aware middleware de gestion de ressources dynamique pour les applications orientées service, qui vise à traiter la dynamicité inhérente aux équipements locaux et au réseau. Basé sur un environnement de coopération de services sécurisés, fourni en regroupant les services dans des communautés virtuelles, une architecture de surveillance inter-couches est désignée pour rassembler les statistiques de performance des services et du réseau. Le service de gestion des ressources est indépendant de la plate-forme. Cette solution prend en charge, de bout en bout le provisioning de la QoS, la coopération de service étendue, la confidentialité et le contrôle complet de chaque fournisseur de service sur ses ressources sous-jacentes. Mais là aussi, les ressources considérées sont seulement les ressources réseau et équipement.
Exemple de Service Delivery
Le service Internet Protocol Television (IPTV) [IPTV] est devenu de plus en plus populaire parmi les entreprises de télécommunications, car il peut offrir des programmes de TV anywhere et anytime. Basé sur le Protocol IP il a l’avantage d’une bande passante efficace et une facilité dans la gestion. Si on regarde l’architecture globale nous pouvons identifier trois parties principales à savoir : Les fonctions de transport : contient les fonctions RACS et NASS, fournit le policy control, la réservation de ressource et contrôle d’admission, contient aussi le Transport Processing qui représente le lien d’accès réseau et le cœur IP.
Les fonctions de Contrôle et d’Applications de services IPTV : contient les services applicatifs et le service delivery : Service Selection Function (SSF) qui fournit la liste des services disponibles que l’utilisateur peut sélectionner, Service Discovery Function (SDF) qui fait la découverte des services IPTV disponibles qui sont compatibles avec l’équipement réseau du consommateur. Service Control Function qui fournit le service d’autorisation durant l’initialisation et la modification de la session, le Credit limit et credit control et sélectionne les fonctions medias appropriées MFs (Media Funtions). Les fonctions Media Delivery, Distribution and Storage : contient les services réseaux : le Media Control Function (MCF) qui possède trois interface, une avec les services applicatifs (SCF), une avec les services réseaux (MDF) et une avec l’User Equipement (UE) pour la gestion de la télécommande.
Le Media Delivery Function (MDF) qui fournit le Media Delivery vers l’UE.
Dans cette architecture nous avons les services applicatifs (SSF, SDF, SCF et MCF) et les services réseaux (MCF et MDF). Les services applicatifs identifient les services générateurs de flux qui doivent être transmis à travers le réseau. De tels services peuvent changer pendant la transmission. Le MCF et le MDF sont concernés par le transport de média via tous les composants réseaux avec l’aide du NASS et le RACS, qui gèrent le Policy Enforcement Point (PEP) comme le policy control pour assurer la QoS.
Ainsi, nous avons un Service Delivery qui complète un Media Delivery pour ce service complexe de l’IPTV. Si cet IPTV était fourni sur des terminaux mobiles, le Service Delivery devra prendre en compte la gestion de cette mobilité pour la continuité de service.
Business Process Framework (eTOM)
Défini par le TMF pour fournir un modèle business et une architecture destinés aux fournisseurs de services et acteurs du secteur des télécommunications. Il décrit l’ensemble des processus d’entreprise utilisés par un fournisseur de services et l’analyse selon différents niveaux de détail selon leur importance et leur priorité. L’eTOM [GB921b] se décompose en 4 niveaux hiérarchiques (de zéro à trois) :
Au niveau zéro, il comprend trois principaux domaines de processus : Stratégie, infrastructure et produits (SIP) : qui comprend des processus d’élaboration de stratégies et d’engagements à respecter au sein de l’entreprise; des processus de planification et de gestion de la fourniture et de l’amélioration des infrastructures et des services; et des processus de développement, déploiement et gestion de la chaîne d’approvisionnement des services, c’est dans cette partie que nous avons identifié les processus impliqués dans le déploiement de services.
Opérations (OPS) : qui comprend tous les processus opérationnels d’exploitation des services et de gestion des clients et du réseau. Ce domaine inclut également la gestion des ventes et la gestion des relations avec les fournisseurs/partenaires.
Gestion de l’entreprise : qui comprend les processus permettant la définition et la réalisation d’objectifs stratégiques de l’entreprise ainsi que la fourniture de services de prise en charge requis dans toute l’entreprise (processus de gestion financière, de gestion des ressources humaines, etc.). Dans les deux domaines SIP et OPS, l’eTOM représente quatre niveaux de visibilité (sous forme de processus fonctionnels horizontaux) :
Marchés, Produits et Clients : qui comprend des processus de gestion des ventes, de commercialisation, de produits et de l’offre ; des processus opérationnels tels que la gestion de l’interface client, le traitement des commandes, le traitement des problèmes, la gestion des accords SLA et la facturation ;
Services : qui sont les processus de gestion de capacité de développement, de fourniture de services (traduction entre les services catalogues et les services réels), de configuration des services, de gestion des problèmes de service et d’analyse de la qualité de service ;
Ressources : qui sont les processus de gestion du développement et fourniture d’une infrastructure de ressources (réseaux, applications (services) et équipements), de gestion opérationnelle de ces ressources (approvisionnement, gestion des anomalies, gestion de la performance, etc.).
Fournisseurs / partenaires : processus de gestion des interactions de l’entreprise avec ses fournisseurs et ses partenaires. Il s’agit des processus de développement et de gestion de la chaîne d’approvisionnement sur laquelle l’infrastructure et les produits sont fondés, ainsi que des processus assurant l’interface opérationnelle avec les fournisseurs et les partenaires.
Verticalement l’eTOM représente sept processus de bout en bout qui sont : Stratégie et engagement (strategy and commit): qui permet d’élaborer des stratégies assurant la prise en charge des processus de cycle de vie de l’infrastructure et de cycle de vie des produits et services. Il doit également permettre d’élaborer des engagements au sein de l’entreprise en soutien à ces stratégies. Pour cela, il fait intervenir tous les niveaux, depuis les marchés, les clients et les produits ainsi que les services et les ressources dont ils dépendent et jusqu’à la participation des fournisseurs et des partenaires.
|
Table des matières
CHAPITRE I INTRODUCTION GENERALE
I.1 CONTEXTE
I.2 PROBLEMATIQUES
I.3 CONTRIBUTIONS DE LA THESE
I.3.1 Déploiement Intelligent des éléments de service pour une E2E QoS efficace
I.3.2 Provisioning de service orienté QoS
I.3.3 Delivery de service
I.3.4 Gestion dynamique de la QoS sans couture
I.3.5 Valorisations
I.4 ORGANISATION DU RAPPORT
CHAPITRE II LE CONTEXTE
II.1 INTRODUCTION
II.2 CYCLE DE VIE DE SERVICE
II.3 LE CONTEXTE NGN/NGS
II.3.1 La convergence des réseaux
II.3.2 La convergence des services
II.3.3 La mobilité
II.3.4 Le réseau ambiant
II.4 USER CENTRIC ET E2E QOS
II.5 PERIMETRE D’ETUDE DE LA THESE
CHAPITRE III ÉTAT DE L’ART
III.1 LES SOLUTIONS EXISTANTES POUR LE DEPLOIEMENT DE SERVICES
III.2 LES SOLUTIONS EXISTANTES POUR LE PROVISIONING DE SERVICES
III.2.1 Introduction
III.2.2 Solutions de provisioning de services apportées par le SON
III.2.3 Solutions de provisioning de services apportées par SOA
III.2.4 Discussion
III.3 LES SOLUTIONS EXISTANTES POUR LE DELIVERY
III.3.1 Introduction
III.3.2 Travaux de recherche existants pour optimiser le SON
III.3.3 Exemple de Service Delivery
III.3.4 Discussion
III.4 LES SOLUTIONS EXISTANTES POUR LE HANDOVER DANS LE RESEAU
III.4.1 Introduction
III.4.2 Handover Horizontal de niveau 2 (L2)
III.4.3 Handover Horizontal de niveau 3 (L3)
III.4.4 Handover Vertical
III.4.5 Discussion
III.5 GESTION DE SERVICES DANS LES STANDARDS
III.5.1 Introduction
III.5.2 Évolution des architectures de gestion des télécommunications
III.5.3 Business Process Framework (eTOM)
III.5.4 Discussion
III.6 CONCLUSION DE L’ETAT DE L’ART : LIMITES DES SOLUTIONS
CHAPITRE IV PROPOSITION : GESTION DU CYCLE DE VIE DANS UN CONTEXTE NGN/NGS
IV.1 DEPLOIEMENT INTELLIGENT D’ELEMENTS DE SERVICES POUR UNE QOS EFFICACE DE BOUT EN BOUT
IV.1.1 Motivations
IV.1.2 Quoi déployer ? L’élément de service (SE)
IV.1.3 Comment déployer l’élément de service ?
IV.1.4 Quand déployer un élément de service ?
IV.1.5 Processus de Déploiement
IV.1.6 Redéploiement des éléments de service
IV.2 PROVISIONING DES ELEMENTS DE SERVICE ORIENTE QOS
IV.2.1 Motivations
IV.2.2 VPxN et le Pré-Provisioning des éléments de service
IV.2.3 Provisioning de l’élément de service
IV.2.4 Autogestion de la ressource service
IV.2.5 Mécanisme de gestion de la file d’attente
IV.2.6 Algorithme de gestion de la file d’attente
IV.3 SERVICE DELIVERY
IV.3.1 Motivations
IV.3.2 Service Delivery dirigé par un modèle
IV.3.3 Processus de Service Delivery
IV.3.4 Prise en compte de la mobilité (VSC et ES Ubiquitaire)
IV.4 GESTION DYNAMIQUE DE LA QOS SANS COUTURE
IV.4.1 Introduction
IV.4.2 Contrat de QoS pour un cycle de vie cohérent
IV.5 CONCLUSION DES PROPOSITIONS
CHAPITRE V VALORISATIONS
V.1 HANDOVER SEMANTIQUE POUR UNE CONTINUITE DE SERVICE SANS COUTURE DANS
L’ENVIRONNEMENT AMBIANT
V.1.1 Introduction
V.1.2 Scénario
V.1.3 Concept du Handover Sémantique
V.1.4 Initiateur du Handover.
V.1.5 Décideur du Handover
V.1.6 Exécuteur du Handover
V.1.7 Conclusion
V.2 PRISE EN COMPTE DE LA QOS DANS LE BUSINESS PROCESS FRAMEWORK
V.2.1 Processus impliqués dans le Déploiement de Services dans eTOM
V.2.2 Processus de déploiement proposé
V.2.3 Processus proposés dans l’exploitation pour prendre en compte le contexte NGN/NGS
V.2.4 Processus de Provisioning proposé
V.2.5 Interaction entre les phases de Fullfilment, de Delivery proposé et d’Assurance
V.2.6 Conclusion
CHAPITRE VI IMPLEMENTATION
VI.1 SCENARIO DE GESTION DE LA SESSION D’UN UTILISATEUR : DE L’ABONNEMENT JUSQU’A L’USAGE
VI.1.1 Abonnement : Création d’un « profil utilisateur » contenant tous les services abonnés par le client
VI.1.2 Ouverture de session et Pré-provisioning : Création du VPSN
VI.1.3 Provisioning de QoS de l’élément de service durant l’usage
VI.1.4 Provisioning de QoS de la file d’attente durant l’usage
VI.2 PLATE-FORME DE DEVELOPPEMENT ET DE TEST
VI.2.1 Élément de service de gestion « Queue_QoS Agent »
VI.2.2 Élément de service de gestion « VQC Maintenance »
VI.3 TEST DE FAISABILITE SUR LA FILE D’ATTENTE AVEC OPENMQ
VI.3.1 Scenario 1 : Provisioning du Service Par la QoS courante
VI.3.2 Scenario 2: Expiration du “Time out warning” des requêtes
CHAPITRE VII CONCLUSION GENERALE
VII.1 CONTRIBUTIONS
VII.2 PERSPECTIVES
CHAPITRE VIII REFERENCES BIBLIOGRAPHIQUES
LISTE DES PUBLICATIONS
CHAPITRE IX ANNEXE
Télécharger le rapport complet
