La présente invention concerne les réseaux de communications de type IP (« Internet Protocol »), et notamment ceux parmi les réseaux IP qui sont aptes à mettre en oeuvre des protocoles de contrôle de session. Les réseaux IP permettent la diffusion de données conversationnelles, dans le cadre de services tels que « Voix sur IP » (VoIP), « Partage de Contenu », ou « Messagerie Instantanée ».

Plus particulièrement, la présente invention concerne les moyens mis en place dans un réseau IP pour communiquer aux entités réseau qui en ont besoin la valeur de la bande passante qui a été allouée à un usager en relation avec un média (voix, vidéo, et ainsi de suite) donné.

Les protocoles de contrôle de session, tels que le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'initiation de Session »), utilisent des messages dits de « signalisation », qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière.

Le protocole SIP a été défini par l’IETF ( Internet Engineering Task Force) dans le document RFC 3261. Ce protocole permet l’établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP a ensuite été étendu notamment dans le document RFC 3265. Cette extension définit des procédures de notification d’événements.

Le protocole SIP est utilisé en particulier dans les infrastructures de type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous- système Multimédia sur IP »). L’IMS a été défini par l’organisme de normalisation 3GPP (« Third Génération Partnership Project ») et TISPAN (« Télécommunications and Internet Converged Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux usagers ainsi que la réservation des ressources au niveau du réseau de transport des flux multimédia. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en œuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux usagers. L'IMS permet par exemple d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction.

Lorsque donc un usager souhaite bénéficier des services offerts par un réseau IMS, il émet vers le réseau des messages de signalisation pouvant inclure notamment divers types de requêtes.

Tout d'abord, le dispositif-client de l’usager doit, sauf exceptions (telles que certains appels d'urgence), s'enregistrer sur le réseau. Lorsque le réseau est incapable de faire le lien entre cet enregistrement et un enregistrement précédent (par exemple suite à une panne réseau, ou suite à un arrêt du dispositif-client pendant une durée supérieure à une valeur prédéterminée), l'enregistrement est considéré comme étant un enregistrement initial. Après un enregistrement initial, le dispositif-client de l'usager doit envoyer périodiquement au réseau une requête pour confirmer qu'il souhaite maintenir son enregistrement.

