Étude de la convergence des services de télécommunications

ÉTUDE DE LA CONVERGENCE DES SERVICES DE TÉLÉCOMMUNICATIONS ET SES APPLICATIONS AUX ORGANISATIONS VIRTUELLES

Fonctionnement détaillé de l’IMS : Interopérabilité IMS-SIP

Gestion des profils/identités utilisateurs 

Les types d’identités dans l’IMS

 Comme les réseaux télécoms de base, le réseau IMS utilise aussi la notion d’identités publique et privée. L’identité publique d’un utilisateur désignée ici sous le vocable IMPU (Public User Identity) désigne un URI (SIP ou de type téléphonique) affecté à l’utilisateur et utilisé par les correspondants de ce dernier pour le désigner, et pour le joindre. Selon le type d’URI, le format de l’IMPU peut être : – URI SIP sip :[utilisateur]@[domaine].[com] Voici un exemple :sip :ndiaye@esp.sn – TEL URI Il s’agit d’un numéro de téléphone conventionnel. Voici un exemple : +221338692400 Dans la terminologie télécoms, ce concept est l’équivalent du MSISDN (Mobile Subscriber ISDN Number). L’IMPI (Private User Identity), l’identité privée de l’utilisateur, est utilisée pour identifier et authentifier un abonné et ne joue aucun rôle dans le routage des messages SIP. Cette identité privée est fournie par l’opérateur du réseau IMS et n’est en générale pas connue de l’utilisateur. L’IMPI est généralement stockée dans une ISIM (IMS Subscriber Identity Module). Un équivalent dans les réseaux mobiles est la carte SIM. L’adresse d’une IMPI doit respecter le format suivant : [utilisateur]@[domaine] L’IMS utilise aussi une autre identité : l’IMSU (IMS Subscription). Il s’agit d’un identifiant utilisé pour la facturation. C’est, en général, le nom complet de l’utilisateur. Par exemple, on peut attribuer à IMSU la valeur Claude Lishou ou un numéro par exemple 790010011. 

Relations entre les différents types d’entités 

Dans le terminal de l’utilisateur est stocké une Public et une Private User Identity. Le HSS, qui stocke l’ensemble des informations sur l’utilisateur, dispose d’une table contenant les Public et Private User Identities de l’utilisateur. Le HSS et le S-CSCF lient aussi adresse publique et privée. Le lien entre adresses privées et publiques diffèrent entre les releases 5 et 6 du standard IMS du 3GPP. En effet dans la release 5, un utilisateur possède une unique adresse privée qui peut être liée à plusieurs adresses publiques comme la montre la figure I.2.3 alors que dans la release 6, un utilisateur peut avoir plusieurs adresses privées et deux adresses privées peuvent partager une même adresse publique comme le montre la figure I.2.4. Le fait d’avoir plusieurs adresses privées permet par exemple d’avoir des cartes SIMs différentes pour différents terminaux. 

ÉTUDE AVANCÉE DU RÉSEAU IMS :ARCHITECTURE ET SERVICES 

