WO2007148015A2 - Systeme de declenchement d'un comptage dans un reseau de transport a travers un reseau a architecture de type ims - Google Patents

Systeme de declenchement d'un comptage dans un reseau de transport a travers un reseau a architecture de type ims Download PDF

Info

Publication number
WO2007148015A2
WO2007148015A2 PCT/FR2007/051471 FR2007051471W WO2007148015A2 WO 2007148015 A2 WO2007148015 A2 WO 2007148015A2 FR 2007051471 W FR2007051471 W FR 2007051471W WO 2007148015 A2 WO2007148015 A2 WO 2007148015A2
Authority
WO
WIPO (PCT)
Prior art keywords
network
architecture
counting
server
service
Prior art date
Application number
PCT/FR2007/051471
Other languages
English (en)
Other versions
WO2007148015A3 (fr
Inventor
Murielle Ebrel
Pascal Delvallet
Matthieu Smessaert
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2007148015A2 publication Critical patent/WO2007148015A2/fr
Publication of WO2007148015A3 publication Critical patent/WO2007148015A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Definitions

  • the present invention relates to a system for triggering, in a transport network, counting on flows associated with a service.
  • the invention finds application in the general field of counting via the analysis of the flows conveyed in a transport network, and, more particularly, in the field of type counting architecture.
  • FBC Flow Based Charging
  • counting translated as “charging” in Anglo-Saxon, covers the operations performed to collect network data during sessions or calls implementing a service, so as to provide the billing chain with useful accounting information and also to inform the user of the cost of the service being performed.
  • FBC is known as a particular metering architecture based on three functional entities defined by the 3GPP ("3rd Generation Partnership Project"). These three entities, represented in FIG. 1, are the following:
  • - TAF Application Function
  • CRF Charge RuIe Function
  • TPF Traffic Plane Function
  • GGSN Gateway GPRS Support Node
  • Rx and Gx interfaces are statically created between the different functional entities via the Diameter protocol according to the specifications of 3GPP 1 more precisely, in the documents TS29.210, TS29.211, TS29.212 and TS29.214.
  • IMS IP Multimedia Sub-system
  • TISPAN Telecommunications and Internet Converged Services and Protocols for Advanced Networking
  • This architecture enables the dynamic establishment and control of multimedia sessions between two clients as well as the reservation of resources at the level of the media flow transport network. It also manages the interaction of services.
  • FIG. 1 illustrates a known architecture of a GPRS mobile transport network controlled by an IMS architecture network. This architecture involves:
  • P-CSCF Proxy-Call Session Control Function
  • an S-CSCF (“Serving-CSCF”) routing server that manages the user in the IMS network and, in particular, the trigger points to application servers with which the user has subscribed to one or more services .
  • the S-CSCF server is assigned to the user by an I-CSCF server ("Interrogating-CSCF”), not shown, during the registration of the user equipment in the IMS network;
  • the application server AS contains all the information relating to the service to which the user has subscribed. This information is provided by the service operator or an associated third-party provider. Counting can be essentially of two types:
  • the FBC type counting according to which the P-CSCF proxy server hosts the FBC-type counting AF function as represented in FIG. Figure 1.
  • the AF function performs counting from preconfigured data such as, for example, addresses to which the counting elements set by the AF function are to be sent. This preconfigured data is the same for all users and services.
  • the IMS-type count according to which a counting profile established for a user, hosted by a database of the HSS ("Home Subscriber Server") type, is sent to the S-CSCF server at the time of registration of the user equipment in PIMS and transmitted from the S-CSCF to all IMS nodes.
  • the IMS type counting profile can be "offline", that is to say with deferred user billing, or "online”, that is to say, real time, to manage users with packages. For these profiles, it is addresses of modules that are filled.
  • the information preconfigured in the AF function performing the FBC counting is not relevant with respect to the service in question.
  • a conversational service such as voice over IP (VoIP)
  • VoIP voice over IP
  • counting is supported by the IMS architecture network itself. It is understood that this situation can lead to double counting, namely a counting by the IMS architecture network and an FBC type count in the transport network.
  • an object of the invention is to prevent a count in the transport network is triggered automatically when there is no need to be, the counting can be performed in the only architecture network IMS type.
  • a triggering system in a transport network, of counting on flows associated with a service, remarkable in that said transport network being controlled for said service by an IMS-type architecture network, said system comprises an application server associated with said service, able to decide through said IMS type architecture network to trigger said count in the transport network.
  • the AS application server of the IMS type architecture containing all the data relating to the service in question has all the information enabling it to decide on the relevance. to trigger or not a count in the transport network.
  • said application server decides to trigger the counting based on a count profile established for a user and information concerning said service, critical for counting and may be contrary to the counting profile.
  • the server applying network architecture type IMS has the overall view of the service. It can therefore control, in the IMS, the triggering of the count in the transport network or in the IMS.
  • the system which is the subject of the invention, therefore makes it possible to trigger the counting architecture only if the type of service implemented on the IMS network justifies it. For example, for a streaming read service
  • Streaming it is relevant to trigger in addition to counting in the IMS network a count in the transport network, the latter can be done by volume of data transmitted, time, etc. Conversely, other services managed on the IMS network will only use IMS counting by inhibiting counting in the transport network, as discussed above with respect to conversational services.
  • said counting profile is stored in a database in the IMS-type architecture network and transmitted to the application server by a routing server of said IMS architecture network when a request for access to the service.
  • This database may be hosted in the aforementioned HSS server, or in any other database provided that the latter is functionally attached, either directly or indirectly via, for example, the S-CSCF, to the application server responsible for triggering the database.
  • FBC type counting architecture is stored in a database in the IMS-type architecture network and transmitted to the application server by a routing server of said IMS architecture network when a request for access to the service.
  • the invention advantageously provides that, since said counting is performed according to an FBC-type architecture, the application server decides on a value of a count parameter according to the count profile established for a user and information relating to said service and triggers the counting by sending said count parameter to a server performing an AF application function of said FBC type architecture.
  • This parameter can take a value, 1 or 0 for example, which depends on the trigger decision taken by the application server.
  • the AF application function triggers or not the FBC type count according to the value of said parameter.
  • said entity performing the AF application function is the proxy server P-CSCF.
  • the AF application function of the FBC type counting architecture is directly hosted in the application server AS.
  • the invention also relates to an application server in an IMS type architecture network, which is remarkable in that said application server is able to decide on a trigger, through said IMS type architecture network, of a counting, in a transport network controlled by said IMS-type architecture network for a service associated with said application server, on flows associated with said service.
  • the invention furthermore relates to a routing server in an IMS type architecture network, remarkable in that said routing server is adapted, during a request for access to a service through the IMS-type architecture network, to transmit to an application server associated with said service a metering profile, in a transport network controlled for said service by the IMS architecture network, on flows associated with said service.
  • the invention furthermore relates to a CRF server intended to perform a CRF function in an FBC type counting architecture in a transport network, remarkable in that said CRF server is able to transmit address information to a server.
  • application in an IMS architecture network controlling the transport network said application server being able to decide, through said IMS architecture network, to trigger said count in the transport network and performing an application function AF of said FBC type architecture,
  • the invention relates to a method of triggering, in a transport network, a count on flows associated with a service, characterized in that, said transport network being controlled for said service by a type architecture network.
  • IMS comprising an application server associated with said service
  • said method comprises a step consisting, for said application server, in deciding, through said architecture network type IMS, the triggering of said count in the transport network.
  • said counting being carried out in accordance with an FBC type architecture, said method comprises the steps of: storing in a database a counting profile established for a user,
  • said method further comprises the steps of:
  • Figure 2a is a diagram of a first embodiment of a counting trigger system according to the invention.
  • Fig. 2b is a diagram of a variant of the embodiment of Fig. 2a.
  • Figure 3 is a diagram of a second embodiment of a counting trigger system according to the invention.
  • the functional entities AF, CRF and TPF are designated according to terms defined in version 6 of the 3GPP.
  • the invention also relates to the later versions of 3GPP.
  • FIG. 2a shows a system for triggering an FBC architecture count in a packet type transport network 1, such as a GPRS network.
  • the count is performed on flows associated with a given service subscribed for a UE user equipment 10 to an operator.
  • this service may be, for example, a streaming service or a conversational service of the VoIP type.
  • the transport network is controlled by an IMS-type network 2 which includes an application server 20
  • the operator defines for the user equipment 10 a user profile which is stored in a database 21 which may be the HSS base as indicated above or a database of the application server AS.
  • a database 21 which may be the HSS base as indicated above or a database of the application server AS.
  • the counting profile established for a user housed in the HSS database 21 is retrieved by the S-CSCF routing server 22 of the IMS network when the user equipment 10 is stored in the network. the IMS network.
  • the S-CSCF server 22 transmits the counting profile to the server 20 by inserting this information in the SIP message ( "Session Initiation Protocol") INVITES using for example the parameter "P-Charging Function Address”.
  • the application server AS 20 analyzes the metering profile received and decides to trigger the count in the transport network 1.
  • the AS application server 20 returns to the S-CSCF server 22 in the SIP message INVITE an FBC count parameter.
  • This parameter may take a value equal to 1, for example, indicating that an FBC type count must be triggered in the transport network 1, as for the "streaming" service that actually requires an FBC type count. If, on the contrary, the count profile received by the server 20 must be contradicted, as for the VoIP service counted in the IMS network, the count parameter returned to the server S-CSCF 22 is equal to a value For example to indicate that an FBC type count in the transport network 1 is not necessary.
  • the routing server 22 S-CSCF transmits the routing parameter to the proxy server 23 P-CSCF in a SIP message 200 OK.
  • the P-CSCF server 23 hosting the AF application function of the FBC architecture triggers or not the FBC type counting, via a command sent to the CRF entity via the Rx interface, according to the parameter count received from server 22 S-CSCF.
  • FIG. 2b shows a variant of the system of FIG.
  • the application server AS itself creates, according to its service logic, the counting parameter that it transmits to the proxy server 23 P-CSCF via the server 22 S-CSCF to rely on the AF application function of the P-CSCF server 23, which provides the command for triggering the FBC type architecture in the transport network 1 via a command sent to the entity CRF via the Rx interface.
  • FIG. 3 is shown a second embodiment of the system according to the invention.
  • the FBC type counting profile is stored in the HSS database 21 or any other database, then transmitted to the S-CSCF server 22 during the registration of the equipment. in the IMS network 2.
  • This counting profile is then supplied to the application server AS by the server 22 S-CSCF following a request for access to the service from the user equipment 10.
  • the server 20 The application decides whether or not an FBC count should be triggered and establishes a counting parameter based on its decision.
  • the AS application server 20 is enriched with an AF application function that enables it to trigger the FBC type architecture. This triggering is based on the creation of a link between the server 20 AS and a server 24 providing the CRF function of the FBC type architecture, said link being made by an Rx-type interface requiring the reassembly of the address information. the CRF to the AS server via the P-CSCF server 23, as shown in FIG.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

Système de déclenchement, dans un réseau (1 ) de transport, d'un comptage sur des flux associés à un service. Selon l'invention, ledit réseau de transport étant contrôlé pour ledit service par un réseau (2) à architecture de type IMS, ledit système comprend un serveur (20) d'application associé audit service, apte à décider à travers ledit réseau (2) à architecture de type IMS du déclenchement dudit comptage dans le réseau (1 ) de transport. Application à l'architecture de comptage de type FBC dans un réseau de transport.

Description

SYSTEME DE DECLENCHEMENT D'UN COMPTAGE DANS UN RESEAU DE TRANSPORT ATRAVERS UN RESEAU AARCHITECTURE DE TYPE
IMS
La présente invention concerne un système de déclenchement, dans un réseau de transport, d'un comptage sur des flux associés à un service.
L'invention trouve une application dans le domaine général du comptage via l'analyse des flux véhiculés dans un réseau de transport, et, plus spécialement, dans le domaine de l'architecture de comptage de type
FBC (« Flow Based Charging ») définie en normalisation pour les accès mobiles mais également applicable pour les accès fixes.
Dans le cadre de l'invention, le terme de « comptage », traduit par « charging » en anglo-saxon, recouvre les opérations effectuées pour collecter des données réseau lors de sessions ou d'appels mettant en œuvre un service, de manière à fournir à la chaîne de facturation les éléments comptables utiles et également à notifier à l'utilisateur des informations sur le coût à payer pour le service exécuté.
On connaît sous l'acronyme FBC une architecture de comptage particulière qui repose sur trois entités fonctionnelles définies dans le cadre du 3GPP («3rd Génération Partnership Project»). Ces trois entités, représentées sur la figure 1 , sont les suivantes :
- TAF (« Application Function ») qui est chargée de collecter les informations propres au service et de les transmettre à l'entité CRF ; - la CRF (« Charging RuIe Function ») qui, à partir des informations reçues de FAF, définit, statiquement et dynamiquement, une règle de comptage ainsi que certains paramètres de la règle de comptage ;
- la TPF (« Traffic Plane Function ») qui est une fonction logique du GGSN (« Gateway GPRS Support Node ») assurant l'identification des paquets dans les flux du réseau de transport et l'application de la règle de comptage en fonction des informations reçues de la CRF. Des interfaces Rx et Gx sont créées de manière statique entre les différentes entités fonctionnelles via le protocole Diameter conformément aux spécifications du 3GPP1 plus précisément, dans les document TS29.210, TS29.211 , TS29.212 et TS29.214.
L'IMS («IP Multimedia Sub-system ») est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN («Télécommunications and Internet converged Services and Protocols for Advanced Networking») pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau de transport des flux médias. Elle gère aussi l'interaction de services.
L'IMS est actuellement défini essentiellement pour des applications de type téléphonie, visiophonie, présence et messagerie instantanée. Sur la figure 1 est illustrée une architecture connue d'un réseau de transport mobile GPRS contrôlé par un réseau d'architecture de type IMS. Cette architecture fait intervenir :
- un serveur mandataire P-CSCF («Proxy-Call Session Control Function ») qui est le premier point de contact de l'équipement utilisateur UE dans le réseau IMS et qui gère l'interaction avec les ressources du réseau de transport ;
- un serveur de routage S-CSCF (« Serving-CSCF ») qui gère l'utilisateur dans le réseau IMS et, notamment, les points de déclenchement vers des serveurs d'application auprès desquels l'utilisateur a souscrit à un ou plusieurs services. Le serveur S-CSCF est attribué à l'utilisateur par un serveur I-CSCF («Interrogating-CSCF»), non représenté, lors de l'enregistrement de l'équipement utilisateur dans le réseau IMS ;
- un serveur d'application, noté AS (« Application Server »), associé au service considéré. Le serveur d'application AS contient toutes les informations relatives au service auquel l'utilisateur a souscrit. Ces informations sont fournies par l'opérateur du service ou un fournisseur tiers associé. Le comptage peut être essentiellement de deux types :
- le comptage de type FBC, selon lequel le serveur mandataire P-CSCF héberge la fonction AF de comptage de type FBC telle que représentée sur la figure 1. La fonction AF réalise le comptage à partir de données préconfigurées comme, par exemple, des adresses auxquelles les éléments de comptage établis par la fonction AF doivent être envoyés. Ces données préconfigurées sont les mêmes pour tous les utilisateurs et tous les services. - le comptage de type IMS, selon lequel un profil de comptage établi pour un utilisateur, hébergé par une base de données du type HSS («Home Subscriber Server»), est envoyé vers le serveur S-CSCF au moment de l'enregistrement de l'équipement utilisateur dans PIMS et transmis depuis le S- CSCF vers tous les nœuds IMS. Le profil de comptage de type IMS peut être « offline », c'est-à-dire avec facturation différée de l'utilisateur, ou « online », c'est-à-dire temps réel, pour gérer des utilisateurs avec forfaits. Pour ces profils, ce sont des adresses de modules qui sont renseignées.
Or, il peut se produire que, dans le cadre de l'architecture mixte réseau de transport/réseau IMS représentée sur la figure 1 , les informations préconfigurées dans la fonction AF réalisant le comptage FBC ne soient pas pertinentes eu égard au service considéré. Par exemple, dans le cas d'un service conversationnel, comme la voix sur IP (VoIP), le comptage est pris en charge par le réseau à architecture de type IMS lui-même. On comprend que cette situation puisse conduire à un double comptage, à savoir un comptage par le réseau d'architecture de type IMS et un comptage de type FBC dans le réseau de transport.
Aussi, un but de l'invention est d'éviter qu'un comptage dans le réseau de transport ne soit déclenché automatiquement alors qu'il n'a pas lieu de l'être, le comptage pouvant être effectué dans le seul réseau à architecture de type IMS.
Ce but est atteint, conformément à l'invention, au moyen d'un système de déclenchement, dans un réseau de transport, d'un comptage sur des flux associés à un service, remarquable en ce que ledit réseau de transport étant contrôlé pour ledit service par un réseau à architecture de type IMS, ledit système comprend un serveur d'application associé audit service, apte à décider à travers ledit réseau à architecture de type IMS du déclenchement dudit comptage dans le réseau de transport. Ainsi, dans le système de déclenchement de comptage conforme à l'invention, le serveur d'application AS de l'architecture de type IMS contenant l'ensemble des données relatives au service considéré dispose de toutes les informations lui permettant de décider de la pertinence de déclencher ou non un comptage dans le réseau de transport.
En particulier, ledit serveur d'application décide du déclenchement du comptage en fonction d'un profil du comptage établi pour un utilisateur et d'informations concernant ledit service, déterminantes pour le comptage et pouvant s'avérer contraires au profil de comptage. En d'autres termes, le serveur s'application du réseau à architecture de type IMS a la vision d'ensemble du service. Il peut donc commander, dans l'IMS, le déclenchement du comptage dans le réseau de transport ou dans l'IMS.
Le système, objet de l'invention, permet donc de ne déclencher l'architecture de comptage que si le type de service mis en œuvre sur le réseau IMS le justifie. Par exemple, pour un service de type lecture en transit
(« streaming »), il est pertinent de déclencher en plus du comptage dans le réseau IMS un comptage dans le réseau de transport, ce dernier pouvant se faire en volume de données transmises, du temps, etc. A l'inverse, d'autres services gérés sur le réseau IMS utiliseront uniquement le comptage IMS en inhibant le comptage dans le réseau de transport, comme on l'a vu plus haut à propos des services conversationnels.
Les avantages de l'invention sont les suivants :
- optimisation des ressources mises en œuvre sur le réseau de transport pour le comptage du fait que l'architecture de comptage n'est pas systématiquement sollicitée ;
- simplification des traitements du système d'information chargé de la facturation, le système d'information n'ayant pas à sélectionner l'information utile en fonction de l'usage, cette action étant réalisée dans le réseau ;
- commande centralisée des mécanismes de comptage appropriés en fonction du service demandé par l'utilisateur qui se traduit par un seul point de comptage vu de l'utilisateur ;
- gain en termes de procédures ;
- gain en termes de coût par la minimisation des liens entre les architectures. Selon un mode de réalisation de l'invention, ledit profil de comptage est stocké dans une base de données dans le réseau à architecture de type IMS et transmis au serveur d'application par un serveur de routage dudit réseau à architecture de type IMS lors d'une demande d'accès au service. Cette base de données peut être hébergée dans le serveur HSS précité, ou dans toute autre base à condition que cette dernière soit attachée fonctionnellement, soit directement ou indirectement via par exemple le S-CSCF, au serveur d'application responsable du déclenchement de l'architecture de comptage du type FBC. Par ailleurs, s'agissant du déclenchement du comptage dans l'architecture de comptage, l'invention prévoit de façon avantageuse que, ledit comptage étant effectué conformément à une architecture de type FBC, le serveur d'application décide d'une valeur d'un paramètre de comptage en fonction du profil de comptage établi pour un utilisateur et d'informations concernant ledit service et déclenche le comptage par émission dudit paramètre de comptage vers un serveur réalisant une fonction d'application AF de ladite architecture de type FBC. Ce paramètre peut prendre une valeur, 1 ou 0 par exemple, qui dépend de la décision de déclenchement prise par le serveur d'application. La fonction d'application AF déclenche ou non le comptage de type FBC selon la valeur dudit paramètre.
Dans un premier mode de réalisation, ladite entité réalisant la fonction d'application AF est le serveur mandataire P-CSCF.
Dans un deuxième mode de réalisation, la fonction d'application AF de l'architecture de comptage de type FBC est directement hébergée dans le serveur d'application AS.
L'invention concerne également un serveur d'application dans un réseau à architecture de type IMS, remarquable en ce que ledit serveur d'application est apte à décider d'un déclenchement, à travers ledit réseau à architecture de type IMS, d'un comptage, dans un réseau de transport contrôlé par ledit réseau à architecture de type IMS pour un service associé audit serveur d'application, sur des flux associés audit service.
L'invention concerne en outre un serveur de routage dans un réseau à architecture de type IMS, remarquable en ce que ledit serveur de routage est apte, lors d'une demande d'accès à un service à travers le réseau à architecture de type IMS, à transmettre à un serveur d'application associé audit service un profil de comptage, dans un réseau de transport contrôlé pour ledit service par le réseau à architecture de type IMS, sur des flux associés audit service.
L'invention concerne de plus un serveur CRF destiné à réaliser une fonction CRF dans une architecture de comptage de type FBC dans un réseau de transport, remarquable en ce que ledit serveur CRF est apte à transmettre des informations d'adresses à un serveur d'application dans un réseau à architecture de type IMS contrôlant le réseau de transport, ledit serveur d'application étant apte à décider à travers ledit réseau à architecture de type IMS du déclenchement dudit comptage dans le réseau de transport et réalisant une fonction d'application AF de ladite architecture de type FBC,
Enfin, l'invention concerne un procédé de déclenchement, dans un réseau de transport, d'un comptage sur des flux associés à un service, caractérisé en ce que, ledit réseau de transport étant contrôlé pour ledit service par un réseau à architecture de type IMS comprenant un serveur d'application associé audit service, ledit procédé comprend une étape consistant, pour ledit serveur d'application, à décider, à travers ledit réseau à architecture de type IMS, du déclenchement dudit comptage dans le réseau de transport.
Selon une première mise en oeuvre, ledit comptage étant effectué conformément à une architecture de type FBC, ledit procédé comprend les étapes consistant à : stocker dans une base de données un profil de comptage établi pour un utilisateur,
- transmettre ledit profil de comptage audit serveur d'application,
- décider par le serveur d'application d'une valeur d'un paramètre de comptage en fonction dudit profil de comptage et d'informations concernant ledit service,
- transmettre par le serveur d'application ledit paramètre de comptage à une fonction d'application AF de l'architecture de type FBC. Dans une deuxième mise en oeuvre, ledit comptage étant effectué conformément à une architecture de type FBC, ledit procédé comprend en outre les étapes consistant à :
- transmettre au serveur d'application des informations d'adresses d'un serveur hébergeant une fonction CRF de l'architecture de comptage de type
FBC,
- transmettre par le serveur d'application ledit paramètre de comptage audit serveur CRF.
La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
La figure 2a est un schéma d'un premier mode de réalisation d'un système de déclenchement de comptage conforme à l'invention. La figure 2b est un schéma d'une variante du mode de réalisation de la figure 2a.
La figure 3 est un schéma d'un second mode de réalisation d'un système de déclenchement de comptage conforme à l'invention.
Dans ce qui suit, les entités fonctionnelles AF, CRF et TPF sont désignées selon des termes définis en version 6 du 3GPP. Toutefois, l'invention concerne également les versions ultérieures du 3GPP.
Sur la figure 2a est représenté un système de déclenchement d'un comptage à architecture FBC dans un réseau 1 de transport de type paquet, tel qu'un réseau GPRS. Le comptage est effectué sur des flux associés à un service donné souscrit pour un équipement utilisateur 10 UE auprès d'un opérateur. Comme mentionné plus haut, ce service peut être, par exemple, un service de lecture en transit (« streaming ») ou un service conversationnel du type VoIP.
Relativement audit service, le réseau de transport est contrôlé par un réseau 2 à architecture de type IMS lequel inclut un serveur 20 d'application
AS associé au service considéré, au sens où il contient toutes les données définissant le service, ici « streaming » ou VoIP, à fournir à l'équipement utilisateur 10 sur une demande d'accès à ce service. Par ailleurs, l'opérateur définit pour l'équipement utilisateur 10 un profil utilisateur qui est stocké dans une base 21 de données qui peut être la base HSS comme indiqué plus haut ou une base de données du serveur 20 d'application AS. Comme on peut le voir sur la figure 2a, le profil de comptage établi pour un utilisateur hébergé dans la base HSS 21 est récupéré par le serveur 22 de routage S-CSCF du réseau IMS lors de l'enregistrement de l'équipement utilisateur 10 dans le réseau IMS.
Lorsqu'un appel est établi par l'équipement utilisateur 10 vers le serveur 20 d'application AS afin d'accéder au service, le serveur 22 S-CSCF transmet le profil de comptage au serveur 20 en insérant cette information dans le message SIP (« Session Initiation Protocol ») INVITE en utilisant par exemple le paramètre « P-Charging Function Address ».
Le serveur 20 d'application AS analyse alors le profil de comptage reçu et décide du déclenchement du comptage dans le réseau 1 de transport. Le serveur 20 d'application AS retourne au serveur 22 S-CSCF dans le message SIP INVITE un paramètre de comptage FBC. Ce paramètre peut prendre une valeur égale à 1 par exemple indiquant qu'un comptage de type FBC doit être déclenché dans le réseau 1 de transport, comme pour le service de « streaming » qui nécessite effectivement un comptage de type FBC. Si, au contraire, le profil de comptage reçu par le serveur 20 doit être contredit, comme pour le service de VoIP dont le comptage est assuré dans le réseau IMS, le paramètre de comptage retourné au serveur 22 S-CSCF est égal à une valeur 0 par exemple de manière à indiquer qu'un comptage de type FBC dans le réseau 1 de transport n'est pas nécessaire.
Conformément à la figure 2a, le serveur 22 de routage S-CSCF transmet le paramètre de routage au serveur mandataire 23 P-CSCF dans un message SIP 200 OK. Le serveur 23 P-CSCF hébergeant la fonction d'application AF de l'architecture FBC déclenche ou non le comptage de type FBC, via une commande envoyée vers l'entité CRF par l'intermédiaire de l'interface Rx, selon le paramètre de comptage reçu du serveur 22 S-CSCF.
Plus précisément, si la valeur du paramètre de comptage vaut 0, le serveur 23 P-CSCF n'envoie aucune donnée à la fonction CRF, ce qui implicitement correspond à une désactivation de l'architecture de type FBC dans le réseau de transport. Par contre, si la valeur du paramètre de comptage vaut 1 , le serveur P-CSCF envoie ses données vers la fonction CRF et commande donc l'architecture de type FBC. La figure 2b montre une variante du système de la figure 2a dans laquelle le serveur 20 d'application AS crée lui-même en fonction de sa logique de service le paramètre de comptage qu'il transmet au serveur mandataire 23 P-CSCF via le serveur 22 S-CSCF pour s'appuyer sur la fonction d'application AF du serveur 23 P-CSCF, laquelle assure la commande pour le déclenchement de l'architecture de type FBC dans le réseau 1 de transport via une commande envoyée vers l'entité CRF par l'intermédiaire de l'interface Rx.
Sur la figure 3 est représenté un second mode de réalisation du système conforme à l'invention. Comme dans le mode de réalisation de la figure 2a, le profil de comptage de type FBC est stocké dans la base HSS 21 ou toute autre base de données, puis transmis au serveur 22 S-CSCF lors de l'enregistrement de l'équipement 10 dans le réseau IMS 2. Ce profil de comptage est ensuite fourni au serveur 20 d'application AS par le serveur 22 S-CSCF à la suite d'une demande d'accès au service venant de l'équipement utilisateur 10. Le serveur 20 d'application décide si un comptage de type FBC doit ou non être déclenché et établit un paramètre de comptage en fonction de sa décision.
Dans le mode de réalisation de la figure 3, le serveur 20 d'application AS est enrichi d'une fonction d'application AF qui lui permet de déclencher l'architecture de type FBC. Ce déclenchement repose sur la création d'un lien entre le serveur 20 AS et un serveur 24 assurant la fonction CRF de l'architecture de type FBC, ledit lien étant réalisé par une interface de type Rx nécessitant la remontée des informations d'adresses de l'entité CRF au serveur 20 AS via le serveur 23 P-CSCF, comme indiqué sur la figure 3.

Claims

REVENDICATIONS
1. Système de déclenchement, dans un réseau (1 ) de transport, d'un comptage sur des flux associés à un service, caractérisé en ce que, ledit réseau de transport étant contrôlé pour ledit service par un réseau (2) à architecture de type IMS, ledit système comprend un serveur (20) d'application associé audit service, apte à décider à travers ledit réseau (2) à architecture de type IMS du déclenchement dudit comptage dans le réseau (1 ) de transport.
2. Système selon la revendication 1 , caractérisé en ce que ledit serveur (20) d'application décide du déclenchement du comptage en fonction d'un profil de comptage établi pour un utilisateur et d'informations concernant ledit service.
3. Système selon la revendication 2, caractérisé en ce que ledit profil de comptage est stocké dans une base (21 ) de données dans le réseau (2) à architecture de type IMS et transmis au serveur (20) d'application par un serveur (22) de routage dudit réseau à architecture de type IMS lors d'une demande d'accès au service.
4. Système selon la revendication 2, caractérisé en ce que ledit profil de comptage est stocké dans une base de données du serveur (20) d'application.
5. Système selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, ledit comptage étant effectué conformément à une architecture de type FBC, le serveur (20) d'application décide d'une valeur d'un paramètre de comptage en fonction du profil de comptage établi pour un utilisateur et d'informations concernant ledit service et déclenche le comptage par émission dudit paramètre de comptage vers un serveur (23,20) réalisant une fonction d'application AF de ladite architecture de type FBC.
6. Serveur d'application dans un réseau (2) à architecture de type IMS, caractérisé en ce que ledit serveur (20) d'application est apte à décider d'un déclenchement, à travers ledit réseau à architecture de type IMS, d'un comptage, dans un réseau (1 ) de transport contrôlé par ledit réseau à architecture de type IMS pour un service associé audit serveur (20) d'application, sur des flux associés audit service.
7. Serveur d'application selon la revendication 6, caractérisé en ce que ledit serveur (20) d'application décide du déclenchement du comptage en fonction d'un profil de comptage établi pour un utilisateur et d'informations concernant ledit service.
8. Serveur d'application selon l'une quelconque des revendications 6 à 7, caractérisé en ce que, ledit comptage étant effectué conformément à une architecture de type FBC, ledit serveur (20) d'application décide d'une valeur d'un paramètre de comptage en fonction du profil de comptage établi pour un utilisateur et d'informations concernant ledit service et déclenche le comptage par émission d'un paramètre de comptage vers un serveur (23) réalisant une fonction d'application AF de ladite architecture de type FBC.
9. Serveur de routage dans un réseau (2) à architecture de type IMS, caractérisé en ce que ledit serveur (22) de routage est apte, lors d'une demande d'accès à un service à travers le réseau à architecture de type IMS, à transmettre à un serveur (20) d'application associé audit service un profil de comptage, dans un réseau (1 ) de transport contrôlé pour ledit service par le réseau (2) à architecture de type IMS, sur des flux associés audit service.
10. Serveur CRF destiné à réaliser une fonction CRF dans une architecture de comptage de type FBC dans un réseau (1 ) de transport, caractérisé en ce que ledit serveur CRF (24) est apte à transmettre des informations d'adresses à un serveur (20) d'application dans un réseau (2) à architecture de type IMS contrôlant le réseau (1 ) de transport, ledit serveur d'application (20) étant apte à décider à travers ledit réseau (2) à architecture de type IMS du déclenchement dudit comptage dans le réseau (1 ) de transport et réalisant une fonction d'application AF de ladite architecture de type FBC.
11. Procédé de déclenchement, dans un réseau (1 ) de transport, d'un comptage sur des flux associés à un service, caractérisé en ce que, ledit réseau de transport étant contrôlé pour ledit service par un réseau (2) à architecture de type IMS comprenant un serveur (20) d'application associé audit service, ledit procédé comprend une étape consistant, pour ledit serveur (20) d'application, à décider, à travers ledit réseau (2) à architecture de type IMS, du déclenchement dudit comptage dans le réseau (1 ) de transport.
12. Procédé selon la revendication 11 , caractérisé en ce que, ledit comptage étant effectué conformément à une architecture de type FBC, ledit procédé comprend les étapes consistant à :
- stocker dans une base (21) de données un profil de comptage établi pour un utilisateur,
- transmettre ledit profil de comptage audit serveur (20) d'application,
- décider par le serveur (20) d'application d'une valeur d'un paramètre de comptage en fonction dudit profil de comptage et d'informations concernant ledit service,
- transmettre par le serveur (20) d'application ledit paramètre de comptage à une fonction d'application AF de l'architecture de type FBC.
13. Procédé selon la revendication 12, caractérisé en ce que, ledit comptage étant effectué conformément à une architecture de type FBC, ledit procédé comprend les étapes consistant à :
- transmettre au serveur (20) d'application des informations d'adresses d'un serveur (24) hébergeant une fonction CRF de l'architecture de comptage de type FBC, - transmettre par le serveur (20) d'application ledit paramètre de comptage audit serveur CRF (24).
PCT/FR2007/051471 2006-06-20 2007-06-19 Systeme de declenchement d'un comptage dans un reseau de transport a travers un reseau a architecture de type ims WO2007148015A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0652561 2006-06-20
FR0652561 2006-06-20

Publications (2)

Publication Number Publication Date
WO2007148015A2 true WO2007148015A2 (fr) 2007-12-27
WO2007148015A3 WO2007148015A3 (fr) 2008-03-06

Family

ID=37460129

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2007/051471 WO2007148015A2 (fr) 2006-06-20 2007-06-19 Systeme de declenchement d'un comptage dans un reseau de transport a travers un reseau a architecture de type ims

Country Status (1)

Country Link
WO (1) WO2007148015A2 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1662702A1 (fr) * 2004-11-30 2006-05-31 Lucent Technologies Inc. Commande d'appel avec logique de serveur d'application et logique de passerelle convergente dans des réseaux IMS

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1662702A1 (fr) * 2004-11-30 2006-05-31 Lucent Technologies Inc. Commande d'appel avec logique de serveur d'application et logique de passerelle convergente dans des réseaux IMS

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project;Technical Specification Group Services and System Aspects;Telecommunication management; Charging architecture and principles (Release 6)" ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. 3-SA, no. V600, septembre 2004 (2004-09), XP014022018 ISSN: 0000-0001 *

Also Published As

Publication number Publication date
WO2007148015A3 (fr) 2008-03-06

Similar Documents

Publication Publication Date Title
EP2504982B1 (fr) Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP2926524B1 (fr) Routage d'une requête de service visant un abonné ims
WO2020128258A1 (fr) Procédé de basculement d'une communication de tcp sur udp
WO2011001061A1 (fr) Procede de selection d'une ressource reseau
WO2019102117A1 (fr) Procédé de propagation d'informations concernant la bande passante allouée à un usager d'un réseau ip
WO2015197937A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
EP2030382A1 (fr) Unite et procede de definition d'une regle de session dans un reseau
WO2015181505A1 (fr) Procédé pour informer une entité d'un réseau ip du type de réseau d'accès utilisé par un terminal
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
WO2017168084A1 (fr) Procédé de transfert de réseau d'accès pour un terminal mobile en itinérance
WO2007148015A2 (fr) Systeme de declenchement d'un comptage dans un reseau de transport a travers un reseau a architecture de type ims
EP3472993B1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
EP3646578B1 (fr) Procédé de synchronisation d'état média
WO2012085429A2 (fr) Procédé de localisation et d'identification d'un abonné connecté à un réseau émulant le rtc/rnis
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
WO2018215719A1 (fr) Procédé de contrôle d'une communication comprenant des transactions multiples
WO2012072942A2 (fr) Procede contre la formation de boucles dans les renvois d'appel
WO2012072920A1 (fr) Procédé et dispositif de gestion d'une souscription a un service dans un réseau ims
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
EP2238727A1 (fr) Procede de communication pour gerer des sessions de communication au niveau d'une passerelle domestique

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07803896

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07803896

Country of ref document: EP

Kind code of ref document: A2