FR2934745A1 - Terminal multimode a connexions optimisees - Google Patents

Abstract

L'invention concerne un terminal mobile comprenant un dispositif (ACM1) de gestion de canaux (CA1, CAx) utilisés par des applicatifs (App1, Appx) internes au terminal mobile, permettant de proposer à chaque applicatif des canaux optimisés notamment grâce au fait qu'il comprend un bus (B0) de gestion en communication avec le dispositif de gestion et avec au moins un applicatif, une pluralité de messages étant transmis entre le dispositif de gestion et cet applicatif, dont au moins des messages représentatifs d'un canal de communication de type déterminé, cet applicatif comprenant un module d'enregistrement permettant son enregistrement auprès du dispositif de gestion lors de son activation et un module de désenregistrement permettant son désenregistrement lors de sa désactivation.

Description

TERMINAL MULTIMODE A CONNEXIONS OPTIMISEES

Le domaine de la présente invention est celui des télécommunications. Plus particulièrement, il s'agit d'un dispositif de gestion des communications dans un terminal capable de communiquer par plusieurs réseaux. Les réseaux de communication par ondes radiofréquence couvrent des zones communes et des zones complémentaires les unes des autres. L'évolution technologique par exemple des différents réseaux cellulaires, s'est accompagnée d'un développement des terminaux mobiles multimodes capables de communiquer sur plusieurs réseaux. Un terminal mobile pouvant communiquer par le réseau UMTS (Universal Mobile Telecommunications System) également appelé 3G, est aussi capable de communiquer par le réseau GPRS (General Packet Radio Service) ou 2,5G et par le réseau GSM (Global System for Mobile communications) ou 2G. Un procédé de transfert entre deux cellules, également appelé handover permet par exemple lors d'une communication, de passer d'une cellule radio à une autre dans un même réseau ou permet de passer d'un réseau à un autre. Le handover permet de gérer la continuité dans la transmission de données, par exemple pour les données de type voix, de type texte, de type multimédia ou d'autres types de données transférées. Un dispositif de gestion des connexions, également appelé connection manager , intégré dans un terminal mobile, permet par exemple de sélectionner un réseau parmi plusieurs réseaux disponibles.

Cependant les solutions actuelles de dispositifs de gestion des connexions ou les solutions de hand over entre réseaux telles que UMA ou Mobile IP, se contentent généralement de traiter les problèmes de connexion, par exemple à Internet, par la gestion des couches de protocoles au niveau TCP/IP ou inférieures et ne prennent pas en compte l'ensemble des spécificités de fonctionnement au niveau de la couche applicative. Un dispositif de gestion des connexions existant peut par exemple basculer d'un premier réseau vers un second réseau tandis qu'un applicatif incompatible avec le second réseau est exécuté. Cet applicatif se place alors dans un état bloqué ou un état d'erreur, puis même si le dispositif de gestion des connexions rebascule vers le premier réseau compatible avec cet applicatif, l'applicatif ne peut pas sortir de l'état bloqué ou d'erreur sans une intervention par exemple de l'utilisateur. Un navigateur Internet installé sur un terminal mobile sera par exemple limité à des accès Internet via un réseau local Wi-Fi ou éventuellement via le réseau cellulaire UMTS, selon le type d'abonnement souscrit par l'utilisateur. Une application de consultation de courriers électroniques sera par exemple limitée aux connexions sécurisées après authentification telles que les communications par le réseau UMTS ou GPRS, tandis que son fonctionnement par un réseau Wi-Fi public non protégé sera empêché. De plus selon le type de réseau utilisé, un utilisateur disposera de plus ou moins de ressources disponibles en terme de vitesse de transfert et d'occupation des ressources radio. Il existe donc un besoin pour les terminaux utilisant les dispositifs de gestion des connexions d'accorder en temps réel les états des applicatifs en cours d'exécution dans le terminal mobile d'une part avec les états des connexions établies par le terminal mobile et d'autre part avec le plan tarifaire adopté par le client, de façon à améliorer la qualité d'utilisation pour avoir un réseau dont la vitesse de transfert, la sécurité et le coût d'utilisation sont adaptés à l'applicatif utilisant ces ressources, tout en optimisant les utilisations des ressources des différents réseaux. La présente invention a pour objet de supprimer un ou plusieurs des inconvénients de l'art antérieur en proposant, dans un terminal mobile, un dispositif de gestion d'un ou plusieurs canaux de communication pour un ou plusieurs applicatifs du terminal mobile permettant d'améliorer la qualité d'utilisation pour avoir un réseau dont la vitesse de transfert, la sécurité et le coût d'utilisation sont adaptés à l'applicatif utilisant ces ressources, tout en optimisant les utilisations des ressources des différents réseaux. . Cet objectif est atteint grâce à un terminal mobile comprenant des composants de communication avec l'extérieur du terminal mobile et un dispositif de gestion des connexions qui comprend un module de création ou de suppression de canaux de communication entre l'extérieur du terminal mobile et au moins un applicatif interne au terminal mobile, les canaux établis via plusieurs couches de protocoles étant commandés par le dispositif de gestion, caractérisé en ce qu'il comprend un bus logiciel de gestion prédéterminé en communication d'une part avec une interface du dispositif de gestion et d'autre part avec une interface dudit applicatif, ledit applicatif comprenant un module d'enregistrement permettant son enregistrement auprès du dispositif de gestion au moment d'une activation de cet applicatif et un module de désenregistrement permettant son désenregistrement auprès du dispositif de gestion au moment d'une désactivation de cet applicatif, une pluralité de messages relatifs à des canaux de communication, étant transmis entre le dispositif de gestion et ledit applicatif, dont au moins un message envoyé au dispositif de gestion et représentatif d'un canal de type déterminé requis par ledit applicatif ou au moins un message envoyé audit applicatif et représentatif d'un canal déterminé disponible pour ledit applicatif. Selon une autre particularité, ledit applicatif activé envoyant une requête d'enregistrement comprenant des données représentatives des types de canaux de communication utilisables par l'applicatif, le dispositif de gestion comprend un module d'adressage d'applicatifs communiquant avec l'extérieur du terminal mobile, mémorisant des identifiants d'applicatifs activés et supprimant des identifiants d'applicatifs désactivés.

Selon une autre particularité, à chaque enregistrement d'un identifiant d'un applicatif nouvellement activé, par le module d'adressage, le dispositif de gestion transmet à l'applicatif nouvellement activé, un message comprenant des données représentatives d'un canal déterminé parmi les canaux créés, attribués par le dispositif de gestion, à l'applicatif nouvellement créé, ou le dispositif de gestion transmet à l'applicatif nouvellement activé, un message comprenant des données représentatives des canaux utilisables par l'applicatif nouvellement créé.

