FR3111507A1 - Procédé de traitement de messages échangés dans un réseau de télécommunication, par exemple en vue de leur analyse. - Google Patents

Abstract

Procédé de traitement de messages échangés dans un réseau de télécommunication, par exemple en vue de leur analyse Ce procédé (TT-MSG) de traitement de messages est mis en œuvre par un dispositif (100i) dans un réseau de télécommunication. Il comporte :- une étape (E20, E60, E11, E14) d’obtention d’un identifiant dit de corrélation (CID) associé de façon unique à un service réalisé par le réseau de télécommunication, ledit identifiant de corrélation étant apte à établir une corrélation entre des messages (MSGi E, MSGi S) associés audit service indépendamment des protocoles auxquels se conforment lesdits messages et/ou des interfaces sur lesquelles sont véhiculés lesdits messages ;- une étape (E16, E18, E40, E70) d’enregistrement dudit identifiant de corrélation (CID) dans un contexte (CTX) associé audit service; et- une étape d’envoi (E100) d’au moins un message (MSGi S) en vue de réaliser ledit service, chaque message envoyé comportant ledit identifiant de corrélation (CID) enregistré dans le contexte associé audit service. Fig. 2

Description

Procédé de traitement de messages échangés dans un réseau de télécommunication, par exemple en vue de leur analyse.

L’invention se rapporte au domaine général des télécommunications. Elle vise plus particulièrement une solution permettant d’extraire des messages, par exemple des messages de signalisation échangés entre des équipements d’un réseau de communication, en vue notamment d’analyser ces messages.

De façon connue, les opérateurs ont fait le choix, pour la téléphonie sur IP, de s’appuyer sur le protocole d’établissement de sessions SIP (Session Initiation Protocol). Dans l’architecture de réseau IMS (IP Multimedia Subsystem) définie par le standard 3GPP, ce protocole SIP permet d’échanger des messages de signalisation entre l’ensemble des nœuds du réseau IMS le constituant, et notamment entre les équipements utilisateurs UE, les dispositifs P-CSCF (Proxy-Call Session Control Function), I-CSCF (Interrogating CSCF) et S-CSCF (Serving CSCF), les serveurs d’application AS (Application Server), les messageries vocales, etc.

Le protocole SIP est structuré en différentes couches définies dans le document RFC 3261 (en anglais Request for Comment) : Transport, Transaction, Dialog, Session.

Conformément au document RFC 3261, un dialogue SIP (en anglais Dialog) représente une relation SIP pair-à-pair entre deux agents UA (en anglais User Agent) qui persiste pendant un certain temps. Le dialogue facilite l'enchaînement des messages entre les agents utilisateurs et le routage des requêtes entre ces agents. Le dialogue représente un contexte dans lequel il est possible d’interpréter les messages SIP. Un dialogue est identifié au niveau de chaque agent UA avec un identifiant de dialogue (Dialog ID) qui comporte trois paramètres Call-ID, localTag et remoteTag.

Dans une architecture réseau simple, l’ensemble des messages de signalisation relatifs à une même session, telle que par exemple un appel audio/vidéo, une conversation (en anglais « chat ») en MSRP (Message Session Relay Protocol…), partagent le même dialogue et donc les mêmes informations de dialogue Call-ID et tags (localTag, remote Tag). Il est alors relativement simple d’identifier et d’analyser les messages de signalisation relatifs à une session donnée ou à un utilisateur donné en cas de problème à partir de ces informations de dialogue.

Cependant dans les architectures des réseaux opérationnels, il existe, notamment pour des raisons de sécurité mais pas uniquement, des entités dites B2BUA (Back-to-Back User Agent) qui plutôt que d’utiliser le même dialogue en amont et en aval de leur traversée, modifient les informations de dialogues et font de l’aboutement de dialogues. Dans ce cas, l’analyse des messages de signalisation associés à une session donnée se complique fortement.