Gestion des identités

 Les terminaux IMS sont identifiés par la présence d’une carte à puce appelée UICC (Universal Integrated Circuit Card), qui comporte un ensemble d’informations d’identification et de personnalisation. L’interface de communication entre la carte UICC et le terminal est standardisée, mais la carte UICC est générique et peut comporter toutes sortes d’applications, notamment les applications classiques suivantes : SIM (Subscriber Identity Module), USIM (Universal Subscriber Identity Module), ISIM (IP multimedia Services Identity Module).trois applications ne sont évidemment pas les seules. Elles peuvent être utilisées en même temps par le terminal pour fournir plusieurs de ces données enregistrées, selon les connexions (SIM pour les réseaux GSM, USIM pour les réseaux UMTS, etc.). Par contre, il est indispensable de disposer au moins de l’application ISIM ou USIM pour se connecter dans un réseau du 3GPP. En ce qui concerne la version IMS du 3GPP2, la notion d’UICC est absente, mais ces mêmes applications USIM et ISIM peuvent être fournies comme une configuration du terminal de l’utilisateur. 2.4.1.4 Notions de réseau visité et de roaming Avec l’architecture IMS, il est possible d’utiliser de multiples technologies d’accès. Par ailleurs, les zones d’accès géographiques peuvent être aussi larges que possible. Autrement dit, le terminal IMS de l’utilisateur doit pouvoir se connecter de partout. Puisqu’un opérateur possède une infrastructure physique forcément limitée, il convient de prendre en compte la possibilité d’exploiter des réseaux tiers, c’est-à-dire de permettre à un abonné d’un opérateur d’utiliser des réseaux d’accès physiques qui appartiennent à d’autres opérateurs que le sien. Pour cela, on introduit le concept de réseau visité : lorsqu’un utilisateur utilise un réseau qui n’est pas celui de l’opérateur auquel il a souscrit un contrat de services. La connexion de l’utilisateur à un réseau visité est soumise aux accords qui lient son opérateur à l’opérateur qui exploite le réseau visité. On parle de roaming pour désigner la possibilité qu’a un utilisateur de se connecter à un réseau qui n’est pas celui de son opérateur. De même, les accords de roaming décrivent les conditions contractuelles qui lient un opérateur, exploitant une base de données de clients, à un opérateur, exploitant un réseau d’accès avec une couverture géographique. 

Authentification dans l’IMS 

Le mécanisme utilisé pour l’authentification dans l’IMS s’appelle IMS-AKA (Authentication and Key Agreement). C’est un mécanisme d’authentification qui repose sur l’utilisation d’un secret partagé entre l’utilisateur (sur l’ISIM ou à défaut l’USIM) et le réseau IMS (au niveau du HSS). Le HSS, toujours localisé dans le réseau « home » de l’utilisateur, contient un quintuple d’authentification : un challenge aléatoire, RAND, un jeton d’authentification, AUTN (contenant un numéro de séquence et un identifiant MAC), une réponse attendue XRES, une clé de cryptage, CK, et une clé d’intégrité, IK, qui assurent l’intégrité et la confidentialité des messages SIP échangés entre le terminal et le P-CSCF. Au cours de l’enregistrement, le S-CSCF transmet les paramètres RAND et AUTN au terminal qui s’en sert pour calculer une réponse attendue XMAC. L’authentification est mutuelle entre l’utilisateur et le réseau (S-CSCF) : a) le terminal compare son XMAC avec le MAC reçu du réseau : le réseau est authentifié s’ils sont identiques ; b) le réseau compare son XRES avec le RES calculé par le terminal : l’utilisateur est authentifié s’ils sont identiques. Lorsque seule l’USIM est utilisée, il faut dériver les paramètres utiles à l’IMS (qui seraient normalement sur l’ISIM) depuis l’IMSI (identifiant de l’utilisateur pour l’UMTS) stocké sur l’USIM : a) l’identité privée de l’utilisateur qui est une identité publique temporaire qui ne sert que lors de l’enregistrement, les identités publiques associées peuvent en revanche être utilisées ; b) une identité publique de l’utilisateur ; c) le nom de domaine. Par ailleurs, un mécanisme a été introduit pour assurer l’authentification des terminaux qui accèdent à l’IMS sans USIM ni ISIM, en l’occurrence, les terminaux 2G qui n’implémentent pas de fonction IPSec. Ce mécanisme associe l’adresse IP du terminal et les identités de l’utilisateur (identité privée, identités publiques) au niveau du S-CSCF, ce qui permet de vérifier que les messages SIP reçus au S-CSCF ne proviennent pas d’un autre utilisateur.

