Continuité des services de télécommunications dans l’IMS

Continuité des services de télécommunications dans l’IMS

 Motivation 

On ne peut aujourd’hui étudier les services de télécommunications sans considérer l’IP Multimedia Subsystem (ims cf. 1.2.2). Cette architecture nouvelle génération a donc été le point de départ de notre étude sur la continuité et ce pour plusieurs raisons : une orientation « télécoms » qui correspondait à l’angle d’attaque choisi, une infrastructure complète, standardisée et prometteuse s’imposant comme la nouvelle architecture de référence et enfin la disponibilité de plateformes expérimentales ims permettant d’évaluer nos contributions au sein même de nos laboratoires à TELECOM SudParis et Alcatel-Lucent Bell Labs France. L’infrastructure ims est le cœur fonctionnel de la téléphonie mobile nouvelle génération (3G), il comporte ainsi un grand nombre de mécanismes participant à la gestion de la mobilité : routage, itinérance (roaming), profils de service, identification, etc. De plus, l’un des objectifs majeurs étant d’assurer la convergence des réseaux, l’interopérabilité des différentes technologies d’accès est réalisée autour d’un noyau IP commun, l’ims, sur lequel repose les services. La couche accès étant dissociée de la couche service dans ce modèle horizontal, un plus grand nombre de terminaux et donc de clients potentiels apparaissent ; les services doivent alors 61 Continuité des services de télécommunications dans l’IMS être délivrés de manière cohérente entre ces appareils électroniques de plus en plus nombreux, puissants mais surtout aux capacités hétérogènes. Avec plus de réseaux d’accès, plus de terminaux et plus de clients, le besoin en mobilité se renforce. Si les mécanismes ims basés sur le protocole sip (cf. 2.3.2) assurent les différents types de mobilité tels que définis par l’itu (cf. 2.1), la mobilité de service au sens propre, qui inclut la contrainte de continuité, n’est pas assurée. Les problématiques classiques de continuité : network et terminal handover, ne sont pas prises en compte. Le network handover est partiellement réalisé uniquement. Si les handovers horizontaux sont gérés de manière transparente pour l’ims au niveau de l’accès, les handovers verticaux nécessitant un changement d’adresse ont pour incidence d’interrompre les sessions de communications. Or l’ims, reposant sur sip, ne délivre intrinsèquement que des services basés sur des sessions. Ce type de continuité requiert des mécanismes spécifiques qui font actuellement défaut dans l’ims. Le terminal handover, quant à lui, n’est simplement pas réalisable en l’état actuel de l’infrastructure. Le protocole sip peut théoriquement effectuer un transfert de sessions entre plusieurs terminaux, mais d’un point de vue architectural l’ims n’implémente pas les mécanismes requis pour mettre en œuvre ces solutions. Face à un besoin croissant en mobilité et une infrastructure de services 3G telle que l’ims qui ne peut assurer une continuité et donc une expérience utilisateur satisfaisante, nous essayons de répondre à cette problématique et ses deux principales contraintes : le network handover (mobilité de terminal) et le terminal handover (mobilité d’utilisateur). L’objectif est de permettre à un utilisateur de conserver ses services en mobilité lors de la transition entre différents milieux : au travail, à la maison, dans un lieu public. . . transition qui se traduit généralement par divers transferts (inter- terminaux et technologies cf. Figure 3.1). Nous étudions ces différents scénarios dans le cadre de l’ims, donc d’un point de vue applicatif, et proposons des solutions compatibles avec les spécifications actuelles. 

Network handover 

