Une architecture convergente pour une continuité et personnalisation de services

Architecture NGN/NGS

   De nos jours, le NGN (Next Generation Networks) [41][43][51] est considéré comme la plus grande évolution dans le monde des télécoms, et comme étant un premier pas vers une approche user-centric dans le monde économique et technologique d’aujourd’hui. Ce nouveau concept modélise d’une manière générique les nouvelles architectures de réseaux de communication, qui reposent sur l’indépendance et la séparation formelle entre les niveaux accès, transport, contrôle et service.
-La couche des terminaux : elle contient un ensemble de terminaux de natures et de capacités différentes. Nous pouvons ainsi trouver dans l’environnement de l’utilisateur des ordinateurs fixes et portables, des téléphones fixes, des téléphones mobiles supportant différentes technologies cellulaires, des téléphones IP, etc.
-La couche d’accès : elle contient un ensemble de technologies d’accès de natures et de caractéristiques différentes. L’utilisateur peut ainsi accéder à ses services en utilisant des réseaux d’accès de différentes technologies comme les réseaux cellulaires, les réseaux WiFi, les réseaux téléphoniques commutés, et les différentes technologies des réseaux filaires.
-La couche de transport : elle est dominée par le protocole IP (Internet Protocol) depuis l’avènement de l’Internet. En effet, l’approche best-effort adoptée par IP permet un transfert rapide des données, ce qui a favorisé l’usage d’IP comme protocole de transport. Cette couche de transport vient s’interfacer au-dessus de la couche d’accès, permettant ainsi la convergence du trafic provenant de différents réseaux d’accès dans une seule couche de transport IP.
-La couche de contrôle : elle est basée sur la technologie IMS (IP Multimedia Subsystem) [43] qui introduit un environnement de contrôle de session. IMS permet ainsi d’établir, de modifier et de libérer des sessions multimédias en se basant sur le protocole de signalisation SIP (Session Initiation Protocol). De plus, IMS introduit plusieurs fonctions et interfaces pour invoquer les services, contrôler le trafic IP transporté, contrôler les politiques d’accès aux services, maintenir les profils des utilisateurs et de leurs services, garantir la sécurité d’accès aux services, garantir un environnement OAM&P (Opération, Administration, Maintenance et Provisionnement), etc.
-La couche des services : elle contient un ensemble de services de natures différentes (Telco, Web ou IT). Grâce à cette séparation en différentes couches, NGN permet aux fournisseurs de services, aux opérateurs et aux fournisseurs d’équipements de créer, gérer et faire évoluer leurs produits indépendamment les uns des autres. Cependant, avoir une vision globale du marché reste toujours un facteur important dans la stratégie économique des fournisseurs et des opérateurs. En outre, autre que la séparation en couches horizontales, la convergence de réseaux constitue le deuxième atout primordial de l’évolution NGN. Grâce à ce nouveau concept, l’utilisateur peut utiliser n’importe quel terminal et n’importe quel réseau d’accès an d’accéder à ses services. Cependant, en face à cette liberté d’accès garantie par ce cadre NGN multi-accès et multi-terminaux, des défis NGN surgissent, comme la continuité de la session, la QoS de bout-en-bout et l’hétérogénéité de l’environnement complexe entourant l’utilisateur. La gestion de ces défis est ainsi primordiale pour avoir une meilleur QoE. En parallèle à cette évolution des architectures de réseau de communication vers un nouveau contexte NGN, une nouvelle ère de services voit le jour. En effet, aujourd’hui, des fournisseurs de services sans réseaux (ex. Google, Amazon, Skype, etc.) rendent leurs services sans s’appuyer sur aucune architecture réseau fournie par un opérateur télécom, mais plutôt en se basant sur des architectures techniques issues du monde Web et du monde IT. Ces acteurs cherchent à augmenter leurs parts du marché en adoptant un nouveau modèle économique. Ce dernier consiste à surmonter la concurrence du marché en attirant le plus d’abonnés. Pour ce faire, ils ne se contentent plus de traiter les abonnés comme des simples clients d’une offre d’accès. Au contraire, ils les considèrent comme des utilisateurs ayant des besoins et des préférences qui doivent être pris en compte dans leurs écosystèmes. Avec ce nouveau contexte de services orientés utilisateur, une nouvelle architecture semble nécessaire pour structurer cette nouvelle vision de services de nouvelle génération, notés NGS (Next Generation Services).