Enregistrement d’un terminal dans le réseau IMS

 L’enregistrement d’un utilisateur dans le réseau est la première action réalisée par un terminal, dès sa mise en route. Elle est indispensable puisqu’elle permet à la fois d’appeler et d’être joignable par ses correspondants. La méthode associée à cette fonctionnalité est REGISTRER, du protocole de signalisation SIP. La figure I.2.5 illustre les étapes temporelles liées au scénario d’enregistrement. Figure I.2.5 – Procédure d’enregistrement dans l’IMS [4] Dans un premier temps, le terminal IMS envoie sa requête d’enregistrement au serveur P-CSCF. Celui-ci ne connaît pas nécessairement le serveur I-CSCF. Pour localiser ce dernier, le serveur P-CSCF procède à une requête DNS à partir du nom de domaine fourni par l’utilisateur. Une fois localisé, le P-CSCF joint l’I-CSCF en lui fournissant la requête de l’utilisateur, dans laquelle il a ajouté un champ d’entête P – VISITED-NETWORK-ID. Ce champ contient un identifiant du réseau dans lequel le P-CSCF se trouve. Il permettra au S-CSCF de vérifier que le réseau visité bénéficie d’un accord de roaming avec l’opérateur de l’utilisateur. Un autre champ ajouté par le P-CSCF est le champ d’en-tête PATH qui spécifie l’adresse SIP du P-CSCF. Cette information permettra de retourner la réponse à cette requête via ce même serveur P-CSCF. Lorsque le I-CSCF reçoit la requête, il ignore si elle concerne un utilisateur qui est déjà enregistré ou s’il s’agit d’un nouvel enregistrement. Le I-CSCF utilise le protocole Diameter pour contacter la base de données HSS et lui demander, à partir des identités publiques et privées contenues dans le message de requête REGISTER, d’authentifier l’utilisateur (requête UAR). Ensuite, lorsque le client reçoit le message de réponse 401, il prépare automatiquement une réponse adaptée. Cette réponse est générée dans une nouvelle requête d’enregistrement REGISTER. Elle est envoyée en suivant le même processus d’acheminement que le premier message de requête : le terminal client ne connaît que le serveur P-CSCF, qui, lui-même, ne peut s’adresser qu’au I-CSCF, qui, à son tour, sous-traite la demande auprès du serveur S-CSCF. Si les paramètres d’authentification sont valides, le serveur S-CSCF en informe le HSS (par un message SAR). Le HSS répond ensuite au S-CSCF en lui envoyant le profil complet de l’utilisateur, qui est stocké temporairement et servira à paramétrer et personnaliser les services de ce dernier. Pour terminer, le serveur S-CSCF envoie un message de réponse 200 OK au terminal pour lui notifier le succès de l’opération d’enregistrement. 

Mise en communication de deux utilisateurs 

Une communication implique une première étape de recherche des abonnés, de vérification des autorisations d’accès, puis de mise en relation entre les correspondants. La méthode associée à cette dernière fonctionnalité est INVITE avec le protocole de signalisation SIP. La figure I.2.6 ci-dessous illustre la mise en communication de deux utilisateurs. On considère que l’appelant et l’appelé ont des opérateurs différents et se trouvent dans des réseaux visités. Ce scénario de mise en relation de deux terminaux peut être découpé en sept grandes étapes : 1. L’appelant (A) envoie un message d’invitation à l’appelé (B), pour proposer de négocier les paramètres de la communication. A doit solliciter le terminal de B et, pour cela, il s’adresse au serveur I-CSCF de B, qui le localise après une requête Diameter. Le terminal de B lui envoie deux réponses temporaires : une réponse 100 pour indiquer la tentative et une réponse 183. 2. Pour rassurer son correspondant qu’il a bien reçu la réponse 183, A doit impérativement envoyer à B un acquittement temporaire. 3. Le terminal A négocie ensuite les paramètres de qualité de service pour garantir sa communication dans le réseau. Cette étape permet aux utilisateurs d’établir une communication avec une bande passante garantie, et donc un service de qualité. Le terminal de B vérifie ensuite que lui aussi a réservé les ressources nécessaires à la communication dans le réseau et valide la requête par sa réponse. 4. Dès cet instant, le terminal de B commence à sonner. Cette étape complète les réponses temporaires à la requête d’invitation par une réponse 180, elle aussi temporaire. 5. Pour s’assurer que cette réponse est bien reçue du terminal A, ce dernier doit confirmer la réception par une requête d’acquittement, qui attend elle-même une réponse. 6. Dès que l’utilisateur du terminal B a répondu, la réponse définitive 200 est envoyée à la requête initiale d’invitation. 7. La requête d’acquittement finale valide l’initialisation de la communication, qui peut dès lors débuter pour permettre aux terminaux de s’échanger des flux de données multimédias. 

