Tester la fiabilité d’un cœur de réseau IMS

Aujourd’hui, les consommateurs exigent des services de pointe à travers de multiples outils technologiques. Avec la prolifération des appareils mobiles qui peuvent supporter une grande variété de services comme la voix, la vidéo, les données et de la présence, la démarcation traditionnelle entre les appareils mobiles et fixes dispositifs s'estompe.

Les fournisseurs de services réseaux (NSP) ne veulent plus être qu’un fournisseur de tuyau mais récupérer de nouvelles recettes en offrant des services à valeur ajoutée offerts par d’autres fournisseurs utilisant leur infrastructure existante. Afin d’effectuer cette transition, les fournisseurs de services réseaux ont besoin d'une architecture qui leur permet d'offrir simultanément des services à valeur ajoutée, à travers à la fois la téléphonie fixe et mobile, et l’IMS peut répondre à ces besoins.

L’IMS permet la convergence fixe mobile et le déploiement de la convergence des services multimédias à travers tout l'accès. Il a été adopté par la majorité des fournisseurs de services réseau comme l'architecture de choix pour fournir des services convergents, et les fabricants d'équipements réseau (NEMS) ont commencé à adapter  leurs produits à l'architecture IMS.

Figure 1. IMS architecture

L’ IMS est un réseau d'infrastructures qui permet la convergence, non seulement dans la technologie mais aussi dans la charge du réseau. Le résultat de cette convergence est que, si l'IMS n'est pas dimensionné correctement, il peut devenir un goulet d'étranglement, entrainant un manque de bande passante et / ou l'incapacité d’éléments critiques du réseau à traiter les paquets d’information et à les transmettre à leur destination ; ce qui est essentiel pour fournir un niveau acceptable de qualité de service (QoS). Pour ces raisons, le développement et le déploiement des réseaux IMS peuvent présenter de sérieux défis pour les équipementiers, les intégrateurs de systèmes et les fournisseurs de services réseau.

Cet article examine, les défis auxquels font face ces métiers dans le développement et le déploiement d'un réseau IMS, ainsi que quelques-uns des meilleurs tests de pré-déploiement visant à assurer la fiabilité du réseau IMS.

Scénarii de trafic Vérification/Validation

L'objectif principal de toute architecture de réseau, tel que l'IMS, est de fournir à l'utilisateur final une qualité d'expérience (QoE) qui soit complètement satisfaisante. Si le temps qu'il faut pour effectuer un appel est plus long que prévu, nous percevrons une mauvaise qualité de service, pouvant entraîner l'annulation de services. Pour ces raisons, il est évidemment dans le meilleur intérêt de l’opérateur d’éviter ces problèmes. Le déploiement de services à valeur ajoutée par les fournisseurs de services  sont la clé de la fidélisation des clients et de l’accroissement du revenu moyen par utilisateur (ARPU), mais la qualité des nouveaux services offerts doit aussi répondre aux attentes du client, ce qui rend indispensable l'analyse de la réponse du réseau en fonction du trafic et des services (de point de vue des utilisateurs).

L’analyse de la réponse du réseau en fonction du trafic consiste à générer plusieurs types de flux utilisateurs vers le cœur de réseau IMS (l'architecture IMS en tant que "GM" interface). En plus de l'interface Gm, il existe un certain nombre d'éléments de l’architecture IMS qui interagissent les uns avec les autres en utilisant les interfaces définies par l'architecture IMS. L'interaction entre ces éléments nécessite d'être testé et vérifié de manière qu'il n'y ait pas de surprises une fois le réseau déployé.
Les sections suivantes examinent les principales questions qui doivent être adressées avant le déploiement d’un réseau IMS.

Enregistrement et Authentication

L'enregistrement est une composante clé de tout réseau IMS. Si les utilisateurs ne sont pas enregistrés, ils ne peuvent pas accéder aux services du réseau. Pour qu’un utilisateur soit enregistré, l'utilisateur doit être valide et le réseau vers lequel l'enregistrement est réalisé doit être accessible pour l'acceptation de ces enregistrements.

Dans un réseau IMS, plusieurs éléments du réseau sont impliqués dans le processus d'enregistrement. Le premier point de contact pour l'UE est le P-CSCF, qui agit comme un proxy de sortie pour tous les messages de l'UE. Basé sur le domaine de l'UE et les pouvoirs, le P-CSCF contacte l’I-CSCF, qui est le point d'entrée dans le réseau domestique. L’ I-CSCF dirige toutes les demandes d'enregistrement au S-CSCF, qui est responsable de l'authentification de l'UE en téléchargeant les vecteurs d'authentification du HSS. Une fois authentifié avec succès, un tunnel IPSec est établi entre l'UE et P-CSCF basé sur les clés qui sont échangées dans le cadre du protocole AKA. Afin d'assurer la fiabilité de l'enregistrement et des procédures d’authentification, les procédures suivantes doivent être bien comprises et testées de façon approfondie:

·         Mélange de scénarii d'enregistrement :
L'enregistrement en utilisant l’IMS AKA se compose de l'authentification avec une procédure d’échange de clés pour mettre en place le tunnel IPSEC entre l'UE et le P-CSCF. L'enregistrement initial avec authentification nécessite deux fois plus de messages que le processus d'inscription parce qu’un challenge se déroule dans le cadre de l'authentification. Dans un monde réel de déploiement IMS, en parallèle avec l’enregistrement initial , il ya d'autres formes de trafic tels que le ré-enregistrement, le « dé-enregistrement » et la création et cessation de sessions multimédias. Les effets de toutes ces formes de trafic vers le cœur IMS doivent être simulées en laboratoire en créant un mélange de trafic (par exemple, 25% d'enregistrement, 15% de ré-inscription, 25% de fin d’appel et le reste en appels vocaux ) afin de s'assurer que le processus d'enregistrement est sans erreur.

·      Test à partir d'interfaces multiples :
la plupart des tests du cœur IMS se concentre sur la création de la charge de l'UE de l'interface Gm. Même si cela est une interface importante, il faut porter attention aux tests d’autres interfaces, telles que les interfaces HSS (des points de référence de l'architecture IMS Cx, Dx, Sh et Dh). Une panne de réseau chez un important fournisseur de service en Europe, à entrainé une perte de service sur près de 300 000 abonnés. La cause de la panne a été identifiée comme l’échec de la mise à niveau du logiciel de la base de données HLR, entraînant une impossibilité d’enregistrement. Ce scénario met en évidence l'importance des tests sur les autres interfaces, telles que celles à destination et en provenance du HSS ; ce qui inclut la compréhension de l'impact de l'enregistrement, du  ré-enregistrement et du désenregistrement vers le HSS, en plus du trafic générer vers l'IMS par le HSS, tels que les mises à jour du profil du S-CSCF (en raison d’utilisateurs changeant leurs services) et l'enregistrement des demandes de résiliation du HSS. Ce mélange de trafic peut surcharger le cœur IMS et doit être testé pour s'assurer de sa fiabilité. Le graphique suivant montre certaines des interfaces qui génèrent du trafic vers l'IMS et qui devraient être testée avant le déploiement :

Figure 2. Test IMS depuis diverses interfaces. Un port de l’InterWatch est utilisé pour émuler un grand nombre de clients (en utilisant sipFlex), tandisqu’un autre port est utilisé pour émuler le HSS (en utilisant hssFlex)

Veuillez nous contacter pour la suite de ce document.