Soutenance mémoire
Négociation de la QoS dans IMS
Dans cette section nous présentons comment les entités du système IMS négocient les paramètres de la QoS. L’objectif de la négociation de QoS vise à déterminer la meilleure configuration de service et d’allocation des ressources réseau qui maximise la qualité du service de l’utilisateur (Skorin-Kapov et al., 2007). Fig. 2.6 illustre la négociation des paramètres de la qualité de service et de réservation de ressources entre UE et le serveur d’application (AS). Les procédures de négociation des caractéristiques de la session multimédia sont spécifiées par le 3GPP et sont basées sur le mécanisme SIP / SDP et les paramètres qui pourraient être négociés comprennent le type, la qualité, l’encodage des médias, capacités du terminal à utiliser, et QoS désirée (QoS garantie, non garanti Qos, best effort). La première étape, un UE doit obtenir l’accès à IMS à travers un réseau d’accès (GPRS, UMTS). La seconde étape, consiste à allouer un Proxy-CSCF qui va s’interfacer avec le PDF (Policy Decision Function) pour autoriser l’utilisation du bearer et les ressources de la QoS pour les services IMS dans le réseau d’accès.Après, le P-CSCF sélectionne le S-CSCF qui va interroger le Home Subscriber Server (HSS) pour accéder aux informations de profil utilisa teur, récupérer les données de l’abonnement, et pour réaliser l’authentification, l’autorisation et de facturation. La dernière étape, à la fin de la transmission les deux entités communicantes libèrent les ressources déjà réservées.
Mappage de la QoS dans IMS
Lors de l’étude de la QoS dans le contexte des réseaux de prochaines générations il est important de prendre en considération le mappage de la QoS lors de l’inter fonctionnement entre réseaux hétérogènes. En général, le mappage de la QoS dans ces réseaux catégorisé par le mappage entre les différentes classes de service et paramètres pour les différents réseaux. Cependant, la mise en oeuvre de cette technique est difficile et ne garantit pas la granularité de la classe de QoS entre des réseaux différents (Ryu et al., 2006). De même, chaque opérateur téléphonique utilise sa propre architecture de QoS pour fournir une qualité acceptable a leurs abonnées qui justifie leur abonnement a un service donné. L’aspect hétérogène de ces réseaux pose la question suivante, comment les opérateurs peuvent gérer la QoS lors du mappage entre des réseaux IMS de caractéristiques différentes ? Différentes approches ont été adressées pour le problème mappage de la QoS dans IMS. Ainsi, le mappage peut être accompli entre deux réseaux IMS utilisant le un même modèle de gestion ou des modèles de gestion différents. Par exemple, le mappage entre deux domaines Diffserv ou le mappage entre IP et UMTS. Le tableau 2.5 montre un exemple de mappage entre les classes de QoS d’IP et les réseaux hétérogènes (DiffServ, InterServ et UMTS)(Ryu et al., 2006).
D’autres études spécifient l’utilisation d’une entité à part qui se charge de cette fonction pour assurer plus de granularité lors du mappage. (Ryu et al., 2006) proposent une méthode mappage de la QoS entre les différentes technologies de transport à l’aide d’une Application Service Map (ASM). Après avoir déterminé l’exigence en paramètre de base (délai, gigue, bande passante, la perte de paquets, etc.) en fonction du service demandé. Le mappage de la QoS en utilisant ASM est basé sur la perception des utilisateurs de bout en bout indépendante de la technologie réseau. Afin de garder les utilisateurs, les opérateurs développent leur portefeuille avec l’intégration des services avec des différentes exigences de qualité de service pour les applications destinées à plusieurs utilisateurs mobiles tels que l’IPTV.Ce type de services est appelé multi-utilisateur session, car ils peuvent être répartis entre plusieurs utilisateurs en même temps avec des profils de qualité de service différents. (Cerqueira et al., 2007) présentent une nouvelle approche Session-aware QoS mapping and adaptation (SOMA) qui mappe la session dans le service réseau le plus approprié dans les réseaux hétérogènes (par exemple IntServ, DiffServ et UMTS) et différentes technologies de transport (par exemple IP unicast ou multicast) (Cerqueira et al., 2007). Les SOMA peuvent être implémentés directement dans les entités de frontière ou dans le coeur du réseau. En effet, le schéma proposé SOMA repose sur les exigences de chaque utilisateur. L’agent du réseau avec lequel le récepteur est attaché crée un « Session Object » composé des paramètres de QoS comme le débit binaire, garantie de bande passante, la tolérance à la perte et la gigue et les métriques du trafic (taille des paquets). Fig. 2.7 montre un exemple d’emplacement de SOMA et la Fig. 2.8 montre un exemple de fonctionnement SOMA.
Clearwater IMS core
Le projet de Clearwater IMS est sponsorisé par la compagnie Metaswitch Networks(Networks, 2014). C’est une solution libre publiée en mai 2013. Clearwater IMS suit les principes d’architecture IMS et supporte toutes les interfaces clés standardisées attendues d’un cœur de réseau IMS. À la différence des implémentations traditionnelles de IMS, Clearwater IMS a été conçu dès le départ pour être optimisé pour le déploiement dans les environnements virtualisés et dans le nuage informatique d’où la particularité de cette solution par rapport à open source IMS Core. Le framework de Clearwater IMS s’appuie sur des patrons de conception et de composants logiciels libres ce qui donne la possibilité à l’évolutivité et la rentabilité de cette solution. Tous les composants de Clearwater permettent le passage à l’échelle horizontale en utilisant un équilibrage de charge simple. L’ état à long terme ne sont pas stockées sur les noeuds du cluster, 55 en évitant la nécessité des systèmes de réplication de données complexes. Au lieu de cela, l’état à long terme est stocké dans des noeuds de service back-end en utilisant les technologies de stockage nuage optimisé tel que Cassandra. L’interface entre les composants SIP frontaux et les services back-end utilisent «RESTFULL» API de services Web. Ainsi, que l’interface entre les différents composants utilise le regroupement de connexion avec recyclage statistique de connexions pour assurer que la charge est répartie uniformément comme des noeuds sont ajoutés et supprimés dans chaque couche.
Bono (Edge Proxy)
Le noeud Bono forme un proxy SIP horizontalement évolutive offrant à la fois une interface compatible SIP IMS Gm ( P-CSCF ) et une interface de WebRTC aux clients. Les requêtes clientes sont partagées sur les noeuds on utilisant un équilibrage de charge. Ce noeud constitue le premier point de contact du client avec le système Clearwater , y compris le soutien pour les divers mécanismes de traduction d’adresse réseau NAT (Network Address Translation) pour les différents noeuds traversée . Un client est donc ancré à un noeud Bono particulier pour la durée de son enregistrement , mais peut se déplacer vers un autre noeud Bono si la connexion ou le client échoue. Les clients peuvent se connecter à Bono en utilisant le protocole SIP/UDP ou SIP/TCP. Bono prend en charge tout client Web RTC qui effectue la signalisation d’établissement d’appel utilisant le protocole SIP surWebSocket. Les noeuds Bono ne sont pas nécessaires si Clearwater est déployé avec un tiers P-CSCF ou SBC (Session Border Controller) mise en oeuvre de P-CSCF. Sprout (routeur SIP ) Les noeuds de Sprout agissent comme registraire SIP horizontalement évolutive qui gère l’authentification des clients et l’interface ISC pour les serveurs d’applications ainsi que l’interfaçage avec le reste des serveurs tel que Homestead et Homer.
Les noeuds de Sprout contiennent également une option pour construire un serveur d’application MMTel. Le cluster Sprout comprend un cluster redondant Memcached pour stocker les données d’enregistrement des clients avec l’état à long terme. Les Transactions SIP sont équilibrées sur le cluster Sprout et il n’y a pas d’association à long terme entre un client et un noeud de Sprout particulier . Sprout utilise des interfaces de services Web fournis par Homestead et Homer pour récupérer les informations de configuration du HSS telles que les données d’authentification et du profil utilisateur ainsi que les paramètres de service MMTel. Homestead (HSS Mirror) Homestead fournit une interface de services Web à Sprout pour récupérer des informations relatives au profil d’utilisateur comme les informations d’authentification. Cette composante gère directement les données à travers l’interface web ou les extraire à partir d’un HSS à travers l’interface Cx conforme à IMS. Les noeuds de Homestead fonctionnent comme un cluster à l’aide de Cassandra pour stocker les données. Dans l’architecture d’IMS , la fonction de miroir HSS est considérée comme partie des composants I-CSCF et S-CSCF , cependant dans Clearwater IMS les fonctions des deux composants I-CSCF et S-CSCF sont implémentée avec une combinaison de cluser de Sprout et Homestead.
|
Table des matières
CHAPITRE 1 INTRODUCTION
1.1 Problématique
1.2 Objectifs du mémoire
1.3 Plan du mémoire
CHAPITRE 2 REVUE DE LITTÉRATURES DE LA QUALITÉ DE SERVICE DANS LES RÉSEAUX DE NOUVELLE GÉNÉRATION (NGN)
2.1 Introduction
2.2 Contexte des réseaux de nouvelle génération
2.2.1 Définition et concept
2.2.2 Caractéristiques
2.3 Qualité de service dans les réseaux IP
2.3.1 Définitions de la QoS
2.3.2 Type de la qualité de service
2.3.3 Les principales métriques de la QoS dans les réseaux IP
2.3.4 Exigence de la QoS pour les applications temps réel
2.3.5 Exigence de la QoS pour les applications non-temps réel
2.3.6 Modèles de gestion de la QoS
2.3.6.1 Le modèle Best-effort
2.3.6.2 Le modèle InterServ
2.3.6.3 Le modèle DiffServ
2.4 Qualité de service dans IMS
2.4.1 Présentation d’IMS
2.4.2 Architecture d’IMS
2.4.3 Gestion des identités en IMS
2.4.4 Concepts et approches de gestion de la QoS dans IMS
2.4.5 Architecture de PCC(Policy and Charging Control)
2.4.6 Négociation de la QoS dans IMS
2.4.7 Mappage de la QoS dans IMS
2.5 Conclusion
CHAPITRE 3 ANALYSE DES EXIGENCES D’IMS DANS LE NUAGE
3.1 Introduction
3.2 Nuage informatique
3.2.1 Définition et concept
3.2.2 Types de nuages
3.2.3 Modèle de service
3.2.4 Caractéristique du nuage informatique
3.3 Exigences du système IMS déployé dans le nuage
3.4 Virtualisation du système IMS
3.4.1 Définition
3.4.2 Technique de virtualisation
3.4.3 Avantage de la virtualisation du système IMS
3.4.4 Virtualisation d’IMS
3.5 Mise à l’échelle automatique
3.5.1 Mise à l’échelle verticale
3.5.2 Mise à l’échelle horizontale
3.6 Élasticité
3.7 Provisionnement des ressource
3.7.1 Provisionnement statique
3.7.2 Provisionnement dynamique
3.7.3 Auto-provisionnement par l’utilisateur
3.8 Design et architecture d’IMS dans le nuage
3.9 Conclusion
CHAPITRE 4 PROVISIONNEMENT DE LA QOS D’IMS DANS LE NUAGE
4.1 Introduction
4.2 Les systèmes IMS existants
4.2.1 Open Source IMS core
4.2.2 Clearwater IMS core
4.2.3 Infrastructure en tant que service libre : Openstack
4.3 Métriques de performance d’IMS
4.3.1 Demande d’enregistrement
4.3.2 Demande d’établissement d’une session audio
4.3.3 Demande d’établissement d’une session donnée
4.4 Provisionnement de la QoS d’IMS dans le nuage informatique
4.4.1 Provisionnement des ressources dans le nuage informatique
4.4.2 Modèle de provisionnement de la QoS proposé
4.5 Conclusion
CHAPITRE 5 TEST ET VALIDATION
5.1 Introduction
5.2 Architecture et conception des bancs d’essai
5.2.1 Banc d’essai 1 : Cloud open source IMS core
5.2.2 Banc d’essai 2 : Cloud Clearwater IMS
5.2.3 Banc d’essai 3 : Traditional open source IMS Core
5.3 Test de fonctionnement des architectures d’IMS dans le nuage
5.3.1 Tableau de bord d’Openstack
5.3.2 Demande d’enregistrement
5.3.3 Établissement d’une session audio
5.3.4 Établissement d’une session donnée
5.3.5 Gestion du profil d’utilisateur
5.3.6 Test de fonctionnement du service IMS
5.4 Protocole expérimental et résultats
5.4.1 Scénario d’évaluation des métriques de la QoS
5.4.2 Processus de surveillance du trafic dans IMS
5.5 Résultats
5.5.1 Analyse de délai d’une demande d’enregistrement (RRD)
5.5.2 Analyse du délai d’une demande d’établissement d’une session vidéo (SRD)
5.5.3 Analyse du délai d’une demande d’établissement d’une session donnée
5.5.4 Analyse de flux RTP d’une session audio
5.5.5 Analyse de l’utilisation de CPU et mémoire
5.5.6 Analyse de l’utilisation de CPU et mémoire virtuelle
5.5.7 Comparaison des systèmes IMS déployés dans le nuage informatique
5.6 Conclusion
CHAPITRE 6 CONCLUSION
ANNEXE I INSTALLATION D’OPEN SOURCE IMS CORE
ANNEXE II INSTALLATION DE CLEARWATER IMS
ANNEXE III CONFIGURATION DE SIPP TRAFFIC GENERATOR
BIBLIOGRAPHIE
Télécharger le rapport complet