Cette difficulté a été adressée par l’introduction d’un nouvel entête (en anglais « header ») Session-ID décrit dans le document RFC 7989 (https://tools.ietf.org/html/rfc7989). Cet entête Session-ID étant conservé à la traversée des B2BUA et des proxys, il permet de maintenir un lien entre différentes transactions associées à une même session. L’utilisation de cet entête présente cependant plusieurs inconvénients.

L’entête Session-ID est en effet constitué d’un identifiant unique de l’émetteur « local-uuid » et d’un identifiant unique du destinataire «remote-uuid » (les informations « local-uuid » et « remote-uuid » présentes dans une requête étant inversées dans les réponses). L’entête ne peut donc être connu qu’après avoir reçu la première réponse de l’équipement distant. Cet équipement distant pouvant évoluer au cours de la logique de l’appel (par exemple en cas de connexions successives vers des serveurs vocaux avant le destinataire, en raison de la mise en œuvre d’une logique de transfert d’appel en l’absence de réponse, en cas de transfert d’appel…), la partie local-uuid et/ou la partie remote-uuid de l’entête peut être amenée à changer au cours de la progression de l’appel selon les équipements impliqués pendant l’appel. Le fait que des informations contenues dans l’entête Session-ID du RFC 7989 peuvent évoluer pendant le déroulement de la session, et la permutation des informations ‘local-uuid‘ / ‘remote-uuid’ en fonction de la direction du message rendent l’utilisation de cet entête très compliquée.

Un autre inconvénient relatif à l’utilisation de cet entête Session-ID tel que défini dans RFC 7989 réside dans le fait que cet entête est prévu et utilisé uniquement pour l’identification d’une session (à savoir d’une communication établissant un média). Il ne peut donc pas être utilisé pour analyser des messages échangés en dehors d’une session, par exemple un échange de messages lors de l’enregistrement d’un terminal, un ensemble d’échanges de requêtes indépendantes mais liées à la mise en œuvre d’un unique service, par exemple un service SMSoIP (SMS over IP), etc.

Un autre inconvénient est que cet entête est défini pour le protocole SIP et qu’il ne peut donc être utilisé que pour l’analyse des messages conformes au protocole SIP. Or dans un réseau IMS, le protocole SIP n’est pas le seul protocole impliqué dans l’établissement des communications. Des équipements du réseau peuvent en effet communiquer entre eux via des interfaces utilisant d’autres protocoles que le protocole SIP.

Ainsi, par exemple, certaines interfaces du réseau IMS peuvent utiliser le protocole Diameter défini dans le document IETF RFC 6733 (ex. interfaces Rx / Gx pour l’établissement des différents flux médias, interface Sh utilisée par un serveur d’application, ou interface Cx utilisée par le S-CSCF ou interfaces Ro / Rf utilisées pour la gestion des tickets de taxation) ou encore le protocole H.248 défini par l’ITU (ex. interface Iq utilisée par le P-CSCF pour le contrôle des flux médias, interface Ix utilisée par l’IBCF (Interconnection Border Control Function) ou encore interface Mn utilisée par le MGCF (Media Gateway Control Function)). Dans le réseau paquet mobile EPC (Evolved Packet Network) qui permet d’accéder au réseau IMS, c’est le protocole GTPv2 défini dans la norme 3GPP TS 29.274 V0.3.0 qui permet de contrôler les ressources associées à un équipement mobile lors de l’attachement au réseau ou lors de l’exécution d’un appel par exemple.

Les messages échangés lors des communications, conformes à ces protocoles, ne peuvent donc pas être analysés à partir de l’entête session-ID tel définie dans RFC 7989.

Il existe donc un besoin d’un mécanisme permettant l’analyse des messages échangés dans un réseau IMS qui ne présente pas les inconvénients précités.

Plus précisément, l’invention concerne un procédé de traitement de messages mis en œuvre par un dispositif dans un réseau de télécommunication, ce procédé comportant :
- une étape d’obtention d’un identifiant dit de corrélation, associé de façon unique à un service réalisé par le réseau de télécommunication, ledit identifiant de corrélation étant apte à établir une corrélation entre des messages associés audit service indépendamment des protocoles auxquels se conforment lesdits messages et/ou des interfaces sur lesquelles sont véhiculés lesdits messages ;
- une étape d’enregistrement de cet identifiant de corrélation dans un contexte associé audit service ; et
- une étape d’envoi d’au moins un message en vue de réaliser ledit service, chaque message envoyé comportant ledit identifiant de corrélation enregistré dans le contexte associé à ce service.

Corrélativement l’invention concerne un dispositif de traitement de messages comportant :
- un module d’obtention d’un identifiant dit de corrélation associé de façon unique à un service réalisé par un réseau de télécommunication, ledit identifiant de corrélation étant apte à établir une corrélation entre des messages associés audit service indépendamment des protocoles auxquels se conforment lesdits messages et/ou des interfaces sur lesquelles sont véhiculés lesdits messages ;
- un module d’enregistrement de cet identifiant de corrélation dans un contexte associé à ce service;
- un module de communication ; et
- un module de contrôle configuré pour contrôler que chaque message envoyé par le dispositif en vue de réaliser ce service comporte l’identifiant de corrélation associé à ce service.

Dans la suite, lorsqu’il est dit qu’un message est envoyé en vue de réaliser un service, cela signifie que le message est envoyé pour réaliser un service ou pour participer/contribuer à la réalisation de ce service avec d’autres messages.

Comme décrit ultérieurement, l’invention peut être mise en œuvre par des dispositifs de toute nature dans le réseau, notamment UE (en anglais User Equipment), eNB (evolved Node B), MME (Mobility Management Entity), SGW (Serving Gateway), PGW (Packet Data Network Gateway), PCRF (Policy and charging rules function), HSS (Home Subscriber Server), P-CSCF (Proxy-Call Session Control Function), I-CSCF (Interrogating Call Session Control Function), S-CSCF (Serving-Call Session Control Function), TAS (Telephony Application Server), …

L’invention vise également un système comportant au moins un dispositif de traitement de messages tel que mentionné ci-dessus. Dans un mode particulier de réalisation, ce système comporte :
- au moins un espace de stockage dans lequel sont stockés des messages comportant l’identifiant de corrélation associé à ce service ; et
- un dispositif de consultation configuré pour extraire au moins un message dudit au moins un espace de stockage en utilisant l’identifiant de corrélation.

Les messages peuvent par exemple être stockés dans l’espace de stockage par une ou plusieurs sondes qui scrutent, par exemple en permanence le réseau, et enregistrent une copie de ces messages dans l’espace de stockage.

Les messages associés à un même service comportent tous l’identifiant de corrélation, et peuvent donc être récupérés dans le ou les espaces de stockage en utilisant cet identifiant de corrélation, au moyen d’un filtre adéquat. Les messages ainsi extraits peuvent ensuite être analysés par exemple en vue de diagnostiquer un problème (« troubleshooting » en anglais) sur le réseau ou dans le cadre de tests automatiques de réseau pour faciliter l’analyse des résultats de ces tests. L’analyse des messages extraits peut être indifféremment conduite par un dispositif d’analyse auxquels sont fournis les messages ainsi extraits ou par un expert.

De façon très avantageuse, l’identifiant de corrélation est inséré dans les messages, indépendamment de leurs protocoles et des interfaces sur lesquelles sont véhiculés ces messages.

Ainsi, l’identifiant de corrélation est apte à établir une corrélation entre des messages associés à un service, pour une pluralité de protocoles distincts et/ou une pluralité d’interfaces distinctes.

Lorsque l’invention est mise en œuvre dans un réseau IMS, elle permet de corréler et d’analyser l’ensemble des messages associés à un même service, quels que soient leurs protocoles, par exemple SIP, Diameter, GTPv2, ou H.248.

En effet, dans un mode particulier de réalisation, les messages reçus ou envoyés sont conformes à un protocole parmi le protocole SIP, le protocole Diameter, le protocole GTPv2 et le protocole H.248.

Lorsque le dispositif selon l’invention met en œuvre deux protocoles, il peut recevoir l’identifiant de corrélation dans un message conforme à un premier protocole et envoyer un message comportant l’identifiant de corrélation selon un deuxième protocole distinct du premier protocole.

C’est par exemple le cas d’une entité I-CSCF qui dans le cadre d’un même service, reçoit des messages conformes au protocole SIP et envoie des messages conformes au protocole Diameter.

Dans un mode particulier de réalisation de l’invention, l’identifiant de corrélation est destiné à établir la corrélation entre des messages associés à un service, autrement dit il est spécifiquement prévu pour ce seul usage.

Ainsi, et de façon générale, l’invention propose d’introduire un identifiant de corrélation associé de façon unique à un service réalisé par un réseau de télécommunication, d’enregistrer cet identifiant de corrélation dans un contexte associé à ce service, et d’insérer cet identifiant de corrélation dans les messages relatifs à ce service, indépendamment du protocole de ces messages et/ou de l’interface sur laquelle ils sont envoyés. Autrement dit, conformément à l’invention, les messages associés à un même service comprennent tous un même identifiant véhiculé à travers tous les protocoles et toutes les interfaces sollicitées pour la mise en œuvre du service, et qui permet de relier les messages entre eux de manière univoque. Le contexte dans lequel l’identifiant de corrélation est enregistré peut être le contexte qui regroupe de façon connue d’un homme du métier des télécommunications, l’ensemble des données nécessaires à la bonne exécution d’un service.

Les messages traités par différents équipements qui coopèrent pour la réalisation d’un service donné peuvent ainsi être corrélés par l’identifiant de corrélation proposé par l’invention. L’identification et l’analyse des messages échangés dans le cadre de ce service sont ainsi grandement facilitées, et ce, de façon très simple.

L’invention peut être mise en œuvre pour tout type de service, notamment pour un service d’enregistrement d’un terminal dans le réseau, un service d’établissement d’une communication sur le réseau, un service d’envoi d’un message court (en anglais SMS, short message service), un service de visioconférence, un service de souscription à un événement du réseau, par exemple un événement notifiant un dépôt de message ou un événement de conférence.

De façon très avantageuse, l’identifiant de corrélation peut être utilisé par le dispositif d’analyse pour collecter des informations sur l’ensemble des messages impliqués dans la mise en œuvre d’un service, quels que soient les protocoles de ces messages et les interfaces utilisées pour échanger ces messages. Les informations collectées peuvent être utilisées pour établir le diagnostic d’un problème (en anglais « troubleshooting ») ou pour faciliter l’analyse de résultats de tests automatiques de réseau, préoccupation majeure des opérateurs de télécommunication, valider un service, vérifier une répartition de charge. L’invention peut aussi être mise en œuvre dans le cadre d’interceptions légales par exemple.

Dans un mode de réalisation du procédé de traitement selon l’invention, l’identifiant de corrélation est extrait d’un champ dédié d’un message reçu par le dispositif. Ainsi, lorsqu’un dispositif reçoit un message, il vérifie si ce message comporte un identifiant de corrélation dans ce champ dédié et l’enregistre dans le contexte associé au service réalisé par ce message si ce n’est pas déjà fait. Le dispositif peut alors insérer dans les messages qu’il émet à destination des autres dispositifs du réseau, quel que soit leur protocole, et quelle que soit l’interface utilisée, pour propager l’identifiant de corrélation de sorte à corréler tous les messages impliqués dans un même service.

Lorsqu’un dispositif reçoit un message comportant l’identifiant de corrélation, le dispositif peut propager le message vers un autre dispositif, après avoir vérifié que l’identifiant de corrélation est bien enregistré dans le contexte associé au service auquel les messages reçus et propagés (c’est-à-dire envoyés) participent.

L’identifiant de corrélation propagé par un dispositif peut être identique à celui reçu par le dispositif ou dérivé de celui-ci.

L’identifiant peut par exemple être constitué par une racine commune à tous les messages relatifs au service complétée par des informations complémentaires avant insertion dans un message.

Dans un mode de réalisation, au moins une partie de l’identifiant de corrélation, par exemple la racine précitée, peut être générée aléatoirement.

Ces informations complémentaires peuvent être de toute nature. Elles peuvent par exemple représenter un utilisateur du dispositif qui insère l’identifiant de corrélation dans le message, un instant de génération de l’identifiant …

Une information complémentaire peut aussi représenter le dispositif qui insère l’identifiant de corrélation dans le message. Il peut par exemple s’agir de l’IMSI (International Mobile Subscriber Identity) ou l’IMEI (International Mobile Equipment Identity) pour un dispositif mobile et de l’adresse MAC (Media Access Control) pour un dispositif fixe.

Cette information complémentaire permet de tracer simplement l’ensemble des sessions / souscriptions / services invoqués à l’initiative d’un dispositif ou d’un utilisateur.

Dans un mode de réalisation du procédé de traitement selon l’invention, l’identifiant de corrélation est généré par ledit dispositif.

Par exemple, dans un mode de réalisation du procédé de traitement selon l’invention, l’identifiant de corrélation est généré par ledit dispositif et inséré dans un message émis par ledit dispositif, lorsque ledit message émis est le premier message émis par ledit dispositif dans le cadre d’un service.

C’est notamment le cas pour le premier dispositif impliqué dans le service, par exemple l’équipement utilisateur.

Dans un autre mode de réalisation du procédé de traitement selon l’invention, l’identifiant de corrélation est généré par ledit dispositif, sur réception d’un message relatif à un service et ne comportant pas d’identifiant de corrélation. Ainsi, lorsque le premier équipement impliqué dans le service n’est pas conforme à l’invention ou n’est pas en mesure de générer l’identifiant de corrélation, celui-ci peut être généré par le premier équipement de la chaîne de dispositifs impliqués dans le service sur réception d’un message qui bien que participant au même service, ne comporte pas d’identifiant de corrélation.

Dans un mode de réalisation, chaque message envoyé en vue de réaliser un service comprend l’identifiant de corrélation associé à ce service sauf si ce message est envoyé sur une interface de communication vérifiant un critère prédéfini.

Ce critère prédéfini peut par exemple être que l’interface de communication est une interface radio. Ce mode de réalisation évite de surcharger les messages véhiculés sur l’interface air, entre la station de base eNodeB et les terminaux UE, et d’économiser ainsi les ressources radio.

En variante, ce critère prédéfini peut être que l’interface de communication est une interface entre deux équipements donnés du réseau, par exemple entre l’entité MME et la station eNodeB, pour lesquels l’analyse des messages échangés entre ces deux équipements n’est pas utile.

Dans un mode de réalisation, chaque message envoyé en vue de réaliser un service comprend l’identifiant de corrélation associé à ce service sauf si ce message est envoyé à destination d’un réseau externe vérifiant un critère prédéfini.

Ce critère prédéfini peut être que le réseau externe ne dispose pas d’accord avec le réseau dans lequel l’invention est mise en œuvre.

Ces exemples de critères ne sont pas exhaustifs et d’autres critères peuvent être envisagés.

Le procédé de traitement de messages peut être mise en œuvre par un programme d’ordinateur.

Par conséquent, l’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur, ce programme comporte des instructions permettant la mise en œuvre d’un procédé tel que décrit 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'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur, ou une mémoire flash.

D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.

Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l’un des procédés tels que décrits précédemment.

D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :

la figure 1 représente un système conforme à un mode particulier de réalisation de l’invention ;

la figure 2 représente sous forme d’ordinogramme les principales étapes d’un procédé de traitement de messages conforme à un mode particulier de réalisation de l’invention ;

la figure 3A représente un exemple de champ d’un message pouvant être utilisé dans un mode particulier de réalisation de l’invention ;

la figure 3B représente un exemple de déclaration d’un package H.248 définissant l’identifiant de corrélation CID pour le protocole H.248 conformément à un mode particulier de réalisation de l’invention ;

la figure 4A présente une séquence de messages d’établissement d’un appel vocal conforme à l’état de la technique ;

la figure 4B illustre un exemple de mise en œuvre de l’invention dans le contexte de la séquence de messages de la figure 4A ;

la figure 5A présente une séquence de messages, connue de l’art antérieur, pour l’enregistrement d’un équipement utilisateur dans un réseau IMS ;

la figure illustre un exemple de mise en œuvre de l’invention dans le contexte de la séquence de messages de la figure 5A ;

la figure 6A illustre un flux de signalisation conforme à l’état de la technique pour configurer une session du réseau d'accès IMS ;

la figure 6B illustre comment les messages de la figure 6A peuvent être modifiés par un exemple de mise en œuvre de l’invention ;

la figure 7 représente l’architecture matérielle d’un dispositif de traitement de messages conforme à un mode particulier de réalisation de l’invention ; et

la figure 8 représente l’architecture fonctionnelle d’un dispositif de traitement de messages conforme à un mode particulier de réalisation de l’invention.

Description détaillée de plusieurs modes de réalisation particuliers

La figure 1 représente un système S conforme à un mode particulier de réalisation de l’invention dans un réseau de télécommunications géré par un opérateur OP. Le système S comporte un ensemble de dispositifs 100ⁱ, i = 1, …,N de traitement de messages conformes à l’invention, une sonde SO, un espace de stockage SS, et un dispositif d’analyse DAN.

Les dispositifs de traitement 100ⁱde messages sont configurés pour communiquer entre eux via diverses interfaces de communication, au moyen de messages MSGⁱ _E, MSGⁱ _S, MSG’ⁱ _S, conformes à des protocoles identiques ou différents pour coopérer dans la réalisation d’un service donné (enregistrer un équipement utilisateur dans un réseau, établir une communication entre plusieurs équipements, mettre en place une visioconférence…). Dans ce sens, ces messages sont considérés comme associés à ce service et chacun ou certains des équipements mémorise comme de façon connue un contexte pour stocker les éléments nécessaires à la réalisation de ce service.

Les dispositifs de traitement 100ⁱde messages sont configurés conformément à l’invention pour enregistrer dans le contexte associé au service un identifiant de corrélation CID associé de manière unique à ce service, et permettant de corréler entre eux les messages échangés dans le cadre de ce service. Dans le mode de réalisation décrit ici, on suppose qu’un champ dédié destiné à contenir cet identifiant de corrélation CID a été prévu dans chaque protocole utilisé par le réseau de télécommunications, ce champ dédié pouvant varier d’un protocole à l’autre.

Sur cette figure et par la suite, on note MSGⁱ _Eun message reçu par le dispositif de traitement 100ⁱet MSGⁱ _S, MSG’ⁱ _Sdes messages émis par le dispositif de traitement 100ⁱdans le cadre de cette coopération.

Comme décrit ultérieurement, ces dispositifs 100ⁱsont configurés pour insérer dans tous les messages participant à un service (éventuellement à quelques exceptions près), l’identifiant de corrélation CID enregistré dans le contexte associé à ce service, ceci permettant d’établir un lien entre les messages appartenant à un même service, indépendamment des protocoles auxquels se conforment ces messages et des interfaces sur lesquelles sont véhiculés ces messages.

Dans la description ci-dessous, les dispositifs 100ⁱsont configurés pour tous insérer un même identifiant de corrélation CID pour un service donné. En variante, des identifiants de corrélation différents mais dérivés les uns des autres et comprenant une racine commune (par exemple complétée par un suffixe et/ou un préfixe variable(s)) peuvent être utilisés, l’important étant de pouvoir relier entre eux les identifiants de corrélation insérés dans l’ensemble des messages mis en œuvre dans la réalisation d’un service donné, et de pouvoir filtrer aisément les messages relatifs à un même service à partir de la racine commune.

La sonde SO est configurée pour scruter le réseau et enregistrer une copie de ces messages dans l’espace de stockage SS, par exemple dans des fichiers de trace. Les messages qui réalisent un même service comportent, dans un champ prédéfini par le protocole de ce message, un identifiant de corrélation associé à ce service.

Le dispositif d’analyse DAN comporte un module MCO de consultation configuré pour extraire les messages de l’espace de stockage SS en utilisant l’identifiant de corrélation CID associé à un service et un module MOA apte à déclencher l’analyse de ces messages. On note que le déclenchement de l’analyse des messages peut consister à les transmettre à l’opérateur OP du réseau ou à une entité tierce pour analyse. L’invention permet ainsi d’analyser tous les messages associés à un même service sur la base de l’identifiant de corrélation CID compris dans ces messages.

La figure 2 représente les principales étapes d’un procédé de traitement de message conforme à l’invention, mis en œuvre par un dispositif 100ⁱ.

Ce procédé comporte deux processus :
- le processus P1 est mis en œuvre par le dispositif 100ⁱpour émettre au moins un message MSGⁱ _S, suite à la réception d’un message entrant MSGⁱ _E; et
- le processus P2 est mis en œuvre par le dispositif 100ⁱpour émettre au moins un message MSGⁱ _S, cette émission n’étant pas en relation avec la réception d’un message par ce dispositif.

On suppose que le dispositif 100ⁱreçoit un message MSGⁱ _Eau cours d’une étape E10 et qu’il déclenche l’exécution du processus P1.

Au cours d’une étape E20, le dispositif 100ⁱvérifie si le message MSGⁱ _Ereçu à l’étape E10 comporte un identifiant de corrélation CID. Si c’est le cas le résultat du test E20 est positif, sinon il est négatif.

Dans le mode de réalisation décrit ici, comme mentionné précédemment, chaque protocole définit un champ dédié destiné à contenir l’identifiant de corrélation CID.

Par conséquent, à l’étape E20, le dispositif 100ⁱvérifie si le message MSGⁱ _Ecomporte le champ dédié défini par le protocole de ce message destiné à contenir l’identifiant de corrélation CID. Si ce champ existe dans le message MSGⁱ _Eet comporte une valeur, cette valeur est considérée comme étant un identifiant de corrélation CID au sens de l’invention.

Si le message MSGⁱ _Ereçu à l’étape E10 comporte un identifiant de corrélation CID, le dispositif 100ⁱvérifie au cours d’une étape E30 si cet identifiant de corrélation CID est enregistré dans le contexte CTX associé au service auquel contribue le message MSGⁱ _Eou dans le cadre duquel ce message est échangé. De façon connue de l’homme du métier, le contexte CTX associé à un service regroupe l’ensemble des données nécessaires à la bonne exécution de ce service ; l’homme du métier sait associer un message reçu au contexte du service auquel se rapporte ce message.

Si tel n’est pas le cas, le résultat du test E30 est négatif et le dispositif 100ⁱenregistre, au cours d’une étape E40, l’identifiant de corrélation CID dans le contexte CTX associé au service réalisé par le message MSGⁱ _E.

Si le message MSGⁱ _Ereçu à l’étape E10 ne comporte pas d’identifiant de corrélation (résultat du test E20 négatif), le dispositif 100ⁱvérifie au cours d’un test E50 si le contexte CTX associé au service réalisé par le message MSGⁱ _Ecomporte déjà un identifiant de corrélation CID.

Si tel n’est pas le cas, le résultat du test E50 est négatif et le dispositif 100ⁱgénère un identifiant de corrélation CID au cours d’une étape E60, puis enregistre, au cours d’une étape E70, cet identifiant de corrélation CID dans le contexte CTX associé au service réalisé par le message MSGⁱ _E.

L’identifiant de corrélation CID associé à un service peut être généré de façon aléatoire. Il peut en outre comporter plusieurs parties, par exemple :
- une partie commune (ou racine) permettant d’identifier et de corréler les messages participant à la réalisation de ce service ;
- une partie (ex. suffixe ou préfixe) identifiant une date et un instant de génération de l’identifiant de corrélation CID;
- une partie (ex. suffixe ou préfixe) identifiant le dispositif 100ⁱqui a généré cet identifiant, ou tout dispositif 100ⁱvia lequel l’identifiant a transité ;
- une partie (ex. suffixe ou préfixe) identifiant un utilisateur de ce dispositif.

Ces différentes parties sont définies en fonction des traitements sur les messages stockés qui pourront être effectués par le dispositif d’analyse DAN en appliquant des filtres correspondant à une ou plusieurs de ces parties (dont la racine commune).

Dans le mode de réalisation décrit ici, le test E50 lorsque son résultat est positif, le test E30 lorsque son résultat est positif, l’étape E40 et l’étape E70 sont suivis par une étape E80 au cours de laquelle le message MSGⁱ _Ereçu à l’étape E10 est traité. Ce traitement dépend du message MSGⁱ _Eet de la logique du service auquel il se rapporte. Il ne fait pas partie de l’invention. Différents exemples de traitement seront décrits ultérieurement.

Dans le mode de réalisation décrit ici, le dispositif 100ⁱdétermine, au cours d’une étape E82, si le dispositif 100ⁱdoit envoyer au moins un message MSGⁱ _Sà au moins un équipement 100^jdu réseau suite à ou dans le cadre de ce traitement. Si tel n’est pas le cas, le résultat du test E82 est négatif et le processus P1 s’arrête.

Si le dispositif 100ⁱdoit transmettre au moins un message MSGⁱ _Sà au moins un équipement 100^jdu réseau, le dispositif 100ⁱdétermine, au cours d’un test E84, si l’identifiant de corrélation CID doit être inséré dans ce message.

Conformément à l’invention, l’identifiant de corrélation CID est inséré dans chaque message émis par le dispositif 100ⁱdans le cadre du service considéré pour être en mesure de corréler aisément les messages échangés par les diverses entités du réseau se rapportant à ce service. Toutefois, dans un mode particulier de réalisation, on peut envisager quelques exceptions, notamment en vue d’économiser les ressources du réseau, ou lorsque les messages sont émis vers un autre réseau que l’opérateur OP ne contrôle pas. Par exemple, il peut être décidé de ne pas insérer l’identifiant de corrélation CID :
- dans les messages envoyés sur une interface de communication radio ; ni
- dans les messages émis vers un réseau externe qui ne dispose pas d’accord avec le réseau de l’opérateur OP.

D’autres exceptions peuvent être envisagées, comme par exemple, exclure la transmission de l’identifiant de corrélation entre deux entités données du réseau pour lesquelles cela ne présente pas ou peu d’intérêt d’analyser les messages échangés entre ces entités, de sorte à préserver les ressources du réseau.

Si l’identifiant de corrélation CID doit être compris dans un message MSGⁱ _S, le résultat du test E84 est positif. Lorsque le message MSGⁱ _Sà envoyer est un simple transfert (ou propagation) du message reçu MSGⁱ _E, le dispositif 100ⁱn’a pas à proprement parler besoin d’insérer l’identifiant de corrélation CID dans le message MSGⁱ _S, mais juste de contrôler que l’identifiant de corrélation CID est bien présent dans les message MSGⁱ _S. Sinon, le dispositif 100ⁱinsère l’identifiant de corrélation CID dans le message MSGⁱ _Sau cours d’une étape E90.

Le dispositif 100ⁱenvoie le message au dispositif 100^jau cours d’une étape E100.

Si le résultat du test E84 est négatif, le dispositif 100ⁱenvoie le message MSGⁱ _Sau dispositif 100^j(étape E100) sans y insérer l’identifiant de corrélation CID.

On rappelle que chacun des messages MSGⁱ _Speut être envoyé par le dispositif 100i selon un protocole identique au ou distinct du protocole du message reçu MSGⁱ _E. Les exemples décrits ci-après illustreront en particulier des situations dans lesquelles :
- les messages reçu MSGⁱ _Eet envoyé MSGⁱ _Ssont tous les deux conformes au protocole SIP ;
- les messages reçu MSGⁱ _Eet envoyé MSGⁱ _Ssont tous les deux conformes au protocole Diameter ;
- les messages reçu MSGⁱ _Eet envoyé MSGⁱ _Ssont respectivement conformes aux protocoles SIP et Diameter.

Le procédé de traitement de message conforme à l’invention décrit ici comporte également un processus P2 mis en œuvre par le dispositif 100i pour émettre au moins un message MSGⁱ _S, cette émission n’étant pas en relation avec la réception d’un message par ce dispositif.

Au cours d’une étape E11, le dispositif 100ⁱdétermine si le contexte associé au service réalisé par le message MSGⁱ _Scomporte un identifiant de corrélation CID.

Si tel n’est pas le cas, le résultat du test E11 est négatif et le processus P2 comporte une étape E14, similaire à l’étape E60 au cours de laquelle le dispositif 100ⁱgénère un identifiant de corrélation CID et une étape E16, similaire à l’étape E70, au cours de laquelle le dispositif 100ⁱenregistre cet identifiant de corrélation CID dans le contexte CTX associé au service réalisé par le message MSGⁱ _S.

L’étape E16 est suivie par le test E84 déjà décrit au cours duquel le dispositif 100ⁱdétermine si l’identifiant de corrélation CID doit être inséré dans le message MSGⁱ _S.

Le message MSGⁱ _Sest transmis au dispositif 100^j,au cours de l’étape E100, ce message comprenant ou non l’identifiant de corrélation CID selon le résultat du test E84.

Si le dispositif 100ⁱdétermine (test E11) que le message MSGⁱ _Sparticipe à un service dont le contexte CTX comporte un identifiant de corrélation CID, le résultat du test E11 est positif, et le processus P2 obtient (étape E18) l’identifiant de corrélation enregistré dans ce contexte.

L’étape E18 est suivie par le test E84 déjà décrit au cours duquel le dispositif 100i détermine si l’identifiant de corrélation CID doit être inséré dans le message MSGⁱ _S. Le message MSGⁱ _Sest transmis au dispositif 100^j,au cours de l’étape E100, ce message comprenant ou non l’identifiant de corrélation CID selon le résultat du test E84.

Conformément à l’invention, le même identifiant de corrélation CID peut être avantageusement compris dans des messages conformes à différents protocoles et/ou émis sur différentes interfaces de communication.

Lorsque le message est conforme au protocole Diameter tel que défini dans le document IETF RFC 6733, l’identifiant de corrélation CID peut être compris dans un champ AVP (en anglais « Attribute-Value Pair ») du message prévu à cet effet, nommé par exemple « SIP-Correlation-ID », dont un exemple référencé ATD est donné à la figure 3A.

Lorsque le message est conforme au protocole H248 défini par la norme ITU-T.H.248.1, l’identifiant de corrélation CID peut être défini dans un nouveau paquet (en anglais « Package ») prévu à cet effet, dont un exemple référencé P248 est présenté à la figure 3B.
Lorsque le message est conforme au protocole GTPv2 défini dans le document de spécification 3GPP TS 29.274, l’identifiant de corrélation CID peut être inséré dans un nouvel élément d’information appelé par exemple « SIP-Correlation-ID » prévu à cet effet.

Nous allons maintenant illustrer par des exemples comment le procédé de traitement de messages selon l’invention peut être utilisé dans le cadre de différents services de communication (ex. établissement d’un appel, etc.) de l’état de la technique.

Ainsi, selon un premier exemple, la figure 4A présente une séquence de messages d’un service d’établissement d’un appel vocal telle qu’elle est décrite dans l’état de la technique, à la figure 5 du document « VoLTE Service Description and Implementation Guidelines Version 1.0 18 December 2014 ».

Au cours d’une étape D1, un équipement utilisateur UE1 envoie un message SIP INVITE dans lequel il définit les paramètres de la communication conformément au protocole SDP (Session Description Protocol). Ce message SIP INVITE est envoyé au P-CSCF (Proxy-Call Session Control Function) identifié pendant la procédure d’enregistrement de l’équipement utilisateur UE1.

Au cours d’une étape D2, le P-CSCF ajoute un en-tête comportant des informations de facturation (P-Charging-Vector) et transmet le message SIP INVITE au S-CSCF (Serving CSCF) identifié au cours de la procédure d'enregistrement.

Le S-CSCF vérifie si les services demandés peuvent être délivrés pour l’équipement utilisateur UE1. Si c’est le cas, le S-CSCF achemine, au cours d’une étape D3, le message SIP INVITE vers un serveur TAS (Telephony Application Server).

Au cours d’une étape D4, le S-CSCF achemine le message SIP INVITE vers l’I-CSCF (Interrogating CSCF) afin de déterminer le S-CSCF de la partie appelée.

Au cours d’une étape D5, l’équipement utilisateur appelé UE2 (non représenté) renvoie une réponse SDP dans un message SIP 183 Progress. La réponse SDP indique que des conditions préalables sont également souhaitées, qu'une confirmation doit être envoyée lorsque les conditions préalables de réservation de ressources seront remplies du côté de l’appelant, et que le flux média est inactif.

Le message SIP 183 Progress est reçu par le S-CSCF et transmis au P-CSCF (étape D6). Le P-CSCF utilise la réponse SDP pour configurer l'IMS-AGW (Access Gateway) s'il est déployé.

Au cours d’une étape D7, le P-CSCF analyse la réponse SDP et envoie un message AAR (Authorize/Authenticate Request) du protocole Diameter au PCRF avec les informations de service requises. Le PCRF associe les informations de service avec les informations d'abonnement correspondant aux services autorisés et les informations de qualité de service QoS. Le PCRF identifie la session IP-CAN (IP-Connectivity Access Network) qui a été établie au cours de la procédure d’attachement LTE Attach.

Au cours d’une étape D8, le PCRF envoie une requête RAR (protocole Diameter) à la passerelle PGW (Packet Data Network Gateway) pour déclencher la création d'un support (en anglais bearer) dédié à la voix avec les paramètres de qualité de service associés.

Au cours d’une étape D9, la passerelle PGW accuse réception du message RAR (protocole Diameter) au PCRF.

Le PCRF accuse ensuite réception du message AAR (protocole Diameter) au P-CSCF au cours d’une étape D10. À ce stade, la session SIP IMS et le support utilisé pour la voix sont liés.

Au cours d’une étape D11, la passerelle PGW envoie un message Create Bearer Request à la passerelle SGW (Serving Gateway) conforme au protocole GTP-v2 afin de créer le support pour les médias VoLTE.

Au cours d’une étape D12, la passerelle SGW envoie le message Create Bearer Request (protocole GTP-v2) à l’entité MME (Mobility Management Entity).

Au cours d’une étape D13, l’entité MME envoie un message E-RAB Setup Request (protocole S1 AP) à la station de base eNodeB comportant notamment les paramètres de qualité de service pour activer le support (bearer) pour le trafic vocal.

La station de base eNodeB associe ces paramètres de qualité de service à ceux requis pour le support radio, puis envoie, au cours d’une étape D14, une demande de reconfiguration de connexion RRC Conn Reconfiguration (protocole RRC) à l’équipement utilisateur appelant UE1.

Au cours d’une étape D15, l’équipement utilisateur appelant UE1 envoie un message (RRC Conn Reconfiguration Response) (protocole RRC) d’accusé de réception à la station de base eNodeB.

La station de base eNodeB accuse réception à l’entité MME du message E RAB Setup Request (par l’envoi d’un message E-RAB Setup Response) (protocole S1 AP) au cours d’une étape D16.

Au cours d’une étape D17, l’entité MME envoie un message Create Bearer Response (protocole GTPv2) à la passerelle SGW pour accuser réception de l'activation du support. Ce message comprend l'identité du support et les informations sur la localisation de l'utilisateur.

La passerelle SGW transmet ces informations à la passerelle PGW (protocole GTPv2) au cours d’une activité D18.

Au cours d’une étape D19, le P-CSCF transmet la réponse SIP 183 Progress à l’équipement utilisateur appelant UE1.

Au cours d’une étape D20, l’équipement utilisateur UE1 génère un message PRACK (protocole SIP) qui est transmis au côté de terminaison de l'appel.

La figure 4B illustre un exemple de mise en œuvre de l’invention dans le cadre du service d’établissement d’un appel vocal décrit précédemment en référence à la figure 4A.

Dans cette figure, les messages sont marqués du signe « * » pour représenter le fait qu’ils comprennent un champ de corrélation CID.

Dans cet exemple, chacun des dispositifs UE1, eNB, MME ; SGW, PGW, PCRF ; P-CSCF, S-CSCF, TAS, I-CSCF et UE2 est un dispositif 100ⁱconforme à l’invention et met en œuvre le procédé de traitement de message décrit en référence à la figure 2. Pour mieux comprendre l’invention et notamment comment celle-ci s’articule avec la séquence des messages contribuant à la réalisation du service d’établissement de l’appel vocal présenté à la figure 4A, il est fait référence dans la suite, de façon combinée, aux étapes de la figure 4A et aux étapes de la figure 2 lorsque les étapes de la figure 2 viennent compléter les étapes de la figure 4A.

Dans cet exemple, lorsque l’équipement utilisateur appelant UE1 veut envoyer un message SIP INVITE, il exécute le processus P2 du procédé de traitement de message. Au cours d’une étape E14, il génère un identifiant de corrélation CID, et l’enregistre dans le contexte CXT associé au service d’établissement d’appel vocal au cours d’une étape E16 de ce procédé. Il insère l’identifiant de corrélation CID dans le message SIP INVITE (étape E90) et envoie ce message au P-CSCF (étape D1, étape E100).

Lorsque le P-CSCF reçoit ce message SIP-INVITE (résultat du test E10 positif), il crée un contexte CTX associé au service d’établissement d’appel vocal. Il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation n’est pas enregistré dans le contexte CTX. Le P-CSCF enregistre l’identifiant de corrélation dans le contexte CTX (étape E40) puis traite le message SIP INVITE (étape E80). Ce traitement consiste notamment à ajouter au message un en-tête comportant des informations de facturation (P-Charging-Vector). Le P-CSCF détermine (test E82) qu’il doit propager le message SIP INVITE au S-CSCF. Dans le mode de réalisation décrit ici, le P-CSCF contrôle que l’identifiant de corrélation est déjà inséré dans ce message SIP INVITE. Le P-CSCF propage le message SIP INVITE au SCSCF (étape E100, étape D2).

Lorsque le S-CSCF reçoit le message SIP-INVITE (résultat du test E10 positif), il crée un contexte CTX pour le service d’établissement d’appel vocal. Il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation n’est pas enregistré dans le contexte CTX. Le S-CSCF enregistre l’identifiant de corrélation dans le contexte CTX (étape E40) puis traite le message SIP INVITE (étape E80). Au cours de ce traitement, le S-CSCF vérifie notamment si les services demandés peuvent être délivrés pour l’équipement utilisateur appelant UE1.

Le S-CSCF détermine (test E82) qu’il doit propager le message SIP INVITE vers le TAS. Dans le mode de réalisation décrit ici, le S-CSCF contrôle que l’identifiant de corrélation CID est déjà compris dans ce message SIP INVITE. Le S-CSCF propage le message SIP INVITE au serveur TAS (étape E100, étape D3).

Le S-CSCF détermine qu’il doit également propager le message SIP INVITE vers l’I-CSCF. Dans le mode de réalisation décrit ici, le S-CSCF détermine que l’identifiant de corrélation doit aussi être compris dans ce message SIP INVITE. Le S-CSCF transmet le message SIP INVITE à l’I-CSCF (étape E100, étape D4) pour que celui-ci détermine le S-CSCF de la partie appelée.

Lorsque l’équipement utilisateur appelé UE2 reçoit le message SIP INVITE (résultat du test E10 positif), il crée un contexte CTX pour ce service d’établissement d’appel vocal. Il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation n’est pas enregistré dans le contexte CTX. L’équipement utilisateur appelé UE2 enregistre l’identifiant de corrélation CID dans le contexte CTX (étape E40) puis traite le message SIP INVITE (étape E80).

Au cours d’une étape E90, l’équipement utilisateur appelé UE2 insère l’identifiant de corrélation dans le message SIP 183 Progress. L’équipement utilisateur appelé UE2 renvoie le message SIP 183 Progress à destination de l’équipement utilisateur appelant UE1 (étape D5, étape E100).

Lorsque le S-CSCF reçoit le message SIP 183 Progress, il détermine (test E20) que ce message comporte un identifiant de corrélation CID et (test E30) que cet identifiant de corrélation est déjà enregistré dans le contexte CTX de service d’établissement d’appel vocal. Il propage ce message SIP 183 Progress au P-CSCF (étape D6).

Lorsque le P-CSCF reçoit le message SIP 183 Progress, il détermine (test E20) que ce message comporte un identifiant de corrélation CID et (test E30) que cet identifiant de corrélation est déjà enregistré dans le contexte CTX du service d’établissement d’appel vocal. Le P-CSCF traite le message au cours d’une étape E80, ce traitement consistant notamment à analyser la réponse SDP contenue dans le message. Il insère (étape E90) l’identifiant de corrélation CID dans le message AAR du protocole Diameter en utilisant un nouveau champ AVP SIP-Correlation-ID défini dans ce protocole et envoie (étape E100, étape D7) le message AAR (protocole Diameter) au PCRF.

Lorsque le PCRF reçoit le message AAR du protocole Diameter, il crée un contexte CTX pour le service d’établissement d’appel vocal. Il détermine (test E20) que ce message AAR comporte un identifiant de corrélation CID et (test E30) que cet identifiant de corrélation n’est pas enregistré dans le contexte CTX. Le PCRF enregistre l’identifiant de corrélation dans le contexte CTX (étape E40) et traite le message AAR au cours d’une étape E80. Ce traitement consiste notamment à associer les informations de service avec les informations d'abonnement correspondant aux services autorisés et les informations de qualité de service QoS. Au cours d’une étape E90 le PCRF insère l’identifiant de corrélation CID dans le message RAR du protocole Diameter. Le PCRF envoie (étape D8, étape E100) la requête RAR à la passerelle PGW.

Lorsque la passerelle PGW reçoit le message RAR (protocole Diameter), elle crée un contexte CTX pour le service d’établissement d’appel vocal. Elle détermine (test E20) que le message RAR comporte un identifiant de corrélation CID et (test E30) que cet identifiant de corrélation CID n’est pas enregistré dans le contexte CTX. La passerelle PGW enregistre l’identifiant de corrélation CID dans le contexte CTX (étape E40) et traite le message RAR au cours d’une étape E80.

Au cours d’une première instance de l’étape E90 la passerelle PGW insère l’identifiant de corrélation CID dans le message RAA (protocole Diameter) qu’elle envoie (étape D9, étape E100) au PCRF.

Au cours d’une deuxième instance de l’étape E90 la passerelle PGW insère l’identifiant de corrélation CID dans le message Create Bearer Request conforme au protocole GTP-v2 qu’elle envoie (étape D11, étape E100) à la passerelle SGW (Serving Gateway) afin de créer le support pour les médias VoLTE. La passerelle PGW utilise à cet effet un nouvel élément d’information du protocole GTP-v2 défini pour porter l’identifiant de corrélation CID.

Le PCRF insère l’identifiant de corrélation CID dans le message AAA du protocole Diameter qu’il envoie au P-CSCF (étape E100, étape D10).

Lorsque la passerelle SGW reçoit le message Create Bearer Request (protocole GTP-v2), elle crée un contexte CTX pour l’appel vocal. Elle détermine (test E20) que ce message comporte un identifiant de corrélation CID et (test E30) que cet identifiant de corrélation CID n’est pas enregistré dans le contexte CTX. La passerelle SGW enregistre l’identifiant de corrélation dans le contexte CTX (étape E40) et traite le message Create Bearer Request au cours d’une étape E80. La passerelle SGW propage le message Create Bearer Request à l’entité MME (étape E100, étape D12).

Dans le mode de réalisation décrit ici, lorsque l’entité MME reçoit le message Create Bearer Request (protocole GTP-v2), elle crée un contexte CTX pour le service d’établissement d’appel vocal. Elle détermine (test E20) que ce message comporte un identifiant de corrélation CID et (test E30) que cet identifiant de corrélation n’est pas enregistré dans son contexte CTX. L’entité MME enregistre l’identifiant de corrélation dans son contexte CTX (étape E40) et traite le message Create Bearer Request au cours d’une étape E80.

Dans le mode de réalisation décrit ici, l’entité MME décide à l’étape E84 que l’identifiant de corrélation CID doit être compris dans le message E-RAB Setup Request (protocole S1 AP) qu’elle doit envoyer à la station de base eNodeB pour activer le support (bearer) pour le trafic vocal. L’entité MME insère l’identifiant de corrélation CID dans le message E-RAB Setup Request (protocole S1 AP) et envoie ce message à la station de base eNodeB (étape E100, étape D13).

Lorsque la station de base eNodeB reçoit le message E-RAB Setup Request, elle crée un contexte CTX pour le service d’établissement d’appel vocal. Elle détermine (test E20) que ce message E-RAB Setup Request comporte un identifiant de corrélation et (test E30) que cet identifiant de corrélation n’est pas enregistré dans le contexte CTX. La station de base eNodeB enregistre l’identifiant de corrélation CID dans le contexte CTX (étape E40) et traite le message E-RAB Setup Request au cours d’une étape E80. Ce traitement consiste en particulier à associer les paramètres de qualité de service à ceux requis pour le support radio. Dans le mode de réalisation décrit ici, la station de base eNodeB décide (étape E84) de ne pas envoyer l’identifiant de corrélation CID dans le message de demande de reconfiguration de connexion RRC Conn Reconfiguration qu’elle envoie à l’équipement utilisateur appelant UE1 via l’interface radio (étape E100, étape D14).

L’équipement utilisateur appelant UE1 reçoit le message de demande de reconfiguration de connexion RRC Conn Reconfiguration et y répond par l’envoi d’un message (RRC Conn Reconfiguration Response) à la station de base eNodeB (étape E100, étape D15).

Lorsque la station de base eNodeB reçoit le message RRC Conn Reconfiguration Response, elle détermine (test E20) que ce message participe au service d’établissement d’appel associé au contexte CTX et que ce contexte CTX comporte un identifiant de corrélation CID (test E30) La station de base eNodeB insère l’identifiant de corrélation CID dans le message E-RAB Setup Response (protocole S1 AP) qu’elle envoie à l’entité MME (étape E100, étape D16).

Lorsque l’entité MME reçoit le message E-RAB Setup Response, elle détermine (test E20) que ce message comporte un identifiant de corrélation CID et (test E30) que cet identifiant de corrélation est déjà enregistré le contexte CTX associé au service d’établissement d’appel. L’entité MME insère l’identifiant de corrélation CID dans le message Create Bearer Response (protocole GTPv2) qu’elle envoie à passerelle SGW (étape E100, étape D17).

Lorsque la passerelle SGW reçoit le message Create Bearer Response, elle détermine (test E20) que ce message comporte un identifiant de corrélation CID et (test E30) que cet identifiant de corrélation est déjà enregistré dans le contexte CTX associé au service d’établissement d’appel. La passerelle SGW propage le message Create Bearer Response vers la passerelle PGW (étape E100, étape D18).

Le P-CSCF insère l’identifiant de corrélation CID dans la réponse SIP 183 Progress qu’il transmet à l’équipement utilisateur appelant UE1 (étape D19).

L’équipement utilisateur appelant UE1 insère l’identifiant de corrélation CID dans le message SIP PRACK qu’il transmet au côté de terminaison de l'appel (étape D20).

Dans le mode de réalisation décrit ci-dessus, l’entité MME a décidé à l’étape E84 que l’identifiant de corrélation CID devait être envoyé dans le message E-RAB Setup Request (protocole S1 AP) à la station de base eNodeB.

Dans un autre mode de réalisation, à l’étape E84, l’entité MME décide de ne pas envoyer l’identifiant de corrélation CID à la station de base eNodeB.

Selon un deuxième exemple illustratif, la figure 5A présente une séquence de messages, connue de l’art antérieur, pour la réalisation d’un service d’enregistrement d’un équipement utilisateur UE dans un réseau IMS. Cette séquence est extraite de la figure 3 du document « VoLTE Service Description and Implementation Guidelines Version 1.0 18 December 2014 ».

Au cours d’une étape F1, l’équipement utilisateur UE envoie un message SIP REGISTER au P-CSCF identifié au cours de la procédure d’enregistrement.

Le P-CSCF reçoit la demande d'enregistrement SIP de l'équipement utilisateur UE et insère un en-tête PATH comportant l’adresse SIP-URI du P-CSCF et transmet la demande d’enregistrement à l'I-CSCF au cours d’une étape F2. L'I-CSCF peut être est déterminé par une requête DNS ou peut être préconfiguré dans le P-CSCF.

Au cours d’une étape F3, l’I-CSCF envoie un message UAR (User Authorization Request) du protocole Diameter au serveur HSS (Home Subscriber Server) pour obtenir l’identifiant du serveur S-CSCF associé à l’équipement utilisateur UE.

Le serveur HSS envoie cet identifiant au I-CSCF dans un message UAA (User Authorization Answer) du protocole Diameter au cours d’une étape F4.

Au cours d’une étape F5, l’I-CSCF transmet la demande d’enregistrement SIP REGISTER au S-CSCF.

Au cours d’une étape F6, le S-CSCF envoie un message MAR (Multimedia Authentication Request) (protocole Diameter) au serveur HSS afin de récupérer des vecteurs d'authentification du protocole de sécurité IMS AKA (Authentication and Key Agreement).

Au cours d’une étape F7, le serveur HSS renvoie les vecteurs d'authentification au S-CSCF dans un message MAA (Multimedia Authentication Answer) du protocole Diameter.

Sur réception des vecteurs d'authentification IMS AKA, le S-CSCF répond (étape F8) à la demande de SIP REGISTER en envoyant à l’I-CSCF une réponse SIP 401 Unauthorized indiquant le mécanisme de sécurité à utiliser.

Cette réponse est propagée (étape F9) par le I-CSCF au P-CSCF puis (étape F10) par le P-CSCF à l’équipement utilisateur UE.

L’équipement utilisateur UE extrait des paramètres RAND et AUTN de ce message de réponse SIP, calcule une valeur RES (user RESPONSE) du protocole AKA, et des clés de chiffrement et d'intégrité.

Au cours d’une étape F11, l’équipement utilisateur UE envoie un nouveau message de demande d’enregistrement SIP REGISTER au P-CSCF, ce message comportant la valeur RES indiquant que ce message est protégé.

Le P-CSCF vérifie les paramètres de sécurité et propage, au cours d’une étape F12, le message de demande d’enregistrement SIP REGISTER à l’I-CSCF en y incluant la valeur RES.

Au cours d’une étape F13, l’I-CSCF envoie un message UAR du protocole Diameter au serveur HSS pour récupérer le nom du S-CSCF. Le serveur HSS répond à ce message par l’envoi d’un message UAA du protocole Diameter au cours d’une étape F14.

L’I-CSCF transmet le message SIP REGISTER au S-CSCF au cours d’une étape F15.

Au cours d’une étape F16, le S-CSCF envoie un message SAR (Server Assignment Request) du protocole Diameter au serveur HSS pour obtenir le profil de l’utilisateur de l’équipement utilisateur UE.

Le serveur HSS envoie le profil de l’utilisateur au S-CSCF dans un message SAA (Server Assignment Answer) du protocole Diameter au cours d’une étape F17.

Au cours d’une étape F18, le S-CSCF envoie un message de réponse SIP 200 OK à l'I-CSCF, qui transmet ce message au P-CSCF au cours d’une étape F19.

Le P-CSCF transmet la réponse SIP 200 OK à l’équipement utilisateur UE au cours d’une étape F20 et l’équipement utilisateur UE est enregistré auprès du réseau IMS.

De façon optionnelle, le P-CSCF envoie au cours d’une étape F21 un message AAR (Authenticate and Authorize Request) du protocole Diameter au PCRF pour demander à être informé en cas de problème de communication pour déclencher un désenregistrement IMS.

Le PCRF répond au P-CSCF par un message AAA (Authenticate and Authorize Answer) du protocole Diameter au cours d’une étape F22.

La figure 5B illustre un exemple de mise en œuvre de l’invention dans le cadre du service d’enregistrement d’un équipement utilisateur UE décrit précédemment en référence à la figure 5A.

Dans cette figure, les messages sont marqués du signe « * » pour représenter le fait qu’ils comprennent un champ de corrélation CID.

Dans cet exemple, chacun des dispositifs UE, P-CSCF, I-CSCF, HSS, PCRF est un dispositif 100ⁱconforme à l’invention et met en œuvre le procédé de traitement de message décrit en référence à la figure 2.

Dans cet exemple, lorsque l’équipement utilisateur UE veut envoyer un message SIP REGISTER, il exécute le processus P2 du procédé de traitement de message. Au cours d’une étape E14, il génère un identifiant de corrélation CID, et l’enregistre dans le contexte CXT associé au service d’enregistrement de l’équipement UE au cours d’une étape E16 de ce procédé. Il insère l’identifiant de corrélation CID dans le message SIP REGISTER (étape E90) et envoie ce message au P-CSCF identifié au cours de la procédure d’enregistrement (étape F1, étape E100).

Lorsque le P-CSCF reçoit le message SIP REGISTER (résultat du test E10 positif), il crée un contexte CTX pour ce service d’enregistrement. Il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation n’est pas enregistré dans le contexte CTX. Le P-CSCF enregistre l’identifiant de corrélation dans le contexte CTX (étape E40) puis traite le message SIP REGISTER (étape E80). Le P-CSCF insère un en-tête PATH comportant l’adresse SIP-URI du P-CSCF dans le message SIP REGISTER puis propage ce message à l'I-CSCF (étape F2, étape E100).

Lorsque l’ICSCF reçoit le message SIP REGISTER (résultat du test E10 positif), il crée un contexte CTX pour ce service d’enregistrement. Il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation n’est pas enregistré dans le contexte CTX. L’I-CSCF enregistre l’identifiant de corrélation dans le contexte CTX (étape E40).

Dans le mode de réalisation décrit ici, l’I-CSCF décide (étape E84) de ne pas envoyer l’identifiant de corrélation CID dans le message UAR du protocole Diameter envoyé au serveur HSS (étape F3, étape E100).

Le serveur HSS répond au message UAR du protocole Diameter en envoyant au I-CSCF un message UAA comportant l’identifiant du S-CSCF.

L’I-CSCF détermine que ce message UAR participe au service d’enregistrement associé au contexte CTX et que ce contexte comporte un identifiant de corrélation CID. Il insère l’identifiant de corrélation CID (étape E90) dans la demande d’enregistrement SIP REGISTER et transmet cette demande au S-CSCF (étape F5, étape E100).

Lorsque le S-CSCF reçoit le message SIP REGISTER (résultat du test E10 positif), il crée un contexte CTX pour le service d’enregistrement. Il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation n’est pas enregistré dans le contexte CTX. Le S-CSCF enregistre l’identifiant de corrélation dans le contexte CTX (étape E40).

Dans le mode de réalisation décrit ici, le S-CSCF décide (étape E84) d’insérer l’identifiant de corrélation (étape E90) dans le message MAR (protocole Diameter) qu’il envoie au serveur HSS afin de récupérer des vecteurs d'authentification du protocole de sécurité IMS AKA (étape F6, étape E100).

Lorsque le serveur HSS reçoit le message MAR (résultat du test E10 positif), il crée un contexte CTX pour le service d’enregistrement. Il détermine (test E20) que ce message MAR comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation n’est pas enregistré dans le contexte CTX. Le serveur HSS enregistre l’identifiant de corrélation dans le contexte CTX et insère cet identifiant CID (étape E90) dans le message MAA (protocole Diameter) comportant les vecteurs d'authentification qu’il transmet ce message au S-CSCF (étape F7, étape E100).

Lorsque le S-CSCF reçoit le message MAA (résultat du test E10 positif), il détermine (test E20) que ce message participe à la réalisation du service d’enregistrement associé au contexte CTX et que ce contexte comporte un identifiant de corrélation CID (test E30). Le S-CSCF insère l’identifiant de corrélation (étape E90) dans le message SIP 401 Unauthorized et transmet ce message au I-CSCF (étape F8, étape E100).

Lorsque le I-CSCF reçoit le message SIP 401 Unauthorized (résultat du test E10 positif), il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation est enregistré dans le contexte CTX associé au service d’enregistrement de l’utilisateur UE. Le I-CSCF propage le message SIP 401 Unauthorized vers le P-CSCF (étape F9, étape E100).

Lorsque le P-CSCF reçoit le message SIP 401 Unauthorized (résultat du test E10 positif), il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation est déjà enregistré dans le contexte CTX associé au service d’enregistrement de l’utilisateur UE . Le P-CSCF propage le message 401 Unauthorized à l’équipement utilisateur UE (étape F10, étape E100).

Lorsque l’équipement utilisateur UE reçoit le message SIP 401 Unauthorized (résultat du test E10 positif), il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation CID est déjà enregistré dans le contexte associé au service d’enregistrement. L’équipement utilisateur UE traite ce message au cours d’une étape E80. Notamment, l’équipement utilisateur UE extrait des paramètres RAND et AUTN de ce message, calcule une valeur RES (user RESPONSE) du protocole AKA, et des clés de chiffrement et d'intégrité. L’équipement utilisateur UE insère l’identifiant de corrélation CID (étape E90) dans un nouveau message de demande d’enregistrement (étape E90) SIP REGISTER et transmet ce message au P-CSCF (étape F11, étape E100).

Lorsque le P-CSCF reçoit le nouveau message de demande d’enregistrement SIP REGISTER (résultat du test E10 positif), il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation est déjà enregistré dans le contexte associé au service d’enregistrement de l’utilisateur UE. Le dispositif P-CSCF traite ce message au cours d’une étape E80, notamment en vérifiant les paramètres de sécurité. Le dispositif P-CSCF insère la valeur RES et propage la nouvelle demande d’enregistrement SIP REGISTER au I-CSCF (étape F12, étape E100).

Lorsque le I-CSCF reçoit ce nouveau message de demande d’enregistrement SIP REGISTER résultat du test E10 positif), il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation est déjà enregistré dans le contexte associé au service d’enregistrement de l’utilisateur UE.

