FR3014630A1 - Procede de test de qualite de service, module d'identite de souscripteur, terminal mobile et systeme correspondants - Google Patents

Abstract

L'invention concerne un procédé de test de la qualité de service d'un canal de communication entre un terminal mobile comprenant un module d'identité de souscripteur auprès d'un opérateur de réseau de téléphonie mobile, et un équipement distant d'un réseau cible. Un contexte de protocole d'échange de paquets de données, PDP, est activé dans ledit réseau de téléphonie mobile pour la communication entre le terminal mobile et l'équipement distant. Le procédé comporte les étapes suivantes, mises en œuvre par le module d'identité de souscripteur : envoi, (322) par le canal de communication mettant en œuvre le contexte PDP, de données de test à destination dudit équipement distant, réception (324) par le canal de communication, d'une réponse à l'envoi des données de test, et traitement (326) de ladite réponse, pour évaluer la qualité de service dudit canal de communication.

Description

DOMAINE DE L'INVENTION L'invention concerne le domaine des télécommunications. Elle est notamment relative à un procédé de test de la qualité de service d'un canal de communication entre un terminal mobile et un équipement distant, par un module d'identité de souscripteur à un réseau de téléphonie mobile, compris dans le terminal.

L'invention est également relative à un module d'identité de souscripteur, à un terminal mobile et à un système correspondant. CONTEXTE DE L'INVENTION Afin de permettre à un terminal mobile, tel qu'un téléphone portable, d'échanger des données avec un équipement distant d'un réseau cible, par exemple un serveur d'un réseau de données, un contexte de protocole d'échange de paquets de données, PDP, est activé au sein d'un réseau de téléphonie mobile auquel le terminal est accroché. L'activation de ce contexte PDP a pour effet d'ouvrir un canal de communication dans le réseau de téléphonie mobile, pour une communication (un échange de données) avec le réseau cible, selon un protocole de paquets de données. Pour ce faire, le terminal mobile peut envoyer une requête d'activation à un noeud cible, noté SGSN (pour Serving GPRS Support Node en anglais), du réseau de téléphonie mobile, typiquement de type GPRS (pour General Packet Radio Service en anglais). L'envoi de cette requête peut être initié par une demande d'ouverture d'un canal de communication vers le réseau cible, envoyée par un module d'identité de souscripteur à un réseau de téléphonie mobile (e.g. carte SIM ou UICC ou AIM), par exemple incorporé dans le terminal mobile. L'activation d'un contexte PDP peut également se faire à l'initiative de l'équipement distant, sur requête de celui-ci au noeud SGSN du réseau de téléphonie mobile précité. Le contexte PDP permet notamment de rendre le terminal mobile visible par le réseau cible hébergeant l'équipement distant, en associant au terminal mobile une adresse reconnue par ce réseau cible, généralement une adresse IP (pour Internet Protocol en anglais) par exemple lorsque le réseau cible est un réseau IP, ou encore X.121 dans le cas où le réseau cible est de type X.25. Ce réseau cible peut être externe au réseau de téléphonie mobile auquel le terminal mobile est attaché. C'est par exemple le cas du réseau Internet. Dans certaines configurations, ce réseau cible peut être un sous-réseau de données dans le réseau de téléphonie mobile, par exemple géré par l'opérateur du réseau de téléphonie mobile. Le contexte PDP contient notamment des informations de qualité de service (QoS). Ces informations correspondent à la qualité de service négociée par le terminal mobile (ou l'équipement distant) lors de l'activation du contexte PDP, en vue d'établir une connexion avec le réseau cible. Le contexte PDP comprend aussi généralement des informations de routage ayant conduit, lors de son activation, par exemple à la sélection d'une passerelle (GGSN pour Gateway GPRS Support Node en anglais) vers ce réseau cible, notamment lorsque celui-ci est externe au réseau de téléphonie mobile. Quel que soit le réseau cible auquel se connecte le terminal mobile, le contexte PDP permet de caractériser cette connexion. Un terminal mobile peut d'ailleurs avoir activé plusieurs contextes PDP en parallèle (de même qu'un équipement distant peut avoir activé plusieurs contexte PDP), en vue typiquement d'ouvrir plusieurs sessions simultanées avec des réseaux cibles différents ou avec des niveaux de qualité de service différents. Ainsi, le contexte PDP indique une association logique entre le terminal mobile et des noeuds du réseau de téléphonie mobile (SGSN et/ou GGSN), définissant ainsi un canal de communication dans l'infrastructure du réseau de téléphonie mobile vers le réseau cible. Un identifiant PDP est attribué au contexte pour identifier les données (paquets de données) qui sont échangées dans ce contexte PDP, et ainsi les router de façon efficace. On s'intéresse par la suite au cas où l'activation du contexte PDP se produit à l'initiative du terminal mobile. Une fois le contexte PDP activé, le terminal mobile informe le module d'identité de souscripteur de l'ouverture du canal de communication vers le réseau cible.

Toutefois, l'activation du contexte PDP ne garantit pas la possibilité d'échanger des données avec succès sur le canal de communication ainsi défini. De plus, l'activation d'un contexte PDP avec une qualité de service demandée ne garantit pas que la qualité de service effectivement disponible sur le canal de communication soit conforme à la qualité de service demandée.

Un terminal mobile peut ainsi être amené à tester la qualité de service du canal de communication ainsi ouvert. Il est cependant difficile de transmettre de telles informations sur la qualité de service depuis le terminal mobile vers le module d'identité de souscripteur en respectant les interfaces de communication normalisées. Par exemple, les commandes définies dans la norme ETSI TS 102.223 ne permettent pas de transmettre ces informations au module d'identité de souscripteur. La transmission de telles informations de qualité de service au module d'identité de souscripteur nécessite donc une adaptation du terminal, par exemple une adaptation du système d'exploitation installé sur celui-ci.

En outre, ces informations de qualité de service obtenues par le terminal mobile peuvent être sujet à caution car fortement dépendantes du terminal mobile utilisé. Or il peut être intéressant pour l'opérateur du réseau de téléphonie mobile, de connaître de façon fiable la qualité de service de son réseau sans dépendre du type et de l'architecture logicielle des terminaux mobiles connectés.

Il est à noter qu'aujourd'hui, seules des mesures de puissance de signal (NMR pour Network Measurement Report en anglais) sont accessibles par le module d'identité de souscripteur. L'opérateur n'est donc pas informé de la qualité de service du canal de communication ouvert par l'activation d'un contexte PDP.

Une solution pour l'opérateur pour obtenir des informations sur la qualité de service de son réseau de téléphonie mobile consiste à équiper ce dernier de capteurs disposés à de nombreux emplacements du réseau. Cette solution est toutefois extrêmement couteuse à déployer et à entretenir. Il est donc nécessaire de trouver une solution permettant à l'opérateur de récupérer des informations de qualité de service sur son réseau de téléphonie mobile, à moindre coût, et ce indépendamment du terminal et en conservant les interfaces existantes entre les modules d'identité de souscripteur et les terminaux mobiles les intégrant. RESUME DE L'INVENTION La présente invention a ainsi pour objet de pallier au moins un de ces inconvénients. Dans ce contexte, un premier aspect de l'invention concerne un procédé de test de la qualité de service d'un canal de communication entre un terminal mobile comprenant un module d'identité de souscripteur auprès d'un opérateur de réseau de téléphonie mobile, et un équipement distant d'un réseau cible, un contexte de protocole d'échange de paquets de données, PDP, étant activé dans ledit réseau de téléphonie mobile pour la communication entre le terminal mobile et l'équipement distant, le procédé étant caractérisé en ce qu'il comporte les étapes suivantes, mises en oeuvre par le module d'identité de souscripteur : envoi, par le canal de communication mettant en oeuvre le contexte PDP, de données de test à destination dudit équipement distant, réception sur le canal de communication d'une réponse à l'envoi des données de test, et traitement de ladite réponse, pour évaluer la qualité de service dudit canal de communication.

L'invention permet ainsi à un opérateur de réseau de téléphonie mobile, d'avoir accès à la qualité de service effectivement disponible sur un canal de communication ouvert sur son réseau de téléphonie mobile entre un terminal mobile et un équipement distant d'un réseau cible, indépendamment du terminal mobile. En effet, suite à l'activation d'un contexte de protocole d'échange de paquets de données PDP dans le réseau de téléphonie mobile, un module d'identité de souscripteur auprès de l'opérateur situé dans le terminal, effectue un test de qualité de service sur le canal de communication ainsi établi. Pour ce faire, des données de test sont envoyées à l'équipement distant via le canal et la réponse à cet envoi est analysée par le module d'identité de souscripteur.

L'opérateur peut ainsi récupérer des données de qualité de service directement sur le module d'identité de souscripteur, sans avoir à modifier l'interface entre le terminal et le module d'identité de souscripteur, ou à adapter le terminal. Enfin, l'opérateur peut ainsi déterminer si la qualité de service de la connexion est conforme à la qualité demandée (négociée) lors de l'activation du contexte PDP. D'autres caractéristiques du procédé selon des modes de réalisation de l'invention sont décrites dans les revendications dépendantes. Selon les modes de réalisation, l'équipement distant peut être un équipement d'infrastructure comme par exemple un serveur de gestion de mobilité (SGSN) du réseau de téléphonie mobile, ou un équipement d'un sous-réseau de données du réseau de téléphonie mobile, ou un équipement d'un réseau de données externe au réseau de téléphonie mobile. Le contexte PDP peut être activé à l'initiative du terminal mobile. En variante, le contexte PDP peut être activé à l'initiative de l'équipement distant. Dans des modes de réalisation de l'invention, le procédé comprend en outre une étape de modification du canal de communication entre le terminal mobile et l'équipement distant par exemple, en cas de qualité de service évaluée insuffisante. Ainsi, lorsque la qualité de service n'est pas conforme à la qualité de service négociée lors de l'activation du contexte PDP, le canal de communication peut être modifié (adapté).

Dans des modes de réalisation de l'invention, l'étape de traitement de la réponse comprend la comparaison d'au moins une information de qualité de service évaluée sur la base de la réponse de l'équipement distant, avec une valeur prédéfinie de qualité de service du contexte PDP activé, ladite modification du canal de communication étant déclenchée par ledit module d'identité de souscripteur en cas de différence supérieure à une valeur seuil.

Ainsi, dans ces modes de réalisation, le module d'identité de souscripteur prend lui-même la décision de modifier le canal de communication, en fonction des résultats du test, à savoir la réponse de l'équipement distant aux données de test. Dans des modes de réalisation de l'invention, la modification comprend l'activation par le terminal d'un autre contexte PDP avec une autre valeur de qualité de service.

Par exemple, l'activation d'un nouveau contexte PDP permet de renégocier la qualité de service du canal de communication. L'activation de cet autre contexte peut notamment être déclenchée par une commande type OPEN CHANNEL envoyée par le module d'identité de souscripteur au terminal mobile. Dans des modes de réalisation de l'invention, la modification comprend le changement de réseau de téléphonie mobile par le module d'identité de souscripteur. Par exemple, dans le cas où l'opérateur n'est pas à même de fournir une qualité de réseau satisfaisante dans une zone géographique par exemple, le module d'identité de souscripteur peut avantageusement se connecter à un autre réseau ayant par exemple un accord d'itinérance avec l'opérateur du réseau de téléphonie initial.

Dans des modes de réalisation de l'invention, le module d'identité de souscripteur comprend en mémoire un identifiant international d'abonné IMSI courant et un autre identifiant international d'abonné IMSI, et ladite modification comprend la bascule entre l'identifiant IMSI courant et l'autre identifiant IMSI.

Typiquement, l'identifiant IMSI courant est propre à l'opérateur de réseau initial, tandis que l'autre identifiant IMSI correspond par exemple à un opérateur intermédiaire (e.g. broker) ayant passé des accords d'itinérance avec d'autres opérateurs, par exemple étrangers. Ces dispositions (changement de réseau et bascule d'IMSI) conduisent au final à activer un nouveau contexte PDP afin d'obtenir une autre qualité de service.