Mobilité

   L’évolution rapide des réseaux NGN dans l’industrie de la communication assure une grande couverture et une diversité de technologies sur les offres d’accès accompagnées d’une hétérogénéité au niveau des terminaux utilisés, ce qui permet à l’utilisateur de se déplacer au gré de ses besoins sans aucune limitation. Ce contexte NGN favorise ainsi l’approche user-centric et rend l’utilisateur d’aujourd’hui de plus en plus nomade et de plus en plus exigeant au niveau de sa QoE. Par conséquent, dans le cadre de l’approche « Every Service for Everyone, Anywhere, Anytime and Anyhow », tout utilisateur désire conserver sa session de bout-en-bout qui lui permet d’accéder d’une manière continue à ses services, quelque soit le terminal, le réseau d’accès, le réseau coeur, et le fournisseur de services choisis. De plus, il réclame une session continue qui prend bien en considération ses préférences fonctionnelles et sa QoS de bout-en-bout demandée. Dans ce nouveau contexte NGN et user-centric, les exigences au niveau mobilité deviennent des graves défis qui augmentent la complexité de la gestion des ressources. Afin de dépasser ce problème de continuité de session, nous devons préciser les différents évènements qui peuvent surgir durant la session de l’utilisateur et peuvent impacter sa continuité. Nous les classifions sous quatre types de mobilités :
-Mobilité du terminal : elle représente le passage du terminal d’un point d’accès réseau à un autre. En effet, grâce à l’évolution technologique au niveau des réseaux d’accès filaires et des réseaux d’accès sans fils, et grâce à l’apparition des terminaux multi-technologies, l’utilisateur d’aujourd’hui est devenu capable d’accéder à ses services lors de son déplacement géographique, tout en se servant d’un même terminal qui commute d’un réseau d’accès à un autre. Pour cette raison, ce type de mobilité spatiale pose un défi vis-à-vis de la continuité de la session.
-Mobilité de l’utilisateur : elle représente le passage d’un utilisateur d’un terminal à un autre. En effet, de nos jours, tout utilisateur se trouve dans un environnement hétérogène qui contient des terminaux très diversifiés. Par conséquent, l’utilisateur est devenu capable d’accéder à ses services tout en passant d’un terminal à un autre. Pour cela, ce type de mobilité spatiale pose un défi vis-à-vis de la continuité de la session.
-Mobilité du réseau : elle représente le déplacement d’un routeur et par conséquent du plan de routage du réseau associé. Les machines virtuelles devraient simplifier, grâce à leurs configurations dynamiques, la prise en compte de cette mobilité du réseau.
-Mobilité du service : elle est dûe essentiellement au principe d’ubiquité de services qui consiste à avoir des services ubiquitaires, c.à.d. des services ayant la même fonctionnalité et une QoS équivalente. Par conséquent, le principe de mobilité de services représente le remplacement d’un service demandé par l’utilisateur par un autre service qui lui soit ubiquitaire. D’après l’approche transorganisationnelle que nous supportons, le service remplaçant peut appartenir à un autre fournisseur de services. En effet, ce type de mobilité devient un défi de plus en plus important à gérer, surtout avec le booming du marché des services et l’augmentation de la concurrence qui incite les fournisseurs à déployer des services ubiquitaires pour mieux répondre aux besoins de leurs utilisateurs. Afin de maintenir la continuité de la session tout en respectant la QoS de bouten-bout et les préférences fonctionnelles demandées par l’utilisateur, il est primordiale de gérer ces quatre types de mobilité. Comme le montre la Figure 1.5, la mobilité de la session résulte de la gestion de ces quatre types de mobilité. Cependant, dans le cadre de cette thèse, nous nous intéressons seulement à la mobilité spatiale au niveau terminal et utilisateur, ainsi que la mobilité de services, et nous négligeons la mobilité du réseau. D’autre part, selon l’approche user-centric, la satisfaction de l’utilisateur n’est pas seulement basée sur la continuité de sa session et sur la prise en compte de ses préférences. La prise de conscience du contexte ambiant de l’utilisateur [13] est aussi un facteur essentiel dans l’amélioration de la QoE de cet utilisateur. Elle consiste à adapter la session de l’utilisateur à son nouveau contexte ambiant. Ce dernier consiste en un ensemble d’informations temps réel qui caractérisent l’environnement de l’utilisateur. Ainsi, pour une meilleure QoE et pour une gestion de mobilité plus efficace, les informations ambiantes doivent être prises en considération. Dans le cadre de cette thèse, nous considérons que les changements dans le contexte ambiant d’un utilisateur sont dûs essentiellement à une mobilité spatiale (mobilité du terminal ou mobilité de l’utilisateur). En effet, durant la mobilité temporelle de l’utilisateur, c.à.d. durant sa session continue, un nouveau contexte ambiant est découvert dynamiquement suite à toute commutation d’un terminal à un autre, ou d’un point d’accès réseau à un autre. Afin d’améliorer la prise en conscience du nouveau contexte ambiant de l’utilisateur et afin de traiter de façon plus efficace les nouvelles informations ambiantes, le concept des réseaux ambiants [29][45] a été conçu dans les années 2002/2003. Ce concept se résume comme une architecture ouverte d’interconnexion de réseaux hétérogènes qui se composent et se décomposent dynamiquement an de permettre la mise en relation automatique et temps réel des terminaux relatifs aux utilisateurs. Par conséquent, lors du déplacement de l’utilisateur, par exemple lorsqu’il entre dans une gare, son réseau ambiant constitué des équipements qui sont à sa portée s’adapte en se composant au réseau ambiant déjà existant dans cette gare. Il faut noter que la couverture des réseaux ambiants peut être petite, comme elle peut être aussi grande (ex. de l’ordre d’une ville). En effet, le concept des réseaux ambiants assure plusieurs avantages : l’interconnexion des réseaux d’accès et des équipements hétérogènes, la convergence fixe-mobile, la gestion de la transparence de la mobilité, la gestion du contexte de l’utilisateur et la sécurité. Cependant, cette solution reste toujours limitée aux réseaux et aux terminaux, et elle néglige toute prise en conscience du contexte de l’utilisateur au niveau de la couche service. Afin de dépasser ce problème, nous considérons l’extension du concept de réseaux ambiants pour prendre en compte la couche service. Ainsi, pour chaque nouvelle situation ambiante de l’utilisateur, dûe à une mobilité spatiale, de nouveaux services sont découverts. Certains de ces services viennent s’additionner à la session de services courante de l’utilisateur, et d’autres s’annoncent comme des candidats ubiquitaires à certains services dans la session de l’utilisateur, ce qui permet le remplacement de ces services non-ambiants par d’autres appartenant à la nouvelle zone ambiante de l’utilisateur.