Selon une autre particularité, lors de la création d'un nouveau canal de communication par le dispositif de gestion, un message, comprenant des données représentatives du nouveau canal, est transmis, par le dispositif de gestion, à chaque applicatif identifié dans le module d'adressage ou le nouveau canal est comparé aux canaux déjà créés pour une éventuelle attribution du canal nouvellement créé à un des applicatifs du module d'adressage. Selon une autre particularité, lors de la suppression d'un canal de communication par le dispositif de gestion, un message, comprenant des données représentatives de la suppression de ce canal, est transmis, par le dispositif de gestion, à chaque applicatif identifié dans le module d'adressage ou une nouvelle attribution de canal est gérée par le dispositif de gestion pour les applicatifs utilisant ce canal. Selon une autre particularité, l'applicatif est réalisé par un script exécuté par un interpréteur comprenant des fonctions de communication avec le dispositif de gestion via le bus logiciel de gestion, l'exécution du script démarrant par l'envoi du message d'enregistrement. Selon une autre particularité, le message d'enregistrement comprend des paramètres de tarification représentatifs d'au moins un type de canal de 20 communication, comprenant : - l'identifiant mémorisé dudit applicatif ou, - un identifiant d'un compteur d'usage incrémenté par le module de gestion lors de l'activation dudit applicatif ou, - un seuil maximum du compteur d'usage dont le dépassement est 25 contrôlé par le dispositif de gestion ou, - un type de tarification. Selon une autre particularité, le message d'enregistrement comprend des données représentatives d'un point d'accès à un service nécessaire à l'applicatif, l'accès à ce point d'accès à un service, étant testé et validé par le 30 dispositif de gestion avant de l'attribution du canal de communication. Selon une autre particularité, le message d'enregistrement comprend des données représentatives d'un protocole déterminé ou d'un serveur déterminé ou d'un port de communication déterminé, testés et validés par le dispositif de gestion avant de l'attribution du canal de communication. Selon une autre particularité, le message d'enregistrement comprend des données représentatives d'une sécurité minimum ou d'une authentification minimum par un identifiant et un mot de passe, testés et validés par le dispositif de gestion avant de l'attribution du canal de communication. Selon une autre particularité, le message d'enregistrement comprend des données représentatives d'un débit minimum ou d'une largeur de bande passante minimum, testés et validés par le dispositif de gestion avant de l'attribution du canal de communication. Selon une autre particularité, le terminal mobile comprend un module d'attribution gérant une pluralité de canaux compatibles avec ledit applicatif et attribuant un de ces canaux à l'applicatif en favorisant : - le canal associé aux données de tarification la moins coûteuse ou, - le canal associé aux données de débit le plus important ou, - le canal comprenant un point de connexion au réseau appartenant à une liste mémorisée de points de connexion au réseau prioritaires. Un autre objet de la présente invention est de proposer un procédé de gestion des communications, dans un terminal mobile, par un dispositif de gestion d'un ou plusieurs canaux de communication pour un ou plusieurs applicatifs du terminal mobile permettant d'améliorer la qualité d'utilisation pour avoir un réseau dont la vitesse de transfert, la sécurité et le coût d'utilisation sont adaptés à l'applicatif utilisant ces ressources, tout en optimisant les utilisations des ressources des différents réseaux. Cet objectif est atteint grâce à un procédé de gestion des communications dans un terminal mobile comprenant des composants de communication avec l'extérieur du terminal mobile et un dispositif de gestion des connexions qui comprend un module de création ou de suppression de canaux de communication entre l'extérieur du terminal mobile et au moins un applicatif interne au terminal mobile, les canaux établis via plusieurs couches de protocoles étant commandés par le dispositif de gestion, caractérisé en ce qu'il comprend : - une étape d'envoi d'une requête d'enregistrement auprès du dispositif de gestion par un module d'enregistrement dudit applicatif après une activation de cet applicatif, via un bus logiciel de gestion prédéterminé en communication d'une part avec une interface du dispositif de gestion et d'autre part avec une interface dudit applicatif, - une pluralité d'étapes d'échange de messages relatifs à des canaux de communication, transmis entre le dispositif de gestion et l'applicatif enregistré, via le bus de gestion, dont au moins un message envoyé au dispositif de gestion et représentatif d'un canal de type déterminé requis par ledit applicatif ou au moins un message envoyé audit applicatif et représentatif d'un canal déterminé disponible pour ledit applicatif, - une étape d'envoi d'une requête de désenregistrement auprès du dispositif de gestion par un module de désenregistrement dudit applicatif lors d'une désactivation de cet applicatif, via le bus de gestion. Selon une autre particularité, le procédé de gestion comprend : - une étape de mise à jour d'un module d'adressage des applicatifs mémorisant un identifiant de l'applicatif activé, reçu dans la requête d'enregistrement, cette étape de mise à jour étant réalisée après l'envoi de la requête d'enregistrement et avant la pluralité d'étapes d'échanges de messages, - une étape d'attribution d'un canal de communication à l'applicatif, par un module d'attribution, - une étape de mise à jour du module d'adressage des applicatifs supprimant l'identifiant de l'applicatif désactivé, reçu dans la requête de désenregistrement, cette étape de mise à jour étant réalisée après l'étape d'envoi de la requête de désenregistrement. Selon une autre particularité, le procédé de gestion comprend une étape de mémorisation d'un script correspondant à l'applicatif, l'étape d'envoi de la requête d'enregistrement correspondant au démarrage de l'exécution du script par un interpréteur, l'étape d'envoi de la requête de désenregistrement correspondant à une fin d'exécution du script. L'invention, ses caractéristiques et ses avantages apparaîtront plus clairement à la lecture de la description faite en référence aux figures référencées ci-dessous et données à titre d'exemples non limitatifs : - la figure 1 représente un exemple d'architecture matériel d'un terminal mobile ; - la figure 2 représente un exemple de configuration d'un terminal selon l'invention ; - la figure 3 représente un exemple de procédé exécuté par le terminal mobile lors du démarrage d'une session ; - la figure 4 représente un exemple d'états successifs d'un terminal mobile multimodes ; - la figure 5 représente un exemple de procédé de mise à jour 15 d'indicateurs de contrôle d'une connexion du terminal mobile, - la figure 6 représente un tableau de données de délais et de dépenses d'énergie successifs pour les différents états successifs d'un canal déterminé, - la figure 7 représente un exemple de tableau de définition de 20 commandes envoyées par le module de gestion des connexions ou par un applicatif interne au terminal mobile, - la figure 8 représente un exemple de tableau de définition de réponses aux commandes, envoyées par l'applicatif interne ou par le module de gestion des connexions, 25 - la figure 9 représente un exemple de procédé d'enregistrement d'un applicatif auprès du module de gestion des connexions selon l'invention, - la figure 10 représente un exemple de module d'adressage, la figure 11 représente un exemple de module de localisation, la figure 12 représente un exemple de module de tarification, 30 la figure 13 représente un exemple de module de priorité. L'invention va à présent être décrite en référence aux figures précédemment citées. Le terminal mobile, comme représenté à la figure 1, comprend des composants de communication permettant une connexion avec différents réseaux. Le terminal comprend par exemple une antenne (A2G) et une interface (Int01) de connexion au réseau 2G, une antenne (A3G) et une interface (IntO2) de connexion au réseau 3G et une antenne (AWIFI) et une interface (Int03) de connexion au réseau Wi-Fi. Le terminal peut aussi comprendre un composant de communication avec : - le réseau 2,5G ou - le réseau 3,5G ou - le réseau WIMAX ou - un autre type de réseau de communication tel que le réseau Internet ou un réseau local de communication par ondes radiofréquences ou un réseau câblé de type Ethernet ou un réseau mobile accédé par une clé électronique telle qu'un dongle 3G USB (Universal Serial Bus). Chaque antenne (A2G, A3G, AWIFI) est par exemple reliée à son composant (Int01, IntO2, Int03) d'interface en communication avec un bus du terminal, relié à une mémoire (Mter) du terminal et à un composant de traitement (PTer) du terminal, comme par exemple un microprocesseur ou un microcontrôleur. Une interface (IntO4) avec un objet d'identification électronique sécuritaire tel qu'une carte SIM, est par exemple reliée au bus du terminal mobile. L'objet sécuritaire comprend par exemple une interface (IntO5) interne de connexion au terminal. Cette interface (IntO5) interne est par exemple reliée par un bus à un composant (PSim) de traitement du composant électronique sécuritaire et à un composant (MSim) de mémorisation du composant sécuritaire.