Dans le mode de réalisation décrit ici, l’I-CSCF décide (étape E84) de ne pas insérer l’identifiant de corrélation (étape E90) dans le message UAR du protocole Diameter qu’il envoie au HSS (étape F13, étape E100).

Le serveur HSS envoie le nom du S-CSCF au I-CSCF dans le message de réponse UAA (protocole Diameter).

L’I-CSCF contrôle que l’identifiant de corrélation CID est bien compris dans la demande d’enregistrement SIP REGISTER reçue de P-CSCF, et propage cette demande au S-CSCF (étape F15, étape E100).

Lorsque le S-CSCF reçoit le message SIP REGISTER (résultat du test E10 positif), il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation est déjà enregistré dans le contexte associé au service d’enregistrement de l’utilisateur UE. Le S-CSCF insère l’identifiant de corrélation CID (étape E90) dans le message SAR (protocole Diameter) et transmet ce message au serveur HSS pour obtenir le profil de l’utilisateur de l’équipement utilisateur UE (étape F16, étape E100).

Lorsque le serveur HSS reçoit le message SAR (résultat du test E10 positif), il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation est déjà enregistré dans le contexte associé au service d’enregistrement de l’utilisateur UE. Le serveur HSS insère l’identifiant de corrélation (étape E90) dans le message SAA (protocole Diameter) comportant le profil de l’utilisateur et transmet ce message au S-CSCF (étape F17, étape E100).