Dans des modes de réalisation de l'invention, le procédé comprend aussi l'envoi, par ledit module d'identité de souscripteur, audit équipement distant, de données de qualité de service évaluées lors de l'étape de traitement par ledit module d'identité de souscripteur. Ainsi, dans ces modes, l'équipement distant reçoit aussi des données sur la qualité de service du réseau, de la part du module d'identité de souscripteur.

Ces données de qualité de service peuvent être des données brutes, c'est-à-dire des valeurs de paramètres de qualité de service comme le débit, le délai de réponse, le nombre de réémission de paquet, etc. Ces données de qualité de service peuvent également prendre la forme d'alertes, en fonction de la valeur des paramètres de qualité de service par rapport à la valeur négociée de ces paramètres. Par exemple, lorsque la valeur d'un paramètre s'éloigne exagérément de la valeur négociée lors de l'activation du contexte PDP, une alerte peut être générée par le module d'identité de souscripteur pour ce paramètre, qui l'envoie alors à l'équipement distant. Ces données de qualité de service peuvent aussi prendre la forme d'une alerte globale, évaluant la conformité générale des paramètres considérés par rapport aux valeurs 25 négociées. Dans certains cas, l'équipement distant peut lui aussi initier un test de qualité de service en envoyant des données de test au module d'identité de souscripteur, par exemple en mode push, et en traitant une réponse du module d'identité de souscripteur à l'envoi de ces données. 30 Dans des modes de réalisation de l'invention, lorsque certaines conditions basées sur les données de qualité de service envoyées sont remplies, le module d'identité de souscripteur reçoit une commande de déclenchement de ladite étape de modification en provenance de l'équipement distant. Dans des modes de réalisation de l'invention, lorsque certaines conditions basées 35 sur les données de qualité de service reçues par l'équipement distant sont remplies, l'équipement distant provoque la désactivation du contexte PDP. Ainsi, dans ces modes, l'équipement distant prend lui-même la décision de modifier le canal de communication, et le module d'identité de souscripteur applique cette décision en modifiant le canal en réponse à une commande de l'équipement distant.

Les conditions à remplir sont par exemple relatives à un nombre critique d'alertes reçues, et/ou à un nombre critique de paramètres dont la valeur n'est pas conforme à la valeur négociée lors de l'activation du contexte PDP (moyennant une valeur seuil). D'autres conditions peuvent être envisagées. Ces conditions peuvent être fixées par l'opérateur, le propriétaire du module d'identité de souscripteur ou par l'équipement distant, ou par ailleurs. Dans des modes de réalisation de l'invention, la commande de déclenchement est reçue par un autre canal de communication, sous forme d'un SMS. Ainsi, même lorsque le contexte PDP est désactivé ou lorsque le canal de communication est inefficace (mauvaise qualité de service), le module d'identité de souscripteur peut mettre en oeuvre une étape de modification en vue de l'activation d'un nouveau contexte PDP avec de nouveau paramètres. Dans des modes de réalisation de l'invention, l'équipement distant est un serveur support du réseau de téléphonie mobile configuré pour valider l'activation du contexte PDP.