Pour pouvoir enregistrer les dispositifs-clients, les réseaux IMS comprennent un ou plusieurs serveurs d’enregistrement, appelés « S-CSCF » (initiales des mots anglais « Serving-Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau.

Les réseaux IMS comprennent en outre un ou plusieurs serveurs d’interrogation, appelés « l-CSCF » (initiales des mots anglais « Interrogating- Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice »)— d'ailleurs souvent combinés physiquement avec les serveurs d’enregistrement S-CSCF pour constituer des serveurs d’appel dénotés « l/S-CSCF » — qui, au moment de l'enregistrement d'un dispositif-client, interrogent un serveur de données d’abonné appelé « HSS » (initiales des mots anglais « Home Subscriber Server » signifiant « Serveur d’Abonné de Rattachement »), afin de pouvoir sélectionner un serveur S-CSCF possédant les caractéristiques qui sont obligatoirement (et, le cas échéant, optionnellement) requises pour atteindre le niveau de service souscrit par l’usager. Les serveurs HSS contiennent chacun une base de données d’usagers, et sont donc l'équivalent dans les réseaux IP des serveurs « HLR » (initiales des mots anglais « Home Location Register » signifiant « Registre de Localisation de Rattachement ») utilisés dans les réseaux GSM. Chaque serveur HSS contient le « profil » d'un certain nombre de dispositifs-clients du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services auxquels il a droit.

En effet, après qu'un serveur S-CSCF lui a été ainsi attribué, chaque usager peut faire usage d’un certain nombre de services pendant la session en cours. Il peut par exemple s’agir de services offerts automatiquement à tous les usagers du réseau IMS. Il peut aussi s’agir de services auxquels cet usager a souscrit auprès de l’opérateur du réseau, et qui sont mis automatiquement à sa disposition. Enfin, il peut s’agir de services dont l’usager peut faire usage après avoir émis une requête appropriée (SIP SUBSCRIBE).

Ces services comprennent des applications audiovisuelles telles que mentionnées ci-dessus. Il peut s’agir également d’une souscription à l’état d’une ressource, auquel cas des notifications d’évènement (SIP NOTIFY) sont envoyées au dispositif-client dès lors que l’état de la ressource change ; par exemple, lorsque l'utilisateur d'un dispositif-client dispose d'une boîte vocale sur le réseau, il pourra être informé chaque fois qu'un message a été enregistré sur cette boîte vocale ; un utilisateur peut, de même, demander à être notifié de l’état d'enregistrement de son propre dispositif-client.

Les réseaux IMS comprennent en outre un ou plusieurs serveurs appelés « P-CSCF » (initiales des mots anglais « Proxy-Call Server Control Function » signifiaOnt « Fonction de Commande de Session d'Appel Mandataire »). Pour chaque dispositif-client connecté à un réseau IMS, il existe un serveur P-CSCF servant d’entité de raccordement entre le cœur de réseau IMS et le réseau d’accès utilisé par ce dispositif-client ; ainsi, toute la signalisation SIP échangée entre le dispositif-client d’une part, et le serveur d’interrogation l-CSCF ou le serveur d’enregistrement S-CSCF d’autre part, passe par le serveur P-CSCF.

Pour mettre en oeuvre la taxation des usagers, les réseaux IMS utilisent une architecture appelée PCC (initiales des mots anglais « Policy and Charging Control » signifiant « Commande de Politique et de Taxation ») Cette architecture PCC est également utilisée dans les réseaux mobiles à commutation de paquets comprenant un réseau cœur EPC (initiales des mots anglais « Evolved Packet Core » signifiant « Cœur de Réseau Paquet Evolué »), comme décrit dans le document TS 23.203 du 3GPP. L’architecture PCC est illustrée sur la figure 1 , qui est adaptée de la figure 5.1.1 dudit document TS 23.203.

Cette architecture PCC comprend notamment une entité de contrôle des règles appelée PCRF (initiales des mots anglais « Policy Control and Charging Ruies Function » signifiant « Fonction de Commande de Politique et de Règles de Taxation »), qui fournit des règles de taxation et de politique d’opérateur (comme par exemple le débit maximum alloué, ou la priorité d’un flux selon son type) à une entité d’application des règles PCEF (initiales des mots anglais « Policy and Charging Enforcement Function » signifiant « Fonction d’Application de Politique et de Taxation »).

L’entité de contrôle des règles PCRF est apte à déterminer la méthode de taxation pour un flux de service donné ; elle a accès aux données d’abonnement de l'usager afin de pouvoir adapter l’utilisation des ressources de transport faite par ce service, ainsi que la taxation du service, en fonction du profil de l'usager. L'entité de contrôle des règles PCRF collecte depuis plusieurs sources des informations liées aux réseaux (telles que le type d’accès radio, les adresses de passerelles, ou la localisation du terminal de l’usager), des informations liées à l’abonnement de l’usager, et des informations liées aux applications utilisées par l’usager sur son terminal (telles que le type d’application, ou le type de média). L’entité de contrôle PCRF a accès aux informations de souscription de l'utilisateur du terminal, qui sont mémorisées dans une base de données appelée SPR (initiales des mots anglais « Subscription Profile Repository »), afin de pouvoir adapter l'affectation des ressources de transport par le service concerné ainsi que la taxation du service en fonction du profil de l'utilisateur du terminal. L’entité PCEF, quant à elle, sélectionne une règle PCC pour chaque paquet de données dudit flux en examinant les données de service contenues dans ce paquet. La fonction PCEF est mise en œuvre au niveau d’une passerelle d’accès (« Gateway » en anglais) au réseau cœur. Le document TS 29.212 du 3GPP (intitulé « Policy and Charging Control over Gx reference point ») définit l’interface « Gx » entre l’entité de contrôle PCRF et l’entité d’application des règles PCEF. Lors de l’ouverture d’une session de communication, l’entité d’application des règles PCEF ouvre une session de commande relative à la session de communication avec l’entité de contrôle des règles PCRF et lui communique des informations associées à cette session de communication (par exemple le type d'accès radio, les paramètres de qualité de service demandés, ou la bande passante demandée). En fonction de ces caractéristiques et d’autres informations provenant de plusieurs autres sources, l’entité de contrôle PCRF détermine la politique initiale (qualité de service, tarification à mettre en place, autorisation d’accès) à appliquer pour les différents services portés par la session de communication en cours. Cette politique peut être modifiée en fonction d’événements se produisant durant la session de communication.

Une Entité Applicative AF (initiales des mots anglais « Application Function ») communique avec l’entité de contrôle des règles PCRF (ou une entité mandataire) pour transmettre des informations de session dynamiques et pour recevoir des notifications, par exemple relatives à l’occurrence d’évènements. Le document TS 29.214 du 3GPP (intitulé « Policy and Charging Control over Rx reference point ») définit l’interface « Rx » entre l’entité de contrôle des règles PCRF et l’Entité Applicative AF. Lors de l’ouverture d’une session de communication, l’Entité Applicative AF fait une demande de ressources média auprès de l’entité PCRF.

Le serveur P-CSCF d’un réseau IMS, mentionné ci-dessus, est un exemple d’Entité Applicative AF.

Enfin, l’entité BBERF (initiales des mots anglais « Bearer Binding and Event Reporting Function » signifiant « Fonction de Compte-Rendu de Liens de Canaux Virtuels et d’Evènements ») permet à l’entité de contrôle des règles PCRF de disposer d’informations utiles pour le contrôle et la supervision des réseaux d’accès locaux sans-fil (« Wireless Local Access Network », ou WLAN en anglais).

Grâce à ces diverses entités, l’architecture PCC est apte à générer des tickets de taxation CDR (initiales des mots anglais « Call Detail Record » signifiant « Enregistrement des Détails d’Appel »), qui ont été définis dans le document TS 32.298 du 3GPP. Plus précisément, une entité OCS (initiales des mots anglais « Online Charging System » signifiant « Système de Taxation En Ligne ») génère des CDR au fil de l’eau, cependant qu’une entité OFCS (initiales des mots anglais « Offline Charging System » signifiant « Système de Taxation Hors Ligne ») génère un fichier comprenant un ensemble de CDR que l’opérateur du réseau vient récupérer périodiquement (par exemple, toutes les heures ou tous les jours).

On notera que toutes les interfaces de l’architecture PCC (hormis l’interface avec la base de données SPR) mettent en œuvre le protocole de base DIAMETER décrit dans le document RFC 3588 de l’IETF.

Lors d’une demande de ressources par une Entité Applicative AF, celle-ci communique, au travers de l’interface Rx mentionnée ci-dessus, les caractéristiques des ressources souhaitées par un usager dont cette AF a la charge, ces ressources étant essentiellement un ensemble de « média » (par exemple un flux « audio » et un flux « vidéo »). Ces caractéristiques sont contenues dans un paramètre Diameter appelé « Media-Component-

Description », lui-même constitué d’un ensemble de sous-paramètres Diameter comme suit :

Media-Component-Description ::= < AVP Header: 517 >

{ Media-Component-Number } ; Ordinal number of the media comp.

*[ Media-Sub-Component ] ; Set of flows for one flow identifier

[ AF-Application-Identifier ]

[ Media-Type ]

[ Max-Requested-Bandwidth-UL ]

[ Max-Requested-Bandwidth-DL ]

[ Max-Supported-Bandwidth-UL ]

[ Max-Supported-Bandwidth-DL ]

[ Min-Desired-Bandwidth-UL ] [ Min-Desired-Bandwidth-DL ]

[ Min-Requested-Bandwidth-UL ]

[ Min-Requested-Bandwidth-DL ]

[ Flow-Status ]

[ Priority-Sharing-Indicator ]

[ Reservation-Priority ]

[ RS-Bandwidth ]

[ RR-Bandwidth ]

*[ Codée -Data ]

[ Sharing-Key-DL ]

[ Sharing-Key-UL ]

[ Content- Version ]

*[ A VP ]

Ainsi, chaque média est identifié par un numéro appelé « Media-Component- Number », ainsi que par des caractéristiques diverses (débit, type de média, adresses, et ainsi de suite).

On comprendra que les ressources média sont précieuses et partagées par les usagers du réseau, auxquels ces ressources sont allouées dynamiquement. Aussi est-il souhaitable de les utiliser au mieux, en évitant de sur-dimensionner ces ressources par rapport aux besoins. Parallèlement, il est important de pouvoir disposer d’indicateurs permettant d’en maîtriser et/ou facturer l’usage, puis de pouvoir propager ces indicateurs dans le cœur de réseau.

Dans l’état de l’art, l’une des données essentielles d’une ressource média, à savoir le débit demandé (équivalent à la bande passante), n’est pas propagée dans le réseau, et n’est disponible que sur l’Entité Applicative AF (mentionnée ci-dessus) qui a demandé la ressource, ou bien sur les interfaces spécialisées des sous-systèmes de taxation, tels que les entités OCS ou OFCS mentionnées ci-dessus. Cette information n’est en aucun cas mise à la disposition des autres éléments réseau constitutifs du cœur IMS. La connaissance de cette information aurait pourtant maintes utilisations possibles, par exemple : - pour l’établissement d’une session de transfert de données, la propagation de l’information sur la bande passante allouée au demandeur vers l’AF de son correspondant permet de ne pas réserver plus de ressources côté demandé que celles réservées côté demandeur ; en effet, un éventuel sur-débit alloué ne serait jamais exploité ; cela permet de dimensionner au plus juste les débits utiles ;

- la propagation de l’information sur la bande passante allouée au demandeur vers l’AF de son correspondant permet également à cet AF d’ajuster le débit demandé en fonction de critères applicatifs ; on peut imaginer ici différents cas d’usage : ajustement d’un flux en fonction de critères de souscription, ou évolution de la session suite à la mise en oeuvre d’une action temporaire (par exemple, augmentation du débit le temps d’un transfert de fichier au cours d’une session de messagerie instantanée) ;

- la transmission à un Serveur d'Applications (« Application Server », ou AS en anglais) en charge de la taxation permet à cet AS d’ajouter dans les tickets de taxation (CDR) l’information de débit utilisé ;

- la transmission à un AS, par exemple un serveur de téléphonie (« Telephony Application Server », ou TAS en anglais), permet à cet AS de sommer en temps réel les débits instantanés utilisés par un groupe d’usagers, tel qu’un ensemble d’usagers ayant souscrit à une offre d’opérateur virtuel (MVNO) ou un ensemble de membres d’un réseau privé d’entreprise ayant négocié un seuil d’usage de ressources avec l’opérateur d’un réseau d’accès radio ; l’AS peut alors contrôler que ce seuil n’est pas atteint et que le contrat (« Service- Level Agreement » ou SLA) est respecté ; dans le cas contraire, l’AS pourra libérer les communications ou rejeter les nouvelles demandes d’établissement de session ;

- la transmission à un AS, par exemple un TAS, de la somme des débits permet de prévenir des risques de saturation, et d’appliquer un rejet sélectif d’appels ou d’intervenir directement sur les ressources demandées en diminuant la bande passante allouée (par exemple, l’AS peut agir sur les paramètres « mode-set » d’un codée audio) ; ainsi, il devient possible à cet AS de réguler la bande passante utilisée aux heures chargées sur une zone déterminée ;

- réservation d’un quota de bande passante pour un évènement particulier ; - offres tarifaires différenciées sur la base de la bande passante souscrite.

Dans l’architecture IMS normalisée, c’est le P-CSCF qui détermine le débit à allouer à la ressource demandée, sur la base d’éléments trouvés dans le protocole SDP (Session Description Protocol, cf. le document RFC 4566 de l’IETF) et de données de configuration locales. L’algorithme qui permet d’en déduire le débit à allouer est complexe, et peut prendre de nombreux paramètres en considération. Cet algorithme n’étant pas normalisé, chaque fournisseur met en oeuvre ses propres solutions. On notera que cet algorithme n’est pas l’objet de la présente invention, mais— à titre d’information— on peut retenir que les éléments exploités par le P-CSCF à cet effet peuvent être : les codées demandés pour la session média (audio et/ou vidéo), le mode de redondance souhaité, les éléments de débit qui peuvent être indiqués dans le SDP, le chiffrement éventuel du flux, la version IP utilisée (IPv4 ou IPv6), le type de média demandé (audio, vidéo, texte, message, application, ou autre), le nombre de flux, ou la possibilité de partager des ressources (« ressource sharing » en anglais) déjà allouées.

En tout état de cause, l’information du débit ainsi alloué n’est classiquement pas propagée dans le plan de contrôle (par exemple vers le S- CSCF, le P-CSCF ou un AS distant) au-delà du P-CSCF lui-même (on notera que l’OCS, l’OFCS ou le PCRF ne sont pas considérés comme des entités de contrôle).

On notera toutefois qu’il existe déjà dans le protocole SDP des attributs indiquant la bande passante demandée. Ces attributs sont nommés b=AS, b=RR, b=RS, b=TIAS ou b=CT dans le protocole SDP (par exemple, « b=AS » identifie le débit souhaité en réception). Cependant l’usage de ces attributs n’est pas recommandé pour propager la valeur du débit alloué. En effet :

- rien ne permet d’affirmer que ces attributs sont ceux qui sont réellement utilisés par le P-CSCF du demandeur dans l’algorithme de calcul de débit mentionné ci-dessus ;

- ces attributs ne sont pas systématiquement présents dans le protocole

SDP ; en particulier, leur usage n’est pas défini, par exemple, pour les flux de type « message » ou « texte » ; - lorsque ces attributs sont présents, rien ne permet d’affirmer qu’ils ont été approuvés ou certifiés par le P-CSCF, et qu’ils sont donc fiables ;

- ces attributs sont nécessairement liés au protocole SDP ; or l’information de débit doit de préférence pouvoir être modifiée sans recourir au protocole SDP (i.e., sans renégociation globale du média).

Ces arguments suffisent à rendre l’usage de ces attributs indésirable pour un opérateur réseau souhaitant propager une information fiable.

La présente invention concerne donc, selon un premier aspect, un procédé de propagation d’informations de bande passante dans un réseau IP mettant en oeuvre un protocole de contrôle de session. Ledit procédé comprend les étapes suivantes :

- un usager dudit réseau demande un flux média ayant certaines caractéristiques,

- une Entité Applicative en charge dudit usager détermine, en fonction au moins desdites caractéristiques, des valeurs relatives à la bande passante allouée à cet usager pour ledit flux média, et

- ladite Entité Applicative insère des informations concernant lesdites valeurs dans un message de contrôle de session.

On notera que l’invention s’applique à tout réseau utilisant un protocole de contrôle de session, notamment les réseaux de type IMS et EPC.

Grâce à ces dispositions, l’invention permet de propager de manière fiable vers d’autres entités du réseau (notamment des entités de contrôle de session), à partir de l’Entité Applicative AF (par exemple, le P-CSCF) en charge du demandeur, des informations concernant la bande passante qui a été, ou sera effectivement réservée (habituellement, auprès du PCRF).

Selon des caractéristiques particulières, lesdites informations comprennent la mention d’au moins un média, et, pour ce média, des valeurs appartenant au groupe comprenant :

- une bande passante maximale pour la voie montante (« uplink » en anglais),

- une bande passante minimale pour la voie montante,

- une bande passante maximale pour la voie descendante (« downlink » en anglais), et - une bande passante minimale pour la voie descendante.

Grâce à ces dispositions, l’AF du demandeur indique, pour chacun des médias négociés, l’état des réservations sur le réseau d’accès du demandeur.

Selon des caractéristiques particulières :

- lesdites informations sont reçues par une Entité Applicative d’un correspondant dudit usager, et

- ladite Entité Applicative du correspondant met en œuvre une réservation dynamique de ladite bande passante sur la base desdites informations.

Grâce à ces dispositions, on peut, au niveau d’un correspondant dudit usager, ajuster ladite bande passante en fonction de besoins locaux et/ou temporaires.

Selon d’autres caractéristiques particulières :

- lesdites informations sont reçues par un Serveur d’Applications en charge de la taxation d’un service associé audit flux média et offert audit usager ou à un correspondant dudit usager, et

- ledit Serveur d’Applications reporte lesdites informations dans un ticket de taxation.

Grâce à ces dispositions, l’opérateur du réseau peut commodément déterminer la taxation à appliquer audit service lorsque cette taxation dépend de la bande passante.

Selon encore d’autres caractéristiques particulières :

- lesdites informations sont reçues par un Serveur de Téléphonie, et

- ledit Serveur de Téléphonie intervient sur des ressources demandées au cas où lesdites informations indiquent un risque de dépassement d’un seuil de bande passante prédéterminé.

Grâce à ces dispositions, ledit Serveur de Téléphonie peut réguler la bande passante utilisée pour prévenir des risques de saturation, ou imposer le respect d’un contrat de service relatif à un ou plusieurs usagers.

Corrélativement, selon un deuxième aspect, l'invention concerne divers dispositifs.

Elle concerne ainsi, premièrement, une Entité Applicative dans un réseau IP mettant en œuvre un protocole de contrôle de session. Ladite Entité Applicative comprend des moyens pour : - déterminer, en fonction au moins des caractéristiques d’un flux média demandé par un usager dudit réseau dont ladite Entité Applicative a la charge, des valeurs relatives à la bande passante allouée à cet usager pour ledit flux média, et

- insérer des informations concernant lesdites valeurs dans un message de de contrôle de session.

L’invention concerne aussi, deuxièmement, une entité réceptrice dans un réseau IP mettant en oeuvre un protocole de contrôle de session. Ladite entité réceptrice comprend des moyens pour recevoir dans un signal de contrôle de session, et prendre en compte, des informations relatives à la bande passante allouée à un usager dudit réseau pour un flux média demandé par ledit usager.

Selon des caractéristiques particulières, ladite entité réceptrice comprend une Entité Applicative d’un correspondant dudit usager, ladite Entité Applicative étant apte à mettre en oeuvre une réservation dynamique de ladite bande passante sur la base desdites informations.

Selon d’autres caractéristiques particulières, ladite entité réceptrice comprend un Serveur d’Applications en charge de la taxation d’un service associé audit flux média et offert audit usager ou à un correspondant dudit usager, ledit Serveur d’Applications étant apte à reporter lesdites informations dans un ticket de taxation.

Selon encore d’autres caractéristiques particulières, ladite entité réceptrice comprend un Serveur de Téléphonie apte à intervenir sur des ressources demandées au cas où lesdites informations indiquent un risque de dépassement d’un seuil de bande passante prédéterminé.

Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus.

On notera qu'il est possible de réaliser ces dispositifs dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques.

Selon un troisième aspect, l’invention concerne un réseau IP comprenant au moins une Entité Applicative et au moins une entité réceptrice telles que décrites succinctement ci-dessus.

L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes du procédé de propagation succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur.

Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé.

D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles :

- la figure 1 , décrite ci-dessus, représente une architecture PCC classique, et

- la figure 2 représente schématiquement un système pour la fourniture de services multimédia apte à mettre en oeuvre l'invention.

Bien que la présente invention concerne tout réseau IP faisant usage du protocole DIAMETER, on va considérer à présent, à titre d’exemple de réalisation, une architecture de réseau de type IMS, telle que présentée succinctement ci-dessus. Cette architecture est illustrée sur la figure 2.

Les services multimédia offerts par ce réseau IMS 1 peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage de contenu (« content-sharing » en anglais), de Présence, de Messagerie Instantanée, ou de télévision. Ces services sont à la disposition de l'utilisateur d'un dispositif-client (« User Equipment », ou UE en anglais) 10 appartenant au réseau 1 , qui permet au dispositif-client 10 d’échanger des flux multimédia et des signaux de contrôle de session conformes au protocole SIP, par exemple avec le dispositif-client (non représenté) d’un usager appartenant à un réseau SIP (non représenté) relié au réseau 1.

Le dispositif-client 10 peut être un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise, disposant de moyens de signalisation SIP et pouvant comprendre des moyens de restitution d'un contenu audiovisuel.

Comme le montre la figure 2, ce réseau IMS 1 comprend, outre une infrastructure de transport IP (non représentée) : • au moins un serveur S-CSCF ; le serveur S-CSCF 27 gère notamment la procédure d'enregistrement des dispositifs connectés au réseau 1 ; le serveur S-CSCF 27 gère également le routage de la signalisation entre le dispositif-client 10 et les serveurs de messagerie vocale VM 25, de Messagerie Instantanée 26, et de téléphonie TAS 29 ;

• au moins un serveur l-CSCF ; le serveur l-CSCF 22 gère notamment le routage en direction d'autres terminaux gérés par le même réseau IMS 1 et le routage de la signalisation entre ce réseau IMS 1 et d'autres réseaux (non représentés) ;

• au moins un serveur P-CSCF ; le serveur P-CSCF 21 sert d’entité de raccordement entre le cœur de réseau IMS et le réseau d’accès utilisé par le dispositif-client 10 ;

• au moins un serveur de base de données, de type HSS ; le serveur HSS 24 contient le profil de l’utilisateur du dispositif-client 10 en termes de données d'authentification et de localisation, et de services souscrits ;

• au moins un serveur VM 25 de messagerie vocale (« voice mai! » en anglais) ; le serveur VM 25 gère la souscription du dispositif-client 10 aux événements de dépôt/consultation des messages à l’intention du dispositif- client 10, et notifie le dispositif-client 10 lors de l'occurrence de ces événements ;

• au moins un serveur de Messagerie Instantanée IM 26 ; en cas de souscription de l’utilisateur de l’UE 10 au service de Messagerie Instantanée, cet utilisateur peut dialoguer « instantanément » en ligne avec d’autres abonnés à ce service ; et

• au moins un serveur de téléphonie TAS 29 ; le serveur TAS gère les services téléphoniques auxquels l'utilisateur du terminal 10 a souscrits auprès de son opérateur, tels que la présentation du numéro ou le renvoi d'appel.

Les serveurs de messagerie vocale VM 25, de Messagerie Instantanée IM 26, et de téléphonie TAS 29 sont des exemples de Serveurs d'Applications (AS). Certains services, comme ceux du serveur VM 25 et du serveur de Messagerie Instantanée IM 26, s'appuient sur la souscription du terminal 10 à des événements prédéterminés, comme expliqué ci-dessus.

Sur la figure 2, les lignes en pointillé représentent le chemin réel suivi par les signaux SIP (entre l’UE 10 et l’entité PCEF 31 , puis entre l’entité PCEF 31 et le serveur P-CSCF 21 ). La ligne hachurée (entre l’UE 10 et le serveur P-CSCF 21 ) représente le chemin « logique » de la signalisation SIP. L’entité PCRF 30 est connectée à l’entité PCEF 31 et au serveur P-CSCF 21 . Le serveur P-CSCF 21 joue ici le rôle d’Entité Applicative AF selon l’architecture PCC.

De manière connue, cette architecture peut mettre en œuvre les étapes suivantes.

Lors d’une étape E1 , le serveur P-CSCF 21 reçoit un message de contrôle de session émis par l’UE 10 et contenant une description de flux media conforme au protocole SDP (Session Description Protocol).

Lors d’une étape E2, le serveur P-CSCF 21 émet une demande de réservation de flux média auprès de l’entité PCRF 30. Cette demande de réservation de flux média est un message de contrôle de ressources Diameter « AAR » (pour « AA-Request ») tel que défini dans le document RFC 4005 de l’IETF.

Lors d’une étape E3, l’entité PCRF 30 envoie au serveur P-CSCF 21 un message d’acquittement de la demande de réservation de flux. Ce message d’acquittement est un message de contrôle de ressources Diameter « AAA » (pour « AA-Answer ») tel que défini dans le document RFC 4005.

Lors d’une étape E4, l’entité PCRF 30 envoie à l’entité d’application des règles PCEF 31 un message décrivant les règles à installer pour mettre en œuvre les flux média. Ce message décrivant les règles à installer est un message de contrôle de ressources Diameter « RAR » (pour « RA-Request ») tel que défini dans le document RFC 4005.

Lors d’une étape E5, l’entité PCEF 31 envoie à l’entité PCRF 30 un message d’acquittement d’installation des règles. Ce message d’acquittement est un message de contrôle de ressources Diameter « RAA » (pour « RA- Answer ») tel que défini dans le document RFC 4005. Enfin, lors d’une étape E6, l’entité PCEF 31 met en œuvre lesdites règles et autorise les flux média.

Considérons à titre d’exemple l’offre SDP suivante :

v=0

o=— 24351 621814 IN IP4 192.0.2.2

s=

c=IN IP4 192.0.2.2

t=0 0

m=audio 54320 RTP/AVP 0

m=video 66544 RTP/AVP 100 et supposons que le P-CSCF a demandé auprès du PCRF :

- exactement 96 kilobit/s pour ledit flux audio, et

- 127 kilobit/s maximum ainsi que 64 kilobit/s minimum pour ledit flux vidéo. Selon un mode de réalisation de l’invention, on utilise un en-tête

(« header » en anglais) SIP dédié, que l’on appellera « P-Reserved-Bandwith », pour propager l’information de débit alloué. Cet en-tête peut être codé comme suit :

P-Reserved-Bandwith : m="audio 54320", max-bandwidth- uplink=96, max-bandwidth-downlink=96, min-bandwidth- uplink=96 , min-bandwidth-downlink=96

P-Reserved-Bandwith : m="video 66544", max-bandwidth- uplink=127, max-bandwidth-downlink=127, min-bandwidth- uplink=64 , min-bandwidth-downlink=64

Cet en-tête est alors transmis au moyen d’un message SIP. Après réception par diverses entités du réseau, l’analyse du contenu de cet en-tête permet à ces entités de mettre en œuvre différentes applications, telles que celles mentionnées ci-dessus.

Par exemple, le P-CSCF en charge du correspondant du demandeur peut alors ajuster les valeurs à réserver, ou les valeurs utilisées dans la session en cours, en alimentant un paramètre Media-Component-Description tel que décrit ci-dessus. On notera à cet égard qu’un P-CSCF classique est apte à alimenter un paramètre Media-Component-Description, mais sur la base d’informations reçues dans le SDP ; en revanche, dans le présent mode de réalisation de l’invention, le P-CSCF en charge du correspondant alimente un paramètre Media-Component-Description sur la base d’informations qu’il a reçues de la part du P-CSCF du demandeur.

Selon un autre exemple, un AS en charge d’un service offert à l’usager ou à son correspondant peut alors reporter ces informations de bande passante dans un ticket de taxation CDR (tel que mentionné ci-dessus), pour exploitation ultérieure par une application de facturation ou de surveillance du réseau. On notera à cet égard que les AS classiques ne reçoivent pas ces informations de bande passante. Dans le cadre du présent mode de réalisation de l’invention, on pourra par exemple prévoir commodément que les AS insèrent les informations de bande passante dans le champ « Record Extension » du CDR, connu en soi.

Selon la politique particulière de l’opérateur, les informations de bande passante pourront, optionnellement, être communiquées à des équipements de moindre confiance du réseau.

A la place de l’en-tête « P-Reserved-Bandwith » selon l’invention, les informations de bande passante pourront, en variante, être propagées au sein d’un body xml encapsulé ; elles pourront aussi être commodément propagées dans des extensions du protocole SDP : en effet, contrairement à l’état de l’art, elles seront fiables car fournies par une entité de confiance, à savoir le P- CSCF/AF du demandeur et non le demandeur lui-même.

De manière générale, la présente invention peut être mise en œuvre au sein des nœuds d’un réseau IP, par exemple des Entités Applicatives ou des Serveurs d’Applications, au moyen de composants logiciels et/ou matériels.

Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d’entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d’ordinateur comportant des instructions pour la mise en œuvre de l'un quelconque des procédés de propagation selon l’invention. En effet, l’invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de propagation selon l’invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d’ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur.

Ce programme peut utiliser n’importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

L’invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou un moyen d'enregistrement magnétique, tel qu’un disque dur, ou encore une clé USB (« USB flash drive » en anglais).

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un quelconque des procédés de propagation selon l'invention.