Des modules ou applicatifs actifs sont par exemple réalisés chacun par un programme mémorisé et exécuté par un composant de traitement pour réaliser une ou plusieurs fonctions déterminées. On comprend que les programmes de traitement du terminal ou du composant électronique sécuritaire sont dotés d'au moins un sous-programme qui permet de mémoriser tous les résultats intermédiaires, obtenus successivement lors du traitement, par exemple à l'aide de tables de mémorisation. Différents algorithmes de calcul sont respectivement utilisés par des modules de calcul agencés pour récupérer les informations adéquates (portions de données ou de signaux en cours de traitement, résultats d'opérations précédentes, etc.). Ainsi les modules actifs, correspondant à des applicatifs exécutés de façon interne au terminal mobile, peuvent communiquer avec différents réseaux, via les composants de communication. De manière non limitative, les applicatifs peuvent être installés dans le terminal mobile et enregistrés auprès du dispositif de gestion des canaux et des connexions, lors de leur installation ou lors de leur activation. Les applicatifs peuvent aussi être réalisés sous la forme de script comprenant une série d'instructions, un script étant exécuté par un interpréteur comme par exemple : un interpréteur Flash, un interpréteur Python, - un interpréteur Java, - un interpréteur Javascript, ou d'autres interpréteurs. L'interpréteur comprend notamment des fonctions ou des primitives de communication avec le gestionnaire de communication (ACM1), via un bus logiciel prédéterminé de communication.

Un navigateur Internet peut aussi être considéré comme un interpréteur et comprend des fonctions ou des primitives de communication avec le gestionnaire de communication (ACM1), via le bus logiciel prédéterminé de communication. De manière non limitative, les fonctions ou primitives de communication avec le gestionnaire de communication (ACM1), via le bus logiciel prédéterminé de communication, sont intégrées nativement dans l'interpréteur ou le navigateur ou sont installées par des mises à jour, par exemple en installant un service pack ou un plugin . Un service pack est par exemple également désigné par ensemble de mises à jour dédiées et un plugin est par exemple également désigné par logiciel greffon. 2934745 -10- Les applicatifs (App1, Appx) exécutés dans le terminal ou dans le composant électronique sécuritaire, communiquent avec un ou plusieurs réseaux de communication, par l'intermédiaire de plusieurs couches de protocoles de communication, telles que par exemple les couches (L1, X1, 5 L2, X2, L3, X3, L4, X4, L5, X5, L6, X6, L7, X7) définies dans le modèle ISO 7498-1, comme représenté à la figure 2. Une couche est par exemple réalisée par un module logiciel mémorisé et exécuté par le terminal ou par un composant électronique piloté par le terminal. Le modèle ISO à sept couches n'est pas limitatif et plusieurs couches de protocoles peuvent être regroupées 10 ou une couche de protocole peut être séparée en deux sous-couches. L'ensemble des couches de communication forme par exemple un canal (CA1, CAx) de communication entre un applicatif ou application interne au terminal mobile et l'extérieur du terminal mobile, les couches utilisées pouvant, par exemple, être déterminées par une commande (cmd_CA1, 15 cmd_CAx) du dispositif (ACM1) de gestion des communications. Des exemples de couches de différents niveaux seront notamment décrits par la suite. Des applicatifs peuvent par exemple être, de manière non limitative, des programmes réalisant les applications suivantes : 20 - télévision en directe utilisant par exemple un service de lecture en continu également désigné par streaming , les données en continu étant par exemple transférées via le réseau 3G avantageusement utilisé pour les contrôles relatifs aux droits d'exploitation et aux licences, - messagerie instantanée utilisant une connexion avec un serveur 25 central fournissant des informations sur les états d'autres usagers connectés et permettant une transmission d'information entre usagers, - courrier électronique réalisant une connexion avec un serveur de messagerie tel qu'un serveur Internet ou réalisant des envois et réception de courriers électroniques protégés par un nom de connexion et un mot de 30 passe, - navigateur également appelé "Browser", permettant l'affichage de pages multimédia interactives comme des pages Internet pouvant être 2934745 -11- décrites selon différents langages tels que par exemple HTML (Hypertext Markup Language) ou XHTML (Extensible HyperText Markup Language), - gestionnaire de téléchargement, également appelé Download Manager utilisant par exemple le réseau Wi-Fi pour lé téléchargement de 5 fichiers vidéo disponible sur des sites Internet ou sur des terminaux fixes ou mobiles appartenant à des particuliers. Chacun des applicatifs comprend par exemple une interface (Inn, Intx) de gestion comprenant une interface (Cl, Cx) client et respectivement une interface (SI, Sx) serveur permettant de communiquer avec une 10 interface serveur et respectivement une interface client du gestionnaire de communication. De manière non limitative, cette interface est prévue dans l'applicatif pour se connecter au mieux à un réseau tel que le réseau Internet. Un module dans l'applicatif comprend par exemple des données d'identification de l'applicatif et des données représentatives d'un ou 15 plusieurs modes de connexion les mieux adaptés pour un fonctionnement optimum ou des modes acceptables pour un fonctionnement dégradés ou des modes interdits incompatibles avec l'applicatif. L'interface de l'applicatif communiquant avec le dispositif de gestion comprend par exemple des données représentatives de types de canaux de communication mémorisés 20 utilisables par l'applicatif. L'interface peut aussi comprendre un module d'attribution ou de choix d'un canal disponible parmi plusieurs canaux proposés par le dispositif de gestion des canaux de communication, mais de préférence l'attribution d'un canal de communication sera attribué à l'applicatif, par le dispositif de gestion des canaux de communication.

25 L'applicatif peut par exemple fournir, dans une requête de canal de communication envoyée au dispositif de gestion, des paramètres relatifs au canal requis par l'applicatif. De manière non limitative, ces paramètres peuvent être obligatoires ou préférés pour l'applicatif. Selon un exemple non limitatif, des attributs peuvent être ajoutés à 30 un page Internet ou à un autre script exécuté par un interpréteur, sous la forme d'une structure de contraintes comprenant : 2934745 -12- - un champ relatif à la tarification comprenant par exemple des données représentatives d'un type déterminé de facturation par un opérateur, - un champ relatif à la sécurité comprenant par exemple une donnée 5 vrai, ou respectivement fausse, représentative d'une communication sécurisé ou cryptée, ou respectivement non sécurisée ou non cryptée, - un champ relatif à l'authentification comprenant par exemple une donnée vrai, ou respectivement fausse, représentative d'une authentification par identifiant et mot de passe, ou respectivement d'une non 10 authentification, - un champ relatif à la bande passante disponible comprenant des données représentatives d'une bande passante minimum ou d'une plage dans laquelle doit se trouver la bande passante. Chaque label ou TAG HTML ou XHTML comprendra par exemple un 15 attribut de contrainte conforme à cette structure de contrainte. Le lien n'est alors exécuté que pour un canal de communication attribué à l'applicatif se conformant à l'attribut de contrainte. Une condition peut par exemple être que la bande passante soit d'au moins 200kbps. De façon avantageuse, un gestionnaire de communication (ACM1) 20 gérant les applicatifs à leur activation et recevant des paramètres de contraintes correspondant à l'applicatif, est particulièrement adapté aux interpréteurs de scripts, pour lesquels chaque script ou chaque page Internet peut nécessiter des contraintes différentes pour le canal de communication utilisé.

25 Si par exemple le terminal se connecte à un point de connexion de type Hotspot Wi-Fi public non sécurisé, le navigateur autorisera par exemple l'accès à Internet non sécurisé mais refusera par exemple d'accéder à une page Internet de consultation de courriers électroniques confidentiels ou bien le navigateur Internet sera par exemple basculé par le dispositif de gestion 30 des communications, vers le réseau GPRS ou UMTS disponible, pour consulter les courriers électroniques. Le basculement est par exemple 2934745 -13- transparent pour l'utilisateur et dépend d'un attribut de contrainte relatif à l'authentification lié à la page de consultation du courrier. Le gestionnaire de communication gérant chaque applicatif au moment de son application, est aussi avantageusement adapté à l'exécution 5 de script, par exemple de type Flash, téléchargés depuis Internet et exécutés dans le terminal mobile par un Interpréteur Flash installé dans le terminal mobile, en prenant en compte des contraintes telles qu'un débit minimum ou une tarification déterminée. Ainsi les canaux de communication peuvent être automatiquement adaptés pour chaque script exécuté.

10 Le bus (BO) est par exemple défini avec un point d'entrée prédéterminé connu et des adresses ou ports prédéterminés et connus des modules client (CO) et serveur (SO) du dispositif de gestion des connexions. Le module (ACM1) de gestion comprend par exemple un module principal (MO) en communication avec l'interface (IntO) de bus et avec des modules 15 secondaire. Le module principal exécute par exemple un algorithme déterminé pour l'envoi d'information ou de commandes relatives aux canaux de communication. Le module principal peut aussi être conforme à des processus de décision sous la forme de réseaux de neurones ou utiliser tout type de programmation avec par exemple des capacités de mémorisation et 20 d'exploitation d'évènements passés. Le dispositif de gestion (ACM1) peut aussi comprendre des fonctions ou des méthodes, par exemple pour une mise à jour ou une initialisation, via un réseau mobile ou fixe, par un opérateur. Ainsi le terminal peut être configuré pour être prêt à recevoir des applicatifs équipés d'une interface supplémentaire de communication avec le 25 bus (BO) en communication avec le dispositif de gestion des connexions et des communications externes. D'une part le canal de communication et la connexion établis pour l'applicatif sont optimisés et d'autre part l'architecture du terminal facilite les installations de nouveaux applicatifs ou l'exécution de nouveaux scripts. De manière non limitative le module principal peut 30 comprendre un module d'attribution des canaux aux applicatifs ou des modules d'attribution peuvent être réalisés dans chaque applicatif. 2934745 -14- L'applicatif peut aussi être associé à un programme greffon, également désigné par plugin , qui permet à l'applicatif d'envoyer ou de recevoir des messages vers ou en provenance du dispositif de gestion des connexions.

5 Un applicatif (App1, Appx) en communication avec le bus (BO) de gestion, comprend par exemple un module de traitement des informations ou évènements envoyés par le dispositif de gestion (ACM1). Cet applicatif peut aussi comprendre un module d'exécution des commandes de branchement à un canal de communication ou de débranchement d'un canal de 10 communication, transmises par le dispositif de gestion. Selon un exemple de réalisation, le bus de gestion est par exemple réalisé selon le protocole RPC (Remote Procedure Cali) qui permet de faire des appels de procédures entre deux programmes à l'aide d'un serveur d'applicatifs. Ce protocole utilisé selon le modèle client-serveur, permet par 15 exemple de gérer les différents messages entre ces programmes. Selon un exemple de réalisation le bus (BO) de gestion est par exemple géré par un contrôleur de bus comprenant par exemple une adresse d'entrée dans une pile telle qu'une pile de type FIFO (First ln First Out) de stockage des messages avant leur transmission. Un pointeur de pile 20 est par exemple incrémenté, ou respectivement décrémenté, après la réception d'un nouveau message, ou respectivement après l'effacement d'un message transmis. Le contrôleur de bus gère ainsi les transmissions de messages entre un ou plusieurs applicatifs et le dispositif gestionnaire de connexions.

25 Le module (ACM1) gestionnaire de connexion permet par exemple la création ou l'ouverture de canaux de communication utilisés par les applicatifs du terminal ou de la carte SIM. Le module (ACM1) gestionnaire de connexion comprend par exemple les fonctionnalités d'un gestionnaire de communications de niveau 4 ou toutes les couches successives peuvent par 30 exemple être déterminées par le dispositif de gestion des connexions. Le dispositif de gestion des connexions peut aussi supprimer un canal après la fin de son utilisation par un ou plusieurs applicatifs. Ainsi tout type de canal 2934745 -15- disponible peut être établi, par le module (ACM1) gestionnaire de connexion, entre un applicatif (App1, Appx) interne au terminal mobile et un applicatif externe au terminal mobile. Les canaux de communication peuvent notamment utiliser différents protocole ou différents ports ou être reliés à 5 différents serveurs. Une application de télévision mobile ne se connecte par exemple que par des protocoles et des ports déterminés connus tels que RTP (Real-time Transport Protocol) ou RTSP (Real Time Streaming Protocol). Les canaux de communication peuvent utiliser différents types de 10 réseaux, certains serveurs ou services n'étant par exemple exclusivement accessibles que par des points d'accès réseaux déterminés. Un opérateur pourra par exemple limiter l'accès à un service déterminé pour des canaux établis passant par un point d'accès de type WAP (Wireless Application Protocol). Une contrainte relative à un point d'accès à un service, imposée 15 au canal de communication, permet ainsi au gestionnaire de communication de gérer les accès de type wallgarden où un serveur ou un service ne sont accessible que depuis un ou plusieurs réseaux sécurisé par authentification, gérés par exemple par un même opérateur. Le module de gestion des connexions comprend de manière non 20 limitative, des modules complémentaires comprenant des données prédéterminées en fonction du type de terminal mobile ou des données mises à jour via le réseau par un serveur de mise à jour de l'opérateur ou via le bus de communication par les applicatifs internes au terminal mobile. Les modules complémentaires réalisent de manière non limitative des fonctions 25 telles que : - un module (M_loc) de localisation du terminal mobile par rapport au point de connexion ou aux noeuds de communications dans les réseaux mobiles de communication, en fonction par exemple de données représentatives d'un point de connexion identifié ou de stations de liaison 30 radiofréquence identifiées, 2934745 -16- - un module (M_tar) de tarification à appliquer pour les communications réalisées par l'utilisateur, en fonction par exemple de données représentatives de l'abonnement de l'utilisateur, - un module (M_prior) de priorité gérant des types de canaux 5 d'accès, en fonction par exemple des données mémorisées représentatives d'un rang de priorité ou d'un niveau de sécurité minimum de codage des données échangées, d'un niveau de sécurité minimum d'authentification, ou d'identifiants de connexion ou de mots de passe mémorisés à la demande de l'utilisateur et associés à des services déterminés, 10 - un module (M_adr) d'adressage des applicatifs reliés au bus (BO) de communication, en fonction de données représentatives d'identifiants des applicatifs, le module d'adressage pouvant par exemple aussi comprendre différents modes de connexion ou protocoles compatibles, des modes de communication avec le module gestionnaire de tâches en mode maître ou 15 esclave ou les deux, des profils optimum des applicatifs toujours connectés ou connectés durant un délai minimum déterminé ou connectés selon des intervalles de temps minimum déterminés, - un module (M5) d'initialisation ou de mise à jour d'indices (ind_CA1_A, ind_CA1_E, ind_CAx_A, ind_CAx_E) de performance associés 20 à des identifiants de canaux (ID_CA1, ID_CAx). Le gestionnaire de communication peut aussi comprendre une bibliothèque de type d'applicatifs chacun associé à des contraintes relatives aux canaux de communication. Les contraintes relatives aux types de canaux de communication requis par les applicatifs peuvent aussi être 25 envoyés directement par les applicatifs, au gestionnaire de communication (ACM1). De manière non limitative, le dispositif de gestion pourra gérer des canaux pour plusieurs applicatifs pouvant utiliser des connexions ou des canaux différents. La figure 10 représente un exemple non limitatif de module (M_adr) 30 d'adressage comprenant une liste d'identifiants d'applicatifs (ID Appt, ID Appx) gérée par un module (Gest_adr) de gestion de la liste. Les identifiants de cette liste correspondent par exemple aux applicatifs activés 2934745 -17- nécessitant une communication avec l'extérieur du mobile et en communication avec le bus de gestion. La figure 11 représente un exemple non limitatif de module (M_Loc) de localisation comprenant un module de gestion (Gest_loc) d'un tableau 5 associant des identifiants (ID_Stal, ID_Acc_pointl) de stations de liaison radiofréquence ou de point de connexion au réseau sans fil ou de hotspot Wi-Fi, à des identifiants d'applicatifs (ID_App1, ID_Appx). Le module de gestion (Gest_loc) réalise par exemple des contrôles sur les canaux, par exemple à l'état de transaction et recherche les identifiants de station ou de 10 point d'accès dans ces canaux. Le dispositif de gestion mémorise par exemple des données représentatives des couches des canaux et des états des canaux. En cas de détection, le module de gestion transmet par exemple au module principal des données représentatives d'une commande de branchement de l'applicatif identifié sur le canal trouvé. La localisation par 15 exemple d'une borne Wi-Fi de connexion correspondant à un boîtier réseau personnel disposé chez l'utilisateur, entraîne par exemple une ou plusieurs commandes de branchements des applicatifs internes à un ou plusieurs canaux passant par ce boîtier. Ainsi les ressources radio des réseaux mobiles sont optimisées pour l'opérateur et la qualité de service est 20 optimisée de façon transparente pour l'utilisateur. L'utilisateur bénéficie par exemple d'un accès gratuit illimité via son boîtier personnel. La localisation peut aussi correspondre à une entreprise comprenant un point d'accès protégé dont l'identifiant est mémorisé dans le module de localisation et associé à un ou plusieurs identifiants d'applicatifs pour les faire utiliser de 25 préférence ce point d'accès protégé. Ainsi la sécurité est de plus optimisée. La figure 12 est un exemple non limitatif de module (M_tar) de tarification comprenant un module (Gest_tar) de gestion d'une ou plusieurs structures (Struct1) dans le module de tarification. Ces structures comprennent par exemple des données (X1, X2, X3) représentatives d'un 30 type de réseau déterminé, associées à : - un identifiant d'applicatif (ID_Appx), - un compteur (Compt) d'usage, 2934745 -18- - un seuil maximum (Max_Compt) déterminé. Le module de gestion réalise par exemple l'incrémentation du compteur d'usage lors d'une utilisation du réseau déterminé par l'applicatif identifié et vérifie que le compteur ne dépasse pas ou n'atteint pas le seuil 5 maximum. Dans le cas où le compteur est supérieur ou égal au seuil maximum, le module de gestion transmet par exemple au module principal (MO) des données de commande de coupure de la communication de l'applicatif identifié par ce type de canal associé. Ainsi selon l'abonnement souscrit par l'utilisateur, les communications peuvent être limitées sur 10 certains types de réseaux pour certaines applications. Un basculement transparent pour l'utilisateur est par exemple alors commandé. La figure 13 est un exemple non limitatif de module (M_prior) de priorité comprenant un module de gestion (Gest_Prior) d'un tableau associant aux identifiants d'applicatifs (ID_App1, ID_Appx) un ou plusieurs 15 types de canaux (CA1, CAx), chaque canal associé à un identifiant d'applicatif étant associé à un rang ou numéro de priorité et éventuellement à un identifiant de connexion et à un mot de passe (login1lpwdl ). De manière non limitative, les rangs de priorité sont établis à partir de données de compatibilité et de manière non limitative fournies par chaque applicatif lors 20 de sa connexion au bus (BO) de gestion. Le module de gestion détermine par exemple un canal à utiliser par une application dans une configuration déterminée, ou les canaux sont contrôlés afin de déterminer les canaux disponibles pour cet applicatif, puis détermine le canal le plus prioritaire parmi les canaux disponibles.

25 La figure 9 est un exemple non limitatif de procédé d'enregistrement d'un applicatif auprès du module de gestion des connexions. L'applicatif par exemple à l'état dormant est par exemple activé (Etp40) lors d'une étape d'activation, par exemple par un système d'exploitation du terminal mobile. Après (Cond40) que l'applicatif ait été activé, une étape suivante 30 d'envoi d'une requête d'enregistrement par l'applicatif au dispositif de gestion des communications, est par exemple exécutée. La requête d'enregistrement comprend par exemple au moins des données d'identification de l'applicatif. 2934745 -19- La requête d'enregistrement peut aussi comprendre des données représentatives des canaux de communications compatibles ou des types de réseaux compatibles ou des données représentatives d'un coût maximum ou d'un niveau de sécurité minimum ou d'une qualité requise minimum pour 5 l'applicatif fonctionne par exemple selon un mode optimum, dégradé 'ou minimum. La requête d'enregistrement peut par exemple être conforme à la figure 7. Un attribut représentatif de contraintes de communication pour l'applicatif, sera par exemple intégré au message d'enregistrement. Après l'envoi (Cond4l) de la requête une étape suivante (Etp42) de 10 réception de la requête d'enregistrement par le dispositif de gestion, est par exemple réalisée. Après la réception et la mémorisation de la requête (Cond42), une étape (Etp43) de mise à jour du module d'adressage est par exemple réalisée. Le module (M_adr) d'adressage mémorise par exemple un 15 identifiant de l'applicatif nouvellement activé. Ainsi le dispositif de gestion prend en compte ce nouvel applicatif dans la gestion des connexions ou des canaux de communication. Après (Cond43) la mémorisation des données d'identification dans le module d'adressage et éventuellement la mise à jour des autres modules du 20 dispositif de gestion, une étape (Etp44) de transmission de données représentatives de l'ensemble des canaux créés, au nouvel applicatif, est par exemple exécutée par le dispositif de gestion. Le dispositif de gestion peut aussi transmettre des données représentatives d'un canal attribué à l'applicatif, le processus de décision pouvant être exécuté par le dispositif de 25 gestion (ACM1) ou par l'applicatif. Le dispositif de gestion pourra par exemple choisir un canal en fonction des conditions tarifaires les moins onéreuses ou en fonction du niveau de ressources utilisées le plus économique. De manière non limitative, le dispositif de gestion (ACM1) peut aussi répondre à l'applicatif appelant, par une demande de confirmation de 30 connexion à un canal payant, par l'utilisateur, via l'interface homme machine. Les données de branchement au canal payant sont par exemple transmises 2934745 -20- à l'applicatif après la réception d'un message de confirmation par l'utilisateur, envoyé par l'applicatif au dispositif de gestion (ACM1). L'initialisation de la table ou du module de priorité est par exemple réalisée par défaut en donnant à chaque canal un même niveau de priorité 5 ou des priorités mémorisées associées à chaque type de canal. Les niveaux de priorité peuvent aussi être déterminés en fonction de paramètres ou de contraintes envoyées par l'applicatif. D'autre part le module gestionnaire de communication réalise par exemple une lecture de différents modules pour pondérer les niveaux de priorité et déterminer le canal le plus avantageux 10 ayant le niveau de priorité pondéré le plus haut ou déterminer de même un ordre des canaux compatibles des plus avantageux au moins avantageux. Le canal le plus rapide étant par exemple dans un état de balayage ne sera par exemple pas sélectionné, un canal moins rapide mais à l'état d'association ou de transaction étant en revanche sélectionné.

15 Après l'envoi de données (Cond44) de branchement à un ou plusieurs canaux disponibles, des étapes (Etp45, Etp46) d'envoi et de réception de messages sont par exemple réalisées. Les messages envoyés (Cond45) par le dispositif de gestion ou respectivement par un des applicatifs activés, sont traités (Cond46) par les applicatifs activés ou respectivement 20 par le dispositif de gestion. Ces messages peuvent être par exemple : - des commandes de branchement ou de débranchement ou, - des requêtes de canaux de communication ou, - des commandes de basculement vers un canal de communication ou, 25 - des informations ou des évènements relatifs aux canaux de communication. Le dispositif gestionnaire (ACM1) peut par exemple transmettre, à un ou plusieurs applicatifs, des données représentatives de la fin d'un canal précédemment utilisé. Ces données de fin d'un canal sont par exemple dues 30 à un déplacement en dehors d'une zone de couverture et sont par exemple accompagnées de données représentatives d'un canal de substitution disponible. Le dispositif de gestion peut aussi déterminer un nouveau canal 2934745 - 21 - attribué à l'applicatif, de façon transparente pour l'utilisateur. De manière non limitative, si le canal de substitution est un canal payant, l'envoi de données de branchement à ce canal, est par exemple précédé d'un envoi d'une demande de confirmation par l'utilisateur et d'une réception par le dispositif 5 de gestion de la confirmation de l'utilisateur. Un évènement peut aussi être lié à l'entrée du terminal mobile dans une zone de couverture permettant de diminuer le coût de communication ou de diminuer les ressources occupées relativement aux ressources disponibles du réseau utilisé ou encore d'améliorer la qualité de service. Le 10 dispositif de gestion (ACM1) envoie alors à un ou plusieurs applicatifs, une commande de basculement sur le nouveau canal disponible plus avantageux pour ce ou ces applicatifs. De manière non limitative, des messages d'information peuvent être affichés via l'interface homme machine, par chaque applicatif, ces messages d'information comprenant : 15 des informations relatives aux canaux utilisés ou, des informations relatives aux nouvelles connexions ou, des informations relatives aux fins de connexions ou, des informations relatives aux confirmations d'utilisation de connexions payantes disponibles.

20 L'applicatif ayant par exemple, terminé son rôle ou sa fonction, exécute par exemple une étape (Etp50) d'envoi d'une requête de désenregistrement. Après l'envoi (Cond50) de la requête de désenregistrement, une étape (Etp51) de désactivation ou terminaison de cet applicatif est par 25 exemple exécutée tandis que le dispositif de gestion réalise la réception de la requête de désenregistrement. Après la réception de la requête (Cond5l) de désenregistrement par le module de gestion, le module de gestion exécute par exemple une étape (Etp52) de mise à jour d'au moins le module d'adressage et éventuellement 30 de l'ensemble des modules du dispositif de gestion. Après cette mise à jour (Cond52) le dispositif de gestion continue par exemple la gestion des 2934745 - 22 - connexions et des canaux de communication, par exemple, pour les applicatifs activés et en communication avec le bus (BO) logiciel de gestion. Des commandes de branchement ou des messages d'information sont par exemple déterminés par le module (MO) principal et envoyés à un 5 ou plusieurs applicatifs, via le bus (BO) de gestion. Des commandes ou des requêtes de branchement peuvent également être envoyées par les applicatifs, au gestionnaire de connexion pour demander, par exemple, l'ouverture d'un accès Internet d'un type déterminé. Des exemples de commandes envoyées par le module de gestion, ou respectivement par un 10 applicatif interne, à un applicatif interne, ou respectivement au dispositif de gestion, sont par exemple représentés selon un tableau à la figure 7. Une commande ou une requête de connexion comprend par exemple : - un en-tête comprenant le nom de la commande de démarrage ou de fin ou de basculement de communication par un canal, suivie de 15 un identifiant de l'applicatif auquel la commande est destinée, ou l'adresse du gestionnaire de connexion, un identifiant de connexion au canal ou un port de l'applicatif, un type de tarification appliquée, la tarification étant par exemple un accès gratuit ou un accès limité en volume ou une tarification en 20 fonction du type de données échangées et du type d'applicatif ou une tarification en fonction de la durée de la session, - un niveau de sécurité correspondant au canal, comme par exemple un canal associé à une authentification par le terminal mobile par exemple par un réseau GSM ou UMTS ou un canal non sécurisé comme par 25 exemple un point d'accès Wi-Fi public, - une bande passante. Des exemples de réponses envoyées par les applicatifs, ou respectivement par le gestionnaire des canaux de communication, au gestionnaire des canaux de communication, ou respectivement aux 30 applicatifs, sont par exemple représentés selon un tableau à la figure 8. Une réponse comprend par exemple : 2934745 - 23 - un en-tête comprenant le nom d'une action réalisée tel que le démarrage ou la fin d'une communication avec l'extérieur du terminal mobile, un identifiant de canal utilisé, une tarification adoptée par l'applicatif.

5 L'état des canaux de communication créés est par exemple pris en compte dans l'évaluation d'un temps de réponse et dans le choix d'attribution d'un canal à un applicatif. La figure 4 représente différents états possibles d'un canal du terminal mobile. Pour chaque canal de communication, le terminal est par exemple dans : 10 - un état de balayage (E01) comprenant l'envoi de signaux d'identification ou de demande de connexion permettant d'explorer les éventuels points d'accès disponibles, - un état d'authentification (E02) comprenant des échanges de messages d'authentification entre le terminal et un point d'accès auquel le 15 terminal est connecté, comme par exemple un point d'accès Wi-Fi privé ou une station de liaison radiofréquence d'un réseau cellulaire, - un état d'association (E03) comprenant la mise à jour d'une ou plusieurs adresses de réseau, telles que des adresses IP, associées chacune à un identifiant de matériel tel qu'une adresse MAC, 20 - un état de transaction (E04) dans lequel des données sont échangées entre un applicatif interne au terminal mobile et un applicatif ou un serveur externes au terminal mobile, - un état de désassociation (E05) comprenant la remise à zéro d'une ou plusieurs adresse de réseau utilisée et de leur identifiant de matériel 25 mémorisés par exemple dans une table ARP, - un état de désauthentification (E06) comprenant la remise à zéro de clé ou la réinitialisation de protocoles sécuritaires. Chaque type de canal (CA1, CAx) établi par le terminal mobile est par exemple associé en mémoire à des indicateurs de performances. Ces 30 indicateurs permettent notamment de réaliser des choix de connexions optimum de façon transparente pour l'utilisateur. Le terminal comprend par 2934745 - 24 - exemple en mémoire des données consultables et pouvant être mises à jour représentatives par exemple de : - un identifiant (ID_CA1, ID_CAx) d'un canal déterminé associé à - un indicateur (ind_CA1 A, ind_CAx_A) d'une qualité de service 5 disponible pour l'utilisation de ce canal et associé à - un indicateur (ind_CA1_E, ind_CAx_E) d'une consommation d'énergie pour l'utilisation de ce canal. Le module (ACM1) de gestion des connexions comprend par exemple un sous-programme (M5) d'initialisation ou de mise à jour des 10 indices de performance associés aux canaux pouvant être établis par le terminal. Les indices de performance variables sont notamment particulièrement utiles pour les réseaux mobiles. Pour une évaluation des indices de performance, le terminal exécute par exemple, des commandes de transition d'un état à un autre pour un 15 canal déterminé pour parcourir au moins une fois chaque état. Chaque passage d'un état à un autre est suivi d'un maintien de l'état pendant une durée déterminée. Grâce par exemple à une sonde de mesure du courant consommé ou de mesure d'augmentations de courant, le programme de mise à jour des indicateurs mémorise par exemple des données 20 représentatives d'un pic d'énergie s'ajoutant à la consommation d'énergie lors d'un passage d'un état à un autre ou des données représentatives d'une puissance moyenne consommée durant un état déterminé. Le terminal comprend par exemple aussi un dispositif de mesure d'intervalles de temps, permettant de mesurer des intervalles de temps pour le passage d'un état à 25 un autre ou pour les temps de maintien de chaque état, des données représentatives de ces temps étant mémorisées. Les indicateurs de performance associés à chaque canal, correspondent par exemple à : une consommation d'énergie (ind_CA1_E, ind_CAx_E) 30 nécessaire pour arriver à l'état (E04) de transaction ou pour terminer cet état (E04) dans lequel un utilisateur obtient un service déterminé, 2934745 - 25 - - une qualité de service (ind_CA1_A, ind_CAx_A) correspondant à l'inverse du temps nécessaire pour arriver à l'état (E04) de transaction ou pour terminer cet état (E04). Ainsi lors d'une phase de test l'ensemble des temps de transition 5 (T12, T23, T34, T45, T56, T61) et des temps de maintien (TOI, T02, T03, T04, T05, T06) ainsi que les consommations d'énergie pour ces transitions (w12, w23, w34, w45, w56, w61) et les consommations d'énergie (w01, w02, wO3, w04, w05, w06) pour ces maintiens sont mémorisés. A chaque changement d'état du terminal, pour un canal contrôlé par le module (M5), 10 les indices de performance associés à ce canal sont par exemple remis à jour. L'indice de consommation d'énergie correspond par exemple à la somme des énergies de transitions successives mémorisées pour arriver à l'état de transaction et à la somme des énergies de maintien des états 15 intermédiaires. L'indice d'énergie peut aussi comprendre l'énergie dépensée lors de l'état de transaction. L'énergie totale nécessaire pourrait par exemple s'exprimer comme suit : Enécessaire = Etransition états intermédiaires + Emaintien états intermédiaire + E maintien état transaction 20 Le temps total nécessaire pourrait par exemple s'exprimer comme suit : Tnécessaire = Ttransition états intermédiaires + Tmaintien états intermédiaire + T maintien état transaction Le tableau mémorisé et représenté à la figure 6 comprend pour un 25 canal déterminé : - les énergies (w01, w02, wO3, w04, w05, w06) dépensées pour les différents états (E01, E02, E03, E04, E05, E06) maintenus de ce canal, - les énergies (w12, w23, w34, w45, w56, w61) dépensées pour les transitions entre les états successifs, 30 - les délais écoulés (TOI, T02, T03, T04, T05, T06) lors des maintiens des différents états (EO1, E02, E03, E04, E05, E06) de ce canal, 2934745 - 26 - - les délais écoulés (T12, T23, T34, T45, T56, T61) pour les transitions entre les états successifs. Le programme de sommation comprend par exemple des accès en mémoire aux données représentatives des énergies successivement 5 dépensées, en commençant à partir de l'état en cours jusqu'à l'état de transaction. L'indice de qualité de service comprend par exemple le calcul du délai total pour se positionner dans un état de transaction pour un canal déterminé ou pour terminer cet état de transaction, à partir de l'état actuel. Le 10 programme de mise à jour réalise par exemple la somme des temps successifs nécessaires pour les transitions et les maintiens jusqu'à la transition dans l'état de transaction ou jusqu'à la fin de l'état de transaction. L'indice de qualité correspond par exemple à l'inverse du temps total nécessaire.

15 Ainsi le choix entre plusieurs canaux pour réaliser une transaction, peut prendre en compte la qualité de service proposée et l'énergie nécessaire. Le module de gestion peut aussi traiter les indices en calculant le rapport de l'indice de qualité par l'indice de consommation d'énergie pour chacun des canaux et choisir, par exemple, le canal associé au rapport le 20 plus élevé. La figure 5 représente un exemple de procédé de test d'une connexion permettant une mise à jour d'indices de performance d'un canal correspondant à cette connexion. Ces opérations effectuées par un programme de test d'une connexion, permettent par exemple d'évaluer les 25 temps de réponse successifs et les dépenses d'énergie successives pour accéder à une ressource après la réalisation du balayage résultant d'une connexion à un point d'accès au réseau sans fil ou à une station de liaison radiofréquence, avec ou sans authentification. Une étape (Etp20) de début des mesures est par exemple réalisée.

30 Un composant ou un module de mesure du temps total et de temps intermédiaires est par exemple démarré ainsi qu'un composant ou un module de mesure de l'énergie totale dépensée et des tranches successives 2934745 - 27 - d'énergie dépensée. Un espace mémoire de stockage des données de mesure est par exemple alloué. Après (Cond20) le démarrage des mesures, une étape (Etp2l) d'association d'une adresse MAC (Media Access Control) et d'une adresse 5 réseau, est par exemple réalisée. Le terminal envoie par exemple une requête ARP (Adress Resolution Protocol) pour obtenir l'adresse IP d'une passerelle. Cette adresse IP est par exemple fournie dans une réponse à la requête ARP. L'association peut aussi comprendre une demande d'adresse IP disponible pour le terminal auprès d'un serveur DHCP (Dynamic Host 10 Configuration Protocol) d'adresse de la passerelle par un client DHCP du terminal mobile. Le terminal comprend par exemple une table ARP dans laquelle des adresses IP sont associées à des adresses MAC. Ces opérations d'association telles que l'envoi d'une ou plusieurs requêtes ARP et la réception d'une ou plusieurs réponses correspondantes ne sont pas 15 conditionnées par l'état de la table ARP. La table est par exemple remise à zéro lors de cette étape de test ou les valeurs contenues sont remises à jour. Ainsi l'énergie et le temps mesurés sont représentatifs du mode d'association et les données de test peuvent être actualisées régulièrement. De manière non limitative, des temps intermédiaires et des dépenses d'énergie 20 intermédiaires sont par exemple mémorisés et réinitialisés à chaque fin d'étape de test et à chaque début d'étape de test suivante. Après la mémorisation (Cond2l) d'une ou plusieurs adresses réseau, une étape (Etp22) de détermination d'une adresse réseau distante est par exemple réalisée. Le terminal envoie par exemple une requête DNS 25 (Domain Name System) comprenant par exemple à une chaîne de caractères mémorisée déterminée correspondant à une adresse de test. Le terminal reçoit par exemple ensuite une réponse à sa requête comprenant une adresse IP correspondante. L'adresse IP est par exemple mémorisée dans une table de correspondance DNS. L'opération d'envoi de la requête 30 DNS est réalisée indépendamment de l'état de la table DNS, de façon à ce que les délais et les énergies mesurées soient représentatifs d'une détermination complète d'adresse réseau distante. 2934745 - 28 - Après (Cond22) la mémorisation de l'adresse réseau distante demandée, une étape (Etp23) d'ouverture d'un point d'accès est, par exemple réalisée. Une commande d'ouverture de session TCP/IP est par exemple réalisée par le terminal mobile. L'ouverture du point d'accès 5 correspond, par exemple, à l'ouverture d'un socket TCP/IP. Après (Cond23) l'ouverture du point d'accès, une étape (Etp24) d'accès à une ressource distante est par exemple réalisée. La ressource distante est, par exemple une page html (Hypertext Markup Language), accédée par l'envoi d'une requête http (Hypertext Transfer Protocol). La 10 requête est envoyée indépendamment d'éventuels fichiers temporaires de navigation précédemment mémorisés. Il est important d'identifier à la fois le protocole utilisé et le serveur distant ou la plateforme distante. Par exemple, sur certains réseaux Wi-Fi publics, des protocoles peuvent être filtrés. De même, des serveurs de destination peuvent être mis sur liste noire ou 15 blacklist , par certains réseaux d'accès et ne sont donc pas accessibles sur certaines connexions. Il est donc préférable d'utiliser les informations fournies par les applicatifs lors de leur enregistrement (informations relatives au protocole, à la sécurité ou au serveur distant) pour réaliser ces tests. Après la réception (Cond24) de la ressource et sa mémorisation, une 20 étape (Etp25) de fin des mesures est par exemple réalisée. Les mesures du temps total et de l'énergie totale sont par exemple arrêtées et les données de temps total écoulés et d'énergie totale dépensée sont par exemple mémorisées. Les données précédemment mémorisées de délais intermédiaires et de dépenses intermédiaires d'énergie sont par exemple 25 traitées pour une mise à jour des indices de performance correspondants. Après la mise à jour des indices (Cond25), une étape (Etp26) d'attente d'écoulement d'une temporisation déterminée avant fermeture du point d'accès est par exemple réalisée. Si (Cond261) une demande d'utilisation du point accès est détectée, alors l'étape d'attente est suivie 30 d'une étape (Etp27) d'utilisation du point d'accès, puis à la fin (Cond27) de cette utilisation, une nouvelle étape d'attente (Etp26) avant fermeture du point d'accès est par exemple réalisée. 2934745 - 29 - Si (Cond262) à la fin de la temporisation, aucune demande d'utilisation n'est détectée, une étape suivante (Etp28) de fermeture du point d'accès est réalisée. La figure 3 représente un exemple de procédé exécuté après une 5 étape (Etp01) de démarrage d'une session initiée par une application démarrée par l'utilisateur. Après le lancement (Cond01) de la session, le module de gestion des connexions teste par exemple, lors d'une étape (Etp02) suivante, si une connexion Wi-Fi est établie et si cette connexion est compatible avec l'application, par exemple en terme de coût, de qualité ou de 10 sécurité ou selon d'autres critères. Si oui (CondO21) la connexion déjà établie est utilisée pour la session de l'application de l'utilisateur lors d'une étape (Etp03) suivante, par exemple conformément au module de localisation ou au module de priorité. Sinon (CondO22) le module gestionnaire réalise par exemple une étape (Etp04) de recherche d'une 15 connexion Wi-Fi disponible, par exemple par balayage d'une liste mémorisée de connexions. Si (CondO41) une connexion est trouvée, une étape suivante (Etp05) de liaison à la connexion Wi-Fi disponible est par exemple réalisée. Puis après que la connexion soit établie (Cond05), une étape (Etp03) d'utilisation 20 de cette connexion Wi-Fi est par exemple réalisée. Si lors du balayage (Etp04) de la liste de connexions Wi-Fi, aucune connexion disponible n'est détectée (CondO42), une étape suivante (Etp06) de test de disponibilité du réseau cellulaire est par exemple réalisée. Si le réseau n'est pas disponible (CondO62), une étape (Etp12) d'abandon de la 25 connexion est par exemple réalisée. Si le réseau cellulaire est disponible (CondO61), une étape suivante (Etp07) de test d'un point d'accès à un service disponible est alors réalisée. Si un point d'accès à un service est disponible (CondO71) une étape suivante de consultation d'une matrice ou une table de priorité est réalisée.

30 Si la connexion n'est pas confirmée (CondO82) par la table de priorité, alors l'étape (Etp12) d'abandon de la connexion est réalisée. Si la connexion est confirmée (CondO81) par la table de priorité, une étape suivante (Etp09) de 2934745 - 30 - connexion à la passerelle associée au point d'accès est réalisée. La table de priorité permet par exemple aussi de gérer l'éligibilité des connexions disponibles pour les applications. Si à l'étape (Etp07) de confirmation d'un point d'accès disponible via 5 une passerelle n'est pas vérifiée (Cond072) une étape suivante (Etp10) de vérification d'autorisation de connexion par l'utilisateur requise est par exemple réalisée. Ainsi si le module de tarification demande un blocage à cause d'un compte dépassant le seuil maximum, l'utilisateur a la possibilité de passer outre. Si une autorisation par l'utilisateur n'est pas requise 10 (Condl 01) l'étape de connexion à la passerelle est par exemple réalisée, tandis que si une autorisation (Cond102) de l'utilisateur est requise, une étape suivante (Etp11) de demande de confirmation d'autorisation par l'utilisateur est par exemple réalisée. Si (Condl 11) l'utilisateur autorise alors cette connexion, l'étape suivante (Etp09) de connexion à la passerelle est 15 par exemple réalisée, sinon (Cond112) l'étape (Etp12) d'abandon de connexion est réalisée. Des exemples de couches de protocoles vont maintenant être décrits. Un applicatif est par exemple connecté selon un protocole correspondant à la couche d'application (7ème couche du modèle ISO 7498- 20 1) tel que, de manière non limitative : - un protocole du type transfert de fichiers comme par exemple le protocole FTP (File Transfer Protocol), le protocole NFS (Network File System) ou le protocole CIFS (Common Internet File System), - un protocole du type messagerie comme par exemple le protocole 25 SMTP (Simple Mail Transfer Protocol), le protocole POP (Post Office Protocol), le protocole IMAP (Internet Message Access Protocol) ou le protocole NNTP (Network News Transfer Protocol), - un protocole du type session à distance correspondant par exemple à la commande rlogin sous UNIX, 30 - un protocole de type envoi de pages HTML (Hypertext Markup Language) comme par exemple HTTP (Hypertext Transfer Protocol), 2934745 - 31 - - un protocole du type exploitation ou gestion comme par exemple DNS (Domain Name System) pour la résolution d'adresse ou SNMP (Simple Network Management Protocol) pour la supervision, - ou d'autres protocoles d'application.

5 De manière non limitative, les données applicatives, manipulées par les applicatifs, sont par exemple codées, par un ou plusieurs modules de codage, et transformées en chaînes d'octets transportées par le réseau (6ème couche du modèle ISO 7498-1). Ce codage est par exemple réalisé en ASCII ou en XML (eXtensible Markup Language) ou selon un autre type de codage 10 utilisé pour la présentation. Les chaînes d'octets codées pour le transport sont par exemple traitées par un module de gestion et de synchronisation des transactions, selon un protocole (5ème couche du modèle ISO 7498-1) tel que, de manière non limitative, ssh (Secure Shell) ou telnet (TELecommunication NETwork).

15 De manière non limitative le module de gestion et de synchronisation des transactions traite aussi la correction des erreurs. De manière non limitative le module de gestion et de synchronisation des transactions traite des transactions point à point ou des transactions multipoints. Le transport de bout en bout est par exemple géré, par des modules 20 de transport de bout en bout, selon un protocole de transport (4ème couche du modèle ISO 7498-1). Les octets sont par exemple transférés sous la forme de messages, de segments, de séquences ou de paquets. De manière non limitative, les protocoles de transport peuvent être : - RTP (Real-time Transport Protocol) ou, 25 - UDP (User Datagram Protocol) ou, - TCP (Transmission Control Protocol) ou, - DCCP (Datagram Congestion Control Protocol) ou, - d'autres protocoles de transport. Les données transportées sont acheminées de bout en bout à partir 30 des voies de communication du ou des réseaux selon un protocole réseau (3ème couche du modèle ISO 7498-1) prenant en compte le routage et le 2934745 - 32 - relayage. De manière non limitative, le protocole de réseau utilisé est par exemple du type : - IP (Internet Protocol) ou, - IPSec (IP Security) ou, 5 - WDS (Wireless Distribution System) ou, - ICMP (Internet Control Message Protocol) ou - d'autres protocoles réseau. La gestion des trames de données transportées, par exemple entre deux machines adjacentes directement reliées entre elles par un support 10 physique, est par exemple réalisée selon un protocole de liaison (2ème couche du modèle ISO 7498-1). Une détection et une correction d'erreur peuvent aussi être réalisées par le protocole de liaison, comme par exemple dans le réseau X.25 ou dans le réseau GSM. De manière non limitative, le protocole de liaison est par exemple du type : 15 - Ethernet ou, - HDLC (High-Level Data Link Control) ou, - MPLS (MultiProtocol Label Switching) ou, - PPP (Protocole Point à Point) ou, - Token Ring (anneau à jeton) ou, 20 - d'autres protocoles de liaison. Ces trames de données sont transportées sur une couche physique de transport selon un codage déterminé. Les ondes radiofréquences utilisables correspondent par exemple au réseau GSM ou GPRS ou UMTS ou HSDPA ou Wi-Fi ou WIMAX. A titre d'exemple non limitatif, les services 25 porteurs peuvent être : - GSM (Global System for Mobile Communications) ou, - GPRS (General Packet Radio Service) ou, - E-GPRS (Enhanced GPRS) ou EDGE (Enhanced Data rates for GSM Evolution) ou, 30 - UMTS FDD-PS (Universal Mobil Telecommunication System - Frequency Division Duplex û Packet Switch) - HSDPA (High Speed Downlink Packet Access) ou 2934745 - 33 - - HSUPA (High Speed Uplink Packet Access) ou - WLAN (Wireless LAN) ou - Wi-Fi (Wireless Fidelity) ou - WiMAX (Worldwide Interoperability for Microwave Access) ou 5 - Bluetooth ou, - MANET (Mobile Ad-hoc NETwork) ou, - CDMA (Code Division Multiple Access) ou, - TDMA (Time Division Multiple Access) ou, - Zigbee, ou Wibro, etc .

10 Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être 15 modifiés dans le domaine défini par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés ci-dessus.

Claims (15)

1. REVENDICATIONS1. Terminal mobile comprenant des composants (A2G, Int01, A3G, Int02, AWIFI, Int03) de communication avec l'extérieur du terminal mobile et un dispositif (ACM1) de gestion des connexions qui comprend un module de création ou de suppression de canaux (CA1, CAx) de communication entre l'extérieur du terminal mobile et au moins un applicatif (App1, Appx) interne au terminal mobile, les canaux établis via plusieurs couches de protocoles étant commandés par le dispositif de gestion, caractérisé en ce qu'il comprend un bus (BO) logiciel de gestion prédéterminé en communication d'une part avec une interface (IntO) du dispositif de gestion et d'autre part avec une interface (Int1, Intx) dudit applicatif, ledit applicatif comprenant un module d'enregistrement permettant son enregistrement auprès du dispositif de gestion au moment d'une activation de cet applicatif et un module de désenregistrement permettant son désenregistrement auprès du dispositif de gestion au moment d'une désactivation de cet applicatif, une pluralité de messages relatifs à des canaux de communication étant transmis entre le dispositif de gestion et ledit applicatif, dont au moins un message envoyé au dispositif de gestion et représentatif d'un canal de type déterminé requis par ledit applicatif ou au moins un message envoyé audit applicatif et représentatif d'un canal déterminé disponible pour ledit applicatif.
2. 2. Terminal mobile selon la revendication 1, caractérisé en ce que ledit applicatif activé envoyant une requête d'enregistrement comprenant des données représentatives des types de canaux de communication utilisables par l'applicatif, le dispositif de gestion comprend un module (M_adr) d'adressage d'applicatifs communiquant avec l'extérieur du terminal mobile, mémorisant des identifiants d'applicatifs activés et supprimant des identifiants d'applicatifs désactivés. 2934745 - 35 -
3. 3. Terminal mobile selon la revendication 2, caractérisé en ce qu'à chaque enregistrement d'un identifiant d'un applicatif nouvellement activé, par le module (M_adr) d'adressage, le dispositif de gestion transmet à 5 l'applicatif nouvellement activé, un message comprenant des données représentatives d'un canal déterminé parmi les canaux créés, attribués par le dispositif de gestion, à l'applicatif nouvellement créé, ou le dispositif de gestion transmet à l'applicatif nouvellement activé, un message comprenant des données représentatives des canaux utilisables par l'applicatif 10 nouvellement créé.
4. 4. Terminal mobile selon la revendication 2 ou 3, caractérisé en ce que lors de la création d'un nouveau canal de communication par le dispositif de gestion, un message, comprenant des données représentatives du 15 nouveau canal, est transmis, par le dispositif de gestion, à chaque applicatif identifié dans le module (M_adr) d'adressage ou le nouveau canal est comparé aux canaux déjà créés pour une éventuelle attribution du canal nouvellement créé à un des applicatifs du module d'adressage. 20
5. 5. Terminal mobile selon la revendication 4, caractérisé en ce que lors de la suppression d'un canal de communication par le dispositif de gestion, un message, comprenant des données représentatives de la suppression de ce canal, est transmis, par le dispositif de gestion, à chaque applicatif identifié dans le module (M_adr) d'adressage ou une nouvelle 25 attribution de canal est gérée par le dispositif de gestion pour les applicatifs utilisant ce canal.
6. 6. Terminal mobile selon l'une des revendications 1 à 5, caractérisé en ce que l'applicatif est réalisé par un script exécuté par un interpréteur 30 comprenant des fonctions de communication avec le dispositif de gestion via le bus logiciel de gestion, l'exécution du script démarrant par l'envoi de la requête d'enregistrement. 2934745 - 36 -
7. 7. Terminal mobile selon la revendication 6, caractérisé en ce que la requête d'enregistrement comprend des paramètres de tarification représentatifs d'au moins un type de canal de communication, comprenant : 5 - l'identifiant mémorisé dudit applicatif ou, - un identifiant d'un compteur d'usage incrémenté par le module de gestion lors de l'activation dudit applicatif ou, - un seuil maximum du compteur d'usage dont le dépassement est contrôlé par le dispositif de gestion ou, 10 - un type de tarification.
8. 8. Terminal mobile selon la revendication 6 ou 7, caractérisé en ce que la requête d'enregistrement comprend des données représentatives d'un point d'accès à un service nécessaire à l'applicatif, l'accès à ce point d'accès 15 à un service, étant testé et validé par le dispositif de gestion avant de l'attribution du canal de communication.
9. 9. Terminal mobile selon l'une des revendications 6 à 8, caractérisé en ce que la requête d'enregistrement comprend des données 20 représentatives d'un protocole déterminé ou d'un serveur déterminé ou d'un port de communication déterminé, testés et validés par le dispositif de gestion avant de l'attribution du canal de communication.
10. 10. Terminal mobile selon l'une des revendications 6 à 9, caractérisé 25 en ce que la requête d'enregistrement comprend des données représentatives d'une sécurité minimum ou d'une authentification minimum par un identifiant et un mot de passe, testés et validés par le dispositif de gestion avant de l'attribution du canal de communication. 30
11. 11. Terminal mobile selon l'une des revendications 6 à 10, caractérisé en ce que la requête d'enregistrement comprend des données représentatives d'un débit minimum ou d'une largeur de bande passante 2934745 - 37 - minimum, testés et validés par le dispositif de gestion avant de l'attribution du canal de communication.
12. 12. Terminal mobile selon l'une des revendications 1 à 11, 5 caractérisé en ce qu'il comprend un module d'attribution gérant une pluralité de canaux compatibles avec ledit applicatif et attribuant un de ces canaux à l'applicatif en favorisant : - le canal associé aux données de tarification la moins coûteuse ou - le canal associé aux données de débit le plus important ou 10 - le canal comprenant un point de connexion au réseau appartenant à une liste mémorisée de points de connexion au réseau prioritaires.
13. 13. Procédé de gestion des communications dans un terminal mobile comprenant des composants (A2G, Int01, A3G, IntO2, AWIFI, Int03) de 15 communication avec l'extérieur du terminal mobile et un dispositif (ACM1) de gestion des connexions qui comprend un module de création ou de suppression de canaux de communication entre l'extérieur du terminal mobile et au moins un applicatif (App1, Appx) interne au terminal mobile, les canaux (CA1, CAx) établis via plusieurs couches de protocoles étant 20 commandés par le dispositif de gestion, caractérisé en ce qu'il comprend : - une étape (Etp4l) d'envoi d'une requête d'enregistrement auprès du dispositif de gestion par un module d'enregistrement dudit applicatif après une activation de cet applicatif, via un bus (BO) logiciel de gestion prédéterminé en communication d'une part avec une interface du dispositif 25 de gestion et d'autre part avec une interface dudit applicatif, - une pluralité d'étapes d'échange de messages relatifs à des canaux de communication, transmis entre le dispositif de gestion et l'applicatif enregistré, via le bus de gestion, dont au moins un message envoyé au dispositif de gestion et représentatif d'un canal de type déterminé 30 requis par ledit applicatif ou au moins un message envoyé audit applicatif et représentatif d'un canal déterminé disponible pour ledit applicatif, 2934745 - 38 - - une étape (Etp50) d'envoi d'une requête de désenregistrement auprès du dispositif de gestion par un module de désenregistrement dudit applicatif lors d'une désactivation de cet applicatif, via le bus de gestion. 5
14. 14. Procédé de gestion selon la revendication 13, caractérisé en ce qu'il comprend : - une étape (Etp43) de mise à jour d'un module d'adressage des applicatifs mémorisant un identifiant de l'applicatif activé, reçu dans la requête d'enregistrement, cette étape de mise à jour étant réalisée après 10 l'envoi de la requête d'enregistrement et avant la pluralité d'étapes d'échanges de messages, - une étape d'attribution d'un canal de communication à l'applicatif, par un module d'attribution, - une étape (Etp52) de mise à jour du module d'adressage des 15 applicatifs supprimant l'identifiant de l'applicatif désactivé, reçu dans la requête de désenregistrement, cette étape de mise à jour étant réalisée après l'étape d'envoi de la requête de désenregistrement.
15. 15. Procédé selon la revendication 13 ou 14, caractérisé en ce qu'il 20 comprend une étape de mémorisation d'un script correspondant à l'applicatif, l'étape d'envoi de la requête d'enregistrement correspondant au démarrage de l'exécution du script par un interpréteur, l'étape d'envoi de la requête de désenregistrement correspondant à une fin d'exécution du script. 25