Lorsque le S-CSCF reçoit le message SAA (résultat du test E10 positif), il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation est déjà enregistré dans le contexte associé au service d’enregistrement de l’utilisateur UE. Le S-CSCF insère l’identifiant de corrélation (étape E90) dans le message de réponse SIP 200 OK et transmet ce message à l’I-CSCF (étape F18, étape E100).

Lorsque l’I-CSCF reçoit le message de réponse 200 OK (résultat du test E10 positif), il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation est déjà enregistré dans le contexte associé au service d’enregistrement de l’utilisateur UE. L’I-CSCF propage le message de réponse 200 OK au P-CSCF (étape F19, étape E100).

Lorsque le P-CSCF reçoit le message de réponse 200 OK (résultat du test E10 positif), il détermine (test E20) que ce message comporte un identifiant de corrélation CID, et que (test E30) cet identifiant de corrélation est déjà enregistré dans le contexte associé au service d’enregistrement de l’utilisateur UE. Le P-CSCF propage le message de réponse 200 OK l’équipement utilisateur UE (étape F20, étape E100).

De façon optionnelle, le P-CSCF insère l’identifiant de corrélation CID dans le message AAR du protocole Diameter qu’il envoie au PCRF pour demander à être informé en cas de problème de communication pour déclencher un désenregistrement IMS (étape F21).