Dans des modes de réalisation de l'invention, le procédé est mis en oeuvre périodiquement ou lorsque certains événements particuliers se produisent. Par exemple, le procédé est mis en oeuvre lorsqu'un nouveau réseau de téléphonie mobile est détecté à proximité du terminal mobile, et/ou lorsqu'un nouveau contexte PDP est activé, et/ou sur requête d'une entité tierce, permettant ainsi régulièrement d'évaluer la qualité de service du réseau de télécommunication mobile. Dans des modes de réalisation de l'invention, la qualité de service est évaluée en fonction d'au moins un des paramètres suivants : nombre de réémission d'au moins un paquet de données de test, délai de réponse à l'envoi d'au moins un paquet de données de test, nombre de paquets de données de test perdus.

Ainsi, la qualité de service n'est pas uniquement évaluée par rapport à la puissance du signal (NMR). Dans des modes de réalisation, la réponse à l'envoi des données de test comprend au moins un acquittement des données de test envoyées. Par exemple, l'acquittement atteste de la bonne réception de l'ensemble des paquets de données de test par l'équipement distant. Corrélativement, un deuxième aspect de l'invention concerne un module d'identité de souscripteur auprès d'un opérateur de réseau de téléphonie mobile, pour terminal mobile, un contexte de protocole d'échange de paquets de données, PDP, étant activé dans ledit réseau de téléphonie mobile pour la communication entre le terminal mobile et un équipement distant, le module d'identité de souscripteur étant caractérisé en ce qu'il comporte : un module d'envoi, par le canal de communication mettant en oeuvre le contexte PDP, de données de test à destination dudit équipement distant, un module de réception sur le canal de communication, d'une réponse à l'envoi des données de test, et un module de traitement de ladite réponse, pour évaluer la qualité de service dudit canal de communication. Corrélativement, un troisième aspect de l'invention concerne un terminal mobile comprenant un module d'identité de souscripteur tel que précité.

Corrélativement, un quatrième aspect de l'invention concerne un système comprenant un terminal mobile avec module d'identité de souscripteur tel que précité, et un équipement distant. Les avantages, buts et caractéristiques particulières du module d'identité de souscripteur, du terminal et du système sont similaires à ceux du procédé précité.

Dans un mode particulier de réalisation, les différentes étapes du procédé précité sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un microprocesseur, ce programme comprenant des instructions qui lorsqu'elles sont exécutées par le processeur mettent en oeuvre les étapes du procédé tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'informations lisible par un microprocesseur, et comprenant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple une ROM de microcircuit, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou encore une mémoire flash. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur une plateforme de stockage d'un réseau de type Internet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Le support d'informations et le programme d'ordinateur précités présentent des caractéristiques et avantages analogues au procédé qu'ils mettent en oeuvre.

BREVE DESCRIPTION DES FIGURES D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : - La Figure 1 illustre schématiquement un réseau de téléphonie mobile auquel se connecte un terminal mobile, et relié à un réseau de paquets de données externe ; - La Figure 2 illustre un exemple d'architecture matérielle pour un terminal mobile embarquant un module d'identité de souscripteur selon un mode particulier de réalisation de l'invention ; - La Figure 3 illustre des échanges de messages dans le réseau de la Figure 1 lors de la mise en oeuvre d'un procédé de test de la qualité de service d'un canal de communication conformément à un mode de réalisation de l'invention ; - La Figure 4 illustre des échanges de messages dans le réseau de la Figure 1 en réaction au test de qualité de service de la Figure 3. DESCRIPTION DETAILLEE DE L'INVENTION L'invention permet à une application cliente d'un module d'identité de souscripteur auprès d'un opérateur de réseau de téléphonie mobile, par exemple incorporé dans un terminal mobile, de tester la qualité de service d'un canal de communication établi entre le terminal mobile et un équipement distant d'un réseau cible, et ceci indépendamment du terminal mobile. Comme décrit par la suite, ce test de qualité de service permet par exemple de déterminer si la qualité de service de la connexion est conforme à la qualité demandée lors de l'activation d'un contexte PDP permettant au terminal d'échanger des données avec l'équipement distant sur le canal de communication. Ce contexte PDP peut être activé à l'initiative du terminal mobile, du module d'identité de souscripteur, ou de l'équipement distant. Dans la description qui suit, on s'intéresse au cas où le module d'identité de souscripteur réalise le test de qualité de service en envoyant des données de test à l'équipement distant. Toutefois, dans certains cas, l'équipement distant peut lui aussi effectuer un tel test auprès du module d'identité de souscripteur. Ensuite, en fonction de réponses au test de qualité de service, le module d'identité de souscripteur peut lui-même décider d'agir sur le canal de communication afin d'améliorer la qualité de service, notamment lorsque la qualité de service n'est pas celle attendue.

Dans d'autres situations, des informations résultant du test de la qualité de service sont transmises à l'équipement distant, qui décide d'agir sur le canal de communication pour le modifier, en cas de besoin. Notamment, l'équipement distant peut agir sur ce canal soit directement, soit par l'intermédiaire du module d'identité de souscripteur en lui envoyant par exemple une commande pour modifier le canal de communication.

La Figure 1 illustre schématiquement un réseau de téléphonie mobile 100 auquel se connecte un terminal mobile 120. Le réseau de téléphonie mobile 100 est par exemple un réseau partiellement IP, de type GPRS, géré par un opérateur de téléphonie mobile. L'application des enseignements de l'invention comme décrit par la suite, aux autres types de réseau de téléphonie mobile requière la transposition des fonctions évoquées en lien avec le GPRS en des fonctions similaires dans ces autres types de réseau sans fil, tel que le réseau Wi-Fi lorsqu'il s'appuie sur une architecture Interworking Wireless LAN (I-WLAN) par exemple. Dans cet exemple, le réseau de téléphonie mobile comprend un sous-réseau de données 102. Ce sous-réseau 102 est typiquement un réseau de paquets de données interne, par exemple spécifique à l'opérateur du réseau de téléphonie mobile 100. Un équipement 103 peut être connecté à ce sous-réseau 102. Par exemple, cet équipement 103 est un serveur du sous-réseau 102. Le réseau de téléphonie mobile 100 peut aussi être relié à un réseau de paquets de données externe 140. Le réseau externe 140 est par exemple un réseau IP public, type l'Internet. En variante, le réseau externe 140 peut être un réseau IP privé permettant l'accès à des serveurs et services de ce réseau privé. Un équipement distant 150 peut être connecté à ce réseau externe 140. Cet équipement distant est par exemple un serveur, par exemple d'un fournisseur de services. En pratique, le réseau de téléphonie mobile 100 comprend un ou plusieurs serveurs SGSN 104 (pour Serving GPRS Support Node en anglais), jouant le rôle de routeurs de paquets et dotés de fonctionnalités dédiées à la gestion du réseau 100. D'une part, ce serveur SGSN 104 conduit les procédures de rattachement des terminaux mobiles (e.g. le terminal 120) au réseau de téléphonie mobile 100, notamment à l'aide de procédures d'authentification et d'autorisation. Cette procédure de rattachement est connue sous l'appellation d'« attach request/response D'autre part, le serveur SGSN 104 reçoit les requêtes d'activation d'un contexte PDP (« activation PDP context request ») émise par des équipements comme le terminal mobile 120, et conduit ces activations. Le contexte PDP peut être activé sur requête du terminal mobile 120 ou bien à l'initiative d'un équipement distant (e.g. équipement 150 ou 103) connecté par exemple à un réseau de données (e.g. réseau externe 140, sous-réseau 102). Dans la suite, pour des raisons de simplicité, on considère le cas où la requête d'activation du contexte PDP provient du terminal mobile 120. L'autre cas est à la portée de la personne du métier. En pratique, lorsqu'un terminal souhaite échanger des données avec un équipement distant situé dans un réseau cible externe, le serveur SGSN conduit des procédures de découverte et de sélection des passerelles du réseau mobile vers ce réseau cible, selon les paramètres définis par l'opérateur télécom du réseau 100. Ainsi, dans l'exemple de la Figure 1, lorsque le terminal mobile 120 souhaite échanger des données avec l'équipement 150 du réseau externe 140, le serveur SGSN 104 sollicité par l'activation d'un contexte PDP, sélectionne par exemple la passerelle 106 qui constitue une porte de sortie du réseau mobile 100 vers le réseau externe 140.

