Problématiques de mobilité

Problématiques de mobilité

Types de contraintes

 La mobilité « c’est quand ça bouge », pourrait-on penser benoîtement. Et en effet, même dans le domaine des Technologies de l’Information et de la Communication, il faut du mouvement pour parler de mobilité. Mais dans un environnement composé de terminaux, de réseaux d’accès, d’utilisateurs, d’applications, de services, de sessions, . . . les combinaisons de mouvement sont infinies. Cette potentielle mobilité totale des composantes du système crée de multiples contraintes et ce à toutes les couches réseau du modèle de référence osi [44]. Au niveau transport bien entendu mais également au niveau applicatif. La mobilité a longtemps été exclusivement étudiée dans les couches inférieures, typiquement pour résoudre des problèmes de routage ou d’accès. Mais avec l’explosion des télécommunications mobiles ces quinze dernières années, la gestion de la mobilité au niveau applicatif a pris une importance croissante, notamment avec le développement d’architectures télécoms de nouvelle génération ngn (Next 35 Problématiques de mobilité Generation Network). Les différents types de contraintes de mobilité ont été répertoriés, formalisés notamment dans une recommandation de l’itu-t (Q.1706 [45]) qui semble partagée par l’ensemble de la littérature. Quatre contraintes de mobilité y sont définies. – Mobilité de terminal (terminal mobility). Permettre à un terminal en mouvement de conserver l’accès au réseau. L’itu-t insiste en fait ici sur la capacité du réseau à gérer le mouvement de ses terminaux (problématiques de localisation, d’identification, de routage, d’itinérance ou roaming, etc). – Mobilité de réseau (network mobility). Permettre à un sous-réseau de se réorganiser afin de changer de point de rattachement à son super-réseau (typiquement Internet). Nous sommes encore dans des problématiques de réseau et plus précisément de routage. – Mobilité personnelle (personal mobility). Permettre à un utilisateur de changer de terminal tout en conservant l’accès au réseau ainsi qu’à son profil et à ses services. Les problématiques restent au niveau architecture avec la capacité du réseau à identifier les utilisateurs et gérer les profils correspondants. – Mobilité de service (service mobility). Enfin la mobilité de service qui reste encore et toujours au niveau réseau. L’itu-t crée ici une nouvelle catégorie qui regroupe à la fois les contraintes de mobilité de terminal et de mobilité personnelle. Donc permettre à un utilisateur, quel que soit sa localisation ou le terminal qu’il utilise d’avoir accès à ses services personnalisés. Ces contraintes sont basées sur des considérations architecturales pour la définition de la mobilité dans les ngn, l’itu répond ainsi à la question : quels mécanismes un réseau, dans le sens « infrastructure de service », doit implémenter pour assurer une mobilité totale de ses services télécoms. Or nous nous intéressons dans cette étude à tous les services et ce du point de vue de l’utilisateur et non pas d’un point de vue purement architectural. La classification de l’itu est particulièrement juste et le nombre de travaux qui la réutilisent en est la preuve. Cependant, pour réellement comprendre quels sont les enjeux et la vraie problématique de mobilité appliquée aux services, nous devons analyser l’impact de chacune de ces contraintes au niveau applicatif. 36 La mobilité de réseau étant comme son nom l’indique une problématique de bas niveau (d’après le modèle osi), nous ne nous y intéresserons pas, d’autant que certains de ses aspects sont traités par la mobilité de terminal (cf. 2.1.1). Il ne reste donc plus que la mobilité de service, c’est à dire les mobilités de terminal et personnelle (cf. Figure 2.1). Nous analysons ces deux contraintes d’un point de vue service dans les sections suivantes sous le nom de terminal en mouvement (cf. 2.1.1) et déplacement de l’utilisateur (cf. 2.1.2). Enfin nous nous intéresserons à une contrainte supplémentaire, la mobilité partielle de service qui consiste en une mobilité interne au service lui-même, d’où son absence dans la classification itu de plus bas niveau. Figure 2.1 – Problématiques de mobilité. 

Terminal en mouvement 

