Brevet FR3036567A1 — publié le 20161125

Procédé de contrôle d'une session relative à un service L'invention se situe dans le domaine de la gestion de flux médias lors d'une session de communication entre deux entités, et concerne plus particulièrement un procédé de contrôle d'une session de communication relative à un service. Plusieurs méthodes de gestion de flux sont connues de l'état de la technique. Dans les réseaux de type IP (pour « Internet Protocol »), il est notamment connu de combiner le protocole SDP (pour « Session Description Protocol ») tel que défini dans le document RFC 4566 de l'IETF (pour « Internet Engineering Task Force »), avec le protocole SIP (pour « Session Initiation Protocol ») tel que décrit dans le document RFC 3261 également de l'IETF, afin d'établir, modifier ou encore terminer une session de communication multimédia entre deux entités. Le protocole SDP permet en particulier de décrire un ensemble de flux médias associés à une telle session de communication multimédia. Le document RFC 3264 de l'IETF, intitulé « An Offer/Answer Model with the Session Description Protocol », décrit par ailleurs un mécanisme permettant à deux entités d'utiliser le protocole SDP afin de négocier des paramètres relatifs à des flux médias souhaités pour une session à établir ou à modifier. Selon ce modèle, une première entité soumet une offre, dite « offre SDP », sous la forme d'une description de session afin d'établir ou modifier une session, à une deuxième entité. Cette offre comprend une liste de descriptions de flux médias précisant notamment pour chaque flux un type de média (e.g. audio, vidéo, texte), un numéro de port de destination, un protocole de transport, ou encore des informations d'encodage. L'entité qui soumet l'offre peut ainsi indiquer à l'entité destinataire de l'offre, les différents médias et caractéristiques (e.g. type d'encodage, bande passante requise, direction du flux) associées qu'elle est en mesure de prendre en charge. L'entité destinataire de l'offre, en fonction par exemple des médias et encodages qu'elle-même prend en charge, accepte l'offre en émettant une réponse, dite « réponse SDP », indiquant à l'entité émettrice de l'offre les flux médias qu'elle est en mesure de traiter. L'entité destinataire de l'offre peut également émettre une nouvelle offre à destination de la première entité, comprenant par exemple d'autres médias qu'elle souhaite ajouter à la session. Les deux entités sont ainsi susceptibles de jouer indifféremment le rôle de l'émetteur d'une offre et celui du destinataire d'une offre. Ce mécanisme d'offre/réponse est en outre également applicable pour des sessions de communications impliquant plus de deux participants (e.g. visioconférence comprenant plus de deux participants). Lors de la création de la session, certains flux sont susceptibles de ne pas être établis. De même, en cours de session, des flux peuvent être libérés de manière permanente ou temporaire en raison, par exemple, de caractéristiques du réseau (e.g. priorisation de certains flux) ou d'incidents survenant dans le réseau (e.g. panne d'un équipement du réseau, saturation des ressources du réseau). Par la suite, les expressions « perte de flux » ou « inactivité du flux » seront 3036567 2 indifféremment utilisées pour désigner le non-établissement ou la libération prématurée d'un flux associé à une session. L'inactivité d'un flux peut avoir un impact plus ou moins important sur la session à laquelle ce flux est associé. Selon le type de service duquel relève une session, un flux peut en effet s'avérer essentiel ou au contraire être de faible importance pour le maintien ou 5 l'établissement de cette dernière. Dans un réseau IMS (pour « IP Multimedia Subsystem »), de manière connue, une entité mandataire P-CSCF (pour « Proxy - Call Server Control Function ») peut demander à être notifiée d'évènements relatifs à une session relative à un service. Le document de spécification TS 129 214 v7.4.0 de l'ETSI (pour « European Telecommunications Standards Institute ») prévoit notamment 10 que l'entité mandataire P-CSCF puisse recevoir un message RAR (pour « Re-Authorization Request ») comprenant un champ « INDICATION_OF_LOSS_OF_BEARER » ou « INDICATION_OF_RELEASE_OF_BEARER » indiquant qu'un flux est inactif. En cas d'inactivité d'un tel flux au sein de la session, l'état de la technique ne propose cependant aucun mécanisme de contrôle de session qui soit adapté au service proposé via la session en cours ou à 15 établir. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. Selon un premier aspect, l'invention concerne un procédé de contrôle d'une session de fourniture d'un certain service, au moins un flux de données étant associé à la session, le procédé 20 comprenant : - une obtention, à partir d'un message de contrôle de session, ou une génération, en fonction d'un type du service, d'une politique de contrôle de session à mettre en oeuvre en cas d'inactivité d'au moins un flux de données, c'est-à-dire en cas de non-établissement ou de libération prématurée d'un flux de données associé à la session ; 25 - un envoi, dans un message de contrôle de session, de la politique de contrôle de session à une entité de contrôle en charge de mettre en oeuvre la politique de contrôle de session ; et - sur détection d'une inactivité d'au moins un flux de la session, une mise en oeuvre de la politique de contrôle de session. Le procédé de contrôle permet ainsi d'obtenir une politique de contrôle de session relative 30 à un service et d'agir sur la session en cours, ou à établir, en fonction du type de ce service. Le message de contrôle de session est par exemple relatif à une session entre une entité appelante et une entité appelée, et reçu depuis l'entité appelante, l'entité appelée ou encore depuis une entité intermédiaire du réseau située sur un chemin réseau entre l'entité appelante et l'entité appelée. Le procédé permet avantageusement de transmettre la politique de contrôle de session depuis une 35 entité en charge du contrôle du service (e.g. un serveur d'application ou AS pour « Application Server » en anglais) à une entité tierce (e.g. P-CSCF, terminal utilisateur) afin que cette dernière mette en oeuvre la politique de contrôle de session. Le message peut le cas échéant être directement 3036567 3 généré par l'entité en charge du contrôle du service. Le procédé permet notamment de subordonner des actions à mettre en oeuvre au niveau de la session en cas d'une inactivité détectée d'un flux de cette session, à une politique obtenue ou générée par l'entité en charge du contrôle du service. Une politique de contrôle de session adaptée au service fourni par la session peut ainsi être mise en 5 oeuvre. Selon une caractéristique particulière, la politique de contrôle de session appartient au groupe comprenant une libération immédiate de la session, une libération différée de la session, un maintien de la session, et une tentative de rétablissement d'un flux de la session. De nombreuses politiques de contrôle de session sont envisageables et peuvent être mises 10 en oeuvre par les entités réceptrices du message de contrôle de session. Le procédé en permettant de différencier les actions mises en oeuvre en fonction du type de service fourni par la session, offre un contrôle de la session en cas d'inactivité d'un flux plus précis qu'avec une simple prise en compte du type de ce flux. Selon le service proposé, pour un même type de flux, une inactivité du flux peut ainsi donner lieu à différentes politiques de contrôle de session. 15 Le procédé permet ainsi de mettre en oeuvre une politique de session adaptée au service proposé et au flux dont une inactivité a été détectée. Dans le cas par exemple où le service est un service de télésurveillance comprenant un flux vidéo et un flux audio, le flux audio étant considéré secondaire par rapport au flux vidéo, une inactivité du flux audio conduit avantageusement à mettre en oeuvre un maintien de la session, tandis qu'une inactivité du flux vidéo conduit à une tentative 20 de rétablissement de ce dernier flux. Au contraire, dans le cas par exemple d'un service de visioconférence comprenant un flux vidéo, un flux audio et un flux de sous-titrages, le flux audio étant considéré essentiel au maintien de la session, une inactivité de ce dernier conduit à une libération différée ou immédiate de la session. Selon une caractéristique particulière, la politique de contrôle de session est définie par un 25 attribut d'une description d'un flux de la session, comprise dans une offre ou une réponse SDP associée au message de contrôle de session. L'obtention de la politique de contrôle à partir d'une offre ou d'une réponse SDP, permet une mise en oeuvre aisée du procédé. Un message SDP peut en particulier facilement être encapsulé dans un message de contrôle d'un protocole de couche supérieure utilisant le protocole SDP. Il 30 n'est pas nécessaire de prévoir des extensions à un tel protocole pour mettre en oeuvre le procédé. Pour une entité de contrôle de type MGCF (pour « Media Gateway Control Function ») communiquant avec une entité média de type IMS-MGW (pour « IP Multimedia Subsystem Media Gateway ») par l'intermédiaire du protocole H.248, il est par exemple possible d'intégrer l'offre ou la réponse SDP contenant la politique de contrôle directement dans un message de 35 contrôle de ressources H.248. Une compatibilité du procédé avec de nombreux protocoles est ainsi assurée. 3036567 4 En outre, l'utilisation d'un attribut pour définir la politique de contrôle de session directement dans la description d'un flux contenue dans l'offre ou la réponse SDP, offre une lisibilité facilitée de cette information. Selon une caractéristique particulière, la politique de contrôle de session est comprise dans 5 un entête du message de contrôle de session. L'obtention de la politique de contrôle de session à partir d'un entête du message de contrôle de session permet de regrouper l'ensemble des politiques de contrôle de session relatives aux flux d'une même session en un même endroit. Il est en particulier possible de prédéterminer les politiques associées aux flux décrits dans une offre ou une réponse SDP sans analyse préalable de 10 cette offre ou réponse SDP. En outre, il n'est pas nécessaire de prévoir un attribut spécifique dans l'offre ou la réponse SDP pour définir une politique de contrôle de session en cas d'inactivité d'un flux. Le procédé peut ainsi être mis en oeuvre avec des entités générant des messages SDP selon des techniques connues. Selon une caractéristique particulière, la politique de contrôle de session est mise en oeuvre 15 sur détection d'une inactivité d'un flux de données appartenant au groupe comprenant un flux multimédia et un flux de contrôle. Selon une caractéristique particulière, le message de contrôle de session est un message SIP. Selon un deuxième aspect, l'invention concerne une entité de contrôle, d'une session de 20 fourniture d'un certain service, dite « entité primaire de contrôle », dans un réseau de communication, comprenant : - un module d'obtention et/ou un module de génération, agencés pour obtenir à partir d'un message de contrôle de session, ou générer en fonction d'un type du service, une politique de contrôle de session à mettre en oeuvre en cas d'inactivité d'au moins un flux de données, c'est-à- 25 dire en cas de non-établissement ou de libération prématurée d'un flux de données associé à la session ; - un module d'envoi, agencé pour envoyer dans un message de contrôle de session, la politique de contrôle de session à une entité de contrôle, dite « entité secondaire de contrôle », en charge de mettre en oeuvre la politique de contrôle de session. 30 Selon une caractéristique particulière, le module d'obtention est agencé pour obtenir la politique de contrôle de session à partir d'une offre ou d'une réponse SDP comprise dans le message de contrôle de session, la politique de contrôle de session étant un attribut d'une description d'un flux de la session contenue dans l'offre ou la réponse SDP. Selon une caractéristique particulière, le module d'obtention est agencé pour obtenir la 35 politique de contrôle de session à partir d'un entête du message de contrôle de session. 3036567 5 Selon un troisième aspect, l'invention concerne une entité de contrôle, d'une session de fourniture d'un certain service, dite « entité secondaire de contrôle », dans un réseau de communication, mettant en oeuvre des signaux de contrôle de session, comprenant : - un module de réception, agencé pour recevoir une politique de contrôle de session à 5 mettre en oeuvre en cas d'inactivité d'au moins un flux de données, c'est-à-dire en cas de non- établissement ou de libération prématurée d'un flux de données associé à la session ; - un module de mise en oeuvre, agencé pour mettre en oeuvre la politique de contrôle de session. Selon une caractéristique particulière, le module de mise en oeuvre est agencé pour exécuter 10 ou commander une libération immédiate de la session de fourniture d'un certain service, une libération différée de la session de fourniture d'un certain service, un maintien de la session de fourniture d'un certain service, ou une tentative de rétablissement d'un flux de la session de fourniture d'un certain service. Selon une caractéristique particulière, l'entité de contrôle selon le troisième aspect, 15 comprend en outre un module de détection, agencé pour détecter une inactivité d'au moins un flux de la session de fourniture d'un certain service. Selon un quatrième aspect, l'invention concerne un système de contrôle d'une session de fourniture d'un certain service, dans un réseau de communication. Le système comprend : - une entité de contrôle, dite « entité primaire de contrôle », selon une caractéristique 20 quelconque du deuxième aspect ; et - une entité de contrôle, dite « entité secondaire de contrôle », selon une caractéristique quelconque du troisième aspect. Cette entité secondaire de contrôle met en oeuvre, sur détection d'une inactivité d'au moins un flux d'une session de fourniture d'un certain service, une politique de contrôle de session reçue 25 de l'entité primaire de contrôle pour la session. Les avantages énoncés pour le procédé de contrôle de session selon le premier aspect sont directement transposables aux entités de contrôle selon le deuxième et le troisième aspect, ainsi qu' au système de contrôle selon le quatrième aspect. Selon un cinquième aspect, l'invention concerne également un programme pour une entité 30 de contrôle, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de contrôle de session précédemment décrit, lorsque le programme est exécuté par l'entité de contrôle et un support d'enregistrement lisible par une entité de contrôle sur lequel est enregistré un programme pour une entité de contrôle. L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation 35 particuliers, en référence aux dessins annexés sur lesquels : - la figure 1 représente un réseau de communication IMS (pour « IP Multimedia Subsystem ») selon un mode particulier de réalisation ; 3036567 6 - la figure 2a représente des étapes d'un procédé de contrôle de session de fourniture d'un service, mis en oeuvre par des entités d'un réseau de communication IMS selon un premier mode particulier de réalisation ; - la figue 2b représente des étapes d'un procédé de contrôle de session de fourniture d'un 5 service, mis en oeuvre par des entités d'un réseau de communication IMS selon un deuxième mode particulier de réalisation ; - le figure 3 représente une entité de contrôle, dite « entité primaire de contrôle », selon un mode particulier de réalisation ; - la figure 4 représente une entité de contrôle, dite « entité secondaire de contrôle », selon 10 un deuxième mode particulier de réalisation. La figure 1 représente un réseau de communication IMS 100 dans lequel des entités de contrôle selon l'invention mettent en oeuvre un procédé de contrôle d'une session de fourniture d'un service, entre une entité appelante 10 du réseau de communication IMS 100 et une entité 15 appelée 20 d'un réseau de communication IMS 200. Une architecture de réseau IMS telle que définie par le groupe de normalisation 3GPP (pour 3rd « Generation Partnership Project ») permet l'établissement et le contrôle de sessions entre des entités réseaux, ainsi que la réservation de ressources pour des flux de données au niveau d'un réseau de transport de données. Grâce à cette architecture, les opérateurs de réseaux peuvent commodément contrôler la qualité de service 20 offerte. L'architecture IMS permet d'offrir des services de type téléphonie, visiophonie, présence, messagerie instantanée, ou télévision, et gère également l'interaction de ces services. Elle met généralement en oeuvre le protocole SIP (pour « Session Initiation Protocol »), tel que défini par l'IETF (pour « Internet Engineering Task Force ») dans le document RFC 3261 en tant que protocole de gestion de sessions, lequel permet l'établissement, la modification et la terminaison de 25 sessions dans un réseau utilisant le protocole IP. Le réseau de communication 100 comprend plus particulièrement des entités de contrôle 30-33, une entité média 40, et une entité à la fois média et de contrôle 15. Les entités de contrôle et entités médias sont respectivement des entités aptes à traiter des messages de signalisation relatifs à la session de fourniture de service, et des entités aptes à traiter le transport de données relatives à la 30 session de fourniture de service. Les entités de contrôles sont dîtes appartenir à un plan de contrôle, tandis que les entités médias sont dîtes appartenir à un plan média. A titre d'exemple, l'entité de contrôle 30 est un serveur d'application AS (pour « Application Server »), l'entité de contrôle 31 est une entité de contrôle de règles PCRF (pour « Policy Control and Charging Rules Function »), l'entité de contrôle 32 est un serveur mandataire 35 P-CSCF (pour « Proxy - Call Server Control Function »), l'entité de contrôle 33 est une entité regroupant des fonctions d'interrogation I-CSCF (pour « Interrogating - Call Server Control Function ») et des fonctions d'enregistrement S-CSCF (pour « Serving - Call Server Control 3036567 7 Function »), l'entité à la fois média et de contrôle 15 est une passerelle PDN-GW (pour « Packet Data Network - Gateway), et l'entité média 40 est une passerelle IMS-AGW (pour « IMS- Access Gateway »). Les entités du réseau de communication IMS 100 sont mises en oeuvre pour gérer la session 5 entre l'entité appelante 10 et l'entité appelée 20. L'entité appelante 10 est abonnée au réseau de communication IMS 100 auquel elle accède par l'intermédiaire de la passerelle PDN-GW 15. L'entité appelée 20 est abonnée au réseau de communication IMS 200. Dans le mode de réalisation décrit, l'entité de contrôle 32 sert d'entité de raccordement entre le coeur du réseau de communication IMS 100 et le réseau d'accès utilisé par l'entité 10 appelante 10, et est apte à retransmettre tous les messages de signalisation entre l'entité appelante 10 et l'entité de contrôle 33. L'entité de contrôle 32 communique en outre avec l'entité média 40. L'entité de contrôle 33 permet notamment d'interroger un serveur d'abonnés (non représenté) afin de gérer la procédure d'enregistrement de l'entité appelante 10. Elle permet également de solliciter l'entité de contrôle 30 pour mettre en oeuvre un ou plusieurs services 15 associés à la session de fourniture de service. L'entité de contrôle 31 est chargée d'adapter et de contrôler l'usage des ressources réseaux du réseau de communication 100 en fournissant des règles de contrôle de la session en fonction par exemple des services requis par l'entité appelante 10 ou de son profil d'abonné. Les échanges entre respectivement, l'entité appelante 10 et la passerelle PDN-GW 15, la 20 passerelle PDN-GW 15 et l'entité de contrôle 32, l'entité de contrôle 32 et l'entité de contrôle 33, l'entité de contrôle 33 et l'entité de contrôle 30, et entre l'entité de contrôle 33 et le réseau de communication IMS 200, sont des messages de signalisation SIP 3. Les échanges entre d'une part l'entité de contrôle 31 et l'entité de contrôle 32, et d'autre part entre la passerelle PDN-GW 15 et l'entité de contrôle 31 sont réalisés par des messages de 25 signalisation Diameter 1 tels que défini dans le document de l'IETF RFC 6733. Les échanges entre l'entité de contrôle 32 et l'entité média 40 sont quant à eux supportés par des messages de signalisation 2 conformes au protocole H.248 défini par le groupe de travail UIT-T de l'UIT (pour « Union Internationale des Télécommunications »). Le procédé de contrôle de session est plus particulièrement mis en oeuvre par les entités de 30 contrôle 30 et 32, qui par la suite seront respectivement dite « entité primaire de contrôle » et « entité secondaire de contrôle ». Ces entités forment un système de contrôle d'une session de fourniture d'un certain service. Ceci sera détaillé par la suite en relation avec la figure 2. Il est par ailleurs à noter que la figure 1 est une représentation simplifiée du réseau de communication IMS 100. Aucune limitation n'est attachée au nombre d'entités de contrôle et 35 d'entités médias appartenant au réseau de communication IMS 100. Les entités du réseau de communication IMS 200 sont similaires à celles du réseau de communication IMS 100 et n'ont pas été représentées afin de ne pas alourdir la figure 1. 3036567 8 Dans une autre configuration réseau, certaines entités de contrôle peuvent en outre être regroupées au sein d'une même entité. De même, certaines fonctions assurées par une même entité peuvent être dissociées et mises en oeuvre par des entités distinctes. C'est par exemple le cas des fonctions d'interrogation I-CSCF et d'enregistrement S-CSCF de l'entité de contrôle 33. 5 Dans encore une autre configuration réseau, le procédé de contrôle de session est mis en oeuvre par des entités localisées dans le réseau de communication IMS 100 et dans le réseau de communication IMS 200. En particulier, le procédé de contrôle de session ne requiert pas que les entités le mettant en oeuvre appartiennent à un même réseau de communication. 10 La figure 2a représente des étapes d'un procédé de contrôle de session de fourniture d'un service, mis en oeuvre par des entités d'un réseau de communication IMS selon un premier mode particulier de réalisation. Par la suite, on se place dans une configuration réseau telle que celle décrite en relation avec la figure 1. Dans ce premier mode de réalisation, la session de fourniture de service est à titre 15 d'exemple établie entre l'entité appelante 10 (e.g. robot d'appel) du réseau de communication IMS 100 et une entité appelée 20 localisée dans le réseau de communication IMS 200 d'un site distant. La session fournit un service de télésurveillance de ce site distant. La session comprend par exemple trois flux de données, à savoir un flux vidéo permettant de transmettre des images du site distant sous surveillance, un flux audio permettant de transmettre 20 des sons ambiants du site distant sous surveillance, et un flux de messagerie instantanée permettant de transmettre d'une part des informations obtenues depuis différents capteurs localisés sur le site distant sous surveillance, et d'autre part des messages de contrôle depuis l'entité appelante 10 (e.g. commande de déclenchement d'une alarme). Lors d'une étape El, l'entité appelante 10 envoie un message de contrôle de session SIP 25 « INVITE » comprenant une offre SDP à destination de l'entité appelée 20 localisée dans le réseau de communication IMS 200. Ce message a pour but d'établir la session de télésurveillance entre l'entité appelante 10 et l'entité appelée 20. Le message de contrôle de session SIP « INVITE » envoyé a par exemple le contenu suivant : 30 INVITE sip:userl@operator.com SIP/2.0 To: From: ;tag=786 Call-ID: 3413an89KU Contact : From: ;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp 35 m=audio 49170 RTP/AVP 8 a=on-loss : * keep a=rtpmap:8 PCMU/8000 m=video 51372 RTP/AVP 31 40 a=on-loss : RTCP keep a=on-loss : RTP release a=rtpmap:31 H261/90000 3036567 12 m=message 51789 TCP/MSRP * a=on-loss : * release a=accept-types:text/plain a=path:msrp://host.operator.com:51789/2s93i9ek2a;tcp 5 Une fois les politiques de contrôle de session générées et insérées dans le message de contrôle de session SIP « INVITE », l'entité primaire de contrôle 30 retourne le message de contrôle de session SIP « INVITE » à l'entité de contrôle 33. 10 Lors d'une étape E8, l'entité de contrôle 33 achemine le message de contrôle de session SIP « INVITE » à destination de l'entité appelée 20 du réseau de communication IMS 200. Lors d'une étape E9, un message de contrôle de session SIP « 200 OK » en provenance du réseau de communication IMS 200 est reçu par l'entité de contrôle 33. Ce message d'acquittement contient une réponse SDP comprenant les mêmes attributs que ceux contenus dans l'offre SDP 15 précédemment décrite. Le message de contrôle de session SIP « 200 OK » a par exemple le format suivant : SIP/2.0 200 OK To: ; tag=345 20 From: ;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp m=audio 21456 RTP/AVP 8 25 a=on-loss : * keep a=rtpmap:8 PCMU/8000 m=video 35687 RTP/AVP 31 a=on-loss : RTCP keep a=on-loss : RTP release 30 a=rtpmap:31 H261/90000 m=message 24879 TCP/MSRP * a=on-loss : * release a=accept-types:text/plain a=path:msrp://host.operator.com:24879/SDHdfg234;tcp 35 Lors d'une étape E10, l'entité de contrôle 33 relaye le message de contrôle de session SIP « 200 OK » auprès de l'entité primaire de contrôle 30. L'entité primaire de contrôle 30 reçoit le message de contrôle de session SIP « 200 OK » et 40 le renvoie à son tour sans le modifier lors d'une étape Ell à l'entité de contrôle 33, qui elle-même le relaye lors d'une étape E12 à l'entité secondaire de contrôle 32 en charge de mettre en oeuvre ladite politique de contrôle de session en cas d'inactivité d'un flux de la session de fourniture de service. Lors d'une étape E13, après réception du message de contrôle de session SIP « 200 OK », 45 l'entité secondaire de contrôle 32 émet une demande de modification de flux auprès de l'entité de contrôle 31 afin de tenir compte des informations contenues dans le message de contrôle de session 3036567 13 SIP « 200 OK », et de mettre à jour les flux précédemment réservés. La demande de réservation de flux est réalisée de la même manière qu'à l'étape E2, par l'envoi d'un message de contrôle de ressources Diameter « AAR ». Lors d'une étape E14, l'entité secondaire de contrôle 32 transmet le message de contrôle de 5 session SIP « 200 OK » à l'entité appelante 10. Cette dernière entité est ainsi informée des politiques de contrôle de session pouvant être mises en oeuvre par le réseau de communication IMS 100 en cas d'inactivité d'un flux de la session. L'entité appelante 10 peut avantageusement utiliser à son tour les informations obtenues quant aux politiques de contrôle de session afin d'interpréter ces dernières localement et de prévoir par exemple un traitement local particulier en cas de 10 libération de la session suite à l'inactivité d'un flux détectée par le réseau de communication IMS 100. Lors d'une étape E15, l'entité de contrôle 31 détecte l'inactivité du flux de messagerie instantanée. Cette inactivité est par exemple déterminée par l'expiration d'une temporisation après un nombre de secondes prédéfinies au bout de laquelle un flux est considéré inactif si aucun paquet 15 de données relatif à ce flux n'a été reçu. Un message indiquant l'inactivité du flux est alors émis par l'entité de contrôle 31, à l'entité secondaire de contrôle 32. Ce message est par exemple un message Diameter « RAR », contenant un champ « Specific-Action » avec la valeur « INDICATION_OF_LOSS_OF_BEARER », et indiquant qu'une perte de flux s'est produite pour le flux identifié par les champs « Media-Component-Number » et « Flow-Number », à savoir le 20 flux de messagerie instantanée. Le message Diameter, à titre d'exemple, a le format suivant : Diameter Protocol Command Code: 258 Re-AuthA Applicationld: 3GPP Rx (16777236) 25 AVP: Session-Id(263) 1=115 f=-... AVP :Specific-Action(513) val= IN DICATION_OF_LOSS_OF_BEARER AVP: Flows (510) 30 AVP: Media-Component-Number(518) val=3 AVP: Flow-Number(509) val=1 Lors d'une étape E16, l'entité secondaire de contrôle 32 reçoit le message Diameter 35 « RAR » et est ainsi notifiée de la perte du flux de messagerie instantanée. L'entité secondaire de contrôle 32 acquitte le message Diameter « RAR » reçu en envoyant à l'entité de contrôle 31 un message Diameter « AAA ». Lors d'une étape E17, l'entité secondaire de contrôle 32 met en oeuvre la politique de contrôle de session obtenue depuis l'offre SDP à l'étape E12, et correspondant à une inactivité du 40 flux de messagerie instantanée. Cette politique de contrôle de session consiste plus particulièrement 3036567 14 à libérer la session, ce qui est indiqué par la ligne « on-loss : * release » de la description du flux de messagerie instantanée contenue dans l'offre SDP. La mise en oeuvre de la politique de contrôle de session pour une inactivité du flux de messagerie instantanée se traduit, lors d'une étape E18, par l'envoi par l'entité secondaire de 5 contrôle 32 d'un message de clôture de session à l'entité appelante 10 et à l'entité de contrôle 31. Dans un autre mode de réalisation, les politiques de contrôle de session sont directement insérées dans un entête d'un message de contrôle de session SIP, par exemple un entête « MediaLoss-Actions », plutôt que dans une offre ou une réponse SDP contenue dans ce message. Les politiques de contrôle de session correspondent alors à une liste ordonnée de valeurs dont l'ordre 10 correspond à l'ordre des descriptions de flux associés à la session dans l'offre ou la réponse SDP contenue dans le message de contrôle de session SIP. Les valeurs de la liste indiquent alors une politique de contrôle de session pour chacun des flux au sein de la session selon l'ordre de la liste. Plus précisément, à une n-ième description de flux d'une offre ou réponse SDP correspond la nième politique de contrôle de session de la liste de valeurs associées à l'entête « Media-Loss- 15 Actions ». A titre d'exemple, un message de contrôle de session SIP « INVITE » selon ce mode de réalisation a la forme suivante : INVITE sip:userl@operator.com SIP/2.0 To: 20 From: ;tag=786 Call-ID: 3413an89KU Media-Loss-Actions: , , , Content-Type: application/sdp 25 v=0 o=userl 2890844526 2890844526 IN IP4 operator.com s c=IN IP4 host.operator.example.com 30 t=0 0 m=audio 49170 RTP/AVP 0 8 97 a=rtpmap:0 PCMA/8000 a=rtpmap:8 PCMU/8000 a=rtpmap:97 iLBC/8000 35 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=message 51789 TCP/MSRP * a=accept-types:text/plain a=path:msrp://host.operator.com:51789/2s93i9ek2a;tcp 40 m=application 64300 UDP/DTLS/SCTP webrtc-datachannel a=setup:passive a=sctp-port:6000 a=max-message-size: 100000 45 Dans un autre mode de réalisation, à l'étape E9, une entité du réseau de communication IMS 200 indique dans sa réponse SDP des attributs valorisés différents de ceux compris dans 3036567 15 l'offre SDP qu'il a reçu. Le réseau de communication IMS 200 peut ainsi proposer des politiques de contrôle de session différentes de celles proposées ou retenues par une entité de contrôle du réseau de communication IMS 100. Dans un autre mode de réalisation, une politique de contrôle de session est insérée par 5 l'entité appelante 10 dans l'offre SDP envoyée à l'étape El. A l'étape E6, l'entité primaire de contrôle 30, selon un paramétrage prédéfini, peut alors modifier la politique de contrôle de session décrite dans l'offre SDP ou encore la conserver telle qu'indiquée par l'entité appelante 10. Dans ce dernier cas, l'entité primaire de contrôle 30 obtient la politique de contrôle de session directement à partir du message de contrôle de session SIP « INVITE » reçu. 10 Dans un autre mode de réalisation, l'entité primaire de contrôle 30 et l'entité secondaire de contrôle 32 sont une même entité. L'entité de contrôle obtenant à partir d'un message de contrôle de session, ou générant, la politique de contrôle de session, est également celle qui la met en oeuvre. Le procédé a été décrit pour une mise en oeuvre d'un service de télésurveillance, il n'existe cependant aucune limitation au type de service bénéficiant d'un contrôle de session. 15 De même, le procédé a été décrit avec une mise en oeuvre dans un réseau de communication IMS 100. Il n'existe cependant pas de limitation quant au nombre de réseaux de communication dans lesquels le procédé est mis en oeuvre. Le procédé peut par exemple aisément être mis en oeuvre avec des entités de contrôle réparties dans plusieurs réseaux distincts. Il n'existe par ailleurs aucune limitation quant aux entités de contrôle susceptibles de 20 mettre en oeuvre le procédé décrit. Une telle entité de contrôle appartient par exemple au groupe d'entités de contrôle suivant : entité P-CSCF (pour « Proxy - Call Server Control Function »), entité I-CSCF (pour « Interrogating - Call Server Control Function »), entité S-CSCF (« Serving Call Server Control Function »), entité AS (pour « Application Server »), entité MGCF (pour « Media Gateway Controller Function »), entité IBCF (pour « Interconnection Border Control 25 Function »), terminal utilisateur. Les précédents modes de réalisation ont été décrits pour le traitement d'un message de contrôle de session SIP « INVITE » et d'un message de réponse correspondant SIP « 200 OK ». Il n'existe cependant pas de limitations quant aux types de requêtes de service traitées. Le procédé de traitement mis en oeuvre par exemple pour une requête SIP « UPDATE » est équivalent à celui mis 30 en oeuvre pour traiter une requête SIP « INVITE ». La figure 2b représente des étapes d'un procédé de contrôle de session de fourniture d'un service, mis en oeuvre par des entités d'un réseau de communication IMS selon un deuxième mode particulier de réalisation. Par la suite, on se place à nouveau dans une configuration réseau telle que 35 celle décrite en relation avec la figure 1. Dans ce deuxième mode de réalisation, la session de fourniture de service est, de même que décrit précédemment en relation avec la figure 2a, une session fournissant un service de 3036567 16 télésurveillance, établie entre l'entité appelante 10 (e.g. robot d'appel) du réseau de communication IMS 100 et une entité appelée 20 localisée dans le réseau de communication IMS 200 d'un site distant. On considère, de même que précédemment, que la session comprend trois flux de données : un flux vidéo, un flux audio, et un flux de messagerie instantanée. 5 A la différence du premier mode de réalisation, l'entité détectant une inactivité d'un flux et la notifiant à l'entité secondaire de contrôle 32 est une entité média 40, à titre d'exemple, une passerelle IMS-AGW. Les autres entités sont identiques au premier mode de réalisation. Lors d'une étape F1 identique à l'étape El précédemment décrite, l'entité appelante 10 envoie un message de contrôle de session SIP « INVITE » comprenant une offre SDP à destination 10 de l'entité appelée 20 localisée dans le réseau de communication IMS 200. Lors d'une étape F2, l'entité secondaire de contrôle 32 reçoit le message de contrôle de session « INVITE » émis par l'entité appelante 10. L'entité secondaire de contrôle 32 émet alors une demande de réservation de flux, pour les trois flux de données de l'offre SDP, auprès de l'entité de contrôle 40. La demande de réservation de flux est plus précisément un message de 15 contrôle de ressources H.248 « Add Request » tel que défini dans le document H.248.1 de l' ITU-T. A titre d'exemple le message de contrôle de ressources H.248 « Add Request » a le contenu suivant : MEGACO/2 [172.20.214.26]:2953 20 Transaction=14289{ Context=63967{ Add=Term1{ Media{ Stream=1{ 25 LocalControl{ event=1111{adid/ipstop{dt=60}}... Local{ v=.. m=audio 30 Stream=2{ LocalControl{ event=2222{adid/ipstop{dt=60}}... Local{ 35 v=.. m=video 40 Stream=3{ LocalControl{ event=3333{adid/ipstop{dt=60}}... Local{ v=.. c=... 45 m=message 3036567 17 }} il, 5 Le message de contrôle de ressources H.248 « Add Request » comprend en outre pour chaque flux une indication « adicliipstop{ dt=60} » indiquant que l'entité secondaire de contrôle 32 demande à être notifiée par l'entité de contrôle 40 des évènements de perte de flux. Plus précisément, un flux est considéré perdu lorsqu'aucun paquet relatif à ce flux n'est reçu dans un 10 délai de 60 secondes. Lors d'une étape F3, l'entité de contrôle 40 envoie un message de contrôle de ressources H.248 « Add Reply », d'acquittement de la demande de réservation de flux à l'entité secondaire de contrôle 32. Des étapes F4 à F6 sont ensuite mises en oeuvre. Ces étapes sont identiques aux étapes E4 15 et E6 précédemment décrites en relation avec la figure 2a. Lors d'une étape F7, à la différence du premier mode de réalisation, l'entité primaire de contrôle 30 ne complète pas l'offre SDP contenue dans le message de contrôle de session SIP « INVITE » avec les politiques de contrôle de session en cas d'inactivité d'un flux déterminées à l'étape précédente. L'entité primaire de contrôle 30 retourne le message de contrôle de session SIP 20 « INVITE » à l'entité de contrôle 33 sans le modifier. Ceci permet avantageusement de ne pas communiquer les politiques de contrôle de session au réseau de communication de l'entité appelée 20. Des étapes F8 à F10 sont ensuite mises en oeuvre de façon similaire aux étapes E8 à E10 précédemment décrites en relation avec la figure 2a, à ceci près que les messages de contrôle de 25 session SIP échangés ne comprennent pas de politiques de contrôle de session en cas d'inactivité de flux. Lors d'une étape F11, l'entité primaire de contrôle 30, après avoir reçu un message de contrôle de session SIP « 200 OK » contenant une réponse SDP en provenance du réseau de communication IMS 200, complète cette réponse SDP à l'aide d'un attribut « a=on-loss » inséré 30 dans les descriptions des flux audio, vidéo et de messagerie instantanée. Cet attribut indique la politique de contrôle à mettre en oeuvre en cas d'inactivité du flux auquel il est associé. L'entité primaire de contrôle 30 génère ainsi, pour chaque flux de données, en fonction du type de service fourni, une politique de contrôle de session à mettre en oeuvre en cas d'inactivité de ce flux, c'est-à-dire en cas de non-établissement ou de libération prématurée du flux. Les politiques de contrôles de 35 session en cas d'inactivité d'un flux sont dans ce deuxième mode de réalisation insérées à réception de la réponse SDP et permettent ainsi d'en préserver la confidentialité vis-à-vis du réseau de communication IMS 200. L'entité de contrôle 30 renvoie ensuite le message SIP modifié à l'entité de contrôle 33, qui elle-même le relaye lors d'une étape F12 à l'entité secondaire de contrôle 32 en 3036567 18 charge de mettre en oeuvre la politique de contrôle de session en cas d'inactivité d'un flux de la session de fourniture de service. Cette étape F12 est identique à l'étape E12 du premier mode de réalisation. Lors d'une étape F13, après réception du message de contrôle de session SIP « 200 OK », 5 l'entité secondaire de contrôle 32 émet une demande de modification de flux auprès de l'entité média 40 afin de tenir compte des informations contenues dans le message de contrôle de session SIP « 200 OK », et de mettre à jour les flux précédemment réservés. La demande de réservation de flux est réalisée de manière similaire à l'étape F2, par l'envoi d'un message de contrôle de ressources H.248 « Modify Request ». 10 L'entité secondaire de contrôle 32 transmet, lors d'une étape F14 identique à l'étape E14 du premier mode de réalisation, le message de contrôle de session SIP « 200 OK » à l'entité appelante 10. Lors d'une étape F15, l'entité média 40 détecte l'inactivité du flux audio. Cette inactivité est déterminée par l'expiration de la temporisation prédéfinie à 60 secondes à l'étape F2. Un 15 message indiquant l'inactivité du flux est alors émis par l'entité média 40, à l'entité secondaire de contrôle 32. Ce message est plus précisément un message H.248 «Notify Request » indiquant qu'une perte de flux s'est produite pour le flux audio identifié par l'attribut « Stream=1 ». Le message H.248 « Notify Request » a, à titre d'exemple, le format suivant : 20 MEGACO/2 [172.20.214.23]:2953 Transaction=4214{ Context=63967{ Notify=Term1{ Media{ 25 Stream=1{ LocalControl{ Observed Events=1111 {20150315122000000 : ad id/ipstop} ...}} Lors d'une étape F16, l'entité secondaire de contrôle 32 reçoit le message H.248 «Notify 30 Request » et est ainsi notifiée de la perte du flux audio. L'entité secondaire de contrôle 32 acquitte le message H.248 « Notify Request » reçu en envoyant à l'entité média 40 un message H.248 « Notify Reply ». Lors d'une étape F17, l'entité secondaire de contrôle 32 met en oeuvre la politique de contrôle de session obtenue depuis la réponse SDP, et correspondant à une inactivité du flux audio. 35 Cette politique de contrôle de session consiste plus particulièrement à maintenir la session, ce qui est indiqué par la ligne « on-loss : * keep » de la description du flux audio contenue dans la réponse SDP. La politique de contrôle de session mise en oeuvre revient ainsi à ne pas tenir compte de la perte du flux audio. 3036567 19 La figure 3 représente une entité de contrôle 30, d'une session de fourniture d'un certain service, dite « entité primaire de contrôle ». L'entité primaire de contrôle 30 comprend : - un module d'obtention 310 et/ou un module de génération 320, agencés pour obtenir à partir d'un message de contrôle de session, ou générer en fonction d'un type dudit service, une politique de 5 contrôle de session à mettre en oeuvre en cas d'inactivité d'au moins un flux de données, c'est-à- dire en cas de non-établissement ou de libération prématurée d'un flux de données associé à la session ; - un module d'envoi 330, agencé pour envoyer dans un message de contrôle de session, la politique de contrôle de session à une entité de contrôle 31, dite « entité secondaire de contrôle », en charge 10 de mettre en oeuvre la politique de contrôle de session. Dans un mode de réalisation particulier, le module d'obtention 310 est agencé pour obtenir la politique de contrôle de session à partir d'une offre ou d'une réponse SDP comprise dans le message de contrôle de session, la politique de contrôle de session étant un attribut d'une description d'un flux de la session contenue dans l'offre ou la réponse SDP. 15 Dans un autre mode de réalisation particulier, le module d'obtention 310 est agencé pour obtenir la politique de contrôle de session à partir d'un entête du message de contrôle de session. La figure 4 représente une entité de contrôle 31, dite « entité secondaire de contrôle ». Cette entité met en oeuvre des signaux de contrôle de session. L'entité de contrôle 31 comprend : 20 - un module de réception 410, agencé pour recevoir une politique de contrôle de session à mettre en oeuvre en cas d'inactivité d'au moins un flux de données, c'est-à-dire en cas de non-établissement ou de libération prématurée d'un flux de données associé à la session ; - un module de mise en oeuvre 420, agencé pour mettre en oeuvre la politique de contrôle de session. 25 Dans un mode de réalisation particulier, le module de mise en oeuvre 420 est agencé pour exécuter ou commander une libération immédiate de la session de fourniture d'un certain service, une libération différée de la session de fourniture d'un certain service, un maintien de la session de fourniture d'un certain service, ou une tentative de rétablissement d'un flux de la session de fourniture d'un certain service. 30 Dans un autre mode de réalisation particulier, l'entité de contrôle 31 comprend en outre un module de détection 430, agencé pour détecter une inactivité d'au moins un flux de la session de fourniture d'un certain service. L'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans 35 cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte 3036567 20 à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un 5 programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc). De la même manière, un composant matériel correspond à tout élément d'un ensemble 10 matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Dans un mode de réalisation particulier, les modules 310, 320 et 330 sont agencés pour mettre en oeuvre le procédé de contrôle précédemment décrit. Il s'agit de préférence de modules 15 logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de contrôle précédemment décrit, mises en oeuvre par une entité primaire de contrôle. L'invention concerne donc aussi : - un programme pour une entité primaire de contrôle, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de contrôle 20 précédemment décrit, lorsque ledit programme est exécuté par ladite entité primaire de contrôle ; - un support d'enregistrement lisible par une entité primaire de contrôle sur laquelle est enregistré le programme pour une entité primaire de contrôle. De même, les modules 410, 420 et 430 sont agencés pour mettre en oeuvre le procédé de contrôle précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des 25 instructions logicielles pour faire exécuter celles des étapes du procédé de contrôle précédemment décrit, mises en oeuvre par une entité secondaire de contrôle. L'invention concerne donc aussi : - un programme pour une entité secondaire de contrôle, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de contrôle précédemment décrit, lorsque ledit programme est exécuté par ladite entité secondaire de contrôle; 30 - un support d'enregistrement lisible par une entité secondaire de contrôle sur laquelle est enregistré le programme pour une entité secondaire de contrôle. Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, 35 optique ou radio, ou un réseau de télécommunication. REVENDICATIONS1. Procédé de contrôle d'une session de fourniture d'un certain service, au moins un flux de données étant associé à ladite session, ledit procédé comprenant : - une obtention (E6, F11), à partir d'un message de contrôle de session, ou une génération, en fonction d'un type dudit service, d'une politique de contrôle de session à mettre en oeuvre en cas d'inactivité d'au moins un flux de données, c'est-à-dire en cas de non-établissement ou de libération prématurée d'un flux de données associé à la session ; - un envoi (E7, F11), dans un message de contrôle de session, de ladite politique de contrôle de session à une entité de contrôle (32) en charge de mettre en oeuvre ladite politique de contrôle de session ; et - sur détection (E15, F15), d'une inactivité d'au moins un flux de ladite session, une mise en oeuvre (E17, F17) de ladite politique de contrôle de session. 2. Procédé selon la revendication 1, dans lequel ladite politique de contrôle de session appartient au groupe comprenant une libération immédiate de la session, une libération différée de la session, un maintien de la session, et une tentative de rétablissement d'un flux de la session. 3. Procédé selon la revendication 1, dans lequel ladite politique de contrôle de session est définie par un attribut d'une description d'un flux de la session, comprise dans une offre ou une réponse SDP associée au message de contrôle de session. 4. Procédé selon la revendication 1, dans lequel ladite politique de contrôle de session est comprise dans un entête du message de contrôle de session. 5. Procédé selon la revendication 1, dans lequel ladite politique de contrôle de session est mise en oeuvre sur détection d'une inactivité d'un flux de données appartenant au groupe comprenant un flux multimédia et un flux de contrôle. 6. Procédé selon la revendication 1, dans lequel ledit message de contrôle de session est un message SIP. 7. Entité de contrôle (30), d'une session de fourniture d'un certain service, dite « entité primaire de contrôle », dans un réseau de communication, comprenant : - un module d'obtention (310) et/ou un module de génération (320), agencés pour obtenir à partir d'un message de contrôle de session, ou générer en fonction d'un type dudit service, une politique de contrôle de session à mettre en oeuvre en cas d'inactivité d'au moins un flux de données, c'est-à- 3036567 22 dire en cas de non-établissement ou de libération prématurée d'un flux de données associé à la session ; - un module d'envoi (330), agencé pour envoyer dans un message de contrôle de session, la politique de contrôle de session à une entité de contrôle, dite « entité secondaire de contrôle », en 5 charge de mettre en oeuvre ladite politique de contrôle de session. 8. Entité de contrôle (30) selon la revendication 7, dans laquelle ledit module d'obtention (310) est agencé pour obtenir ladite politique de contrôle de session à partir d'une offre ou d'une réponse SDP comprise dans le message de contrôle de session, ladite politique de contrôle de session étant 10 un attribut d'une description d'un flux de la session contenue dans ladite offre ou réponse SDP. 9. Entité de contrôle (30) selon la revendication 7, dans laquelle ledit module d'obtention (310) est agencé pour obtenir ladite politique de contrôle de session à partir d'un entête du message de contrôle de session. 15 10. Entité de contrôle (31), d'une session de fourniture d'un certain service, dite « entité secondaire de contrôle », dans un réseau de communication, mettant en oeuvre des signaux de contrôle de session, comprenant : - un module de réception(410), agencé pour recevoir une politique de contrôle de session à mettre 20 en oeuvre en cas d'inactivité d'au moins un flux de données, c'est-à-dire en cas de non- établissement ou de libération prématurée d'un flux de données associé à la session ; - un module de mise en oeuvre (420), agencé pour mettre en oeuvre ladite politique de contrôle de session. 25 11. Entité de contrôle (31) selon la revendication 10, dans laquelle ledit module de mise en oeuvre (420) est agencé pour exécuter ou commander une libération immédiate de ladite session de fourniture d'un certain service, une libération différée de ladite session de fourniture d'un certain service, un maintien de ladite session de fourniture d'un certain service, ou une tentative de rétablissement d'un flux de ladite session de fourniture d'un certain service. 30 12. Entité de contrôle (31) selon la revendication 10, comprenant en outre un module de détection (430), agencé pour détecter une inactivité d'au moins un flux de ladite session de fourniture d'un certain service. 35 13. Système de contrôle d'une session de fourniture d'un certain service, dans un réseau de communication, comprenant : 3036567 23 - une entité de contrôle (30), dite « entité primaire de contrôle », selon l'une des revendications 7 à 9 ; et - une entité de contrôle (31), dite « entité secondaire de contrôle », selon l'une des revendications 10 à 12; 5 ladite entité secondaire de contrôle mettant en oeuvre, sur détection d'une inactivité d'au moins un flux d'une session de fourniture d'un certain service, une politique de contrôle de session reçue de l'entité primaire de contrôle pour ladite session. 14. Programme pour une entité de contrôle, comprenant des instructions de code de programme 10 destinées à commander l'exécution des étapes du procédé selon l'une des revendications 1 à 6, lorsque ledit programme est exécuté par ladite entité de contrôle. 15. Support d'enregistrement lisible par une entité de contrôle sur lequel est enregistré le programme selon la revendication 14. 15