Lorsque le réseau cible est un sous-réseau (e.g. le sous-réseau 102) du réseau mobile 100, le serveur SGSN 104 gère également le routage des paquets de données vers le réseau cible. Un terminal mobile 120 peut disposer de connectivités simultanées avec plusieurs passerelles pour échanger des données avec des équipements distants de plusieurs réseaux. Par exemple, le terminal mobile peut souhaiter échanger des données avec l'équipement 103 du sous-réseau 102 et l'équipement 150 du réseau externe 140. Plusieurs contextes PDP sont alors activés à l'aide du serveur SGSN 104. Ainsi, dans des modes de réalisation, l'équipement distant est distinct du serveur SGSN 104, ce serveur jouant le rôle de routeur de paquets entre le terminal mobile 120 et l'équipement distant 150 (ou 103). Dans d'autres modes de réalisation, l'équipement distant est le serveur SGSN 104 lui-même. Dans la suite de la description, on décrit principalement le cas où le réseau cible est le réseau externe 140, et où le terminal mobile 120 souhaite échanger des données avec l'équipement distant 150 de ce réseau cible externe 140. Toutefois, l'invention ne se limite pas à ce cas, et couvre également les modes de réalisation où le réseau cible est un sous-réseau 102 du réseau de téléphonie mobile 100, ainsi que le cas où le réseau cible est le réseau de téléphonie mobile 100 lui-même (et l'équipement distant est le serveur SGSN 104 ou bien un autre terminal mobile du réseau de téléphonie mobile). Il est toutefois à la portée de la personne du métier d'appliquer les enseignements relatifs au cas décrit en détail ci-après, aux autres cas de figures couverts par l'invention. Comme montré sur la Figure 1, le terminal mobile 120 comprend un module d'identité de souscripteur 122 auprès d'un opérateur de téléphonie mobile exploitant le réseau de téléphonie mobile 100. Le module d'identité de souscripteur 122 peut par exemple correspondre à une carte SIM, USIM ou UICC (pour Universal Integrated Circuit Card) conforme à la norme ETSI TS 102 221. Le module d'identité de souscripteur 122 peut être mis en oeuvre dans un composant embarqué ou amovible de type élément sécurisé (eSE ou SE)) qui est un chipset distinct du processeur principal du terminal mobile. Le module d'identité de souscripteur 122 répond par exemple aux spécifications ISO 7816 (norme ETSI TS 102 223), voire à la norme Critères Communs (ISO/CEI 15408). Il peut dialoguer avec le terminal mobile 120 dans lequel il est embarqué ou incorporé, au moyen de trames APDU (pour Application Protocol Data Unit). La Figure 2 représente un exemple d'architecture possible pour un terminal mobile comportant un module d'identité de souscripteur, conforme à des modes de réalisation de l'invention.

Il s'agit par exemple du terminal mobile 120 représenté sur la Figure 1, comportant notamment un module d'identité de souscripteur 122. Le module d'identité de souscripteur 122 est adapté à mettre en oeuvre les principales étapes d'un procédé de test de la qualité de service conforme à des modes de réalisation de l'invention, tel que décrit ultérieurement en référence à la Figure 3, ou 4. Le module d'identité de souscripteur 122 comprend un bus de communication 20 auquel sont reliés : - une unité de traitement 22 -ou microprocesseur- notée CPU (pour Central Processing Unit) ; - une ou plusieurs mémoires non volatile 24 par exemple ROM (pour Read Only Memory) pouvant constituer un support au sens de l'invention, c'est-à-dire pouvant comprendre un programme informatique comprenant des instructions pour la mise en oeuvre d'un procédé de test conforme à des modes de réalisation de l'invention ; cette mémoire non volatile peut également être une mémoire EEPROM (pour de Electrically Erasable Read Only Memory) ou encore une mémoire Flash; - une mémoire vive 26 ou mémoire cache ou mémoire volatile par exemple RAM (pour Random Access Memory) comprenant des registres adaptés à l'enregistrement des variables et paramètres créés et modifiés au cours de l'exécution du programme précité ; lors de la mise en oeuvre de l'invention. Les codes d'instructions du programme stocké en mémoire non volatile (ex. EEPROM ou flash) sont chargés en mémoire RAM en vue d'être exécutés par l'unité de traitement CPU ; - une interface de communication 28 adaptée à transmettre et à recevoir des données, par exemple via un réseau de télécommunications ou une interface de lecture/écriture. Notamment, le terminal 120 comprend une interface de communication complémentaire (non représentée) pour interagir avec l'interface 28 aux fins par exemple de transmettre au module 122 des événements ou données provenant du réseau de téléphonie mobile ou d'un utilisateur du terminal. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le module d'identité de souscripteur ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité de traitement est susceptible de communiquer des instructions à tout élément du module d'identité de souscripteur directement ou par l'intermédiaire d'un autre élément de ce module d'identité de souscripteur. Tel qu'il sera décrit ci-après en référence à la Figure 4, la mise en oeuvre d'un test de qualité de service conforme à des modes de réalisation de l'invention peut permettre de modifier les paramètres de connexion du terminal mobile 120 à un équipement distant d'un réseau cible en fonction des résultats du test. De manière générale, le module d'identité de souscripteur 122 comporte en mémoire un identifiant international d'abonné IMSI, associé à l'opérateur du réseau de téléphonie mobile 100 (opérateur de base). Il peut également comporter un ou plusieurs autres identifiants IMSI, par exemple utilisés par des opérateurs intermédiaires pour l'authentification du module d'identité 122 sur des réseaux internationaux. Ainsi, à l'issue du test de qualité de service, le module d'identité de souscripteur 122 peut par exemple basculer d'un IMSI à un autre.