Peut-être la contrainte de mobilité la plus commune : le terminal en mouvement. Lorsque vous passez un appel en voiture avec votre téléphone mobile (et votre kit main libre), sans le savoir votre communication audio peut être transférée plus de vingt fois. . . une vraie prouesse technique. C’est l’exemple même d’une mobilité de service réalisée avec succès car totalement transparente pour l’utilisateur. Ce type de contrainte intrinsèque à toute connectivité sans fil fait l’objet de nombreux travaux, on peut même dire que c’est l’effort principal des problématiques de recherche sur la mobilité. Un terminal en déplacement, typiquement un téléphone mobile, n’est opérationnel que lorsqu’il est relié au réseau téléphonique dont il dépend. Pour être 37 plus exact, c’est le service de communication délivré via ce terminal qui requiert une connexion à l’infrastructure de l’opérateur téléphonique. Cette connectivité est réalisée grâce à diverses technologies de radiocommunication entre le terminal et les antennes-relais déployées par l’opérateur afin d’assurer une couverture maximale et donc une connectivité constante de ses clients. Toute la problématique consiste alors à maintenir la connexion entre le terminal et le réseau, chaque antenne ayant une portée limitée il est nécessaire de changer régulièrement de point d’accès pendant un déplacement, ce mécanisme de transfert s’appelle handover ou handoff . Le handover est un mécanisme fondamental dans la télécommunication mobile et il se décline en deux sous-catégories : handover horizontal et vertical . Le handover horizontal consiste en le passage d’un point d’accès à un autre via la même technologie radio, c’est ce qui arrive typiquement à votre téléphone mobile gsm lorsque vous vous déplacez. Mais l’émergence d’un grand nombre de nouvelles normes radio (umts, wi-fi, wimax, etc) a fait qu’un même terminal peut avoir simultanément le choix de connectivité entre plusieurs technologies d’accès. Le terminal se déplace alors « abstraitement » au niveau réseau (pas de mouvement géographique nécessaire), passant d’un point d’accès à un autre en changeant de technologie radio. C’est ce que l’on appelle « handover vertical ». Ce deuxième type de handover est plus difficile à mettre en œuvre, de part l’hétérogénéité des technologies et des mécanismes entrant en jeu, mais aussi des infrastructures pouvant être contrôlées par différents opérateurs. De nombreux travaux de recherche se sont intéressés à ces problèmes qui sont généralement traités par paire de technologies parmi les plus connues : gprs, wi-fi, umts, wimax, . . . Que ce soit dans le cadre d’un handover horizontal ou vertical, un terminal en mouvement entraîne uniquement des conséquences de niveau réseau : interruption de la connectivité, modification de la bande passante ou du délai, etc. D’un point de vue applicatif, seuls les services connectés (cf. [45]) sont sensibles à ce type de contrainte. 

Déplacement de l’utilisateur

 Deuxième contrainte ayant un impact applicatif : le déplacement de l’utilisateur, et uniquement lui. . . En effet, si le terminal se déplace en même temps que son propriétaire, alors on revient au cas précédent où la seule mobilité est celle du terminal par rapport à son environnement (2.1.1). On suppose ici que c’est l’interface Homme/Machine qui change, l’utilisateur passe d’un terminal à un autre comme précédemment le terminal passait d’un point d’accès à un autre, on parle alors de terminal handover, par opposition au (network) handover que nous venons de voir. Ce type de handover a un impact direct sur tous les services de l’utilisateur qui passe d’une interface, d’un environnement, à un autre a priori complètement différent. Cette contrainte de mobilité est finalement très peu étudiée alors qu’elle concerne l’ensemble des services, posant de nombreux problèmes notamment ceux de continuité et d’adaptabilité. Cependant, une nouvelle fois le problème a été approché d’un point de vue « réseau », ainsi en se basant sur les sessions (cf. 1.1.2) certains mécanismes ont rendu possible le transfert de services connectés simples (communication audio) d’un terminal à un autre. Sip par exemple permet de transférer un service de communication multimédia tout en l’adaptant à son nouvel environnement, cf. 2.3.2. Ce type de transfert est communément illustré par la redirection d’appels dans les standards téléphoniques. Le transfert de sessions ne répond toutefois pas de manière satisfaisante au problème, un service connecté (ou non-connecté a fortiori) ne peut être réduit à une (ou des) session. Il est également intéressant de noter que d’un point de vue réseau, un terminal handover se traduit uniquement par un changement d’adressage (typiquement ip) de manière analogue à un network handover vertical (2.1.1). Ainsi une solution qui permettrait le transfert d’un service basique (constitué uniquement de sessions) entre réseaux hétérogènes pourrait dans une certaine mesure être utilisé pour réaliser un terminal handover. 

 Principe de transfert

 La contrainte de déplacement de l’utilisateur qui induit le mécanisme de terminal handover sera le type de mobilité le plus étudié durant ces travaux. Afin 39 d’assurer une compréhension uniforme, nous rappelons ici le principe de transfert et la terminologie employée. Un terminal handover a pour principe le déplacement d’un service en cours, d’un terminal origine vers un terminal destination, cf. Figure 2.2. Le déclenchement du processus de mobilité est réalisé soit de manière automatique, soit de manière manuelle par l’utilisateur. Dans le cas manuel, on distingue deux types de déclenchement : le mode « push » lorsque l’utilisateur contrôle la mobilité depuis le terminal origine (et « exporte » le service vers sa destination) et le mode « pull » où il contrôle la mobilité depuis le terminal destination (et importe le service distant vers celui-ci). Figure 2.2 – Principe de transfert (terminal handover ).

Mobilité partielle de service 