Le PCRF répond au P-CSCF par un message AAA (Authenticate and Authorize Answer) comportant l’identifiant de corrélation CID au cours d’une étape F22.

En référence aux figures 6A et 6B, nous allons maintenant décrire un mode de mise en œuvre de l’invention dans un exemple d’interfonctionnement entre les protocoles SIP et H.248, par exemple dans le cadre d’un service de visioconférence.

A cet effet, la figure 6A illustre un flux de signalisation conforme à l’état de la technique pour configurer une session du réseau d'accès IMS vers le noyau IMS lorsque le P-CSCF invoque la fonction IMS-ALG (IMS Application Level Gateway). Cette figure correspond à la figure 6.2.1.2 du document 3GPP TS 23.334 version 12.

Au cours d’une étape G1, la passerelle IMS-ALG (IMS Application Level Gateway) reçoit une offre SDP en signalisation SIP.

À la réception d'une demande d'ouverture de session, la passerelle IMS-ALG extrait l'adresse ou les adresses du réseau de destination et le(s) numéro(s) de port de l'offrant du corps du message de signalisation reçu du point d'extrémité de la partie appelante. Au cours d’une étape G2, elle demande à la passerelle IMS-AGW d'allouer des ressources (T2) de transport IP via la procédure Reserve AGW Connection Point. Au cours d’une étape G3, la passerelle IMS-AGW crée la terminaison sortante. Sur réception de la réponse de la passerelle l'IMS-AGW, la passerelle IMS-ALG modifie l'adresse de destination et/ou le(s) port(s) de l'offrant contenu(s) dans le corps de message de signalisation de l'application et propage (étape G4) l'établissement de la session vers la partie appelante.