Modification des sessions 

Parmi les services offerts par l’IMS, la session multimédia apparaît comme le service de base qui permet de mettre en communication deux terminaux pour échanger un ou plusieurs flux de média. Des serveurs d’application peuvent être contactés lors de l’établissement de la session. Il est également possible d’établir une session multimédia entre un terminal et un serveur d’application via le réseau IMS. L’appelant ou l’appelé peut demander une modification de la session en cours à tout moment. La demande de modification de session est exprimée par le terminal via le message « SIP UPDATE » ou un message de type « re-INVITE » qui contient une nouvelle description pour la session en cours. Une modification de session peut consister à ajouter ou supprimer un ou plusieurs médias, à changer de codec sur un ou plusieurs médias, à changer de numéro de port pour un ou plusieurs flux de médias, à changer la bande passante pour un ou plusieurs médias. 

Fin d’enregistrement 

Le terminal demande notamment la fin d’enregistrement quand l’utilisateur ne souhaite plus accéder à ses services. Cette procédure démarre avec l’envoi d’un message SIP REGISTER depuis le terminal. La fin d’enregistrement peut également survenir à l’initiative du réseau. Dans ce cas, on utilise le message « SIP NOTIFY » en lieu et place de «SIP REGISTER ». Lors d’une fin d’enregistrement, le terminal doit mettre fin à ses sessions en cours, le HSS supprime l’adresse du S-CSCF stockée pour l’utilisateur, les CSCF et le terminal suppriment les données d’enregistrement correspondant à l’adresse publique et l’adresse IP pour lesquelles la fin d’enregistrement est demandée. Enfin, le terminal et le P-CSCF suppriment l’association de sécurité établie entre eux pendant l’enregistrement, s’il ne reste plus d’enregistrement actif pour l’utilisateur. 

L’architecture de service IMS 

Dans cette section, nous examinerons en détails la couche service de IMS. Le plan de service de l’IMS est conçu pour fournir la prochaine génération d’applications avec SIP et fonctionner avec les plates-formes de services existantes. Les éléments du plan de service appelés serveurs d’applications (SA) ont la capacité de prendre en charge la logique applicative d’un service. Ils peuvent fournir les services multimédia à valeur ajoutée tels que la présence, le service push-to-talk, etc. Les fonctions principales des SA sont : – la possibilité de traiter et modifier une session SIP entrante – la capacité d’initier des requêtes SIP – la capacité d’envoyer des informations de comptabilisation aux organes de taxation. Ils peuvent en outre fonctionner comme une passerelle ou fournir une fonction d’interopérabilité avec un serveur natif -du réseau intelligent- ou un serveur non-SIP. Ils peuvent aussi jouer un rôle de coordination de la logique de service entre plusieurs serveurs. Quel que soit leur rôle, les SA communiquent avec le S-CSCF par le protocole SIP au travers de l’interface IMS Service Control (ISC). Ils ont également accès aux informations d’abonné stockées dans le serveur HSS. Les SA se retrouvent aussi bien dans le réseau nominal de l’abonné que dans celui d’un fournisseur tiers de services.