Comme précisé en section 2.1.1, seul le cas du network handover vertical requiert un comportement applicatif spécifique pour assurer la continuité de service, le reste de cette section sera dédiée aux problématiques propres à ce cas précis dans la définition du Session Continuity AS. Déclenchement. Comment déclencher un transfert entre différents réseaux ? Les motivations d’un changement de technologie d’accès pendant la fourniture d’un service sont multiples : coût, encombrement du réseau, perte de signal, qualité de service requise, . . . De manière générale, ces motivations résultent d’une décision automatique, basée sur des règles, et effectuée au niveau du terminal ou de l’infrastructure selon des critères réseau. L’utilisateur est rarement l’initiateur d’un tel transfert, alors la question est moins de savoir comment mais quand effectuer ce transfert ? Selon notre approche as et avec un terminal standard, la décision ne peut s’effectuer qu’au niveau infrastructure et ce d’après les messages de signalisation sip qui transitent par le cœur ims. Un changement de réseau d’accès pourra alors se détecter de deux manières en fonction des capacités du terminal et de la couverture des technologies réseaux. Soit le terminal peut se connecter simultanément aux deux réseaux (on parle de hard handover), soit il devra se déconnecter au réseau d’origine avant d’initier la seconde connexion (on parle alors de soft handover) cf. [78]. On peut intuitivement supposer qu’une déconnexion préalable sera moins 64 optimale qu’une connexion simultanée d’un point de vue continuité (temporelle) du service. Pour pouvoir se connecter simultanément à deux accès, deux conditions doivent être remplies au moment du transfert : le terminal doit être couvert par les deux technologies (cf. Figure 3.2) et il doit gérer les deux interfaces simultanément (au niveau réseau, propriété appelée multihoming [79] mais aussi au niveau radio, propriété appelée dual mode). Si les deux conditions sont remplies, le terminal restera connecté en continu avec l’infrastructure (via l’une ou les deux interfaces), un processus de transfert sans interruption est alors envisageable, sinon le terminal passera obligatoirement par une phase déconnectée (cf. Figure 3.3), on pourra alors seulement offrir une solution de secours ou reconnexion. 

Soft handover

 Le soft handover est un transfert sans interruption réalisable si le terminal est connecté simultanément à l’ims via deux interfaces différentes. Il est alors identifié doublement au niveau de l’infrastructure qui le voit comme deux entités distinctes, chacune possédant une adresse réseau différente. La problématique de network handover revient ainsi à celle de terminal handover, en transférant le service d’une adresse réseau à une autre le mécanisme de continuité réalisera en fait un changement d’interface sur le même terminal. Les détails du mécanisme en question sera présenté dans la section 3.3.3. Il est à noter que l’infrastructure ims doit supporter l’enregistrement multiple des clients. En effet, l’adresse sip-ims (appelée sip uri) doit pouvoir être associée à de multiples adresses réseaux. Cette fonctionnalité aussi appelée multi-registration incluse dans la norme est parfois non supportées par les solutions ims. Le cas échéant, le terminal devra utiliser un sip uri différent pour chaque interface et non par terminal, le mécanisme de transfert sera lui indique.

 Hard handover

 Lorsque la déconnexion est inévitable, une solution alternative de (relative) continuité consiste à rétablir le service en initiant une nouvelle connexion. En enregistrant les messages de signalisation, le scas peut sauvegarder les différentes caractéristiques des services de communications établis dans l’ims. L’interruption  causée par le changement de réseau d’un terminal va terminer la (ou les) session correspondante de manière brutale, la laissant dans un état non-terminal. En effet, si la session n’est pas terminée « proprement » par un message de type bye [12], le scas pourra déterminer qu’un incident de connectivité s’est produit. La reconnexion du terminal à l’ims une fois le changement d’interface effectué, le scas possèdera suffisamment d’informations pour rétablir la communication en établissant une nouvelle session entre les interlocuteurs. Cette solution peut être implémentée de deux manières différentes, soit via un contrôle de la session par une tierce partie (3pcc [62]) soit via le mécanisme sip refer (cf. [54]). Quel que soit la méthode choisie, il est nécessaire de respecter la logique de paiement de l’appel initialement établi. En effet, il doit y avoir une cohérence entre les services mis en œuvre (et donc facturés) dans l’appel initial interrompu et la communication nouvellement établie qui n’est que la continuité de ce premier. Par exemple, si A appelle B puis est interrompu, après reconnexion A doit être facturé (et non B) comme pour un unique appel et conformément à la durée réelle de connexion.