Au cours d’une étape G5, la passerelle IMS-ALG remplace l'adresse IP dans le SDP en utilisant les informations reçues de la passerelle IMS-AGW.

Au cours d’une étape G6, la passerelle IMS-ALG transmet la nouvelle offre SDP à la partie appelée.

Au cours d'une étape G7, la réponse SDP answer est reçue de la partie appelée par la passerelle IMS-ALG.

Sur réception du SDP de la partie de terminaison, la passerelle IMS-ALG envoie (étape G8) une commande H248 MD Req à la passerelle IMS-AGW dans le cadre de la procédure « Configure AGW Connection Point » et demande à la passerelle IMS-AGW d'attribuer des ressources de transport (T1) via la procédure « Reserve and Configure AGW Connection Point ». Au cours d’une étape G9, la passerelle IMS-AGW (ATGW) configure la terminaison sortante. Au cours d’une étape G10, la passerelle IMS-AGW répond à la passerelle IMS-ALG avec un message H.248 MOD Resp.

Sur réception de la réponse de la passerelle IMS-AGW, la passerelle IMS-ALG envoie un message H.248 ADD Req pour créer la terminaison entrante. Au cours d’une étape G12, la passerelle IMS-AGW crée la terminaison entrante. Au cours d’une étape G13, la passerelle IMS-AGW répond à la passerelle IMS-ALG avec un message H.248 ADD Resp et fournit l'adresse et le port de la terminaison entrante.

