Brevet FR2893803A1 — publié le 20070525

METHODE DE COMMUNICATION ENTRE UNE CARTE (U)SIM EN MODE SERVEUR ET UN CLIENT DESCRIPTION 5 DOMAINE TECHNIQUE L'invention concerne le domaine des télécommunications mobiles et plus particulièrement celles mettant en oeuvre une carte à puce dans un terminal mobile. 10 ÉTAT DE LA TECHNIQUE ANTÉRIEURE On sait que dans un réseau GSM, par exemple, un abonné dispose dans son terminal mobile d'une carte à puce, dite carte SIM, pour Subscriber Identity Module, comprenant une mémoire et un 15 microcontrôleur. La mémoire stocke des répertoires et fichiers qui contiennent classiquement l'identifiant de l'opérateur, les données liées au réseau, les numéros d'appel d'urgence, le répertoire téléphonique etc. Plus récemment, la carte SIM a été dotée de 20 nouvelles fonctionnalités, lui permettant de sauvegarder le contenu de certains fichiers comme le répertoire sur un serveur distant, en utilisant le canal SMS (Short Message Service). Les derniers développements concernent entre autres le rôle qu'est 25 appelée à jouer la carte SIM dans le réseau GPRS (pour General Packet Radio Service), dit aussi 2,5G , et le réseau UMTS (pour Universal Mobile Telecommunication System), dit aussi 3G. Dans ce dernier cas, la carte SIM est appelée UICC pour Universal Integrated 30 Circuit Card . Par la suite on utilisera le terme générique (U)SIM pour désigner une carte comportant une fonction SIM, quelle que soit la génération concernée. Il a été proposé dans ce cadre un mécanisme permettant à la carte (U)SIM d'accéder au terminal et au réseau, quel que soit mode de connexion du terminal mobile, à savoir en mode de circuit commuté (typiquement GSM) ou en mode paquet (typiquement GPRS). Ce mécanisme est connu sous l'acronyme de BIP pour Bearer Independent Protocol , le canal logique permettant à la carte (U)SIM de communiquer avec le terminal mobile étant pour cette raison appelée canal BIP. Il convient de noter qu'en général un ou plusieurs canaux BIP peuvent être établis entre la carte et le terminal. Ce dernier dispose d'un logiciel médiateur (middleware) permettant aux applications de la carte (U)SIM d'interagir avec celles du terminal, logiciel dénommé CAT pour Card Application Toolkit . On trouvera une description détaillée du protocole BIP dans le document de l'ETSI intitulé TS 102223, notamment dans sa version 7 d'Octobre 2005, V7.1.0, disponible sous le site wca_.etsi.org. Au moyen du protocole BIP, la carte (U)SIM peut notamment agir comme client et envoyer des requêtes à un serveur distant. Dernièrement, il a été proposé d'héberger un serveur sur la carte (U)SIM. Dans ce cas des clients distants ou bien locaux (c'est-à-dire dans le terminal mobile, comme un browser local ou un applet, peuvent transmettre des requêtes http au serveur hébergé sur la carte et récupérer notamment des pages web stockées dans sa mémoire. Que la carte (U)SIM opère en mode client ou en mode serveur, le terminal mobile assure au moyen du logiciel médiateur CAT la conversion du protocole BIP en protocole TCP/IP et réciproquement. La Figure 1 illustre schématiquement une 5 communication entre une carte (U)SIM opérant en mode serveur et un client. On y distingue la carte (U)SIM (ici une carte UICC) comportant un serveur SCWS pour (SmartCard Web Server), 110, le module du logiciel CAT, 120, 10 dénommé ici SATS (pour SIM Application Toolkit Server) remplissant la fonction de passerelle entre les protocoles BIP et TCP/IP, les piles TCP/IP client et serveur représentées respectivement en 130 et 140, et le client 150. Ce client peut être local, par exemple 15 le browser du terminal ou une mobilette (application midlet), ou bien distant. Selon les spécifications actuelles du protocole BIP, une seule connexion client peut être acceptée par canal BIP. Si le serveur de la carte veut 20 accepter une autre connexion client, il lui faut alors créer un nouveau canal. Etant donné que les canaux BIP sont en nombre limité (au maximum 7 d'après la norme TS 102223 mais le terminal mobile peut en supporter moins), les contraintes de fonctionnement sont 25 importantes. Par exemple, si la carte veut ouvrir un canal BIP en mode client alors que le nombre maximal de canaux BIP a été atteint, la carte devra préalablement fermer un canal BIP, par exemple un canal BIP en mode serveur. 30 En outre, lorsque plusieurs canaux BIP ont été établis, des données ne peuvent être échangées simultanément sur les différents canaux. En d'autres termes, la communication entre le terminal mobile et la carte a lieu en mode série, un canal BIP après l'autre. La Figure 2 illustre schématiquement un chronogramme communication en mode serveur entre la carte et un client, par exemple le browser local. Les piles TCP/IP n'ont pas été représentées par souci de simplification. On remarque que le serveur ne supporte les connexions avec le client que de manière séquentielle. Ainsi deux requêtes de connexions du même client (dues par exemple à deux requêtes HTTP GET) seront satisfaites successivement. Il convient de noter que les messages d'évènement transmis par la passerelle 120 au serveur 110 pour l'avertir de la connexion/ deconnexion avec le client ne comportent pas d'identifiant de la connexion concernée. Dans la version de protocole HTTP 1.0 et les versions précédentes, les connexions TCP sont, par défaut, fermées après un échange de requête et réponse ( connection :Close dans l'en-tête de la requête). Il est néanmoins possible en incluant un en-tête connection : Keep-Alive dans la requête de demander à ce que la connexion soit maintenue ouverte. Dans ce cas, si le client envoie une autre requête, celle-ci utilise la connexion précédemment crée. Dans la version de protocole HTTP 1.1, les connexions sont maintenues ouvertes par défaut. Si le client envoie plusieurs requêtes HTTP 1.1 en rafale, par exemple parce que le client après avoir téléchargé un première page HTML doit télécharger d'autres objets (images, sons), les requêtes autres que la première échoueront. La Figure 3 illustre la situation évoquée plus haut, à savoir une rafale 210 de requêtes du client (browser) 150 au serveur 110. Une telle rafale est susceptible d'être traitée par le serveur s'il travaille en mode dit automatic reconnection tel que défini au point 6.4.27.1 de la norme susmentionnée. La connexion demandée par la première requête est confirmée au client en 211. Une seule connexion TCP pouvant être acceptée, la seconde requête est rejetée et le client en est averti en 212. Après que le client et le serveur ont échangé des données via la connexion TCP et le canal BIP, le client transmet une requête de déconnexion 213 qui est confirmée en 214. Le browser relance la seconde requête et demande à nouveau une connexion en 216, après l'arrivée à échéance d'un timer 215 (du browser ou de la pile TCP/IP du client), armé lors du premier échec en 212. En pratique la temporisation peut atteindre 10 s ce qui freine considérablement le téléchargement et peut même conduire au non téléchargement de certains objets. La Figure 4 illustre une tentative de communication entre la carte 110 opérant en mode serveur et deux clients, ici deux clients locaux, le browser du terminal mobile 150 et un midlet 160 d'une application Java (par exemple un jeu sur le terminal mobile). Comme on peut le constater, après que le browser a fait une tentative fructueuse de connexion en 220, la requête de connexion issue du midlet échoue en 221, car le port TCP associé au canal BIP n'est pas disponible. De manière plus critique, si la requête HTTP du browser est du type Keep-Alive (par ex. requête HTTP 1.1) et que celui-ci ne demande plus de nouvelles données, le port TCP du serveur reste mobilisé alors que le serveur est inactif. Par exemple si l'usager, après avoir téléchargé une page du serveur décide de lancer une nouvelle application requérant d'accéder au serveur, cette dernière ne pourra se dérouler qu'après l'arrivée à échéance du timer (du browser) pour la première connexion. En définitive, le protocole BIP actuel impose au serveur de la carte d'être monoclient (à tout le moins lorsqu'un seul canal BIP peut être ouvert). La Figure 5 illustre une communication entre la carte 110 opérant en mode serveur et un client, le serveur étant lui-même en mode dit automatic reconnection au sens du point 6.4.27.1 de la norme susmentionnée. Brièvement, si le serveur est dans ce mode, le canal BIP n'est pas fermé (par une commande Close channel) lorsque la connexion TCP avec le client est coupée et la passerelle est mise en attente d'une nouvelle connexion. Le serveur peut alors accepter un seconde requête du client et une nouvelle connexion TCP peut être établie. Dans cette Figure on a explicité les piles TCP/IP. Dans une première phase 230, un canal BIP est ouvert sur une commande Open Channel du protocole BIP. Le terminal mobile le confirme par une réponse Terminal Response positive. Le browser transmet alors une première requête en 231, la liaison TCP est établie après l'échange 232. Le browser 150 peut alors échanger des données avec la carte 110, comme indiqué en 233. Si une seconde requête est transmise par le browser en 234 avant que l'échange 233 soit terminé, la passerelle 120 rejettera la demande de connexion en 235 et se remettra en attente d'une nouvelle requête de connexion, 236. Le but de la présente invention est de remédier aux inconvénients mentionnés ci-dessus, notamment de permettre le traitement par la carte (U)SIM opérant en mode serveur de plusieurs requêtes simultanées issues du même client ou de clients distincts. EXPOSÉ DE L'INVENTION A cette fin l'invention est définie par une méthode de communication entre une carte à puce, équipée d'un serveur, et un ou plusieurs clients, ladite carte étant comprise dans un terminal radiomobile et communiquant avec ce dernier au moyen d' au moins un canal BIP, caractérisée en ce que ledit terminal assure une fonction de passerelle entre ledit canal BIP et une pluralité de connexions TCP avec le ou lesdits clients. Ainsi un canal BIP pourra supporter plusieurs connexions TCP avec ce ou ces clients pour satisfaire des requêtes simultanées. La méthode de communication entre le serveur et la passerelle pourra avantageusement comprendre une première commande (Open Channel), ladite commande comprenant un paramètre indiquant audit terminal le nombre maximal de connexions TCP à ouvrir pour ledit canal BIP. La méthode de communication pourra encore avantageusement comprendre, l'émission d'une seconde commande (Receive Data) par le serveur demandant au dit terminal de lui transmettre les données issues d'une des connexions TCP associées au dit canal BIP (lorsque le serveur aura été averti que de telles données étaient disponibles), ladite commande comprenant un paramètre identifiant ladite connexion TCP. La méthode de communication pourra avantageusement prévoir que ledit serveur envoie des données au dit terminal via le canal BIP et demande à ce dernier de les transmettre vers le ou l'un desdits clients, au moyen d'une troisième commande (Send Data), ladite commande comprenant un paramètre identifiant la connexion TCP à utiliser par le terminal pour la transmission. La méthode de communication pourra avantageusement prévoir que ledit serveur demande au dit terminal de fermer une ou plusieurs des connexions TCP associées au dit canal BIP, au moyen d'une quatrième commande (Close Channel), ladite commande comprenant un paramètre identifiant la ou les connexions TCP à fermer. La méthode de communication pourra avantageusement prévoir que ledit terminal transmet au dit serveur un message d'évènement (Data available event), ledit message indiquant que des données du ou d'un desdits clients sont disponibles pour ledit canal BIP et identifiant la connexion TCP associée au dit canal sur laquelle elles ont été reçues. La méthode de communication pourra enfin avantageusement prévoir que ledit terminal transmet au dit serveur un message d'évènement (Channel status event) indiquant qu'une connexion TCP associée au canal BIP a été établie ou a été fermée et identifiant cette connexion. Ainsi le protocole BIP entre la carte à puce et la passerelle pourra supporter la gestion de plusieurs connexions TCP associées à un même canal. L'invention prévoit également le format des messages pour ce protocole. L'invention vise enfin une carte à puce comportant des moyens logiciels adaptés à générer des messages de commande et un terminal mobile comportant des moyens logiciels adaptés à générer des messages d'évènement, leur permettant de mettre en oeuvre la méthode susmentionnée. BRÈVE DESCRIPTION DES DESSINS L'invention sera mieux comprise par la description de modes de réalisation à l'aide des figures suivantes : la Fig. 1 illustre schématiquement une communication entre une carte (U)SIM opérant en mode serveur et un client. la Fig. 2 illustre schématiquement un chronogramme de la communication entre la carte et un client, - la Fig. 3 illustre schématiquement la situation où une rafale de requêtes est transmise par le client à la carte (U) SIM ; - la Fig. 4 illustre schématiquement une tentative de communication entre la carte (U)SIM et deux clients ; - la Fig. 5 illustre schématiquement le chronogramme d'une communication entre un client et le serveur de la carte (U)SIM, celui-ci étant en mode automatic reconnection ; - la Fig. 6 illustre schématiquement le chronogramme d'une communication entre la carte (U)SIM et un client, selon un mode de réalisation de l'invention ; - la Fig. 7 illustre schématiquement le mécanisme de rupture de la communication entre la carte (U)SIM et un client, selon un mode de réalisation de l'invention; - la Fig. 8 illustre schématiquement une tentative de communication entre la carte (U)SIM et deux clients, dans le cadre de la mise en oeuvre de l'invention ; - la Fig. 9 illustre schématiquement le chronogramme d'une communication entre la carte (U)SIM et un client, selon un mode de réalisation de l'invention, lorsque le serveur de la carte (U)SIM est en mode automatic reconnection . EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS L'idée à la base de l'invention est de permettre l'association de plusieurs connexions TCP à un canal BIP. Pour ce faire le protocole BIP entre le serveur hébergé par la carte et la passerelle est enrichi de manière à spécifier, pour un canal BIP donné, à quelle connexion TCP s'applique la commande. En particulier, comme nous le verrons en détail plus loin, l'invention prévoit que les commandes Receive data , Send data , Close channel du serveur et les messages d'évènement Data available et Status channel du terminal mobile, tels que définies dans la norme ETSI TS 102223, doivent désormais comporter un identifiant de la connexion TCP à laquelle ils s'appliquent. La Figure 6 illustre un chronogramme de communication entre une carte (U)SIM opérant en mode serveur et un client, par exemple le browser du terminal mobile, lorsque la présente invention est mise en oeuvre. Comme précédemment, l'échange 240 entre la carte et la passerelle assure l'établissement du canal BIP. Une rafale de requêtes est transmise par le browser en 241. En réponse deux connexions TCP sont établies par la passerelle 120, c'est-à-dire deux ports TCP sont ouverts pour ces connexions. L'établissement des connexions est confirmé au browser en 243 et le serveur de la carte en est averti en 244 au moyen de messages d'évènement Channel status . Des données sont ensuite transmises par le browser à destination du serveur sur lesdites connexions TCP. La passerelle 120 du terminal mobile avertit le serveur en 246 et en 250 que des données sont disponibles sur les deux ports TCP respectifs au moyen de messages d'évènement Data available . Chaque message Data available indique la connexion TCP dont il d'agit. En réponse, le serveur demande à la passerelle de lui transmettre les données, au moyen de commandes Receive data , en précisant à chaque fois de quelle connexion TCP (id-1, id-2) il s'agit. On remarque, que contrairement au chronogramme représenté en Figure 6, la seconde requête de connexion n'est pas rejetée et est servie sans délai. Lorsque les données en provenance d'un port ont toutes été transmises, la connexion TCP correspondante peut être rompue à l'initiative du serveur selon un mécanisme illustré en Figure 7. Ainsi des ressources de communication sont libérées et pourront être utilisées pour une autre requête. Ceci est particulièrement avantageux lorsque le nombre de connexions TCP pour le canal BIP a été atteint. Dans le cas présent, toutes les données du port id-1 ayant été transmises au serveur, ce dernier décide de le fermer. Pour ce faire, il transmet en 258 une commande Close channel , identifiant la connexion TCP à fermer. La Figure 8 illustre la situation où deux clients, par exemple le browser du terminal mobile et un midlet tentent de se connecter au serveur de la carte (U)SIM. Les deux requêtes 260 et 262 peuvent être satisfaites sans délai grâce à l'établissement de deux connexions TCP. La passerelle 120 du terminal mobile en avertit le serveur au moyen de messages d'évènement Status channel , 261,263, identifiant les connexions TCP concernées. De manière similaire les requêtes de déconnexions sont servies sans délai et le serveur en est averti en 265, 267 par des messages d'évènement Status channel identifiant les connexions TCP rompues. La Figure 9 illustre le chronogramme d'une communication entre la carte (U)SIM et un client, par exemple un browser, lorsque le serveur de la carte (U)SIM est en mode automatic reconnection . Dans ce mode, le serveur de la carte requiert du terminal mobile l'ouverture d'un canal BIP grâce à une commande Open Channel et précise dans celle-ci le nombre maximal de connexions TCP que le canal BIP peut simultanément supporter (2 dans le cas illustré). Lorsqu'une première requête est émise par le browser, une connexion TCP est établie au terme de l'échange 280. Si une seconde requête est alors émise par le browser, une seconde connexion TCP est établie au terme de l'échange 282. Le browser et le serveur de la carte (U)SIM peuvent alors échanger des données sur les deux connexions. Le nombre maximal de connexions TCP étant atteint, le terminal mobile (la passerelle) n'a pas à retourner en mode écoute et attendre une nouvelle demande de connexion du serveur. Ce n'est que lorsque la passerelle est avertie de la rupture d'une des connexions par le browser, en 284, que la passerelle retourne en mode écoute, en 286. Afin de permettre la mise en oeuvre de l'invention telle que décrite, il est prévu de modifier certaines commandes du protocole BIP défini dans la norme ETSI TS 10223 V7.1.0. Plus précisément il est proposé de paramétrer la commande Open Channel par le nombre maximal de connexions TCP. Ce nombre sera indiqué dans le champ Command Qualifier de l'élément de données TLV Command details de la commande définie au point 6.6.27 de la norme susmentionnée. La commande Close channel sera, quant à elle, paramétrée par : - un premier paramètre indiquant si (a) une ou (b) toutes les connexions TCP sont à fermer et dans le cas (b) si le canal logique BIP est lui-même aussi à fermer un second paramètre identifiant la connexion à fermer dans le cas (a). Ces deux paramètres seront placés dans le champ Command Qualifier de l'élément de données TLV Command details de la commande définie au point 6.6.28 de la norme susmentionnée. La réponse du terminal (TR) à une telle commande comportera le cas échéant l'identifiant de connexion. La commande Receive data sera paramétrée par la connexion TCP (c'est-à-dire le port TCP) dont le serveur veut récupérer les données. L'identifiant de la connexion sera indiqué dans le champ Command Qualifier de l'élément de données TLV Command details de la commande définie au point 6.6.29 de la norme susmentionnée. La réponse du terminal (TR) à une telle commande comportera le cas échéant l'identifiant de connexion. La commande Send data sera paramétrée par la connexion TCP sur laquelle le terminal doit transmettre les données. L'identifiant de la connexion sera indiqué dans le champ Command Qualifier de l'élément de données TLV Command details de la commande définie au point 6.6.30 de la norme susmentionnée. La réponse du terminal (TR) à une telle commande comportera le cas échéant l'identifiant de connexion.30 Le message d'évènement (message aussi appelé ENVELOPE command dans la norme concernée) Data available sera paramétrée par la connexion TCP, i.e. le port TCP sur lequel des données sont disponibles. On rappelle que ce message est transmis du terminal mobile au serveur de la carte (U)SIM. Il contiendra à cet effet un identifiant de la connexion en question dans le champ Channel status de l'élément de données TLV Channel status du message défini au point 7.5.10 de la norme susmentionnée. Le message d'évènement Channel status transmis par le terminal au serveur de la carte (U)SIM donnera le statut de la connexion TCP. Il contiendra à cet effet un identifiant de ladite connexion dans le champ Channel status de l'élément de données TLV Channel status du message défini au point 7.5.11 de la norme susmentionnée. REVENDICATIONS 1. Méthode de communication entre une carte à puce ( (U) SIM) , équipée d'un serveur (SCWS), et un ou plusieurs clients, ladite carte étant comprise dans un terminal radiomobile et communiquant avec ce dernier au moyen d'au moins un canal BIP, caractérisée en ce que ledit terminal assure une fonction de passerelle entre ledit canal BIP et une pluralité de connexions TCP avec le ou lesdits clients. 2. Méthode de communication selon la revendication 1, caractérisée en ce que ledit canal BIP est ouvert au moyen d'une première commande (Open Channel) dudit serveur, ladite commande comprenant un paramètre indiquant audit terminal le nombre maximal de connexions TCP à ouvrir pour ledit canal BIP. 3. Méthode de communication selon la revendication 2, caractérisée en ce que ledit serveur ayant été averti par le terminal que des données issues d'une des connexions TCP associées au dit canal BIP étaient disponibles, transmet une seconde commande (Receive Data) demandant au dit terminal de les lui transmettre, ladite commande comprenant un paramètre identifiant ladite connexion TCP. 4. Méthode de communication selon la revendication 2 ou 3, caractérisée en ce que ledit serveur envoie des données au dit terminal via le canalBIP et demande à ce dernier de les transmettre vers le ou l'un desdits clients, au moyen d'une troisième commande (Send Data), ladite commande comprenant un paramètre identifiant la connexion TCP à utiliser par le terminal pour la transmission. 5. Méthode selon l'une des revendications précédentes, caractérisée en ce que ledit serveur demande au dit terminal de fermer une ou plusieurs des connexions TCP associées au dit canal BIP, au moyen d'une quatrième commande (Close Channel), ladite commande comprenant un paramètre identifiant la ou les connexions TCP à fermer. 6. Méthode selon l'une des revendications 1 à 4, caractérisée en ce que ledit serveur demande au dit terminal de fermer une ou toutes les connexions TCP associées au canal BIP, au moyen d'une quatrième commande (Close Channel), ladite commande comprenant un paramètre indiquant au terminal si : (a) l'une seulement des connexions TCP associées au canal BIP est à fermer ; ou bien (b) toutes les connexions TCP associées au canal TCP est à fermer ; ledit paramètre identifiant, dans le cas (a), la connexion TCP à fermer. 7. Méthode selon la revendication 6 caractérisée en ce que le paramètre de la quatrième commande indique en outre dans le cas (b) si le canal BIP est également à fermer. 8. Méthode selon l'une des revendications précédentes caractérisée en ce que ledit terminal transmet au dit serveur un message d'évènement (Data available event), ledit message indiquant que des données du ou d'un desdits clients sont disponibles pour ledit canal BIP et identifiant la connexion TCP associée au dit canal sur laquelle elles ont été reçues. 9. Méthode selon l'une des revendications précédentes caractérisée en ce que ledit terminal transmet au dit serveur un message d'évènement (Channel status event) indiquant qu'une connexion TCP associée au canal BIP a été établie ou a été fermée et identifiant cette connexion. 10. Méthode de communication entre un dispositif possédant une fonction SIM ((U)SIM), équipée d'un serveur (SCWS), et un ou plusieurs clients, ledit dispositif étant connecté à un terminal radiomobile et communiquant avec ce dernier au moyen d'au moins un canal BIP, caractérisée en ce que ledit terminal assure une fonction de passerelle entre ledit canal BIP et une pluralité de connexions TCP avec le ou lesdits clients.