Brevet FR2998755A1 — publié le 20140530

DOMAINE DE L'INVENTION La présente invention concerne le domaine des télécommunications sans fil, et plus particulièrement un procédé d'établissement d'une connexion IP au travers d'un réseau mobile, par exemple de type 3GPP et au moins partiellement de type IP, un équipement réseau de ce réseau mobile, une infrastructure de réseau mobile, un terminal mobile et un système correspondant. CONTEXTE DE L'INVENTION Les réseaux de téléphonie mobile, et notamment de type 3GPP, ont largement évolués avec l'intégration progressive de sous-parties en protocole de paquets de données pour supporter des services de paquets de données, type IP (Internet Protocol). Les réseaux 2G et 3G, notamment GPRS (General Packet Radio Service) et UTMS (Universal Mobile Telecommunications System), reposent sur un réseau mobile GSM (Global System for Mobile Communications) commuté rattaché à un coeur de réseau GPRS, c'est-à-dire IP. Une des dernières versions 3GPP, le LTE pour Long Term Evolution ou EPS pour Evolved Packet System, est un système réseau mobile entièrement basé sur l'IP. Afin de permettre à un module sécurisé, tel une carte à puce ou UICC (Universal Integrated Circuit Card), ou à un terminal mobile utilisateur, UE, d'établir une connexion IP avec un service hébergé sur un serveur cible OTA (pour Over-The-Air), le module sécurisé ou terminal doit généralement connaître l'adresse IP du serveur cible. Une connexion IP est le support à des services de paquets de données. Dans des applications hautement sécurisées où l'utilisateur ne doit pas avoir accès aux paramètres définissant le serveur cible, il est préférable que ce soit l'UICC qui ait à connaître de cette adresse IP le cas échéant. Or une adresse IP a généralement vocation à être attribuée de façon dynamique et à changer dans le temps. En outre, le service cible peut être hébergé sur plusieurs serveurs, lesquels peuvent être déplacés, rendus temporairement inaccessibles, etc. Par conséquent, l'UICC ou terminal doit pouvoir avoir recours à un nom de domaine complètement qualifié (FQDN pour Fully Qualified Domain Name) afin de désigner ce service cible, indépendamment de l'équipement serveur qui sera en mesure de répondre à sa requête à un instant donné. La conversion du FQDN en une adresse IP est connue des réseaux IP classiques, tels l'Internet, sous l'appellation de résolution DNS (Domain Name System). Les normes des réseaux mobiles 3GPP actuels prévoient que l'adresse IP du serveur cible OTA soit connue de l'UICC à l'avance et soit fixe, évitant ainsi une résolution DNS. Il n'est donc pas prévu pour l'UICC de moyen permettant une résolution DNS pour un FQDN. Pour pallier ce manque, le document EP 2 293 525 prévoit qu'une telle UICC puisse solliciter un client DNS classique du terminal mobile l'intégrant afin d'obtenir une adresse IP fixe avec laquelle elle peut communiquer. Cette configuration présente toutefois certains inconvénients. La résolution DNS repose sur le réseau IP externe auquel accède le terminal mobile via le réseau mobile 3GPP. Des paramètres au sein du terminal définissent ce réseau externe. Il s'agit le plus souvent du réseau public Internet. La résolution DNS sur plusieurs réseaux IP distincts, publics et/ou privés, n'est pas possible sans re-paramétrer le terminal. Ce re-paramétrage n'est en outre pas compatible avec des usages sécurisés où les paramètres sont stockés dans l'UICC. Par ailleurs, des développements spécifiques au terminal mobile et à l'UICC sont nécessaires dans EP 2 293 525 afin de permettre la sollicitation du 30 client DNS. Or ces développements sont peu adaptés à certains contextes techniques, notamment celui des communications de type machine (Machine-Type Communications « MTC » ou Machine-to-Machine « M2M ») qui visent des applications peu complexes et à bas coût. Il s'agit par exemple des équipements de mesure et de contrôle à distance, par exemple un compteur de gaz, un compteur électrique, un équipement de mesure d'une station météorologique, etc. Dans ce contexte, il apparaît opportun de développer des solutions de résolution DNS réduisant les coûts de développement et de production des terminaux mobiles, pour permettre par exemple à une UICC dans un terminal mobile ou équipement mobile, ME, d'utiliser et gérer des noms de domaines lors de l'établissement d'une connexion IP dans un réseau mobile 3GPP. RESUME DE L'INVENTION La présente invention vise à remédier tout ou partie de ces inconvénients, en offrant notamment un mécanisme de gestion et résolution DNS qui est indépendant du terminal mobile et du module sécurisé UICC. Dans ce dessein, un premier aspect de l'invention concerne un procédé d'établissement d'une connexion IP au travers d'un réseau mobile comprenant les étapes suivantes, sur un premier équipement du réseau mobile autre qu'un équipement mobile UE du réseau mobile: recevoir un nom de domaine complètement qualifié, FQDN, émis par un équipement mobile, UE, dudit réseau mobile, le FQDN identifiant un serveur de données cible; et déclencher, à réception du FQDN, la résolution du FQDN en une adresse IP du serveur de données cible. Selon l'invention, la gestion/résolution DNS est déportée, incluant le déclenchement de la résolution DNS, sur un équipement de l'infrastructure du réseau mobile (c'est-à-dire autre qu'un terminal mobile utilisant ce réseau), rendant les mécanismes DNS indépendants du terminal mobile et d'un éventuel module sécurisé UICC qu'il hébergerait. En basant le réseau mobile sur ces mécanismes, une application cliente dans l'UICC ou le terminal mobile peut ainsi initier une connexion IP avec une application serveur distante en utilisant un FQDN sans disposer de moyen de résolution DNS en interne. Des terminaux et UICC de faible complexité technique peuvent donc être utilisés, fortement adaptés à des usages M2M. Notamment, on s'affranchit ainsi d'une hypothétique modification de l'UICC pour lui intégrer de coûteux mécanismes de résolution DNS. Cela est rendu possible par la configuration de l'équipement du réseau mobile selon laquelle la réception d'un FQDN déclenche la résolution DNS. En effet, les mécanismes actuels des réseaux mobiles, notamment 3GPP, prévoient uniquement la réception d'adresses IP fixes par les terminaux mobiles, en particulier en provenance d'une UICC. Aucun paramétrage relatif à une résolution DNS n'est donc nécessaire au sein du terminal mobile ou de l'UICC. En outre, la résolution DNS proposée par l'invention sur le réseau mobile permet simultanément de traiter des résolutions DNS relatives à plusieurs réseaux IP. Grâce à l'adresse IP obtenue par la résolution DNS, une connexion IP peut en définitive être établie avec le terminal mobile ou l'UICC, selon le cas. Corrélativement, un deuxième aspect de l'invention vise un équipement de cette infrastructure de réseau mobile 3GPP offrant les mêmes avantages. Ainsi, un équipement d'un réseau mobile, selon l'invention, comprend des moyens configurés pour: recevoir un nom de domaine complètement qualifié, FQDN, émis par un équipement mobile UE du réseau mobile, le FQDN identifiant un serveur de données cible; et déclencher, à réception du FQDN, la résolution du FQDN en une adresse IP du serveur de données cible. D'autres caractéristiques du procédé et de l'équipement de réseau selon des modes de réalisation sont décrites dans les revendications dépendantes Dans un mode de réalisation, le procédé comprend en outre les étapes suivantes : obtenir un nom de point d'accès, APN, identifiant un réseau externe de paquets de données, PDN, pour l'équipement mobile UE ; et sélectionner, par un autre équipement du réseau mobile autre que l'équipement mobile UE, au moins une passerelle du réseau mobile vers le réseau externe PDN, par procédure de découverte et de sélection à partir de l'APN obtenu ; procédé dans lequel le premier équipement est ladite passerelle sélectionnée. Cela correspond à une infrastructure de réseau mobile, comprenant un équipement configuré pour : obtenir un nom de point d'accès, APN, identifiant un réseau externe de paquets de données, PDN, pour un équipement mobile UE du réseau mobile ; et sélectionner au moins une passerelle du réseau mobile 3GPP vers le réseau externe PDN, par procédure de découverte et de sélection à partir de l'APN obtenu, ladite passerelle étant un équipement comme défini ci-dessus recevant un nom de domaine complètement qualifié, FQDN, émis par le même UE. Cette disposition explicite la possibilité, pour l'infrastructure de réseau mobile, de résoudre des noms de domaine DNS externes à ce réseau mobile. En effet, dans ce cas, l'APN permet d'identifier une passerelle idoine vers le réseau PDN auquel le terminal mobile souhaite accéder. Et c'est cette passerelle qui est légitime à engager une procédure de résolution DNS, éventuellement en sollicitant ce réseau PDN. En particulier, le réseau mobile est un réseau mobile 3GPP au moins partiellement de type IP, le premier équipement est une passerelle PDN-GW du réseau mobile 3GPP vers le réseau externe PDN, l'autre équipement est une entité de gestion de mobilité, MME, du réseau mobile 3GPP et le serveur de données cible est un noeud externe au réseau mobile 3GPP appartenant au réseau externe PDN. Il s'agit par exemple d'une architecture EPS (Evolved Packet System) constituant un réseau de téléphonie mobile « 3,9G » basé entièrement sur le protocole IP. Cette configuration permet la mise en oeuvre d'une résolution DNS selon l'invention dans un réseau 3,9G, à savoir dans un système EPS. Selon une autre caractéristique particulière, pour résoudre le FQDN en une adresse IP, le premier équipement formant passerelle vers le réseau externe PDN envoie une requête de résolution DNS à un serveur DNS externe appartenant au réseau externe PDN. En d'autres termes, le premier équipement formant passerelle vers le réseau externe PDN est configuré pour résoudre le FQDN en une adresse IP par l'envoi d'une requête de résolution DNS à un serveur DNS externe appartenant au réseau externe PDN. Ainsi, ici, c'est un équipement de l'infrastructure réseau 3GPP, et non le terminal utilisateur UE, qui effectue la résolution DNS pour le compte de ce terminal (ou de l'UICC qu'il héberge). La requête de résolution DNS sur le réseau externe PDN peut être classique à tout réseau IP. Une variante à cette configuration peut prévoir que le premier équipement envoie une requête de résolution DNS à un serveur DNS interne au réseau mobile 3GPP, ce serveur DNS interne requérant alors un serveur DNS externe appartenant au réseau externe PDN pour ladite résolution DNS. Cette variante est appropriée dans le cas où, selon le paramétrage du réseau mobile 3GPP, la passerelle (le premier équipement) n'est pas autorisée à se connecter au réseau PDN ou à solliciter un serveur DNS externe. Dans un mode de réalisation en variante à l'utilisation de l'APN, le 20 réseau mobile est un réseau mobile 3GPP au moins partiellement de type IP, le premier équipement est une entité de gestion de mobilité, MME, du réseau mobile 3GPP et le serveur de données cible est un noeud interne au réseau mobile 3GPP. Cette disposition explicite la possibilité, pour l'infrastructure de 25 réseau mobile 3GPP basé sur l'IP, de résoudre des noms de domaine DNS internes à ce réseau mobile 3GPP. Cette possibilité s'additionne ainsi aux possibilités de procédure de découverte et de sélection de passerelles SGW (Serving GateWay) et PDN-GW déjà prévues dans les systèmes EPS. L'équipement MME, en ce qu'il centralise déjà ces procédures de découverte et 30 de sélection est légitime à la gestion de cette nouvelle possibilité offerte par l'invention. Selon une caractéristique particulière, le déclenchement de la résolution du FQDN a lieu si le premier équipement MME n'a pas déjà obtenu un nom de point d'accès, APN, identifiant un réseau externe de paquets de données, PDN, pour l'équipement mobile UE ; et si un APN a déjà été obtenu, le premier équipement MME transmet le FQDN à une passerelle interne au réseau mobile 3GPP vers le réseau externe PDN. Corrélativement, l'équipement MME considéré est configuré pour effectuer ces étapes. Cette disposition permet de distribuer efficacement la résolution DNS entre la MME et la passerelle, généralement PDN-GW, selon par exemple que le serveur cible soit interne au réseau mobile 3GPP (pas d'APN émis pas l'UE) ou externe au réseau mobile 3GPP (APN émis pas l'UE pour indiquer le réseau PDN externe). Dans un mode de réalisation, la résolution du FQDN en une adresse IP est réalisée pendant une procédure d'activation, dans le réseau mobile, d'un contexte de protocole de données de paquet, PDP, entre l'équipement mobile UE et un noeud cible du réseau mobile, généralement l'APN formant point d'accès à un réseau de paquets de données externe. Corrélativement, l'équipement considéré est configuré pour résoudre le FQDN en une adresse IP pendant une procédure d'activation, dans le réseau mobile, d'un contexte de protocole de données de paquet, PDP, entre l'équipement mobile UE et un noeud cible du réseau mobile. Le contexte PDP indique une association logique entre l'UE et un réseau de paquets de données externe, type réseau public tel l'Internet ou privé, définissant un canal de communication dans l'infrastructure IP du réseau mobile. Ce contexte définit des aspects tels le routage, la qualité de service, la sécurité des communications. La procédure d'activation d'un contexte PDP dans un système EPS est connue sous l'appellation « Activation PDP Context request » dans les réseaux 3GPP type LTE. Ce mode de réalisation permet de n'accepter le contexte PDP qu'après résolution DNS, et donc après vérification de si l'adresse IP associée au FQDN existe bien et peut être atteinte. Cette configuration évite ainsi le gaspillage de ressources dans le réseau mobile, qui pourrait se produire si le serveur cible n'était pas atteignable. Dans une variante plus conforme au standard actuel, la résolution du FQDN en une adresse IP est réalisée postérieurement à une procédure d'activation, dans le réseau mobile, d'un contexte de protocole de données de paquet, PDP, entre l'équipement mobile UE et un noeud cible du réseau mobile, en réponse à la transmission, par l'équipement mobile UE, d'un paquet de données portant le FQDN comme adresse destinataire. Corrélativement, l'équipement considéré est configuré pour effectuer la résolution DNS dans ces conditions. Ainsi, la résolution DNS prend place après que le réseau mobile ait réservé un canal interne de communication IP (PDP context) entre l'équipement mobile requérant et un point de sortie vers par exemple un réseau externe de paquets de données. Dans le cadre de l'invention où la résolution DNS selon l'invention est déportée dans l'infrastructure même du réseau mobile sans intervention du terminal mobile ou de l'UICC, ces derniers sont amenés à transmettre des données sur la connexion IP alors établie, à l'aide du FQDN. Dans ce contexte, selon un mode de réalisation, il est prévu les 20 étapes suivantes, dans ledit premier équipement : recevoir, de l'équipement mobile UE, un paquet de données indiquant le FQDN comme destinataire dudit paquet de données, et substituer le FQDN en l'adresse IP résolue au sein du paquet de données avant retransmission du paquet de donnés à l'adresse IP résolue. 25 Corrélativement, l'équipement considéré est configuré pour effectuer ces étapes. Ainsi, que le rôle de premier équipement soit joué par la MME ou par la passerelle PDN-GW ou tout autre équipement, l'indication de l'adresse IP destinataire des paquets IP émis par le terminal mobile/l'UICC est effectuée par 30 ce premier équipement, et non pas par le terminal mobile/l'UICC comme cela est le cas dans les techniques classiques. Cette disposition assure la bonne transmission des paquets IP émis par le terminal mobile/l'UICC vers le serveur cible indiqué par le FQDN. Dans un autre mode de réalisation, le premier équipement envoie l'adresse IP résolue à l'équipement mobile UE. Cela permet à cet équipement et/ou au module sécurisé, UICC, d'utiliser directement l'adresse IP résolue selon les mécanismes déjà en vigueur dans les systèmes EPS ou pour les modules sécurisés (voir la norme ETSI TS 102 223 définissant les échanges ente l'UICC et l'UE). Comme évoqué précédemment, certains contextes d'usage nécessitent un niveau élevé de sécurité dans l'établissement de la connexion IP et dans les échanges de données qui s'en suivent. C'est le cas lorsque l'on fait appel à un module sécurisé, type UICC évoquée dans la norme ETSI TS 102 221. Une application cliente de l'UICC doit donc établir une connexion IP avec une application serveur distante. Dans ce mode de réalisation, avant de transmettre le FQDN au premier équipement, l'équipement mobile UE reçoit une requête d'activation d'un contexte de protocole de données de paquet, PDP, comprenant le FQDN et émise par un module sécurisé, l'UICC par exemple, inséré dans l'équipement mobile UE. En particulier, le module sécurisé est une carte de circuit intégré universelle, UICC, et la requête d'activation est une requête OPEN CHANNEL définie selon la norme ETSI TS 102 223. Le circuit ou module sécurisé est ainsi capable de requérir une session IP avec des serveurs en utilisant le protocole Bearer Independent de cette norme ETSI TS 102 223 v11. Selon une caractéristique particulière, la requête OPEN CHANNEL comprend au moins une donnée d'adresse et un octet de type d'adresse dans ladite donnée d'adresse qui prend une valeur particulière autre que '21' et '57' lorsque une adresse renseignée dans un champ de la donnée d'adresse est un FQDN. Cette disposition permet d'éviter l'introduction de modifications à la norme ETSI TS 102 220, en utilisant un nouveau code particulier pour le type d'adresse renseigné dans l'OPEN CHANNEL. En effet, jusqu'à présent, seuls les types '21' et '57' correspondant à des types d'adresses IP respectivement v4 et v6 étaient utilisés. Un autre aspect de l'invention vise un équipement mobile, UE, d'un réseau mobile, comprenant une carte de circuit intégré universelle, UICC ; l'UICC étant configurée pour envoyer, à un processeur de l'équipement mobile UE, une requête OPEN CHANNEL définie selon la norme ETSI TS 102 223, la requête OPEN CHANNEL comprenant au moins une donnée d'adresse et un octet de type d'adresse dans ladite donnée d'adresse qui prend une valeur particulière autre que '21' et '57' lorsque une adresse renseignée dans un champ de la donnée d'adresse est un nom de domaine complètement qualifié, FQDN ; l'UE étant configuré pour transmettre, sur le réseau mobile, des paquets de données incluant le FQDN comme adresse destinataire. En effet, dans le cadre des mécanismes évoqués de gestion DNS dans le coeur IP de réseau, un équipement mobile particulier à l'invention n'a désormais plus besoin de connaître, notamment à l'avance, l'adresse IP du serveur cible à atteindre et peut ainsi transmettre des données uniquement en faisant référence à un FQDN. Un autre aspect de l'invention vise un système comprenant une 20 infrastructure de réseau mobile comme définie ci-dessus et un équipement mobile, UE, comme défini ci-dessus, configuré pour émettre sur le réseau mobile un nom de domaine complètement qualifié, FQDN. BREVE DESCRIPTION DES FIGURES 25 D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - la Figure 1 illustre schématiquement un réseau mobile 3GPP auquel se connecte un équipement mobile utilisateur UE, et relié à deux 30 réseaux de paquets de données externes ; - la Figure 2 illustre des échanges de messages entre diverses entités de la Figure 1 lors de l'établissement d'une connexion IP entre un UE et un serveur cible OTA2 externe au réseau mobile postérieurement à une procédure d'activation d'un contexte PDP ; - la Figure 3 illustre des échanges de messages entre diverses entités de la Figure 1 lors de l'établissement d'une connexion IP entre un UE et 5 un serveur cible OTA2 externe au réseau mobile au cours d'une procédure d'activation d'un contexte PDP ; et - la Figure 4 illustre des échanges de messages entre diverses entités de la Figure 1 lors de l'établissement d'une connexion IP entre un UE et un serveur cible OTA3 interne au réseau mobile au cours d'une procédure 10 d'activation d'un contexte PDP. DESCRIPTION DETAILLEE DE L'INVENTION L'invention permet à une application cliente d'une UICC ou d'un terminal mobile utilisateur UE d'établir une connexion ou session IP avec une 15 application serveur distante à l'aide simplement d'un FQDN, au lieu d'une adresse IP fixe définie à l'avance dans les techniques classiques. Comme décrit par la suite, deux situations principales peuvent apparaitre : d'une part, lorsque le serveur cible hébergeant l'application serveur souhaitée fait partie intégrante du réseau mobile, et d'autre part, lorsque le 20 serveur cible est externe au réseau mobile. Dans le premier cas, où le serveur cible est donc un noeud interne à l'infrastructure réseau de l'opérateur mobile détenant le réseau mobile, l'UE, et de préférence l'UICC, fournit une adresse de type FQDN. La réception d'un tel type d'adresse déclenche, au sein du réseau mobile, une résolution interne 25 DNS pour obtenir une adresse IP correspondant au FQDN reçu. Dans le second cas, où le serveur cible est donc un noeud externe au réseau mobile, l'UE, et de préférence l'UICC, fournit également une adresse de type FQDN. Un nom de point d'accès, APN, est obtenu dans le réseau (par exemple par défaut depuis un serveur ou fourni par l'UE). L'APN renseigne du 30 point d'accès dans le réseau mobile à un réseau IP externe, PDN (pour Packet Data Network), dans lequel le serveur cible est localisé. De façon classique, l'obtention de l'APN déclenche, au sein du réseau mobile, une résolution interne de type DNS pour déterminer des noeuds internes permettant l'accès au réseau externe PDN. Il s'agit par exemple d'une procédure de découverte et de sélection de passerelles SGW et PDN-GW comme définie dans la norme 3GPP TS 29 303 pour un réseau mobile 3GPP de type EPS. En outre, la réception du FQDN déclenche, au sein du réseau mobile et en particulier dans la passerelle PDN-GW dans le cas d'un réseau de type EPS, une résolution DNS pour obtenir une adresse IP correspondant au FQDN reçu. Comme on le verra pas la suite, cette résolution DNS peut comprendre l'envoi de requêtes DNS externes vers un serveur DNS du réseau PDN externe. L'adresse IP alors obtenue par résolution est utilisée dans l'établissement et la conduite d'une session/connexion IP avec le serveur cible. L'équipement du réseau mobile ayant résolu le FQDN peut notamment effectuer une procédure d'établissement d'une connexion IP avec le serveur cible, à l'aide de l'adresse IP résolue. On voit donc que, selon l'invention, la réception d'une adresse de type FQDN par un équipement de l'infrastructure mobile a pour fonction de 20 déclencher une résolution DNS dans le réseau mobile par cet équipement. La Figure 1 illustre schématiquement un réseau mobile 3GPP 100 auquel se connecte un équipement mobile utilisateur UE, et relié à deux réseaux de paquets de données, PDN, externes PDN1 et PDN2. Dans l'exemple de la figure, le réseau externe PDN1 est un réseau 25 IP public, type l'Internet ; le réseau externe PDN2 est un réseau IP privé permettant l'accès à des serveurs et services de ce réseau privé. Le réseau mobile 3GPP 100 est au moins partiellement de type IP. Le système de réseau mobile 3GPP de type EPS est entièrement IP, alors que le système de réseau mobile 3GPP pour la 2G (e.g. GPRS) et la 3G (e.g. 30 UMTS) sont partiellement IP, incluant uniquement un coeur IP (coeur GPRS) au milieu d'un réseau commuté. Bien que l'invention s'applique à n'importe quel type de réseau mobile 3GPP au moins partiellement de type IP, les explications ci-dessous font essentiellement référence au système EPS entièrement IP, c'est-à-dire à la norme LTE récente. L'application des enseignements de l'invention comme décrit par la suite, aux autres types de réseau mobile 3GPP requière la transposition des fonctions évoquées en lien avec l'EPS en des fonctions similaires dans ces autres types de réseau mobile 3GPP. Par exemple, les extensions des fonctions de résolution DNS 10 internes au réseau EPS seront également apportées aux fonctions de résolution DNS internes à ces autres types de réseau mobile 3GPP. La conduite d'une résolution DNS par la MME ou le PDN-GW du système EPS sera prévue de façon similaire dans les équipements jouant des rôles identiques au sein des autres types de réseau mobile 3GPP, par exemple 15 le SGSN (Serving GPRS Support Node) en lieu et place de la MME ou le GGSN (Gateway GPRS Support Node) en lieu et place de la PDN-GW. De retour à la Figure 1, le réseau mobile 3GPP 100 inclut également un sous-réseau de paquets de données interne, PDN3. Ce réseau PDN3 est spécifique à l'opérateur télécom du réseau mobile 3GPP 100 de sorte à fournir 20 des services particuliers, par exemple de gestion OTA. Le réseau mobile 3GPP 100 comprend des stations de base, BS, ou des noeuds B évolués, eNB pour evolved Node B, auxquels des équipements mobiles utilisateurs, UE, se connectent par liaison radio. Les UE sont par exemple des téléphones mobiles. 25 Le réseau mobile 3GPP 100 comprend également une ou plusieurs entités de gestion de mobilité, MME pour Mobility Management Entity. Chaque MME joue un rôle clé dans la gestion classique du réseau 100. D'une part, elle conduit les procédures de rattachement d'un UE au réseau mobile 100, notamment à l'aide de procédures d'authentification et 30 d'autorisation. Cette procédure de rattachement est connue sous l'appellation d'« attach request/response ». D'autre part, elle reçoit les requêtes d'activation d'un contexte PDP (« activation PDP context request ») émise par les UE, et conduit ces activations. Pour ce faire, elle conduit les procédures de découverte et de sélection des passerelles selon les paramètres 3GPP et/ou définis par l'opérateur télécom. De plus, elle peut agir comme résolveur DNS (DNS Resolver) dans le cas où l'UE indique une information restrictive de sélection dans sa requête d'activation. Dans ce cas, la MME crée un FQDN à partir de l'information restrictive de sélection, par exemple un APN particulier (chaine de caractères contenant une référence à un PDN ou à un noeud interne auquel l'utilisateur souhaite accéder) ou un groupe de composants dans le réseau 100. La constitution du FQDN suit des règles particulières à la norme 3GPP, par exemple décrite dans la spécification TS 29 303. Le FQDN ainsi obtenu est utilisé dans les procédures de découverte et de sélection des passerelles. La fonction DNS Resolver n'est utilisée par la MME qu'à l'activation d'un contexte PDP par exemple lorsqu'un nouvel UE accède au réseau, ou lors d'une mobilité géographique (handover) ou lorsqu'un nouveau contexte PDP est sollicité par l'UE qui souhaite plusieurs accès simultanés à plusieurs réseaux PDN. Certains modes de réalisation de l'invention prévoient d'étendre ces fonctionnalités classiques. Selon l'invention, la MME est capable de recevoir un FQDN émis par l'UE et de le traiter comme suit, dans le cas où ce FQDN correspond à un noeud interne au réseau 100, c'est-à-dire à OTA3 du PDN3 montré sur la Figure 1. Cette situation se produit généralement lorsque l'UE n'envoie aucun APN et qu'un APN par défaut doit être utilisé. Le traitement du FQDN reçu par la MME est principalement le déclenchement de la résolution DNS dudit FQDN en une adresse IP. Cela permet d'obtenir l'adresse IP du noeud cible interne, c'est-à-dire de OTA3. Cette 30 résolution DNS peut mettre en oeuvre des mécanismes classiques de résolution DNS. Selon les réalisations équivalentes, ces mécanismes de résolution DNS sont prévus à l'intérieur même de la MME, ou sont ajoutés à des mécanismes DNS internes au réseau mobile 100 et distincts de la MME, auquel cas la MME effectue des requêtes auprès de ces mécanismes DNS internes. Le cas échéant, la MME peut renvoyer l'adresse IP obtenue à l'UE. De préférence, c'est la MME qui effectuera la conversion de paquets de données ultérieurement reçus de UE et portant le FQDN comme adresse destinataire, en paquets portant l'adresse IP résolue comme adresse destinataire. Dans le cas inverse (le FQDN ne correspond pas à un noeud interne à 100), la MME est configuré pour transmettre cette information, FQDN, à une passerelle effectivement sélectionnée par les procédures idoines basées sur I'APN transmis par l'UE. La MME se comporte ensuite comme un élément de routage dans le contexte PDP établi entre l'UE et la passerelle sélectionnée. Le réseau mobile 3GPP 100 comprend également un serveur HSS (Home Subscriber Server) détenant, sous forme d'enregistrements, l'ensemble des informations relatives aux abonnés du réseau 100. Ainsi, c'est en étroite collaboration avec le serveur HSS que la MME mène la procédure de rattachement et celle d'activation du contexte PDP pour un UE donné. En effet, l'HSS contient les informations d'authentification et d'autorisation (droits) des utilisateurs, mais également certains paramètres par défaut, tel qu'un APN par défaut à utiliser par la MME pour les procédures de découverte et de sélection si l'UE n'en mentionne pas. Cet APN par défaut peut désigner un sous-réseau interne au réseau mobile G3PP ou un réseau PDN externe à celui-ci. Le réseau mobile 3GPP 100 comprend également une passerelle X- GW vers PDN3, des passerelles SGW prévues pour router les paquets de donnée vers les réseaux PDN et des passerelles PDN-GW constituant les portes de sortie du réseau mobile 3GPP 100 vers les réseaux externes PDN1 et PDN2. Un UE peut disposer de connectivités simultanées avec plusieurs passerelles PDN-GW pour accéder à de multiples PDN externes. Certains modes de réalisation de l'invention prévoient d'étendre les fonctionnalités classiques du PDN-GW à la gestion d'un FQDN émis par un UE et routé par la MME. Il s'agit d'une situation où le FQDN émis correspond à un noeud externe au réseau 100, en particulier à un noeud appartenant au réseau externe PDN relié au PDN-GW sélectionné par la MME sur la base d'un APN indiqué par l'UE. Le traitement du FQDN par ce PDN-GW consiste principalement en le déclenchement de la résolution DNS dudit FQDN en une adresse IP. Cela permet d'obtenir l'adresse IP du noeud cible sur le réseau PDN externe, par exemple l'OTA2 du PDN2. Cette résolution DNS peut mettre en oeuvre des mécanismes 10 classiques de résolution DNS au sein du réseau externe PDN2, à savoir que le PDN-GW possède un client DNS capable d'émettre des requêtes DNS vers un serveur DNS de PDN2. En variante, si le PDN-GW n'est pas autorisé à émettre des requêtes sur PDN2, il sollicite un autre équipement interne au réseau 100, par exemple 15 un serveur DNS interne, lui autorisé à communiquer sur le réseau PDN2. Cet autre équipement interne réalise alors, pour le compte du PDN-GW, la procédure de résolution DNS auprès du serveur DNS de PDN2 avant de retourner l'adresse IP résolue. Comme montré sur la figure, l'équipement mobile utilisateur UE 20 comprend un équipement mobile, ME (pour Mobile Equipment), et une UICC conforme à la norme ETSI TS 102 221. Le ME et l'UICC communiquent entre eux selon le protocole BIP (Bearer Independent Protocol) défini par la norme ETSI TS 102 223. On décrit maintenant en référence à la Figure 2 un premier mode de 25 réalisation de l'invention. La Figure 2 illustre des échanges de messages entre diverses entités de la Figure 1 lors de l'établissement d'une connexion IP entre un UE et un serveur cible OTA2 externe au réseau mobile 3GPP postérieurement à une procédure d'activation d'un contexte PDP. Le processus de la Figure 2 démarre au niveau de l'UICC qui initie 30 l'établissement d'une connexion IP avec le serveur cible OTA2. En pratique, il s'agit d'une application dans l'UICC qui souhaite accéder à une application ou service du serveur cible OTA2. Pour ce faire, l'UICC dispose, en mémoire, d'une adresse de type FQDN désignant, sous forme de chaine de caractères, l'application ou service souhaité, par exemple « ota2.OT.com ». En outre, l'UICC peut disposer, également en mémoire, d'une information de point d'accès APN notamment si le serveur cible OTA2 est localisé dans un réseau PDN2 externe, ici « OT.com », ou à tout le moins différent du réseau PDN défini par défaut dans le HSS. L'APN est également une chaîne de caractères qui contient une référence au réseau PDN2 dans lequel l'application/service souhaité est disponible. Dans l'exemple correspondant à la Figure 2, l'APN vaut, de façon simplifiée, « OT.com » ou « PDN2 ». Le format exact de l'APN est indiqué dans la norme 3GPP TS 23 003. La première étape 200 consiste pour l'UICC à requérir auprès du ME l'établissement d'une connexion IP vers le serveur cible OTA2. Pour ce faire, il établit une connexion locale IP avec le ME (voir la norme ETSI TS 102 483) et lui fournit, via cette connexion locale, les paramètres nécessaires à l'activation d'un service de paquets de données. Par exemple, l'UICC envoie une commande proactive OPEN CHANNEL conforme au protocole BIP (ETSI TS 102 223 v11) pour requérir du ME l'activation d'un contexte PDP sur le réseau mobile 3GPP 100. La commande OPEN CHANNEL comprend notamment le FQDN cible, l'APN cible (si nécessaire) et l'adresse locale IP de l'UICC. Notamment l'APN cible peut ne pas être transmis s'il correspond à l'APN par défaut mémorisé dans le HSS. Le format de cette commande OPEN CHANNEL est fourni en section 25 6.6.27.1 de la norme susvisée, et comprend une donnée d'adresse locale et une donnée d'adresse destinataire. Pour rendre la commande OPEN CHANNEL compatible avec l'utilisation d'adresses de type FQDN (la norme ne définit que des adresses de type IPv4 et IPv6 pour la commande OPEN CHANNEL), un code de type 30 d'adresse actuellement réservé est affecté au type FQDN d'adresse, par exemple le code 'F0'. Le format des adresses pour la commande OPEN CHANNEL, en particulier pour la donnée d'adresse destinataire devant recevoir le FQDN, est défini ci-dessous, à partir de sa définition dans la norme TS 102 223 (§ 8.58) : Octet(s) Description Length 1 1 Marqueur d'adresse 2 Longueur (X) 1 3 Type d'adresse 1 4 à (X+2) Adresse X-1 Format d'adresse pour la commande OPEN CHANNEL Le champ type d'adresse prend la valeur '21' lorsque l'adresse renseignée est de type IPv4, la valeur '57' lorsque l'adresse renseignée est de type IPv6 et donc le code nouvellement affecté 'F0' lorsque l'adresse renseignée est de type FQDN. La longueur (X) vaut entre 0 et 28-1, permettant de renseigner des FQDN sur 28 octets, soit 256 caractères ASCII ce qui est généralement suffisant. Dans une variante de réalisation, la commande OPEN CHANNEL classique est utilisée sans l'adaptation ci-dessus et ce sont les commandes SEND DATA (voir ci-dessous) qui sont modifiées pour y inclure une adresse destinataire comme indiqué ci-dessus. En effet, dans le présent mode de réalisation de la Figure 2 comme décrit ci-après, l'adresse destinataire de type FQDN n'est utilisée sur le réseau mobile 100 qu'à compter de la transmission de données suite à une commande SEND DATA de l'UICC. Dans cette variante, la commande OPEN CHANNEL peut n'inclure que l'APN (s'il y en a un), le champ d'adresse de destination étant laissé vide. A réception de la requête OPEN CHANNEL, le ME déclenche une procédure de rattachement au réseau mobile 3GPP. De façon classique, cette procédure comprend l'envoi 202 d'une requête « Attach Request » par le terminal utilisateur UE. Cette requête est traitée 204 par la MME qui récupère des informations de souscription associées à l'utilisateur dans le HSS (incluant le APN par défaut) puis réalise des procédures d'authentification/autorisation sur la base de ces informations avant d'accepter 206 le rattachement « Attach Accept ». Dans le réseau mobile de paquet de données 3GPP 100, une connexion PDN est toujours établie lorsque le terminal UE se rattache au réseau. Pour ce faire, le terminal UE, et plus précisément le ME, émet 208, tout de suite après la procédure de rattachement, une nouvelle requête « Activate PDP context Request » au réseau 100. Cette requête comprend éventuellement un APN, celui renseigné dans la commande OPEN CHANNEL générée par l'UICC ou celui par défaut récupéré auprès du HSS. Cette requête est traitée 210 de façon classique par la MME du réseau 100. Il s'agit pour la MME de réaliser les procédures de découverte et de sélection telles que définies dans la norme 3GPP TS 29 303. Ces procédures s'appuient sur la fonction DNS Resolver de la MME 15 en utilisant l'APN inclus dans la requête « Activate PDP context Request » ou l'APN par défaut récupéré du HSS. Elles permettent de sélectionner le PDN2 souhaité par l'utilisateur, ainsi que les noeuds internes à 100 pour permettre l'accès au PDN, à savoir notamment les passerelles SGW2 et PDN-GW2 appropriées. 20 En pratique, la MME construit une requête DNS sur la base de l'APN. Cette requête permet d'obtenir une liste de noeuds internes candidats correspondant à l'accès au PDN souhaité. De cette liste, la MME sélectionne les noeuds appropriés (SGW et PDN-GW). Cette sélection peut reposer sur plusieurs critères, par exemple en fonction des conditions réseau telles que la 25 charge relative entre les différents noeuds internes possibles, la localisation géographique des entités du réseau en tenant compte des noeuds co-localisés, ou encore la proximité topologique des noeuds entre eux. L'ensemble des noeuds internes définissant le contexte PDP ayant été sélectionné, la MME active le contexte PDP pour l'UE, c'est-à-dire le canal 30 de communication entre l'UE et le point de sortie (PDN-GW2) vers le PDN2 souhaité, en envoyant 212 une acceptation « Activate PDP context Accept » au ME. A noter que plusieurs contextes PDP peuvent être activés par la MME pour un même UE, et plus particulièrement un même ME, qui souhaite accéder à plusieurs PDN de façon simultanée. Pour identifier séparément chacun des contextes PDP, un identifiant leur est affecté qui est mémorisé, par la MME, en association avec l'adresse IP du ME pour la MME. Ces informations permettront en effet de router des messages de réponse vers le ME ad hoc en fonction des adresses IP. A réception de l'activation du contexte PDP, le ME répond 214 à la commande OPEN CHANNEL par un message TERMINAL RESPONSE à 10 destination de l'UICC. Un même message peut être retourné indiquant si la commande OPEN CHANNEL n'a pas été exécutée avec succès. Puis, I'UICC émet 216 des premiers paquets de données à l'aide de la fonction SEND DATA également décrite dans la norme ETSI TS 102 223, via la connexion locale IP entre I'UICC et le ME. 15 Le ME émet 218 ces paquets de données dans le contexte PDP activé, en y incluant le FQDN (obtenu par la commande OPEN CHANNEL et associé à la connexion utilisée entre l'UICC et le ME) comme adresse destinataire, et l'adresse IP du terminal UE comme adresse source. Le premier paquet de données atteint la passerelle PDN-GW2 20 sélectionnée à l'étape 210. La détection de l'adresse FQDN comme adresse destinataire par PDN-GW2 déclenche 220 une procédure de résolution DNS de cette adresse FQDN en une adresse IP. La passerelle PDN-GW2 récupère ainsi l'adresse IP fixe du serveur cible OTA2, par exemple 64.134.242.212. 25 Tout d'abord, partant du FQDN présent dans le paquet reçu, la passerelle PDN-GW2 vérifie si elle ne dispose pas déja en mémoire de l'adresse IP associée au FQDN. En effet, PDN-GW2 peut mémoriser dans une mémoire temporaire les résolutions DNS antérieures. Si ce n'est pas le cas, la passerelle PDN-GW2 sollicite une résolution 30 DNS. Dans un mode de réalisation, la passerelle PDN-GW2 possède un client DNS sur le réseau externe PDN2 apte à solliciter un serveur externe DNS du réseau externe PDN2. PDN-GW2 envoie 222 donc une requête DNS au serveur externe 5 DNS, aux fins de résolution de l'adresse FQDN. En réponse, PDN-GW2 reçoit 224 l'adresse IP résolue, c'est-à-dire l'adresse IP fixe de OTA2. PDN-GW2 mémorise cette adresse IP dans sa mémoire interne temporaire. En variante, PDN-GW2 peut ne pas être autorisée, selon les paramètres du réseau 100, à solliciter des noeuds du réseau externe PDN2. 10 Dans ce cas, PDN-GW2 peut solliciter un serveur DNS interne au réseau 3GPP 100 en lui demandant de résoudre l'adresse FQDN pour son compte. Ce serveur DNS interne est autorisé à solliciter le serveur externe DNS au travers des messages 222 et 224 ci-dessus. Dans un mode de réalisation, la passerelle PDN-GW2 peut renvoyer 15 l'adresse IP résolue correspondant au FQDN à l'UE ou l'UICC si ce dernier l'a demandé. Une fois l'adresse IP fixe de OTA2 obtenue, PDN-GW2 émet 228 le ou les paquets de données en provenance de UE sur le réseau externe PDN2 en ayant au préalable inséré l'adresse IP fixe de OTA2 comme adresse 20 destinataire de ces paquets. En d'autres termes, PDN-GW2 substitue 226 l'adresse FQDN destinataire par l'adresse IP fixe obtenue. Grâce aux adresses IP et aux identifiants des contextes PDP, les messages et autres paquets de données réponses envoyés 230 par le serveur 25 cible OTA2 sont routés vers UE puis vers UICC. Le mode de réalisation de la Figure 2 permet ainsi à l'UICC d'établir une connexion IP avec le serveur cible OTA2, en limitant l'impact de l'invention à une légère adaptation de la commande OPEN CHANNEL et à une adaptation de certains noeuds internes au réseau mobile 3GPP pour qu'ils déclenchent 30 une résolution DNS à réception d'une adresse de type FQDN émise par l'UE. L'UICC peut ainsi accéder à un service/application hébergé par OTA2. La Figure 3 illustre des échanges de messages entre diverses entités de la Figure 1 lors de l'établissement d'une connexion IP entre un UE et un serveur cible OTA2 externe au réseau mobile 3GPP au cours d'une procédure d'activation d'un contexte PDP. Cette variante prévoit d'effectuer la résolution DNS de l'adresse FQDN pendant la procédure d'activation du contexte PDP. L'activation du contexte PDP n'est ainsi acceptée que lorsque l'adresse IP est résolue, ce qui permet de conclure à l'accessibilité et à la disponibilité du serveur cible souhaité. Cette variante évite ainsi le gaspillage de ressources du réseau, incluant l'activation d'un contexte PDP pour rien en cas d'absence de résolution DNS. Les étapes 200 à 208 sont identiques à celles portant même référence dans la Figure 2, aboutissant à la requête d'activation d'un contexte PDP pour l'UE. C'est lors du traitement de cette requête que la résolution DNS du FQDN a lieu. Ainsi l'étape 310 de traitement de cette requête par le réseau mobile 3GPP 100 est différente de l'étape 210. Notamment, après l'envoi 208 de la requête « Activate PDP context 20 Request », l'UE transmet 311 également à la MME, dans un message particulier, l'adresse FQDN du serveur cible telle qu'il l'a reçue de l'UICC. Un acquittement du message 311 par la MME peut être prévu le cas échéant. En variante au message 311, l'adresse FQDN peut être insérée dans la requête « Activate PDP context Request », par exemple en concaténant 25 l'APN (s'il y en a un) avec l'adresse FQDN, éventuellement à l'aide de délimiteurs permettant à la MME de récupérer les deux informations. L'étape 310 comprend une sous-étape 210 similaire à l'étape 210 de la Figure 2 consistant, pour la MME, à découvrir et sélectionner les noeuds internes à 100 satisfaisant l'APN indiqué dans la requête ou l'APN par défaut, 30 ainsi qu'une sous-étape 312 consistant pour la MME à transmettre, par message, l'adresse FQDN reçue à la passerelle PDN-GW sélectionnée, une sous-étape 220 similaire à l'étape 220 de la Figure 2 consistant, pour le PDN- GW2, à effectuer une résolution DNS de l'adresse FQDN, et une sous-étape 314 consistant pour le PDN-GW2 à informer la MME du succès ou non de la résolution DNS de l'adresse FQDN en une adresse IP. La sous-étape 220 comprend les transmissions 222 et 224 explicitées plus haut. La sous-étape 314 peut également inclure la transmission de l'adresse IP résolue à la MME. Ce n'est qu'après avoir été informé du succès de la résolution DNS, que la MME accepte 212 l'activation du contexte PDP. Les étapes 214, 216, 218, 226, 228 et 230 sont identiques à celles portant même référence dans la Figure 2 : notamment, le PDN-GW2 est en charge de substituer 226 l'adresse FQDN par l'adresse IP de OTA2 dans les paquets de données transmis par l'UE à destination de OTA2. La Figure 4 illustre des échanges de messages entre diverses entités de la Figure 1 lors de l'établissement d'une connexion IP entre un UE et un serveur cible OTA3 interne au réseau mobile 3GPP au cours d'une procédure d'activation d'un contexte PDP. Les étapes 200 à 208 sont identiques à celles portant même référence dans la Figure 2, aboutissant à la requête d'activation d'un contexte PDP pour l'UE. Toutefois, comme le serveur cible OTA3 souhaité est interne au réseau 3GPP 100, l'UICC renseigne un APN correspondant au réseau interne PDN3 en plus de l'adresse FQDN ou ne renseigne qu'une adresse FQDN, mais aucun APN, dans la commande OPEN CHANNEL. Cette dernière situation, la plus courante en pratique, repose sur le fait que l'APN par défaut mémorisé dans le HSS est celui correspondant au réseau interne PDN3. La requête « Activate PDP context Request » n'inclut donc généralement aucun APN également. De façon similaire à la Figure 3, l'étape 311 consiste en l'envoi du 30 FQDN par l'UE sur le réseau mobile 3GPP (à destination de la MME). En variante, le FQDN peut être indiqué dans le champ de l'APN au sein de la requête susvisée, à l'aide de délimiteurs particuliers permettant à la MME de savoir qu'il s'agit d'un FQDN et non d'un APN. Si aucun APN n'est transmis à la MME, ce dernier obtient l'APN par défaut du HSS. Sinon il obtient l'APN transmis dans la requête. Si l'APN obtenu est relatif au réseau interne PDN3, la MME est en charge du traitement du FQDN reçu. Selon l'invention, l'obtention du FQDN déclenche, sur la MME, la résolution DNS de ce FQDN en une adresse IP correspondant au serveur cible OTA3. Ainsi, l'étape 410 de traitement de la requête « Activate PDP context 10 Request » et du FQDN reçu à l'étape 311 comprend une sous-étape 210 similaire à l'étape 210 de la Figure 2 consistant, pour la MME, à découvrir et sélectionner les noeuds internes à 100 satisfaisant l'APN obtenu (référençant PDN3), ainsi qu'une sous-étape 412 consistant pour la MME à effectuer une résolution DNS de l'adresse FQDN reçue. 15 La sous-étape 412 de résolution DNS consiste tout d'abord, pour la MME, à vérifier si elle ne dispose pas déjà en mémoire de l'adresse IP associée au FQDN. En effet, la MME peut mémoriser dans une mémoire temporaire les résolutions DNS antérieures. Si ce n'est pas le cas, la MME sollicite une résolution DNS auprès 20 d'un serveur DNS interne au réseau mobile 3GPP (éventuellement mise en oeuvre au sein même de la MME). On prévoit ainsi que les fonctionnalités d'un serveur DNS interne au réseau mobile 3GPP soient étendues à la résolution DNS pour tout noeud interne à ce réseau et non plus uniquement à tout passerelle ou noeud fonctionnel de l'architecture réseau. 25 L'étape 412 peut donc comprendre l'envoi d'une requête DNS auprès de ce serveur interne et la réception d'une réponse DNS comprenant l'adresse IP de l'OTA3. A réception de cette adresse, la MME la mémorise en mémoire interne temporaire. 30 Dans un mode de réalisation, la MME peut renvoyer l'adresse IP résolue correspondant au FQDN à l'UE ou l'UICC si ce dernier l'a demandé. Les étapes suivantes 212, 214, 216, 218, 226, 228 et 230 sont identiques à celles portant même référence dans la Figure 2 : notamment le MME est en charge de substituer 226 l'adresse FQDN par l'adresse IP de OTA3 dans les paquets de données transmis par l'UE à destination de OTA3. Dans ces divers modes de réalisation des Figures 2, 3 et 4, une connexion IP est donc établie entre l'UE et l'OTA cible, notamment constituée en partie dans le contexte PDP activé dans le réseau mobile 3GPP entre l'UE et le MME et en partie par un lien IP entre cette MME et l'OTA cible. Pour permettre l'accès de l'UICC à la fois à un serveur cible interne 10 OTA3 et à un serveur cible externe OTA2, le mode de réalisation de la Figure 4 peut être combiné à l'un ou l'autre de ceux des Figures 2 et 3. Le réseau mobile 3GPP 100 comprend ainsi à la fois une MME et une ou plusieurs passerelles PDN-GW configurées pour déclencher une résolution DNS à réception d'une adresse FQDN. 15 En combinant les Figures 3 et 4, la MME peut comprendre une logique permettant de traiter les deux cas : Si la requête « Activate PDP context Request » n'inclut pas d'APN et qu'une adresse FQDN est reçue de l'UICC/UE (étape 311), alors la MME résout elle-même l'adresse FQDN en adresse IP (Figure 4). Cela est le cas le plus 20 courant où l'APN par défaut dans le HSS correspond à un réseau interne au réseau mobile 3GPP. D'une façon plus générale, la résolution de l'adresse FQDN par la MME est déclenchée lorsque cette dernière détermine que l'APN pour l'UE en question est un APN pour un réseau local au réseau mobile 100 ; Sinon, la MME résout seulement l'APN obtenu (découverte et 25 sélection de passerelles), transmet le FQDN à la passerelle sélectionnée, cette dernière résolvant l'adresse FQDN en adresse IP (Figure 3). Les fonctions décrites ci-dessus pour les diverses entités de l'infrastructure de réseau mobile 3GPP ainsi que pour l'UE et les réseaux externes PDN sont préférentiellement mises en oeuvre sous forme logicielle au 30 sein d'équipements matériels correspondants. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. REVENDICATIONS1. Procédé d'établissement d'une connexion IP au travers d'un réseau mobile (100), comprenant les étapes suivantes, sur un premier 5 équipement (MME, PDN-GW) du réseau mobile autre qu'un équipement mobile UE du réseau mobile : recevoir (218, 311) un nom de domaine complètement qualifié, FQDN, émis par un équipement mobile UE dudit réseau mobile, le FQDN identifiant un serveur de données cible (OTA1, OTA2, OTA3); et 10 déclencher (220, 412), à réception du FQDN, la résolution du FQDN en une adresse IP du serveur de données cible. 2. Procédé selon la revendication 1, comprenant en outre les étapes suivantes : obtenir (202), un nom de point d'accès, APN, identifiant un réseau 15 externe de paquets de données, PDN pour l'équipement mobile UE ; et sélectionner (210), par un autre équipement (MME) du réseau mobile (100) autre que l'équipement mobile UE, au moins une passerelle (PDN-GW) du réseau mobile vers le réseau externe PDN, par procédure de découverte et de sélection à partir de l'APN obtenu ; 20 procédé dans lequel le premier équipement est ladite passerelle sélectionnée. 3. Procédé selon la revendication 2, dans lequel le réseau mobile est un réseau mobile 3GPP au moins partiellement de type IP, le premier équipement est une passerelle PDN-GW du réseau mobile 3GPP vers le réseau externe PDN, l'autre équipement est une entité de gestion de mobilité, 25 MME, du réseau mobile 3GPP et le serveur de données cible est un noeud externe au réseau mobile 3GPP appartenant au réseau externe PDN. 4. Procédé selon la revendication 2 ou 3, dans lequel, pour résoudre le FQDN en une adresse IP, le premier équipement formant passerelle vers le réseau externe PDN envoie (222) une requête de résolution 30 DNS à un serveur DNS externe appartenant au réseau externe PDN. 5. Procédé selon la revendication 1, dans lequel le réseau mobile est un réseau mobile 3GPP au moins partiellement de type IP, le premieréquipement est une entité de gestion de mobilité, MME, du réseau mobile 3GPP et le serveur de données cible est un noeud interne (OTA3) au réseau mobile 3GPP (100). 6. Procédé selon la revendication 5, dans lequel le déclenchement de la résolution du FQDN a lieu si le premier équipement MME n'a pas déjà obtenu un nom de point d'accès, APN, identifiant un réseau externe de paquets de données, PDN, pour l'équipement mobile UE ; et si un APN a déjà été obtenu, le premier équipement MME transmet le FQDN à une passerelle interne au réseau mobile 3GPP vers le 10 réseau externe PDN. 7. Procédé selon l'une des revendications 1 à 6, dans lequel la résolution (220, 412) du FQDN en une adresse IP est réalisée pendant une procédure d'activation (310, 410), dans le réseau mobile, d'un contexte de protocole de données de paquet, PDP, entre l'équipement mobile UE et un 15 noeud cible du réseau mobile. 8. Procédé selon l'une des revendications 1 à 6, dans lequel la résolution (220) du FQDN en une adresse IP est réalisée postérieurement à une procédure d'activation (210), dans le réseau mobile, d'un contexte de protocole de données de paquet, PDP, entre l'équipement mobile UE et un 20 noeud cible du réseau mobile, en réponse à la transmission, par l'équipement mobile UE, d'un paquet de données portant le FQDN comme adresse destinataire. 9. Procédé selon l'une des revendications 1 à 8, dans lequel, avant de transmettre (218, 311) le FQDN au premier équipement, l'équipement 25 mobile UE reçoit (200) une requête comprenant le FQDN et émise par un module sécurisé (UICC) inséré dans l'équipement mobile UE. 10. Procédé selon la revendication 9, dans lequel le module sécurisé est une carte de circuit intégré universelle, UICC, et la requête est une requête OPEN CHANNEL définie selon la norme ETSI TS 102 223. 30 11. Procédé selon la revendication 10, dans lequel la requête OPEN CHANNEL comprend au moins une donnée d'adresse et un octet de type d'adresse dans ladite donné d'adresse qui prend une valeur particulièreautre que '21' et '57' lorsque une adresse renseignée dans un champ de la donnée d'adresse est un FQDN. 12. Procédé selon l'une des revendications 1 à 11, comprenant en outre les étapes suivantes, dans ledit premier équipement : recevoir (218), de l'équipement mobile UE, un paquet de données indiquant le FQDN comme destinataire dudit paquet de données, et substituer (226) le FQDN en l'adresse IP résolue au sein du paquet de données avant retransmission du paquet de donnés à l'adresse IP résolue. 13. Procédé selon l'une des revendications 1 à 12, dans lequel le premier équipement envoie l'adresse IP résolue à l'équipement mobile UE. 14. Equipement (MME, PDN-GW) d'un réseau mobile (100), comprenant des moyens configurés pour: recevoir un nom de domaine complètement qualifié, FQDN, émis par un équipement mobile UE du réseau mobile, le FQDN identifiant un serveur de données cible; et déclencher, à réception du FQDN, la résolution du FQDN en une adresse IP du serveur de données cible. 15. Equipement de réseau mobile selon la revendication 14, de type passerelle PDN-GW d'un réseau mobile 3GPP vers le réseau externe 20 PDN, le serveur de données cible identifié par le FQDN étant un noeud externe au réseau mobile 3GPP appartenant au réseau externe PDN. 16. Equipement de réseau mobile selon la revendication 15, configuré pour résoudre le FQDN en une adresse IP par l'envoi d'une requête de résolution DNS à un serveur DNS externe appartenant au réseau externe 25 PDN. 17. Equipement de réseau mobile selon la revendication 14, de type entité de gestion de mobilité, MME, d'un réseau mobile 3GPP, le serveur de données cible identifié par le FQDN étant un noeud interne au réseau mobile 3GPP. 30 18. Equipement de réseau mobile selon la revendication 17, de type MME, configuré pour déclencher la résolution du FQDN si l'équipementMME n'a pas déjà obtenu un nom de point d'accès, APN, identifiant un réseau externe de paquets de données, PDN, pour l'équipement mobile UE, ; et si un APN a déjà été obtenu, pour transmettre le FQDN à une passerelle interne au réseau mobile 3GPP vers le réseau externe PDN. 19. Equipement de réseau mobile selon l'une des revendications 14 à 18, configuré pour résoudre le FQDN en une adresse IP pendant une procédure d'activation, dans le réseau mobile, d'un contexte de protocole de données de paquet, PDP, entre l'équipement mobile UE et un noeud cible du réseau mobile. 20. Equipement de réseau mobile selon l'une des revendications 14 à 18, configuré pour résoudre le FQDN en une adresse IP postérieurement à une procédure d'activation, dans le réseau mobile, d'un contexte de protocole de données de paquet, PDP, entre l'équipement mobile UE et un noeud cible du réseau mobile, en réponse à la transmission, par l'équipement mobile UE, d'un paquet de données portant le FQDN comme adresse destinataire. 21. Equipement de réseau mobile selon l'une des revendications 14 à 20, configuré pour effectuer les étapes suivantes : recevoir, de l'équipement mobile UE, un paquet de données indiquant le FQDN comme destinataire dudit paquet de données, et substituer le FQDN en l'adresse IP résolue au sein du paquet de données avant retransmission du paquet de donnés à l'adresse IP résolue. 22. Infrastructure (100) de réseau mobile, comprenant un équipement (MME) configuré pour : obtenir un nom de point d'accès, APN, identifiant un réseau externe 25 de paquets de données, PDN, pour un équipement mobile UE du réseau mobile ; et sélectionner au moins une passerelle du réseau mobile vers le réseau externe PDN, par procédure de découverte et de sélection à partir de l'APN obtenu, ladite passerelle étant un équipement selon l'une quelconque des 30 revendications 14 à 21, recevant un nom de domaine complètement qualifié, FQDN, émis par l'équipement mobile UE. 23. Infrastructure de réseau mobile selon la revendication 22, dans laquelle l'équipement configuré pour sélectionner au moins une passerelle est une entité de gestion de mobilité, MME, d'un réseau mobile 3GPP. 24. Equipement mobile, UE, d'un réseau mobile, comprenant une carte de circuit intégré universelle, UICC ; l'UICC étant configurée pour envoyer, à un processeur de l'équipement mobile UE, une requête OPEN CHANNEL définie selon la norme ETSI TS 102 223, la requête OPEN CHANNEL comprenant au moins une donnée d'adresse et un octet de type d'adresse dans ladite donnée d'adresse qui prend une valeur particulière autre que '21' et '57' lorsque une adresse renseignée dans un champ de la donnée d'adresse est un nom de domaine complètement qualifié, FQDN ; l'UE étant configuré pour transmettre, sur le réseau mobile, des paquets de données incluant le FQDN comme adresse destinataire. 25. Système comprenant une infrastructure de réseau mobile selon la revendication 22 ou 23 et un équipement mobile, UE, selon la revendication 24, configuré pour émettre sur le réseau mobile un nom de domaine complètement qualifié, FQDN.20