Au cours d’une étape G14, la passerelle IMS-ALG remplace l’adresse IP dans la réponse SDP en utilisant les informations reçues de la passerelle IMS-AGW.

Au cours d’une étape G15, le message SDP answer est envoyé en réponse à la commande INVITE reçue à l’étape G1.

La figure 6B illustre comment les messages de la figure 6A peuvent être modifiés par un exemple de mise en œuvre de l’invention.

Plus précisément, dans cet exemple :
- l’identifiant de corrélation CID est présent dans le message SIP Invite reçu à l’étape G1. Lorsque la passerelle IMS-ALG met en œuvre le procédé de traitement de message, elle détermine (étape E20) que l’identifiant de corrélation est dans le message SIP INVITE, elle détermine (étape E30) que l’identifiant de corrélation n’est pas dans le contexte CTX associé au service de visioconférence, l’enregistre par conséquent dans ce contexte (étape E40), l’insère dans le message H248 ADD req (étape E90) qu’elle envoie à la passerelle IMS AGW (étape G2, étape E100) ;

- lorsque la passerelle IMS-AGW reçoit le message H248 ADD req (étape G2), elle met en œuvre le procédé de traitement de ce message et détermine (étape E20) que l’identifiant de corrélation est présent dans ce message. Elle détermine (étape E30) que l’identifiant de corrélation CID n’est pas dans le contexte CTX associé au service de visioconférence et l’enregistre dans ce contexte (étape E40). La passerelle MS AGW traite ensuite le message H238 ADD Req en créant la terminaison sortante (étape E80, étape G3). Puis, la passerelle IMS AGW insère l’identifiant de corrélation CID dans le message H248 ADD resp (étape E90) qu’elle envoie à la passerelle IMS ALG (étape G4, étape E100) ;

- lorsque la passerelle IMS-ALG reçoit le message H248 ADD resp (étape G4), elle met en œuvre le procédé de traitement de ce message et détermine (étape E20) que l’identifiant de corrélation CID est présent dans ce message. Elle détermine (étape E30) que l’identifiant de corrélation CID est déjà dans le contexte CTX associé au service de visioconférence. La passerelle IMS AGW traite ensuite le message H238 ADD Resp en remplaçant l'adresse IP dans le SDP en utilisant les informations reçues de la passerelle IMS-AGW (étape E80, étape G5). La passerelle IMS ALG insère l’identifiant de corrélation dans un message SIP INVITE (étape E90) qu’elle envoie à la partie appelée (étape G6, étape E100). La passerelle IMS ALG insère également l’identifiant de corrélation CID dans un message H248 MOD req (étape E90) qu’elle envoie à la passerelle AGW (étape G8, étape E100) ;

- lorsque la partie appelée reçoit le message SIP INVITE (étape G6), elle met en œuvre le procédé de traitement de ce message et détermine (étape E20) que l’identifiant de corrélation est présent dans ce message. Elle détermine (étape E30) que l’identifiant de corrélation CID n’est pas dans le contexte CTX associé au service de visioconférence et l’enregistre par conséquent dans ce contexte (étape E40). La partie appelée insère l’identifiant de corrélation CID dans le message 183 SIP Progress (étape E90) qu’elle envoie à la passerelle IMS ALG (étape G7, étape E100) ;

