Brevet FR2850225A1 — publié le 20040723

PROC D PERFECTIONN DE G N RATION D'UNE REQUETE D'ACTIVATION DE CONTEXTE ENTRE UN QUIPEMENT DE COMMUNICATION ET UN R SEAU DE COMMUNICATIONS L'invention concerne le domaine de la génération de requêtes d'activation de contexte entre des équipements de communication et des réseaux de communications. On entend ici par équipement de communication tout type 10 d'équipement de réseau supportant une activation de contexte via un réseau de radiocommunications, soit directement lorsqu'il s'agit d'un équipement mobile, par exemple de type téléphone mobile, soit indirectement, via un équipement mobile, lorsqu'il s'agit d'un équipement fixe, par exemple de type ordinateur individuel (ou PC) communicant. Par ailleurs, l'invention concerne l'activation des contextes de type paquet, et notamment ceux de type PDP (pour " Packet Data Protocol ") utilisés dans le cadre des connexions avec des réseaux de communications à protocole Internet (IP), via des réseaux de radiocommunications dits " à commutation de paquets ", et notamment les réseaux GPRS et UMTS. L'activation d'un contexte est une opération destinée à permettre la liaison entre un réseau de radiocommunications, notamment GPRS ou UMTS, et un ou plusieurs réseaux de données, comme par exemple Internet. Une telle activation est habituellement initiée par une requête (d'activation) comprenant plusieurs champs, et notamment un champ destiné 25 à l'identifiant (par exemple APN pour " Access Point Name ") du point d'accès au (ou passerelle vers le) réseau de données auquel l'utilisateur souhaite se connecter, et des champs destinés à l'identifiant du protocole d'authentification ainsi qu'aux paramètres d'authentification associés, indispensables aux réseaux de radiocommunications et réseaux de données 30 (externes) pour effectuer l'authentification de l'utilisateur. L'identifiant du point d'accès au réseau de données est généralement fourni par l'utilisateur, soit par saisie, soit par sélection d'un menu ou activation d'une touche dédiée de son équipement de communication. En revanche, l'identifiant du protocole d'authentification n'est pas forcément connu à l'avance. En effet, par exemple dans le cas d'une 5 activation de contexte PDP de type IP à partir d'un équipement fixe connecté à un équipement mobile via une liaison selon un protocole de type PPP, l'identifiant du protocole d'authentification est un paramètre qui est négocié entre l'équipement fixe connecté et l'équipement mobile lors de l'activation de leur lien LCP. Une fois le protocole d'authentification négocié entre ces deux 1o équipements fixe et mobile, l'équipement mobile transmet l'identifiant du protocole négocié au réseau de radiocommunications (GPRS ou UMTS), dans la requête d'activation de contexte. Or, il se peut que ce protocole d'authentification ne soit pas supporté par le point d'accès concerné du réseau de radiocommunications. Cette situation résulte principalement d'un choix d'architecture, pris par les organismes de normalisation, qui n'impose pas au réseau de radiocommunnications (GPRS ou UMTS) de supporter obligatoirement tous les protocoles d'authentification. Ainsi, dans le cas d'une activation de contexte PDP de type IP, via un réseau de type GPRS ou UMTS, le 3GPP 20 impose que ladite activation de contexte PDP se fasse en une seule phase (une requête en provenance d'un équipement mobile et une réponse en provenance du réseau de radiocommunications). Aucune possibilité de négociation n'est offerte. L'organisme 3GPP permet uniquement un mécanisme de négociation de protocole d'authentification entre un 25 équipement mobile et un équipement fixe. Plus précisément, l'équipement mobile propose d'abord le protocole d'authentification CHAP (pour " Challenge Handshake Authentication Protocol ") à l'équipement fixe. Si le protocole proposé n'est pas supporté par l'équipement fixe alors le mobile propose le protocole d'authentification PAP (pour " Password Authentication 3o Protocol "). Par conséquent, chaque fois qu'un point d'accès, désignant un équipement de réseau de radiocommunications, tel qu'un serveur GGSN, couplé au réseau de données, reçoit une requête d'activation de contexte qui comprend un identifiant de protocole d'authentification, éventuellement précédemment négocié localement entre un équipement fixe et un équipement mobile, qui ne correspond pas au protocole d'authentification 5 supporté par cet équipement du réseau de radiocommunications, l'activation requise ne peut pas se faire, et la connexion ne peut donc pas être établie. Pour tenter de remédier à cet inconvénient, il a été proposé de configurer les équipements de communication à l'aide d'interfaces hommemachine dédiées, mais celles-ci sont difficiles à utiliser par un utilisateur non io initié dans la mesure o elles requièrent dudit utilisateur qu'il connaisse en détail les caractéristiques de souscriptions relatives aux paramètres d'authentification. De plus, le protocole d'authentification peut ne pas être le même dans l'ensemble du réseau de radiocommunications. En outre, cette solution n'est pas toujours viable car l'équipement mobile, selon les accords 15 de mobilité passés entre différents opérateurs, peut être amené à se mouvoir dans différents réseaux impliquant différents équipements d'accès aux réseaux de données. L'invention a donc pour but de remédier à cet inconvénient. Elle propose à cet effet un procédé de génération de requêtes 20 d'activation de contexte entre un équipement de communication et un réseau de communications désigné par un identifiant de point d'accès. Ce procédé consiste, chaque fois qu'un utilisateur souhaite activer un contexte entre l'un de ses équipements de communication et un réseau désigné par un identifiant de point d'accès, à déterminer dans une première 25 étape, dans une table de correspondance entre des identifiants de protocole d'authentification et des identifiants de point d'accès réseau, l'identifiant du protocole d'authentification qui correspond à l'identifiant du point d'accès au réseau désigné, puis à générer dans une seconde étape une requête d'activation de contexte comportant notamment cet identifiant de protocole 30 d'authentification et l'identifiant du point d'accès réseau associé. Préférentiellement, on détermine pendant la première étape l'identifiant de protocole d'authentification dans une table de correspondance stockée dans une mémoire de l'équipement de communication. Deux cas peuvent alors être envisagés. Dans un premier cas, l'équipement de communication est de type fixe, supporte une activation de contexte et est susceptible d'être raccordé à 5 un équipement auxiliaire de radiocommunications de type mobile. Dans la première étape, l'équipement fixe envoie tout d'abord une demande d'activation de contexte PDP à l'équipement auxiliaire mobile. L'équipement auxiliaire mobile cherche alors le protocole d'authentification associé au point d'accès donné grâce à la table de correspondance qu'il stocke dans une io mémoire (éventuellement implantée dans la carte SIM). Puis, l'équipement auxiliaire mobile propose à l'équipement fixe l'établissement d'un lien LCP en utilisant le protocole d'authentification sélectionné. Ensuite, l'équipement fixe transmet à l'équipement auxiliaire mobile des informations d'authentification (en général un " login " et un mot de passe). Enfin, on génère, pendant la 15 seconde étape, la requête d'activation de contexte au niveau de l'équipement auxiliaire mobile, à l'aide des informations d'authentification fournies par l'équipement fixe, puis on transmet cette requête au réseau de radiocommunications via l'interface air. Dans un second cas, l'équipement de communication est de type 20 mobile et supporte une activation de contexte. La table de correspondance est alors de préférence stockée dans une mémoire de la carte SIM dudit équipement mobile (lorsqu'elle est prévue). Sinon la table de correspondance est stockée dans une mémoire non-volatile du mobile. Dans ce cas, pendant la seconde étape l'équipement mobile génère la requête d'activation de 25 contexte et la transmet au réseau de radiocommunications. Par ailleurs, il est possible de mettre à jour la table de correspondance par échange de messages SMS, par échange de messages via une interface homme-machine dédiée ou par échange de messages par synchronisation via un terminal (ou équipement) de communication fixe. L'invention porte également sur un dispositif d'aide à la génération de requêtes d'activation de contexte entre un équipement de communication et un réseau de communications désigné par un identifiant de point d'accès. Ce dispositif se caractérise par le fait qu'il comprend une mémoire, pouvant stocker une table de correspondance entre des identifiants de protocole d'authentification et des identifiants de point d'accès réseau, et des moyens de traitement capables, lorsqu'ils reçoivent une demande d'activation 5 de contexte entre un équipement de communication et un réseau désigné par un identifiant de point d'accès, d'une part, de déterminer dans la mémoire l'identifiant de protocole d'authentification correspondant à l'identifiant du point d'accès au réseau désigné, et d'autre part, de transmettre à des moyens de génération de requête d'activation de contexte au moins l'identifiant de io protocole d'authentification et l'identifiant de point d'accès réseau associé. Les moyens de traitement peuvent être agencés de manière à mettre à jour la table de correspondance par échange de messages SMS, par échange de messages via une interface homme-machine dédiée ou par échange de messages par synchronisation via un équipement de 15 communications fixe. L'invention porte en outre sur un équipement de communication mobile comprenant un dispositif du type de celui présenté ci-avant. Si l'équipement comprend une carte SIM pouvant mémoriser la table de correspondance, il est préférable que cette carte comporte la mémoire du 20 dispositif. Si la carte SIM ne peut pas supporter la table de correspondance alors cette dernière est stockée dans une mémoire nonvolatile de l'équipement mobile. L'invention est particulièrement bien adaptée à l'activation des contextes PDP de type IP via une communication radio de type GPRS ou 25 UMTS, ainsi qu'aux protocoles d'authentification appartenant à la famille dite " PPP ", et en particulier aux protocoles PAP et CHAP. D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels: - la figure 1 illustre de façon schématique une partie d'une installation de communications comprenant un réseau de radiocommunications, de type GPRS, raccordé à un réseau de données, de type Internet, et à des équipements d'utilisateurs équipés d'un dispositif selon l'invention, - la figure 2 illustre de façon schématique un exemple de réalisation d'un dispositif selon l'invention implanté dans un équipement d'utilisateur, de type téléphone mobile, et - la figure 3 illustre de façon schématique un premier équipement d'utilisateur, de type ordinateur individuel fixe, couplé à un second équipement d'utilisateur, de type téléphone mobile, équipé d'un dispositif selon l'invention. io Les dessins annexés pourront non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant. Le dispositif de traitement selon l'invention est destiné à être installé dans des équipements de communication (ou équipements d'utilisateurs) raccordés à un réseau public de radiocommunications à commutation de 1 5 paquets, et en particulier les réseaux dits " 2,5G ", tels que le réseau GPRS, ou les réseaux dits " 3G ", tels que le réseau UMTS. On entend ici par équipement d'utilisateur UE tout type d'équipement communicant de réseau supportant une activation de contexte via un réseau de radiocommunications, soit directement lorsqu'il s'agit d'un équipement mobile, par exemple de type 20 téléphone mobile ou assistant numérique personnel (PDA), soit indirectement, via un équipement mobile, lorsqu'il s'agit d'un équipement fixe, par exemple de type ordinateur individuel (ou PC) communicant. Par ailleurs, dans ce qui suit on considère que le réseau de radiocommunications est de type GPRS. 2 5 Comme cela est illustré sur la figure 1, un réseau de radiocommunications de type GPRS comporte, de façon très simplifiée, une multiplicité de stations de base d'émission/réception, également appelées BTS, associées chacune à une cellule d'émission/réception et raccordés à des noeuds d'un premier type, appelés BSC (pour " Base Station 3 0 Controller "), eux-mêmes raccordés à un noeud d'un deuxième type, appelé SGSN (pour " Service GPRS Serving Node "). Ce noeud SGSN est couplé à un ou plusieurs noeuds d'un troisième type, appelés GGSN (pour " Gateway GPRS Serving Node "). Chaque noeud GGSN est couplé à au moins un réseau de données (ici public, comme par exemple le réseau Internet (IP), mais il pourrait s'agir d'un réseau privé, par exemple de type Intranet). En 5 d'autres termes, le noeud GGSN est une passerelle ou un point d'accès à un réseau de données. Par ailleurs, le réseau de radiocommunications comporte un équipement de réseau appelé HLR (pour " Home Location Register "), comportant sa base de clients et raccordé aux noeuds SGSN et GGSN(s). Les équipements d'utilisateurs UE peuvent se raccorder au réseau de 10 radiocommunications, via l'une de ses stations de base BTS, dès lors qu'ils se trouvent situés dans l'une de ses cellules d'émission/réception. Grâce à ce réseau de radiocommunications, les clients de son opérateur peuvent établir des liaisons entre leurs équipements de communications UE et des équipements de réseau, tels que des serveurs, du 15 réseau de données INTERNET auquel ledit réseau de radiocommunications est couplé via l'un de ses GGSNs. L'établissement de ce type de liaison entre un équipement d'utilisateur et un réseau de données requiert, cependant, une opération préalable systématique, à l'initiative de l'utilisateur requérant, que l'homme de 20 l'art appelle une " activation de contexte de type paquet " (ou activation de contexte PDP (pour " Packet Data Protocol ")). Dans le cas d'un réseau de type GPRS (ou UMTS), le contexte PDP est de type IP. Une telle activation est destinée à vérifier que l'utilisateur est autorisé à se connecter au réseau de données (ou au service) requis, via le réseau de 25 radiocommunications de son opérateur. Elle comporte donc une procédure d'authentification initiée par l'équipement UE de l'utilisateur requérant, grâce à une requête d'activation de contexte, et gérée par le noeud SGSN et le noeud GGSN. Cette requête d'activation (ou " Activate PDP Context Request ") 30 comporte plusieurs champs d'information, et notamment un champ destiné à l'identifiant (APN pour " Access Point Name ") du point d'accès (GGSN) au réseau de données (INTERNET) auquel l'utilisateur souhaite se connecter, et un champ PCO (pour " Protocol Configuration Option ") destiné à contenir entre autres l'identifiant du protocole d'authentification supporté par le point d'accès (GGSN) du réseau de radiocommunications GPRS couplé audit réseau de données (INTERNET). Des réseaux de radiocommunications de 5 types sensiblement identiques ou différents peuvent en effet posséder des points d'accès (ou passerelles) supportant des protocoles d'authentification différents. Ainsi, dans le cas d'un contexte PDP de type IP, le protocole d'authentification appartient à la famille PPP. Il peut donc être soit de type CHAP (pour " Challenge Handshake Authentication Protocol "), soit de type PAP (pour A titre d'exemple, dans le cas d'une activation de contexte via un réseau GPRS, la requête comporte les champs PD (pour " Protocol Discriminator "), TI (pour " Transaction Identifier "), NSAPI (pour " Network Service Access Point Identifier "), SAPI (pour " Service Access Point 15 Identifier "), QoS requested (pour " Quality of Service requested "), PDP Type number, PDP Address, APN (" pour Access Point Name "), PCO (pour " Protocol Configuration Options "). Une fois la requête d'activation générée, dans des conditions qui seront décrites plus loin, l'équipement mobile UE la transmet au SGSN du 20 réseau GPRS, via l'interface air AI, la station de base BTS de la cellule dans laquelle il se trouve et le contrôleur BSC auquel est raccordé ladite station de base BTS. A réception de cette requête, le SGSN initie éventuellement avec l'équipement mobile UE requérant une procédure de vérification (" function 25 security "). Le SGSN transmet alors une requête de création de contexte PDP (" Create PDP Context Request ") au GGSN désigné comme point d'accès au réseau de données INTERNET (DN) par le champ APN de la requête d'activation. Cette requête de création contient certains au moins des champs 30 contenus dans la requête d'activation, et notamment le champ PCO contenant le protocole d'authentification du réseau de données INTERNET (DN) ainsi que des paramètres associés (comme par exemple un login et un mot de passe fournis par l'utilisateur ou son équipement UE). A réception de cette requête de création, et après authentification de l'utilisateur, le GGSN transmet au SGSN un message " Create PDP Context Response ") signifiant que le contexte PDP est établi dans le GGSN et que le 5 SGSN peut à son tour établir le contexte PDP associé (ou bien qu'il le refuse). Le SGSN peut alors éventuellement effectuer avec le contrôleur BSC (et/ou la station de base BTS) une procédure d'établissement de contexte de flux de paquets (" BSS Packet Flow Context Procedure "). Puis, le SGSN transmet à l'équipement mobile UE un message (" Activate PDP Context 10 Accept " ou " Activate PDP Context Reject ") lui signalant que l'activation du contexte PDP précédemment requis a été acceptée (ou refusée). En cas d'acceptation, l'équipement mobile UE peut alors activer et configurer la pile de protocoles de transmission de données. Par exemple dans le cas d'un réseau GPRS il configure la pile IP, SNDCP et LLC, qui 15 permet d'échanger des données avec le réseau de données INTERNET (DN). En revanche, en cas de refus, l'échange de données est impossible. L'invention porte plus précisément sur la phase de génération de la requête d'activation de contexte par un équipement d'utilisateur UE. Comme cela est illustré sur les figures 2 et 3, l'invention propose à cet effet un 20 dispositif D comportant une mémoire M capable de stocker une table de correspondance entre des identifiants de protocole d'authentification (par exemple PAP et CHAP) et des identifiants de point d'accès réseau (par exemple APN), ainsi qu'un module de traitement PM chargé, chaque fois qu'il reçoit une demande d'activation de contexte entre un équipement de 25 communication (UE) et un réseau désigné par un identifiant de point d'accès (APN), d'une part, de déterminer dans la mémoire M l'identifiant de protocole d'authentification qui permet de remplir le champ PCO (Protocol Configuration Option) du message " Activate PDP context request ", correspondant à l'identifiant du point d'accès au réseau de données désigné (APN), et d'autre 30 part, de transmettre à des moyens de génération de requête d'activation de contexte au moins le champ (PCO) réservé au protocole d'authentification ainsi que les paramètres d'authentification associés et le champ (APN) réservé à l'identifiant du point d'accès au réseau associé. La mise en oeuvre de ce dispositif D dépend du type d'équipement d'utilisateur UE utilisé pour initier la demande d'activation de contexte. Deux types d'équipement peuvent en effet être envisagés. Un premier type 5 correspond aux équipements mobiles communicants, tels que les téléphones mobiles, qui supportent l'activation de contexte et qui assurent la fonction de " modem " de connexion au réseau GPRS. Un second type correspond aux équipements fixes communicants, tels que les ordinateurs individuels (PC) qui supportent l'activation de contexte mais n'assurent pas la fonction de 10 " modem " de connexion au réseau GPRS. Dans ce second cas, l'équipement fixe doit se connecter à un équipement mobile assurant la fonction de " modem " de connexion au réseau GPRS afin de pouvoir établir une liaison avec un réseau de données DN (INTERNET). L'exemple d'équipement illustré sur la figure 2 correspond au premier 15 type. L'équipement UE est par exemple un téléphone mobile GPRS comprenant classiquement un écran d'affichage S, une interface hommemachine HMI, une carte SIM C, un module de communication CM, également appelé DCE (pour " Data Communication Equipment "), et un module de traitement de données PRM, également appelé DTE (pour " Data Terminal 20 Equipment "). Le module de traitement de données PRM (DTE) est chargé de recevoir et d'émettre les données. Le module de communication CM (DCE) est couplé au module de traitement de données PRM (DTE) de manière à adapter les données qu'il émet aux caractéristiques de la ligne GPRS. Il se présente, par exemple, sous la forme d'un modem ou d'une carte 25 électronique de communication, une carte PCM/CIA ou un module spécifique. L'équipement mobile UE comporte en outre un dispositif selon l'invention D, du type de celui présenté ci avant. Plus précisément, dans ce premier type d'équipement UE, mobile, le module de traitement PM, du dispositif D, est couplé d'une première part, à l'interface homme-machine HMI 30 de manière à recevoir de l'utilisateur la demande d'activation de contexte ainsi que l'identifiant du point d'accès réseau (APN), et d'une deuxième part, au module de traitement de données PRM (DTE), afin de lui transmettre les champs de la requête d'activation de contexte, et d'une troisième part, directement ou indirectement, à la mémoire M afin d'y déterminer les identifiants des protocoles d'authentification associés, dans la table de correspondance, aux identifiants des points d'accès réseau (APN) reçus de 5 l'interface homme/machine HMI. Dans l'exemple illustré, l'équipement mobile UE comporte une carte SIM C dont la mémoire peut avantageusement constituer la mémoire M du dispositif D. Par conséquent, dans ce cas le module de traitement PM est couplé à la mémoire M via les circuits de la carte SIM C. Mais, lorsque la carte SIM ne peut pas supporter la table de 10 correspondance ou lorsque l'équipement mobile UE ne comporte pas de carte SIM, la mémoire M est implantée dans ledit équipement mobile (elle est de préférence de type non-volatile). La génération d'une requête d'activation s'effectue alors comme suit. Dans une première phase, l'utilisateur signale au dispositif D qu'il souhaite 15 activer un contexte avec un réseau de données. Il fournit donc au module de traitement PM du dispositif D, à l'aide de l'interface homme/machine HMI, l'identifiant du point d'accès à ce réseau (APN), soit par saisie, soit par sélection d'un menu ou activation d'une touche dédiée. Dans une seconde phase, le module de traitement PM accède à la 20 mémoire M (via la carte SIM C ou directement lorsqu'elle est implantée dans l'équipement mobile UE), afin de déterminer dans la table de correspondance l'identifiant de protocole d'authentification (par exemple PAP ou CHAP) correspondant à l'identifiant (APN) du point d'accès au réseau, fourni. Lorsque l'utilisateur omet de fournir l'identifiant du point d'accès au réseau, un 25 identifiant de protocole d'authentification par défaut est automatiquement choisi par le module de traitement PM. Il s'agit par exemple de l'identifiant désignant le protocole CHAP, destiné à remplir le champ PCO. Lorsqu'un point d'accès, désigné par un identifiant APN, supporte plusieurs protocoles d'authentification, alors le module de traitement PM choisit l'un d'entre eux, 30 par exemple CHAP (en fonction d'un classement préférentiel). Dans une troisième phase, le module de traitement PM génère une requête d'activation de contexte comportant notamment le champ PCO comprenant l'identifiant de protocole d'authentification (par exemple PAP ou CHAP) et le champ APN comportant l'identifiant de point d'accès réseau associé, puis il la transmet au module de traitement de données PRM. Dans une quatrième phase, le module de traitement de données 5 PRM (DTE) met en forme les données constituant la requête d'activation de contexte, puis les transmet au module de communication CM (DCE). Enfin, dans une cinquième phase, le module de communication CM (DCE) adapte les données reçues de PRM (DTE) aux caractéristiques de la liaison GPRS (préparation du message d'activation du contexte PDP selon le îo format spécifié par la norme GPRS, puis émission de ce message sur l'interface air selon le protocole GPRS). L'exemple illustré sur la figure 3 correspond au second type. Dans cet exemple, l'utilisateur a besoin de deux équipements communicants UE1 et UE2 pour initier, générer et transmettre sa requête d'activation de contexte. 15 Le premier équipement UEI est, par exemple, un ordinateur individuel (PC) fixe comprenant classiquement un moniteur d'affichage Si, une interface homme-machine HMI et un premier module de traitement de données PRM1 (de type DTE), qui comporte généralement au moins une pile de protocoles IP, une application générant les données, de type navigateur (ou " browser ") 20 ou transfert de fichier (tel que ftp, teinet, ou analogue), une pile de protocoles permettant une liaison de type PPP avec un équipement mobile, laquelle est subdivisée en sous- couches IPCP et LCP, et une pile de protocoles définissant une liaison série. Le second équipement UE2 est par exemple un téléphone mobile 25 GPRS sensiblement identique à celui précédemment décrit en référence à la figure 2. Il comprend donc un écran d'affichage S2, un module de communication CM (de type DCE) et un second module de traitement de données PRM2 (de type DTE), qui comporte généralement au moins la pile de protocoles permettant la liaison de type PPP avec l'équipement fixe et la 30 pile de protocoles définissant une liaison série. Le second équipement UE2 comprend en outre, un dispositif selon l'invention D, du type de celui présenté ci avant. L'équipement fixe UE1 est connecté à l'équipement mobile UE2 par exemple grâce à une liaison de type série, IrDa, ou Bluetooth. L'initiation, la génération et la transmission d'une requête d'activation s'effectue alors comme suit. L'utilisateur commence par signaler au dispositif 5 D qu'il souhaite activer un contexte avec un réseau de données. Il fournit donc au module de traitement PM, du dispositif D implanté dans l'équipement mobile UE2, à l'aide de l'interface hommemachine HMI de son premier équipement UE1, l'identifiant du point d'accès à ce réseau (APN). Cette fourniture se fait par exemple à l'aide d'une commande AT. Lorsque l'utilisateur omet de fournir l'identifiant du point d'accès au réseau, un identifiant de protocole d'authentification par défaut est automatiquement choisi par le module de traitement PM. Il s'agit par exemple de l'identifiant désignant le protocole CHAP. Par ailleurs, si un point d'accès est associé à plusieurs protocoles d'authentification, alors un identifiant de i5 protocole préférentiel est choisi automatiquement. Il s'agit par exemple de l'identifiant du protocole CHAP. Puis, le module de traitement PM accède à la mémoire M via la carte SIM C (ou à la mémoire non-volatile implantée dans l'équipement mobile UE2),afin de déterminer dans la table de correspondance l'identifiant de 20 protocole d'authentification (par exemple PAP ou CHAP) correspondant à l'identifiant du point d'accès au réseau désigné (APN). Le second module de traitement de données PRM2 (DTE) adresse ensuite au premier module de traitement de données PRM1 une requête LCP, selon le protocole PPP, pour initier un lien LCP entre les équipements 25 fixe UE1 et mobile UE2, et pour indiquer à l'équipement fixe UE1 quel protocole d'authentification il devra utiliser une fois le lien LCP établi. Dans le cas particulier o l'équipement fixe UE1 ne supporte pas le protocole d'authentification proposé par l'équipement mobile UE2, ledit équipement fixe UE1 peut proposer un autre identifiant de protocole 30 d'authentification audit équipement mobile UE2. Lors de la réception de cette nouvelle proposition, l'équipement mobile UE2 peut optionnellement vérifier si le protocole d'authentification proposé est supporté par le point d'accès désigné par l'APN reçu, en envoyant une requête au dispositif D. Si le dispositif D est agencé pour mettre en oeuvre une telle fonction de vérification, il procède à la vérification en accédant à la table de correspondance stockée dans la mémoire M. En revanche, si cette fonction de vérification n'est pas supportée par le dispositif D, on peut envisager que l'équipement mobile UE2 accepte, par exemple de façon automatique, le protocole d'authentification proposé par l'équipement mobile UE1. Dans ce cas, c'est le réseau de radiocommunications qui décide d'accepter ou de refuser le protocole choisi io par l'équipement fixe UE1. Il se peut, en effet, que le réseau de radiocommunications supporte plusieurs protocoles d'authentification. Une fois que le lien LCP a été établi entre les deux équipements et que le protocole d'authentification a été négocié, les équipements fixe UE1 et mobile UE2 procèdent à la phase d'authentification selon le protocole négocié 15 lors de la phase d'établissement du lien LCP. Pendant cette phase, l'équipement fixe UE1 transmet alors à l'équipement mobile UE2 des informations d'authentification, comme par exemple un login et un mot de passe. L'équipement mobile UE2 mémorise alors l'identifiant de protocole d'authentification négocié lors de l'établissement du lien LCP ainsi que les 20 paramètres associés (login et mot de passe) afin de pouvoir les envoyer au réseau de radiocommunications lors de l'activation du lien IPCP entre les deux équipements UE1 et UE2. Une fois la procédure d'authentification terminée, les deux équipements procèdent à l'établissement du lien IPCP. Pour cela, le premier module de traitement de données PRM1 initie 25 l'établissement du lien IPCP avec le second module de traitement PRM2. Pendant l'établissement du lien IPCP, le second module de traitement de données PRM2 prépare une requête d'activation de contexte PDP en spécifiant l'APN ainsi que l'identifiant du protocole d'authentification et les paramètres d'authentification qui ont été reçus lors de la phase 30 d'authentification entre les deux équipements. Puis, il transmet cette requête au module de communication CM (DCE) qui la met au format de la liaison GPRS et la transmet sur l'interface air AI au réseau de radiocommunications (GPRS). Préférentiellement, le module de traitement PM du dispositif D est agencé de manière mettre à jour la table de correspondance, stockée dans la mémoire M, par échange de messages. Plusieurs types d'échange de 5 messages peuvent être envisagés, et notamment l'échange de message SMS de type " 0 " via l'interface air AI, l'échange de messages via une interface homme-machine dédiée, ou l'échange de messages par synchronisation via un équipement de communications fixe (par exemple un PC). 1o Par ailleurs, le module de traitement M du dispositif D peut être réalisé sous la forme de circuits électroniques, de modules logiciels (ou informatiques), ou d'une combinaison de circuits et de logiciels. L'invention offre également un procédé de génération de requêtes d'activation de contexte entre un équipement de communication UE ou UE1 15 et un réseau de communications désigné par un identifiant de point d'accès. Celui-ci peut être mis en oeuvre à l'aide du dispositif D et des équipements communicants UE, UE2 et UE1 présentés ci-avant. Les fonctions et sous-fonctions principales et optionnelles assurées par les étapes de ce procédé étant sensiblement identiques à celles assurées par les 20 différents moyens constituant le dispositif D, seules seront résumées ciaprès les étapes mettant en oeuvre les fonctions principales du procédé selon l'invention. Ce procédé consiste, chaque fois qu'un utilisateur souhaite activer un contexte entre l'un de ses équipements de communication UE ou UE1 et un 25 réseau désigné par un identifiant de point d'accès (par exemple APN), à déterminer dans une première étape, dans une table de correspondance entre des identifiants de protocole d'authentification (par exemple PAP et CHAP) et des identifiants de point d'accès réseau (par exemple APN), l'identifiant du protocole d'authentification qui correspond à l'identifiant du 30 point d'accès au réseau désigné, puis à générer dans une seconde étape une requête d'activation de contexte comportant notamment cet identifiant de protocole d'authentification (PAP ou CHAP) et l'identifiant (APN) du point d'accès réseau associé. L'invention ne se limite pas aux modes de réalisation de procédé, dispositif et équipement communicant décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après. REVENDICATIONS 1. Procédé de génération d'une requête d'activation de contexte entre un équipement de communication (UE) et un réseau de communication, 5 désigné par un identifiant de point d'accès, caractérisé en ce qu'il consiste, lorsqu'un utilisateur veut activer un contexte entre un équipement de communication (UE) et un réseau désigné par un identifiant de point d'accès, a) à déterminer dans une table de correspondance, entre des identifiants de protocole d'authentification et des identifiants de point d'accès réseau, 10 l'identifiant de protocole d'authentification correspondant audit identifiant de point d'accès au réseau désigné, et b) à générer une requête d'activation comportant notamment ledit identifiant de protocole d'authentification et ledit identifiant de point d'accès réseau associé. 2. Procédé selon la revendication 1, caractérisé en ce qu'à l'étape a) 15 on détermine l'identifiant de protocole d'authentification dans une table de correspondance stockée dans une mémoire (M) dudit équipement de communication (UE). 3. Procédé selon la revendication 2, dans lequel ledit équipement de communication (UE1) est fixe, supporte une activation de contexte et est 20 propre à être raccordé à un équipement auxiliaire de radiocommunications mobile (UE2), caractérisé en ce qu'à l'étape a) on détermine tout d'abord au niveau dudit équipement auxiliaire mobile (UE, UE2) ledit identifiant du protocole d'authentification, puis on détermine auprès dudit équipement fixe (UE1) des informations d'authentification, et en ce qu'à l'étape b) on génère 25 ladite requête au niveau dudit équipement auxiliaire mobile (UE2), de manière à la transmettre audit réseau de radiocommunications. 4. Procédé selon la revendication 2, dans lequel ledit équipement de communication (UE) est mobile et supporte une activation de contexte, caractérisé en ce qu'à l'étape b) on génère ladite requête au niveau dudit 30 équipement mobile (UE), de manière à la transmettre audit réseau de radiocommunications. 5. Procédé selon l'une des revendications 3 et 4, dans lequel ledit équipement mobile (UE2, UE) comporte une carte SIM (C), caractérisé en ce que ladite table de correspondance est stockée dans une mémoire (M) de ladite carte SIM (C). 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que 5 l'on met à jour ladite table de correspondance à l'aide d'une technique choisie dans un groupe comprenant l'échange de messages SMS, l'échange de messages via une interface homme-machine dédiée et l'échange de messages par synchronisation via un équipement de communication fixe. 7. Dispositif (D) d'aide à la génération d'une requête d'activation de 1o contexte entre un équipement de communication (UE) et un réseau de communications désigné par un identifiant de point d'accès, caractérisé en ce qu'il comprend une mémoire (M) propre à stocker une table de correspondance entre des identifiants de protocole d'authentification et des identifiants de point d'accès réseau, et des moyens de traitement (PM) 15 agencés de manière, à réception d'une demande d'activation de contexte entre l'équipement de communication (UE) et un réseau désigné par un identifiant de point d'accès, i) à déterminer dans ladite mémoire (M) l'identifiant de protocole d'authentification correspondant audit identifiant de point d'accès au réseau désigné, et ii) à transmettre à des moyens de 20 génération de requête d'activation de contexte (PRM,PRM2, CM) au moins ledit identifiant de protocole d'authentification et ledit identifiant de point d'accès réseau associé. 8. Dispositif selon la revendication 7, caractérisé en ce que lesdits moyens de traitement (PM) sont agencés pour mettre à jour ladite table de 25 correspondance à l'aide d'une technique choisie dans un groupe comprenant l'échange de messages SMS, l'échange de messages via une interface homme-machine dédiée et l'échange de messages par synchronisation via un équipement de communication fixe. 9. Equipement de communication mobile (UE, UE2), caractérisé en ce 3C qu'il comprend un dispositif (D) selon l'une des revendications 7 et 8. 10. Equipement selon la revendication 9, caractérisé en ce qu'il supporte une activation de contexte, et en ce qu'il comprend des moyens de communication (CM) propres à transmettre chaque requête d'activation de contexte générée par son dispositif (D). 11. Equipement selon la revendication 10, caractérisé en ce qu'il comporte une carte SIM (C) dans laquelle est implantée ladite mémoire (M) du dispositif (D). 12. Utilisation des procédé, dispositif (D) et équipement de communication (UE, UE2) selon l'une des revendications précédentes, pour l'activation d'un contexte PDP de type IP, via une communication radio de type GPRS ou UMTS. 13. Utilisation selon la revendication 12, dans le cas de protocoles d'authentification choisis dans un groupe comprenant les protocoles de la famille PPP, et en particulier les protocoles PAP et CHAP.