Description architecturale et fonctionnelle des RI

  Les RI ont été décrits selon plusieurs approches. La première considère le concept des RI comme un dispositif supplémentaire à l’architecture de commutation existante. Dans ce cas, les RI sont vus comme une collection de serveurs qui exécutent des fonctions spéciales de contrôle. La deuxième approche ne voit pas les RI comme un ensemble de noeuds ; elle les considère plutôt comme une architecture de logiciels qui exécutent des services. Afin d’homogénéiser les différents points de vue, l’ITU (International Telecommunications Union) standardise un modèle conceptuel, noté INCM (Intelligent Network Conceptual Model). Ce dernier réconcilie les approches physiques et logiques de l’architecture des RI. Pour ce faire, l’INCM est répati sur quatre plans de vision [28][40][52] : le plan de services, le plan fonctionnel global, le plan fonctionnel distribué et le plan physique. Le plan de services est le plan supérieur de l’INCM. Il décrit, selon le point de vue de l’utilisateur, des services par un ensemble de caractéristiques, nommées Service Elements Features, sans préciser comment ces services sont implémentés dans le réseau. En eet, chaque caractéristique est vue comme une fonctionnalité réutilisable. L’idée clé des RI est donc de standardiser un ensemble de fonctionnalités (ex. Call forwarding, Authentication, Call limiter, etc.) qui seront réutilisées par les opérateurs de réseaux afin de composer leurs services. Le deuxième plan dans l’INCM est le plan fonctionnel global. Il s’interface, au niveau architectural, juste au dessous du plan de services afin d’ajouter la vision des fournisseurs de services. En effet, le plan fonctionnel global décrit le service par une séquence de composants réutilisables, nommés SIBs (Service Independent Building Blocks). Ces derniers ne sont pas des programmes, mais plutôt des descriptions formelles d’activités agissant sur des données (ex. le numéro appelé, la Black list, etc.). Cette séquence de SIBs obéit à la logique globale de service, notée GSL (Global Service Logic), et représente le traitement substitutif exécuté par le RI par rapport à l’appel normal, noté BCP (Basic Call Process). Pour atteindre ce but, chaque SIB est muni d’un point logique d’initialisation, noté POI (Point of Initialization), et de plusieurs points logiques de retour, notés POR (Points of Return). Par conséquent, comme le montre la Figure 3.1, lors d’un processus d’appel normal, BCP est interrompu par un processus substitutif. Ce dernier est déclenché par un POI (ex. Adresse analysée, Pas de réponse, etc.), puis exécuté par une séquence de SIBs selon une logique GSL bien déterminée. Une fois ce processus terminé, le service rend le contrôle au BCP. Le retour à l’appel normal pourra se faire par plusieurs types de POR (ex. Termine l’appel, Continue avec de nouvelles données, etc.). D’après les standards des RI, il y a 20 SIBs qui sont définis : algorithm, authenticate, charge, compare, distribution, log call information, queue, screen, service data management, service filter, translate, user interaction, verify, BCP, BCUP, split, join, initiate service process, end, message handler. D’après la standardisation CS-2 (Capability Sets – 2 ), le processus de service substitutif n’est plus limité à une seule séquence de SIBs. En eet, lors de l’exécution d’un service RI, plusieurs processus peuvent être déclenchés en parallèle et peuvent ainsi communiquer par des messages. De plus, CS-2 améliore le concept de SIB en définissant un modèle récursif pour la création de services. Ce modèle classifie les SIBs sur différents niveaux de granularité. Pour ce faire, il différencie une opération SIB d’un SIB de haut niveau. La première représente une opération de base qui ne peut pas être décomposée en d’autres composants. Quand au SIB de haut niveau, noté HLSIB (HighLevel SIB), il est décomposable en un ensemble d’opérations SIB, des SIBs normaux ainsi que d’autres HLSIBs.