- lorsque la passerelle AGW reçoit le message H248 Mode req (étape G8), elle met en œuvre le procédé de traitement de ce message et détermine (étape E20) que l’identifiant de corrélation est présent dans ce message. Elle détermine (étape E30) que l’identifiant de corrélation CID est enregistré dans le contexte CTX associé au service de visioconférence. La passerelle AGW traite alors le message H248 MOD Req en configurant la terminaison sortante (étape E80, étape G9). La passerelle AGW insère l’identifiant de corrélation CID dans le message H28 MOD Resp (étape E90) qu’elle envoie à la passerelle IMS ALG (étape G10, étape E100) ;

- lorsque la passerelle ALG reçoit le message H248 Mode resp (étape G10), elle met en œuvre le procédé de traitement de ce message et détermine (étape E20) que l’identifiant de corrélation est présent dans ce message. Elle détermine (étape E30) que l’identifiant de corrélation CID est enregistré dans le contexte CTX associé au service de visioconférence. La passerelle AGW insère l’identifiant de corrélation CID dans le message H28 ADD req (étape E90) qu’elle envoie à la passerelle IMS AGW (étape G11, étape E100) ;

- lorsque la passerelle AGW reçoit le message H248 ADD req (étape G11), elle met en œuvre le procédé de traitement de ce message et détermine (étape E20) que l’identifiant de corrélation est présent dans ce message. Elle détermine (étape E30) que l’identifiant de corrélation CID est enregistré dans le contexte CTX associé au service de visioconférence. La passerelle AGW traite alors le message H248 MOD Req en créant la terminaison entrante (étape E80, étape G12). La passerelle AGW insère l’identifiant de corrélation CID dans le message H248 ADD Resp (étape E90) qu’elle envoie à la passerelle IMS ALG (étape G13, étape E100) ;

- lorsque la passerelle IMS-ALG reçoit le message H248 ADD resp (étape G13), elle met en œuvre le procédé de traitement de ce message et détermine (étape E20) que l’identifiant de corrélation est présent dans ce message. Elle détermine (étape E30) que l’identifiant de corrélation CID est déjà dans le contexte CTX associé au service de visioconférence. La passerelle IMS AGW traite ensuite le message H248 ADD Resp en remplaçant l’adresse IP dans la réponse SDP en utilisant les informations reçues de la passerelle IMS-AGW (étape E80, étape G14). La passerelle IMS ALG insère l’identifiant de corrélation dans le message SIP 183 (étape E90) qu’elle envoie à la partie appelante (étape G15, étape E100).

En référence aux figures précédentes, il a été démontré sur plusieurs exemples, comment un dispositif 100ⁱpeut maintenir dans son contexte CTX un identifiant de corrélation CID compris dans les messages reçus MSGⁱ _Eou émis MSGⁱ _Sdans le cadre de la réalisation d’un service donné (enregistrement d’un équipement utilisateur dans un réseau, établissement d’une communication entre plusieurs équipements utilisateurs, accès à un service de visioconférence…).

La figure 7 représente l’architecture matérielle d’un dispositif 100ⁱconforme à un mode particulier de réalisation de l’invention. Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un ordinateur. Il comporte un processeur 10, des moyens de communication 11, une mémoire vive de type RAM 12, une mémoire non volatile réinscriptible 13 et une mémoire morte 14. La mémoire morte constitue un support d’informations pour stocker un programme d’ordinateur PG-TT-MSG conforme à l’invention. Lorsque le processeur 10 exécute ce programme d’ordinateur, il met en œuvre le procédé de traitement de message décrit en référence à la figure 2. Le contexte CTX associé à un service est enregistré dans la mémoire non volatile réinscriptible 13.

La figure 8 représente l’architecture fonctionnelle d’un dispositif 100ⁱconforme à un mode particulier de réalisation de l’invention. Ce dispositif peut être implémenté de façon matérielle comme illustré à la figure 7. Il comporte :
- un module MOIC configuré pour obtenir un identifiant de corrélation CID associé de façon unique à un service réalisé par un réseau de télécommunication, cet identifiant de corrélation étant apte à établir une corrélation entre des messages associés à ce service indépendamment des protocoles auxquels se conforment lesdits messages et/ou des interfaces sur lesquelles sont véhiculés lesdits messages;
- un module MEIC configuré pour enregistrer un identifiant de corrélation dans un contexte CTX associé à ce service ;
- un module de communication MCOM ; et
- un module MCT de contrôle configuré pour contrôler que chaque message envoyé par le dispositif 100ⁱen vue de réaliser le service comporte l’identifiant de corrélation associé à ce service.

Ce module de contrôle est en particulier configuré pour s’assurer, avant de propager un message reçu vers un autre dispositif, que le message propagé comporte bien l’identifiant de corrélation si cet identifiant doit être envoyé vers ce dispositif.

Claims (16)

1. Procédé (TT-MSG) de traitement de messages mis en œuvre par un dispositif (100ⁱ) dans un réseau de télécommunication, ce procédé comportant :
   - une étape (E20, E60, E11, E14) d’obtention d’un identifiant dit de corrélation (CID) associé de façon unique à un service réalisé par le réseau de télécommunication, ledit identifiant de corrélation étant apte à établir une corrélation entre des messages (MSGⁱ _E, MSGⁱ _S) associés audit service indépendamment des protocoles auxquels se conforment lesdits messages et/ou des interfaces sur lesquelles sont véhiculés lesdits messages ;
   - une étape (E16, E18, E40, E70) d’enregistrement dudit identifiant de corrélation (CID) dans un contexte (CTX) associé audit service; et
   - une étape d’envoi (E100) d’au moins un message (MSGⁱ _S) en vue de réaliser ledit service, chaque message envoyé comportant ledit identifiant de corrélation (CID) enregistré dans le contexte associé audit service.
2. Procédé (TT-MSG) de traitement selon la revendication 1 dans lequel, lors de l’étape d’obtention, ledit identifiant de corrélation (CID) est extrait (E20) d’un champ dédié d’un message (MSGⁱ _E) relatif audit service reçu par ledit dispositif (100ⁱ).
3. Procédé (TT-MSG) de traitement selon la revendication 2 dans lequel ledit message reçu (MSGⁱ _E) est conforme à un premier protocole, et au moins un dit message envoyé (MSGⁱ _S) lors de l’étape d’envoi est conforme à un deuxième protocole distinct du premier protocole.
4. Procédé (TT-MSG) de traitement selon l’une quelconque des revendications 1 à 3 dans lequel au moins un message envoyé (MSGⁱ _S) ou reçu (MSGⁱ _E) est conforme à un protocole parmi le protocole SIP, le protocole Diameter, le protocole GTPv2 et le protocole H.248.
5. Procédé (TT-MSG) de traitement selon la revendication 1, dans lequel ledit identifiant de corrélation (CID) est généré (E16, E60) par ledit dispositif (100ⁱ).
6. Procédé (TT-MSG) de traitement selon la revendication 5, dans lequel ledit identifiant de corrélation (CID) est généré (E60) par ledit dispositif (100ⁱ), sur réception d’un message (MSGⁱ _E) relatif audit service et ne comportant pas d’identifiant de corrélation (CID).
7. Procédé (TT-MSG) de traitement selon l’une quelconque des revendications 1 à 6, dans lequel chaque message (MSGⁱ _S) envoyé en vue de réaliser ledit service comprend ledit identifiant de corrélation (CID) sauf s’il est envoyé sur une interface de communication ou à destination d’un réseau externe vérifiant un critère prédéfini.
8. Procédé (TT-MSG) de traitement selon la revendication 7, dans lequel ledit critère prédéfini est :
   - ladite interface de communication est une interface radio ;
   - ledit réseau externe ne dispose pas d’accord avec ledit réseau.
9. Procédé (TT-MSG) de traitement selon l’une quelconque des revendications 1 à 8, dans lequel ledit identifiant de corrélation (CID) comprend au moins une partie générée aléatoirement.
10. Procédé (TT-MSG) de traitement selon l’une quelconque des revendications 1 à 9 dans lequel ledit identifiant de corrélation (CID) comprend au moins une partie identifiant ledit dispositif (100ⁱ).
11. Procédé (TT-MSG) de traitement selon l’une quelconque des revendications 1 à 10 dans lequel ledit service est un service parmi :
    - un service d’enregistrement sur le réseau ;
    - un service d’établissement d’une communication sur le réseau ;
    - un service de visioconférence ;
    - un service d’envoi d’un message court ;
    - un service de souscription à un événement dudit réseau.
12. Programme d’ordinateur (PG-TT-MSG) comportant des instructions pour la mise en œuvre d’un procédé de traitement de messages selon l’une quelconque des revendications 1 à 11 lorsque le programme est exécuté par un ordinateur.
13. Support d’enregistrement comprenant un programme d’ordinateur (PG-TT-MSG) selon la revendication 12.
14. Dispositif (100ⁱ) de traitement de messages comportant :
    - un module (MOIC) d’obtention d’un identifiant dit de corrélation (CID) associé de façon unique à un service réalisé par un réseau de télécommunication, ledit identifiant de corrélation étant apte à établir une corrélation entre des messages associés audit service indépendamment des protocoles auxquels se conforment lesdits messages et/ou des interfaces sur lesquelles sont véhiculés lesdits messages ;
    - un module (MEIC) d’enregistrement dudit identifiant de corrélation (CID) dans un contexte (CTX) associé audit service ;
    - un module (MCOM) de communication et
    - un module (MCTR) de contrôle configuré pour contrôler que chaque message (MSGⁱ _S) envoyé par le dispositif (100ⁱ) en vue de réaliser ledit service comporte ledit identifiant de corrélation associé audit service.
15. Système (S) comportant au moins un dispositif (100ⁱ) de traitement de messages selon la revendication 14.
16. Système selon la revendication 15 comportant :
    - au moins un espace de stockage (SS) dans lequel sont stockés desdits messages (MSGⁱ _E, MSGⁱ _S) comportant ledit identifiant de corrélation (CID) associé audit service ; et
    - un dispositif (MCO) de consultation configuré pour extraire au moins un message (MSGⁱ _E, MSGⁱ _S) dudit espace de stockage en utilisant ledit identifiant de corrélation (CID).