Classiquement, le module d'identité de souscripteur 122 comprend en outre en mémoire un fichier de réseaux interdits FPLMN (pour Forbidden Public Land Mobile Network) stockant les réseaux de téléphonie mobiles dits interdits. Il est rappelé qu'un réseau de téléphonie mobile est répertorié dans ce fichier de réseaux interdit lorsqu'une tentative d'authentification (ou d'attache) du module d'identité de souscripteur 122 auprès de ce réseau a échoué. Toute tentative future de connexion (ou d'attache) à ce réseau est interdite tant que le réseau est répertorié dans ce fichier de réseaux interdits. Ainsi, à l'issue du test de qualité de service, le réseau de téléphonie mobile courant 100 peut être introduit dans le fichier FPLMN du module d'identité de souscripteur 122, de sorte à ce que celui-ci soit contraint de se déconnecter de ce réseau, afin par exemple de se connecter à un autre réseau de téléphonie mobile et activer un nouveau contexte PDP. La Figure 3 représente des étapes d'un procédé de test de la qualité de service selon des modes de réalisation de l'invention. Les échanges de messages sont décrits entre diverses entités de la Figure 1.

De façon connue, un prérequis à toute ouverture de canal de communication pour échanger des données, est que le module d'identité de souscripteur 122 doit être connecté à un réseau de téléphonie mobile. En particulier, le module d'identité de souscripteur 122 peut présenter un de ces trois statuts de connectivité : - le statut « No Service » signifie que le module d'identité de souscripteur 122 n'est connecté (i.e. ne s'est authentifié) à aucun réseau, - le statut « Limited Service » signifie que le module d'identité de souscripteur 122 n'est pas connecté à un réseau, mais qu'un réseau se trouve à proximité, c'est par exemple le cas des réseaux répertoriés comme réseaux interdits dans un autre fichier élémentaire dénoté 30 FPLMN, - le statut « Normal Service » signifie que le module d'identité de souscripteur 122 est connecté à un réseau de téléphonie mobile. On suppose par la suite que le module d'identité de souscripteur 122 présente un statut « Normal Service » et qu'il est connecté au réseau de téléphonie mobile 100. Le terminal 35 mobile 120 peut donc effectuer des communications téléphoniques (e.g. appels voix) avec d'autres terminaux. Dans le cas où le module d'identité de souscripteur 122 ne serait pas connecté au réseau de téléphonie mobile 100, une procédure classique de connexion serait mise en oeuvre.

Des informations sur le réseau de téléphonie mobile auquel le module d'identité de souscripteur 122 est connecté sont mémorisées dans un des fichiers élémentaires du module d'identité de souscripteur 122, généralement dénommé EF_LOCI (pour Elementary File et LOCation Information).

Ce fichier comprend notamment un code de réseau mobile (MNC), un code de pays du réseau (MCC), et un code de localisation (LAC) qui identifie un ensemble de cellules du réseau de téléphonie mobile pouvant être utilisées pour les communications de type voix. Ce fichier EF_LOCI est régulièrement rafraichi, notamment à chaque fois que le réseau change, et que le module d'identité de souscripteur change de statut.

Le processus de la Figure 3 concerne dans un premier temps l'ouverture d'un canal de communication sur le réseau téléphonique mobile 100 pour échanger des données. Pour ce faire, dans un premier temps, une application cliente (Applet) du module d'identité de souscripteur 122 vérifie que le terminal mobile 120 dispose des capacités nécessaires pour ce type d'échanges, c'est-à-dire pour échanger des données par un canal de 15 communication. Par la suite, pour des raisons de simplicité, les étapes mises en oeuvre par l'application cliente seront décrites en référence au module d'identité de souscripteur. Ainsi, au cours d'une étape 300, le module d'identité de souscripteur 122 envoie une commande PROVIDE LOCAL INFO au terminal mobile 120. 20 Telle que décrite dans la norme TS 102 223 à la section 6.4.15, la commande PROVIDE LOCAL INFO permet au module d'identité de souscripteur 122 d'obtenir des informations au niveau du terminal (identité du terminal mobile, date et heure locales, langue d'usage, état de charge de la batterie, technologie de téléphonie mobile accessible, par exemple GSM (pour Global System for Mobile Communication) ou UMTS (pour Universel 25 Mobile Telecommunications System), etc. En réponse à cette commande, le terminal mobile 120 retourne (étape 302) au module d'identité de souscripteur 122, un message TERMINAL RESPONSE. Ce message comprend généralement les informations demandées par le module d'identité de souscripteur 122. Grâce aux informations contenues dans ce message, le module d'identité de souscripteur 30 122 peut s'assurer que le terminal mobile 120 dispose des capacités nécessaires lui permettant de supporter des communications de type échange de données. On suppose par la suite que le terminal mobile 120 est compatible avec des communications de type échange de données. Au cours d'une étape 304, le module d'identité de souscripteur 122 consulte un 35 fichier élémentaire EF_LOCIGPRS présent en mémoire du module d'identité de souscripteur 122. Ce fichier comprend des informations de routage (RAI pour Routing Area Information) pour des communications de données sur le réseau GPRS. En particulier, de façon similaire au fichier EF LOCI, le fichier EF_LOCIGPRS comprend un code de réseau mobile (MNC), un code de pays du réseau (MCC), et un code de localisation (LAC) qui identifie un ensemble de cellules du réseau de téléphonie mobile pouvant être utilisées pour les communications de type data (c'est-à-dire les échanges de données). La consultation de ce fichier permet de recueillir les caractéristiques du réseau auquel le module d'identité de souscripteur est accroché et auprès duquel il va tenter de s'authentifier, dans le but de permettre l'échange de données entre le terminal mobile et ici l'équipement distant 150. Pour ce faire, un contexte d'échange de paquets de données PDP (pour Packet Data Procotol) va être activé dans le réseau de téléphonie mobile 100. Cette activation peut se faire sur requête de l'équipement distant 150 auprès du serveur SGSN (via la passerelle GGSN 106) ou bien à l'initiative du terminal mobile 120. Ce dernier cas est plus amplement décrit ci-dessous. Toutefois, l'activation d'un contexte PDP à l'initiative d'un équipement distant est bien connue de la personne du métier. Dans cet exemple, le module d'identité de souscripteur 122 initie l'établissement d'une connexion (c'est-à-dire l'ouverture d'un canal de communication) au réseau cible 140, auquel est connecté l'équipement distant 150. Ainsi, au cours d'une étape 306, le module d'identité de souscripteur 122 requiert l'établissement d'une connexion (c'est-à-dire l'ouverture d'un canal de communication) au réseau cible externe 140, auprès du terminal mobile 120 l'incorporant. On rappelle que le module d'identité de souscripteur 122 est déjà connecté au réseau de téléphonie mobile 100 pour les communications téléphoniques, et qu'il s'agit à présent d'établir une autre communication avec le réseau, cette fois pour échanger des données. En pratique, le module d'identité de souscripteur 122 lui fournit les paramètres nécessaires à l'activation d'un service de paquets de données (contexte PDP), par exemple à l'aide d'une trame APDU (IS07816).

Par exemple, le module d'identité de souscripteur 122 envoie une commande proactive OPEN CHANNEL conforme au protocole BIP (définit dans la norme ETSI TS 102 223 v11) pour requérir du terminal mobile 120, l'activation d'un contexte PDP sur le réseau de téléphonie mobile 100. La commande OPEN CHANNEL comprend notamment une liste de paramètres nécessaires, parfois dénommés paramètres « Bearer Independent Protocol », pour l'activation d'un contexte PDP, notamment la qualité de service souhaitée. Par exemple, cette liste peut comprendre une description (« bearer description »), la taille du buffer, l'adresse du réseau cible, le numéro de port de l'interface module/terminal (ex : protocole UDP, port P), le point d'accès « Network Access Name » qui correspond au nom du point d'accès APN (pour Access Point Name) identifiant la passerelle GGSN qui fournit la connexion au réseau de données cible externe, l'adresse IP de l'équipement distant, etc. Ainsi, la qualité de service souhaitée (délai de réponse, débit, etc) est transmise via cette commande OPEN CHANNEL. En variante, la qualité de service peut être transmise à l'aide de toute autre commande proactive envoyée par le module d'identité de souscripteur 122 au terminal mobile 120.

A réception de la requête OPEN CHANNEL, le terminal mobile 120 déclenche une procédure de rattachement au réseau de téléphonie mobile 100, en vue d'ouvrir un canal de communication pour les échanges de données. De façon classique, cette procédure comprend l'envoi (étape 308) d'une requête « Attach Request » par le terminal mobile 120. Cette requête est traitée au cours d'une étape 310 par le serveur SGSN 104 qui récupère des informations de souscription associées à l'utilisateur auprès du réseau 100 puis réalise des procédures d'authentification/autorisation sur la base de ces informations, avant d'accepter au cours d'une étape 312, le rattachement « Attach Accept ». De façon connue, cette procédure de rattachement implique un serveur HLR du réseau 100. A noter que, lors de la connexion classique du module d'identité de souscripteur 122 au réseau de téléphonie 100 pour permettre au module d'identité de souscripteur 122 de mettre en oeuvre des communications téléphoniques classique (de type voix), une procédure de rattachement similaire a été mise en oeuvre.

Au cours d'une étape 314, le terminal mobile 120, émet une nouvelle requête « Activate PDP context Request » au réseau de téléphonie mobile 100 afin d'activer un contexte PDP. Cette requête comprend de paramètres tels que par exemple une valeur de qualité de service, un APN (Access Point Name), un type de PDP. Cette requête est traitée au cours de l'étape 316 de façon classique par le serveur SGSN 104 du réseau de téléphonie mobile 100. Il s'agit pour cette entité 104 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 de découverte et sélection permettent de sélectionner le réseau cible (ici le réseau externe 140) visé par l'utilisateur, ainsi que les noeuds internes au réseau de téléphonie mobile 100 permettant d'accéder au réseau cible externe 140, à savoir notamment la passerelle 106. En pratique, le serveur SGSN 104 obtient une liste de noeuds internes candidats correspondant à l'accès au réseau cible souhaité. De cette liste, le noeud approprié est sélectionné, éventuellement sur la base sur plusieurs critères, par exemple en fonction des conditions réseau telles que la 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. Lorsque le ou les noeuds internes définissant le contexte PDP sont sélectionnés, le serveur SGSN 104 active le contexte PDP pour le terminal mobile 120, c'est-à-dire le canal de communication entre le terminal mobile 120 et le point de sortie 106 vers le réseau cible souhaité. Concrètement, l'activation du contexte PDP consiste à attribuer un identifiant de contexte pour marquer les parquets de données devant transiter par ce contexte PDP, et à l'associer au terminal mobile 120 ainsi qu'à l'ensemble des entités permettant le routage le long du contexte PDP jusqu'à la passerelle GGSN.

Pour ce faire, le serveur SGSN envoie, au cours d'une étape 318, une acceptation « Activate PDP context Accept » au terminal mobile 120. Cette acceptation comprend, entre autres, la qualité de service négociée avec le serveur SGSN 104. A noter que plusieurs contextes PDP peuvent être activés par le serveur SGSN 104 pour un même terminal mobile 120, qui souhaite accéder à plusieurs réseaux cible de façon simultanée. Pour identifier séparément chacun des contextes PDP, un identifiant de contexte leur est affecté. Cet identifiant est mémorisé par le serveur SGSN 104, en association avec un identifiant du terminal mobile 120. Ces informations permettront en effet de router des messages de réponse vers le terminal mobile 120 ad hoc en fonction des identifiants de contexte. A réception de l'acceptation de l'activation du contexte PDP (étape 318), le terminal mobile 120 répond au cours d'une étape 320, à la commande OPEN CHANNEL par un message TERMINAL RESPONSE à destination du module d'identité de souscripteur 122. Le cas échéant, le même type de message peut être retourné pour indiquer que la commande OPEN CHANNEL n'a pas été exécutée avec succès. Par exemple, la qualité de service négociée lors de l'activation du contexte PDP peut être enregistrée dans une mémoire, par exemple la mémoire non-volatile 24, du terminal mobile 120. Le module d'identité de souscripteur 122 peut accéder à cette mémoire, par exemple à réception du message TERMINAL RESPONSE. Alternativement, la qualité de service négociée peut être transmise au module d'identité de souscripteur 122 en paramètre de la commande TERMINAL RESPONSE lors de l'étape 320. Comme décrit par la suite, le procédé de test selon l'invention vise notamment la vérification, par le module d'identité de souscripteur 122, de cette qualité de service négociée. Comme expliqué précédemment, l'invention ne se limite pas aux modes de réalisation dans lesquels le contexte PDP est activé par le terminal mobile, et couvre aussi les modes de réalisation dans lesquels l'équipement distant est à l'initiative de l'activation du contexte PDP.

Conformément à l'invention, le procédé comprend ensuite l'envoi (étape 322) de données de test par le module d'identité de souscripteur 122, à l'équipement distant 150, à l'aide du contexte PDP. En pratique, les données de test sont émises à l'aide de la fonction SEND DATA également décrite dans la norme ETSI TS 102 223, via la liaison conforme à la norme IS07816 entre le module d'identité de souscripteur 122 et le terminal mobile 120, puis transmises via le contexte PDP précédemment activé, sous forme de paquets de données, par exemple des paquets IP (protocole de transport IP), ou encore des paquets UDP (protocole de transport CAT-TP).

Les données de test sont par exemple un ensemble quelconque de 40Ko de données factices (i.e. sans signification). Ces données sont fractionnées en paquets de données envoyés successivement à l'équipement distant via le contexte PDP.

A la réception des paquets de données de test, l'équipement 150 renvoie une réponse (étape 324) au module d'identité de souscripteur 122. La réponse consiste préférentiellement en un ou plusieurs acquittements. Ainsi, dans certains modes de réalisation, le module d'identité de souscripteur 122 reçoit un acquittement pour l'ensemble des données de test, qui atteste de la bonne réception de l'ensemble des données de test par l'équipement distant. Dans d'autres modes de réalisation, le module d'identité de souscripteur 122 reçoit un acquittement par paquet, soit N acquittements si les données de test sont fractionnées en N paquets et sont tous reçus correctement. Au cours d'une étape 326, la réponse (constituée de un ou plusieurs acquittements) de l'équipement 150 est traitée par le module d'identité de souscripteur 122. Dans certains modes de réalisation, lorsqu'aucun acquittement n'est reçu pour un (ou plusieurs) paquet(s) après une certaine durée par le module d'identité de souscripteur 122, celui-ci peut réémettre les données concernées (soit toutes les données de test, soit celles constituant le ou les paquets n'ayant pas été correctement transmis à l'équipement 150).

L'étape de traitement 326 peut alors comprendre le comptage du nombre de réémission de chaque paquet. Ce nombre constitue une information sur la qualité de service de la communication entre le module d'identité de souscripteur 122 et l'équipement distant 150. Une moyenne des réémissions sur l'ensemble des paquets peut également constituer une information de qualité de service.

Dans certains modes, l'étape de traitement 326 comprend le calcul du temps écoulé entre l'émission des données (étape 322) et la réception de l'acquittement (étape 324). Ce délai peut être calculé pour chaque paquet, et/ou moyenné sur l'ensemble des paquets. Dans certains modes de réalisation, le nombre de réémissions et/ou le délai de réponse peuvent être comparés à des valeurs seuils, ou par exemple à des plages de valeurs entourant la valeur correspondante négociée (notamment pour le délai de réponse). Un ou plusieurs paramètres, comme le délai de réponse et le nombre de réémission, peuvent ainsi être évalués lors de l'étape de traitement 326. Ainsi, à l'issue de l'étape de traitement 326, le module d'identité de souscripteur 122 connait la valeur d'un ou de plusieurs paramètres reflétant la qualité de service disponible (e.g. nombre de réémissions, délai moyen de réponse, débit ...). Dans certains modes, le module d'identité de souscripteur 122 compare ces valeurs de paramètres à des valeurs prédéterminées et sait donc si les paramètres de qualité de service sont proches ou non des valeurs attendues (par exemple négociées lors de l'activation du contexte PDP).

Le module d'identité de souscripteur 122 peut par exemple générer une ou plusieurs alertes de qualité de service, pour chaque paramètre concerné n'ayant pas la valeur attendue, ou bien une alerte générale pour l'ensemble des paramètres de qualité de service. Par exemple, une alerte générale peut être générée dès lors que le nombre de paramètres sortant des plages attendues dépasse un certain seuil. En variante, une alerte générale peut être générée dès qu'un des paramètres de qualité de service considéré sort de la plage de valeurs attendue. Par exemple, lorsque la différence entre le débit estimé et le débit négocié dépasse la valeur seuil de 10 %, une alerte peut être générée.

Le traitement de la réponse peut comprendre une combinaison de ces modes. Certains paramètres peuvent être comparés aux valeurs attendues alors que d'autres non, ainsi certains paramètres peuvent faire l'objet d'alertes alors que d'autres peuvent simplement rester en tant que valeurs 'brutes'. Ainsi, l'invention permet au module d'identité de souscripteur, et donc à l'opérateur de réseau correspondant, d'estimer la qualité de service réelle du canal de communication entre le terminal mobile 120 et l'équipement distant 150, sans pour autant modifier l'interface de communication (IS07816) entre le module d'identité de souscripteur et le terminal mobile dans lequel le module est inséré ou embarqué. En outre, l'opérateur peut connaître cette qualité de service indépendamment du terminal dans lequel le module est inséré, ce qui peut s'avérer avantageux notamment dans le cas où l'utilisateur change de terminal mobile tout en conservant le même module d'identité de souscripteur. Enfin, grâce à la pluralité de SIM de ses abonnés, l'opérateur peut désormais avoir une évaluation fidèle de la qualité de service de son réseau en de nombreux points, sans coût de déploiement. Dans certains cas, un test de qualité de service tel que décrit précédemment au niveau du module d'identité de souscripteur, est réalisé à l'initiative de l'équipement distant 150, par exemple dans le but de tester la connexion en vue de la fourniture (par exemple spontanée) d'un service. Les données de test sont envoyées par l'équipement distant 150 au module d'identité de souscripteur 122, et l'équipement 150 traite alors lui-même la réponse du module d'identité de souscripteur 122. Ces modes particuliers peuvent être utiles pour déterminer si la qualité de service réellement disponible entre par exemple un serveur de fournisseur de services, et le module d'identité de souscripteur, est suffisante pour supporter des services délivrés par exemple en mode push, au module d'identité de souscripteur. La Figure 4 représente des étapes d'un procédé de test de la qualité de service selon d'autres modes de réalisation de l'invention. En particulier, ces modes de réalisation comprennent les étapes 300 à 326 décrites en référence à la Figure 3, auxquelles s'ajoutent les étapes décrites ci-dessous en référence à la Figure 4, et qui concernent des actions effectuées pour remédier à une qualité de service insuffisante. Selon des premiers modes de réalisation, le résultat de l'étape de traitement 326 est envoyé par le module d'identité de souscripteur 122 à l'équipement distant 150 au cours d'une étape 328. Tel que décrit précédemment, ce résultat peut comprendre par exemple : - une ou plusieurs valeurs de paramètre de qualité de service évalués à l'étape 326, et/ou - une ou plusieurs alertes pour des paramètres de qualité de service, et/ou - une alerte générale de qualité de service.

Au cours d'une étape 330, l'équipement distant 150 traite ce résultat. Ce traitement 330 peut comprendre le comptage du nombre d'alertes, et/ou la comparaison des valeurs de paramètre de qualité de service avec les valeurs attendues (négociées lors de l'activation du contexte PDP), et/ou le comptage des paramètres ayant une valeur non conforme aux valeurs négociées.

Lorsque l'équipement distant 150 détermine que la qualité de service est insuffisante, il peut commander la fermeture du contexte PDP, doit directement en envoyant une commande au serveur SGSN 104 (étape 332), soit indirectement en envoyant une commande au module d'identité de souscripteur 122 (étape 334). Dans les deux cas, la commande peut être envoyée par le canal de communication actif, ou par un autre biais, par exemple par SMS. Afin d'activer un nouveau contexte PDP, l'équipement distant peut par exemple envoyer une requête d'activation au serveur SGSN 104 (cas non représenté). En variante, l'équipement 150 peut envoyer une commande au module d'identité de souscripteur 122 (étape 334) afin que celui-ci demande au terminal mobile 120 l'activation d'un nouveau contexte PDP selon de nouveaux paramètres. Ces nouveaux paramètres sont par exemple inclus dans la commande en provenance de l'équipement 122. A noter que dans l'exemple de la Figure 1, la commande de modification du contexte PDP envoyée à l'étape 334 comprend implicitement une commande de fermeture du contexte PDP en cours, telle que précitée.

En pratique, la commande envoyée par l'équipement distant 150 au module d'identité de souscripteur 122 conduit à la génération par celui-ci d'une nouvelle commande OPEN CHANNEL avec de nouveaux paramètres (taille du buffer, qualité de service, protocole de transport, réseau de téléphonie mobile, etc.) dans le but d'activer un nouveau contexte PDP selon ces paramètres.

D'autre part, le changement de réseau de téléphonie mobile peut se faire via la bascule de l'identifiant IMSI courant à un autre identifiant IMSI du module d'identité de souscripteur.

Typiquement, l'identifiant IMSI courant est propre à l'opérateur de réseau initial, tandis que l'autre identifiant IMSI correspond par exemple à un opérateur intermédiaire (e.g. broker) ayant passé des accords d'itinérance avec d'autres opérateurs, par exemple étrangers. Le changement de réseau de téléphonie mobile peut ainsi être avantageux lorsque l'opérateur du réseau de téléphonie mobile 100 n'est pas à même de fournir une qualité de réseau satisfaisante à un endroit donné. Il est à noter que lorsque le module d'identité de souscripteur est embarqué dans le terminal mobile, la bascule d'un identifiant IMSI à un autre se produit lors de la bascule d'un profil (appelé aussi profil commercial) à un autre.

On rappelle qu'un profil comprend un identifiant IMSI ainsi qu'un ensemble de données et applications associées à l'opérateur de base correspondant à cet identifiant IMSI. Dans le cas de la bascule de l'identifiant IMSI courant à un autre identifiant IMSI, une commande REFRESH, par exemple envoyée par l'équipement distant 150 permet au module d'identité de souscripteur d'enclencher de nouvelles procédures (décrites précédemment) aboutissant à l'activation d'un nouveau contexte PDP. En variante, le changement de réseau (étape 336) peut être mis en oeuvre au moyen de l'enregistrement du réseau de téléphonie mobile 100 dans un fichier de réseau interdit FPLMN mémorisé dans le module d'identité de souscripteur, de sorte à empêcher la reconnexion à ce réseau après le rafraîchissement des fichiers de paramètres du module d'identité de souscripteur 122, sans pour autant changer l'identifiant IMSI courant. Ainsi, de façon connue, le module d'identité de souscripteur va tenter de se connecter au prochain réseau de téléphonie mobile à proximité du terminal, tel qu'il apparait dans la liste des réseaux de téléphonie mobile préférés liée à un IMSI. Selon les paramètres visés par la commande de changement, l'étape de modification 336 permet ainsi la génération d'une nouvelle commande OPEN CHANNEL incluant ces paramètres Selon des seconds modes de réalisation de l'invention, le résultat de l'étape de traitement 326 n'est pas envoyé par le module d'identité de souscripteur 122 à l'équipement distant 150 et les étapes 328 à 334 n'ont pas lieu.

Dans ces second modes, le module d'identité de souscripteur 122 réalise lui-même une comparaison de la qualité de service évaluée avec des valeurs seuil afin de déterminer si la qualité de service est suffisante ou non. Lorsque la qualité de service est insuffisante, il prend lui-même la décision des modifications à effectuer sur la connexion au cours de l'étape de modification 336, telle que décrite précédemment. Ainsi par exemple, le module d'identité de souscripteur peut changer les paramètres de connexion en vue d'une nouvelle commande OPEN CHANNEL (étape 338), ou changer de réseau de téléphonie mobile à l'aide d'une bascule d'IMSI (ou de profil commercial), ou encore à l'aide du fichier de réseaux interdits FPLMN.

De même qu'expliqué précédemment, le changement de réseau de téléphonie mobile peut être avantageux pour l'opérateur dans le but d'assurer en apparence une bonne couverture réseau, notamment lorsque celui-ci n'est pas à même de fournir une qualité de service satisfaisante à un endroit donné, mais qu'un autre réseau géré par un opérateur avec qui un accord d'itinérance a été passé propose une meilleure qualité de service. Les étapes 322 et suivantes décrites en référence à la Figure 3 et/ou 4, peuvent être mises en oeuvre lorsqu'un des évènements suivant est détecté : - activation d'un nouveau contexte PDP, à l'initiative du terminal ou de l'équipement distant, - présence d'un nouveau réseau de téléphonie mobile à proximité du terminal mobile, - requête d'une entité tierce (par exemple contrôlée par l'opérateur du réseau de téléphonie mobile 100). En variante, les étapes 322 et suivantes décrites en référence à la Figure 3 et/ou 4, peuvent être mises en oeuvre périodiquement. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

Claims (19)

1. REVENDICATIONS1. Procédé de test de la qualité de service d'un canal de communication entre un terminal mobile (120) comprenant un module d'identité de souscripteur (122) auprès d'un opérateur de réseau de téléphonie mobile, et un équipement distant (103 ; 104 ; 150) d'un réseau cible (100 ; 102 ; 140), un contexte de protocole d'échange de paquets de données, PDP, étant activé dans ledit réseau de téléphonie mobile (100) pour la communication entre le terminal mobile (120) et l'équipement distant (103 ; 104 ; 150), le procédé étant caractérisé en ce qu'il comporte les étapes suivantes, mises en oeuvre par le module d'identité de souscripteur : envoi, (322) par le canal de communication mettant en oeuvre le contexte PDP, de données de test, à destination dudit équipement distant, réception (324), sur le canal de communication, d'une réponse à l'envoi des données de test, et traitement (326) de ladite réponse, pour évaluer la qualité de service dudit canal de communication.
2. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape de modification (336) du canal de communication entre le terminal mobile et l'équipement distant.
3. 3. Procédé selon la revendication 2, caractérisé en ce que l'étape de traitement (326) comprend la comparaison d'au moins une information de qualité de service évaluée sur la base de la réponse de l'équipement distant, avec une valeur prédéterminée de qualité de service du contexte PDP activé, ladite modification (336) du canal de communication étant déclenchée par ledit module d'identité de souscripteur (122) en cas de différence supérieure à une valeur seuil.
4. 4. Procédé selon l'une quelconque des revendications 2 à 3, caractérisé en ce que ladite modification comprend l'activation (338) d'un autre contexte PDP avec une autre valeur prédéterminée de qualité de service.
5. 5. Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que ladite modification (336) comprend le changement de réseau de téléphonie mobile par le module d'identité de souscripteur.
6. 6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce que ledit module d'identité de souscripteur comprend en mémoire un identifiant internationald'abonné IMSI courant et un autre identifiant international d'abonné IMSI, et ladite modification (336) comprend la bascule entre l'identifiant IMSI courant et l'autre identifiant IMSI,
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que le procédé comprend aussi l'envoi (328), par ledit module d'identité de souscripteur, audit équipement distant, de données de qualité de service évaluées lors de l'étape de traitement par ledit module d'identité de souscripteur.
8. 8. Procédé selon la revendication 7, caractérisé en ce que lorsque certaines conditions basées sur les données de qualité de service envoyées sont remplies, le module d'identité de souscripteur reçoit (334) une commande de déclenchement de ladite étape de modification en provenance de l'équipement distant.
9. 9. Procédé selon la revendication 8, caractérisé en ce que ladite commande de déclenchement est reçue par un autre canal de communication, sous forme d'un SMS.
10. 10.Procédé selon l'une quelconque des revendications 7 à 9, caractérisé en ce que lorsque certaines conditions basées sur les données de qualité de service reçues par l'équipement distant sont remplies, l'équipement provoque la désactivation (332) du contexte PDP.
11. 11.Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que l'équipement distant est un serveur support (104) du réseau de téléphonie mobile configuré pour valider l'activation du contexte PDP.
12. 12.Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que le procédé est mis en oeuvre périodiquement ou lorsque certains événements particuliers se produisent.
13. 13.Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que la qualité de service est évaluée (326 ; 330) en fonction d'au moins un des paramètres suivants : nombre de réémission d'au moins un paquet de données de test, délai de réponse à l'envoi d'au moins un paquet de données de test, nombre de paquets de données de test perdus.
14. 14.Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce que ladite réponse à l'envoi des données de test comprend au moins un acquittement des données de test envoyées.
15. 15.Module d'identité de souscripteur (122) auprès d'un opérateur de réseau de téléphonie mobile, pour terminal mobile (120), un contexte de protocole d'échange de paquetsde données, PDP, étant activé dans ledit réseau de téléphonie mobile (100) pour la communication entre le terminal mobile (120) et un équipement distant (103 ; 104 ; 150), le module d'identité de souscripteur étant caractérisé en ce qu'il comporte : un module d'envoi, par le canal de communication mettant en oeuvre le contexte PDP, de données de test à destination dudit équipement distant, un module de réception sur le canal de communication, d'une réponse à l'envoi des données de test, et un module de traitement de ladite réponse, pour évaluer la qualité de service dudit canal de communication.
16. 16.Terminal mobile (120) comprenant un module d'identité de souscripteur (122) selon la revendication 15.
17. 17.Système comprenant un terminal mobile (120) avec module d'identité de souscripteur (122) selon la revendication 16, et un équipement distant.
18. 18.Programme d'ordinateur comprenant des instructions pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 14, lorsqu'il est chargé et exécuté par un microprocesseur.
19. 19.Support d'informations lisible par un microprocesseur, comprenant les instructions d'un programme d'ordinateur pour mettre en oeuvre un procédé selon l'une quelconque des revendications 1 à 14.