Description architecturale et fonctionnelle d’OMA

   Au niveau architectural, OMA [48][9] cherche à proposer une architecture qui assure l’intégrité, le passage à l’échelle, l’interopérabilité, la sécurité, et surtout l’élimination des approches monolithiques. Pour atteindre ces objectifs, OMA base son modèle architectural sur des spécifications appelées enablers. Ces derniers sont des blocks standardisés qui étaient conçus au début pour la composition des services mobiles. Mais, au cours des années, plusieurs spécifications liées aux réseaux fixes apparaissent, ce qui a conduit à la prolifération des services mobiles tout en permettant l’interopérabilité entre les réseaux fixes et mobiles. Il faut bien noter que les spécifications devraient préciser comment se fait l’invocation des enablers et l’appel de leurs fonctions. De plus, toutes les exigences et les fonctions qui ne sont pas intrinsèques à un enabler ne devraient pas être dénies dans sa spécification. La spécification d’un enabler devrait seulement spécifier la fonctionnalité intrinsèque exigée pour accomplir son rôle. En effet, l’utilisation de ces enablers est très avantageuse. Tout d’abord, ils représentent des composants interopérables qui permettent l’interaction entre différents composants et applications développés par des fournisseurs hétérogènes. En outre, les spécifications des enablers réduisent les efforts de déploiement et permettent aux mêmes applications de fonctionner à travers une large variété d’environnements d’une façon cohérente. De plus, OMA tient compte du principe de réutilisation dans ses spécifications, ce qui lui permet de réduire le problème des architectures verticales en-silos. En effet, chaque spécification d’enabler peut réutiliser d’autres spécifications existantes. Par exemple, l’enabler Push to talk over Cellular réutilise les enablers de présence et de gestion de groupe. Ayant décrit ces enablers, la question qui se pose est comment les structurer, les intégrer et les gérer ? Pour répondre à cette question, OMA a proposé un environnement d’intégration unifiée pour ses enablers, et l’a nommé OSE (OMA Service Environment) [48][9]. Ce dernier assure une ouverture des enablers vers des nouveaux développeurs et fournisseurs tiers an de permettre le développement et le déploiement de nouvelles applications innovantes. Cependant, il faut noter qu’un des principes fondamentaux d’OMA consiste à ne pas spécier des APIs. De plus, OMA ne précise pas où se trouvent les éléments architecturaux (applications, enablers, etc.). Ils peuvent appartenir à différents domaines OSE (domaine de l’opérateur mobile, domaine du terminal, etc.) et peuvent ainsi interagir indépendamment de leurs localisations. En outre, dans n’importe quel domaine OSE, les implémentations des enablers exposent des interfaces standards pour l’application et l’usage des enablers. Ces implémentations se relient aux ressources actuelles présentes dans le domaine OSE. A l’aide de cette abstraction, il sera possible d’ajouter ou de modifier les ressources sous-jacentes sans affecter l’interface exposée par les implémentations des enablers, et sans affecter ainsi les applications, ce qui est très important dans le cas de différents vendeurs, technologies réseaux et fournisseurs.