Dernière contrainte de mobilité de niveau applicatif : la mobilité partielle de service. La notion de service est assez vague et dépend du domaine concerné tel que nous l’avons vu dans le première chapitre de cet état de l’art (1). Or il est parfois possible qu’un service résulte de la composition de plusieurs autres, plus simples. Dans ce cas la mobilité peut s’appliquer à ses différentes composantes afin de, par exemple, adapter la fonctionnalité globale à son environnement. Les services connectés qui font l’objet de nombreux travaux notamment dans le domaine des télécommunications illustrent bien ce découpage, chacune des ses40 sions de ces services pouvant généralement être assimilée à un sous-service indépendant et donc mobile selon des contraintes terminal ou utilisateur (cf. 2.1.1 et 2.1.2). Par exemple, un service de visiophonie (télécommunication voix + vidéo) peut être vu comme la composition des services de communication audio et vidéo (correspondant aux deux sessions multimédias). Pour diverses raisons (coût, délai, encombrement, etc), il est théoriquement possible de séparer les composantes de ce service et de gérer leur mobilité de manière indépendante : le service audio pourrait par exemple changer de technologie d’accès tout en restant sur le même terminal tandis que le service vidéo serait transféré vers un autre périphérique. Cet « éclatement » du service en sous-services dont la mobilité est gérée indépendamment est appelé session splitting. Naturellement, le mécanisme inverse qui consiste à « rassembler » plusieurs fonctionnalités en un seul super-service est également réalisable et s’appelle session merging. Les travaux réalisés sur cette contrainte de mobilité ne concernent aujourd’hui que les services basés sur des sessions et les approches existantes permettent uniquement le transfert de ces sessions, cf. [47, 48]. Or ce type de mobilité confère de grandes capacités d’adaptation aux super-services concernés, en effet le fractionnement des blocs fonctionnels permettent naturellement une adaptation plus fine à l’environnement.

Notion de continuité

 Nous avons vu les concepts de service et de mobilité, nous arrivons donc à l’aspect « continuité » qui est le concept clé du sujet d’étude. À ce titre, la continuité aurait pu être traitée dans un chapitre à part entière, cependant la continuité n’est autre qu’une contrainte relative et inaliénable au concept général de mobilité. Ainsi dans cette section nous définirons le principe de continuité, puis nous présenterons ses deux aspects majeurs perçus par l’utilisateur. 

Principe 

La continuité est une contrainte supplémentaire à celle de mobilité. Pour être satisfaite, les processus mis en œuvre doivent assurer une fourniture continue de  la fonctionnalité en mobilité. Plus concrètement et du point de vue utilisateur, la continuité est l’assurance d’une mobilité transparente ; ainsi les aspects qui rendent la mobilité perceptible doivent être minimisés, optimisés à défaut d’être supprimés. La mobilité de service qui est l’objet de cette étude ne peut être considérée sans la continuité, elle était d’ailleurs implicitement présente dans les définitions précédentes (cf. handover). En effet, l’utilisateur est en contact direct avec la couche applicative, et la mobilité des fonctionnalités offertes est directement et immédiatement ressentie. Une mobilité de service sans continuité reviendrait à offrir le même service via différents terminaux et ce sans cohérence. . . cela est déjà possible : je peux aujourd’hui établir une communication audio depuis un téléphone fixe, un ordinateur ou un terminal mobile. En d’autres termes, la continuité est la mobilité de l’instance d’un service (cf. 1.1.2). La mobilité de service tel que l’entend l’itu correspond à une problématique réseau qui consiste à assurer une continuité des profils utilisateur, ainsi les mêmes services personnalisés seront disponibles quelque soit le terminal utilisé. Comme nous nous intéressons dans ce mémoire à l’impact utilisateur, nous considérons la mobilité de service d’un point de vue applicatif qui ne peut réalisée sans continuité. Cette problématique de continuité de service présente deux aspects principaux perçus par l’utilisateur : les continuités temporelle et contextuelle (cf. Figure 2.3). Figure 2.3 – Problématiques de continuité. 

Continuité temporelle

 La continuité temporelle impose des contraintes quantitatives aux mécanismes de mobilité. En effet, les travaux existants sur la mobilité de session, qui peuvent être vus comme une première approche de mobilité de service (cf. 2.3.2) cherchent à minimiser une valeur unique : le temps de transfert. La mobilité d’un service implique généralement une interruption liée au mécanisme de transfert (vers un nouveau réseau 2.1.1 ou terminal 2.1.2). La première des « anomalies » de continuité alors perçue par l’utilisateur est le délai d’indisponibilité de la fonctionnalité. Cette anomalie a un fort impact sur l’utilisateur car elle le prive temporairement de son service, nécessitant parfois une réinitialisation dans la cas de services connectés. La continuité temporelle requiert ainsi des mécanismes spécifiques afin de minimiser, voire masquer, cette interruption inéluctable. Le protocole sip par exemple, via la méthode refer (cf. 2.3.2), implémente un mécanisme de synchronisation pour le transfert de sessions audio, le délai est ainsi minimisé et masqué par une superposition des flux audio provenant des terminaux origine et destination. Similairement, un network handover vertical peut être réalisé de manière quasitransparente si le terminal est capable de gérer la connexion simultanée à plusieurs réseaux d’accès. Le délai de transfert peut être optimisé afin d’offrir une continuité temporelle satisfaisante, c’est notamment le cas avec certains services connectés simples qui nécessite finalement une faible quantité de données à transférer. Mais qu’en est-il des services non-connectés ou possédant un contexte important ?