Table des matières

Acronymes
1 Introduction Générale 
1.1 Contexte d’étude
1.1.1 User-centric
1.1.2 Architecture NGN/NGS
1.1.3 Mobilité
1.2 Périmètre de la thèse
1.3 Problématiques
1.4 Organisation
I Architecture de services 
2 Introduction 
3 Analyse des architectures de services existantes 
3.1 Approche Telco
3.1.1 Réseaux Intelligents
3.1.1.1 Description architecturale et fonctionnelle des RI
3.1.1.2 Défis des RI
3.1.2 Parlay/OSA
3.1.2.1 Description architecturale et fonctionnelle du Parlay/OSA
3.1.2.2 Défis du Parlay/OSA
3.1.3 OMA
3.1.3.1 Description architecturale et fonctionnelle d’OMA
3.1.3.2 Défis d’OMA
3.1.4 IMS-SCIM
3.1.4.1 Description architecturale et fonctionnelle d’IMS-SCIM
3.1.4.2 Défis d’IMS-SCIM
3.2 Approche Web
3.2.1 Services Web
3.2.2 Web 2.0
3.2.3 Défis de l’architecture Web
3.3 Approche IT : SOA
3.3.1 Description de l’approche SOA
3.3.2 Défis de l’approche SOA existante
3.4 Conclusion
4 Proposition 
4.1 Modèle Architectural
4.1.1 Approche SOA améliorée
4.1.2 Approche EDA
4.1.3 Approche horizontale sous forme de Middleware
4.2 NGN/NGS Middleware
4.2.1 Les services exposables
4.2.2 Le bus d’interconnexion SEIB
4.2.3 Les services de base
4.2.3.1 Modèle de QoS pour gérer l’hétérogénéité
4.2.3.2 Services de base pour personnaliser la logique de services
4.2.3.3 Services de base pour gérer la mobilité
4.2.3.4 Autres services de base
5 Conclusion 
II Gestion de la mobilité 
6 Introduction 
7 Analyse des solutions existantes pour la gestion de la mobilité 
7.1 Handover horizontal au niveau des réseaux d’accès
7.1.1 Réseaux cellulaires 2G (GSM) et 2.5G (GPRS/EDGE)
7.1.2 Réseaux cellulaires 3G (UMTS)
7.1.3 Réseaux cellulaires 4G (LTE)
7.1.4 WiMAX
7.2 Handover vertical entre les réseaux d’accès
7.2.1 UMA/GAN
7.2.2 MIH
7.3 Handover au niveau du réseau coeur (Mobile IP)
7.4 Défis des solutions de gestion de mobilité existantes
8 Proposition 
8.1 Les Communautés Virtuelles
8.1.1 Description du concept
8.1.2 Aspect architectural des VSCUs
8.1.2.1 CoI : VSC-U&P, VSC-U&L et VSCU-L&P
8.1.2.2 Inner VSC-U&L et Outer VSC-U&L
8.1.3 Aspect fonctionnel des VSCUs
8.1.3.1 Attachement aux VSCUs
8.1.3.2 Création des VSCUs
8.1.3.3 Maintenance des VSCUs
8.1.4 Mise en oeuvre des VSCUs
8.2 Le Handover Sémantique
8.2.1 Description du concept
8.2.2 Aspect architectural du Handover Sémantique
8.2.3 Aspect fonctionnel du Handover Sémantique
8.2.3.1 Initiateur du handover sémantique
8.2.3.2 Décideur du handover sémantique
8.2.3.3 Exécuteur du handover sémantique
8.2.4 Mise en oeuvre du Handover Sémantique
9 Conclusion 
III Valorisation et Faisabilité 
10 Valorisation dans le Cloud 
10.1 Personnalisation de services dans le cloud
10.2 Gestion de la QoS dans le cloud
10.3 Gestion de la Mobilité dans le cloud
11 Faisabilité 
11.1 Scénario Applicatif
11.2 Démonstrateur
11.2.1 Architecture du démonstrateur
11.2.2 Automates des composants de services
12 Conclusions et Perspectives 
12.1 Conclusions
12.2 Perspectives
Liste des Publications
Liste des Délivrables UBIS
Bibliographie

Télécharger le rapport complet