WO2006045497A1 - Procede de controle de communications et equipements pour la mise en oeuvre du procede - Google Patents

Procede de controle de communications et equipements pour la mise en oeuvre du procede Download PDF

Info

Publication number
WO2006045497A1
WO2006045497A1 PCT/EP2005/011205 EP2005011205W WO2006045497A1 WO 2006045497 A1 WO2006045497 A1 WO 2006045497A1 EP 2005011205 W EP2005011205 W EP 2005011205W WO 2006045497 A1 WO2006045497 A1 WO 2006045497A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
communication
gateway
application server
parameters
Prior art date
Application number
PCT/EP2005/011205
Other languages
English (en)
Inventor
Claire Mousset
Mark Watson
Original Assignee
Alcatel Lucent
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 Alcatel Lucent filed Critical Alcatel Lucent
Priority to US11/577,991 priority Critical patent/US20080298300A1/en
Publication of WO2006045497A1 publication Critical patent/WO2006045497A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • 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/1063—Application servers providing network services
    • 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/1066—Session management
    • H04L65/1101—Session protocols
    • 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/80—Responding to QoS

Definitions

  • the present invention relates to communication control.
  • the communications implemented correspond to various communication services, such as voice communications, data transmissions, multimedia applications or any other application.
  • Such systems allow a certain level of control over communications.
  • Such systems typically comprise means of communication with terminals, one or more servers offering predefined communication services, as well as a gateway between the communication means and the servers providing both a management of the communications implemented by the servers.
  • means of communication and analysis and / or processing of the service elements carried by said communications are typically comprised.
  • the General Packet Radio Service (GPRS) radio system enables the implementation of data services involving mobile radio terminals via a gateway called GGSN ("Gateway GPRS Support Node").
  • the GGSN is thus both the last node of the radiocommunication system in which it manages the communications with the terminals and the first Internet Protocol (IP) router to external data networks such as the Internet or networks. Intranet type.
  • IP Internet Protocol
  • other systems may also be envisaged, such as the UMTS (Universal Mobile Telecommunications System), wireless local area networks (WLANs), wired communication systems, and so on.
  • the gateway is then a CEO ("Packet Data Gateway").
  • control In some cases, it may be interesting to have a control of differentiated communications for the same terminal. This is particularly true in a multimedia context where the terminal is able to implement various services.
  • An example of control concerns the billing of communications. Indeed, different strategies can be adopted to bill the traffic according to the service implemented. For example, voice traffic can be advantageously charged to the elapsed time, while data transmissions can be billed preferably based on the volume of data exchanged.
  • voice traffic can be advantageously charged to the elapsed time, while data transmissions can be billed preferably based on the volume of data exchanged.
  • Many other examples of control of communications can be envisaged, for example a statistical analysis of the flows exchanged according to different services.
  • a bearer service is previously established in relation to the gateway mentioned above.
  • the communication then takes place within the framework of this support service.
  • the latter comprises in particular certain characteristics relating to the communication media capable of carrying the communication within the system, such as a traffic class for example, or more generally a quality of service information.
  • a GGSN establishes at least one "Packet Data Protocol context" (PDP context), as a bearer service, for each terminal capable of communicating with the GPRS system.
  • PDP context Packet Data Protocol context
  • the GGSN can perform the control of communications from predefined control rules at the level of the GGSN itself. It is also possible to define control rules at an entity external to the GGSN.
  • the aforementioned technical specification TS 23.125 thus provides for a filtering unit called CRF ("Charging Rules Function"). This unit has predefined filtering rules that it can pass to the GGSN. Filtering rules are used to identify communications based on the service they are implementing. Upon receipt of these filtering rules from the CRF, the GGSN can then filter the various communication flows for their selective treatment, that is to say individualized.
  • the filtering rules may include billing information, such as a billing key or a billing mode, for example. These billing rules can then be taken into account by the GGSN to bill the various communications.
  • billing information such as a billing key or a billing mode, for example.
  • These billing rules can then be taken into account by the GGSN to bill the various communications.
  • the control of the communications provided for by the aforementioned technical specification TS 23.125 is relatively fine, it does not make it possible to achieve differentiated control in certain cases.
  • the GGSN will then receive from the CRF filtering rules to be applied indifferently for the two communications in accordance with what has been indicated above. This operation is not flexible because it encourages the dedication of each
  • PDP context to a given service. It can even be conducive to fraud, for example in the case where a user of a terminal opens several PDPs context to implement communication services normally having different billing rules to the CRF, so as to benefit from the most favorable billing on all its context PDPs.
  • An object of the present invention is to limit the aforementioned disadvantages by providing flexible and effective control of communications.
  • Another object of the invention is to control communications implementing services, in a timely manner vis-à-vis the characteristics of the bearer services used in the system.
  • Another object of the invention is to condition the opening of a support service to the application envisaged on this support service.
  • the invention thus proposes a method of controlling communications in a system comprising communication means, at least one application server and at least one gateway between the communication means and the application server, the system being arranged to implement communications with terminals according to services offered by said application server, each communication being implemented via said communication means in the context of a bearer service between a terminal and said gateway.
  • the method comprises the following steps relating to at least one terminal having or requesting at least one communication according to a service offered by said application server:
  • the treatment in question can be of any type.
  • it comprises a filtering of the communication flows according to the bearer service in which these flows are exchanged.
  • a filtering unit advantageously provides filtering rules to the gateway to allow such filtering. Additional processing may also be performed, such as specific billing, based on billing rules.
  • the selective processing of the communications may comprise an acceptance or a rejection of the establishment of a bearer service for which an establishment request has been transmitted by the terminal.
  • the bearer service is advantageously established only if said determined parameters correspond to characteristics of the bearer service to be established.
  • the parameters considered are, for example, quality of service information, a class of service, a bandwidth occupied by the service, a coding / decoding mode or a transmission delay constraint.
  • the bearer service characteristics to which said determined parameters substantially correspond are, for example, quality of service information or a class of traffic.
  • the indications identifying the service of said communication in progress or required it may advantageously be some of the following information: a source IP address, a destination IP address, a source port number, a destination port number and an identifier of a communication protocol.
  • the invention also proposes an application server in a system further comprising communication means and at least one gateway between the communication means and the application server, the system being arranged to implement communications with terminals according to services offered. by said application server, each communication being implemented via said communication means in the context of a bearer service between a terminal and said gateway, the gateway being further arranged to selectively process communications as a function of service parameters received.
  • the application server comprises, relative to at least one terminal having or requesting at least one communication according to a service offered by said application server:
  • the invention also proposes a gateway between communication means and at least one application server of a system arranged to implement communications with terminals according to services offered by said application server, each communication being implemented by the user.
  • the application server being arranged to determine, for each service offered, parameters corresponding substantially to respective characteristics of bearer service.
  • the gateway comprises the following steps with respect to at least one terminal having or requesting at least one call according to a service offered by said application server: means for receiving the parameters of said service corresponding substantially to respective characteristics of the bearer service determined by the server application; and means for selectively processing said communication as a function of said received parameters.
  • the invention also proposes a filtering unit in a system further comprising communication means, at least one application server and at least one gateway between the communication means and the application server, the system being arranged to implement communications with terminals according to services offered by said application server, each communication being implemented via said communication means in the context of a bearer service between a terminal and said gateway, the application server being arranged to determine, for each service offered, parameters corresponding substantially to respective characteristics of service support.
  • the filtering unit is connected to the gateway and to the application server and comprises, with respect to at least one terminal having or requesting at least one communication according to a service offered by said application server:
  • FIG. 1 is a simplified diagram of the architecture of a system in which the invention can be implemented
  • FIG. 2 is a representation of protocol exchanges according to a first embodiment of the invention
  • FIG. 3 is a representation of protocol exchanges according to a second embodiment of the invention
  • Figure 1 shows the simplified architecture of a system in which the invention can be implemented.
  • a terminal 1 is arranged to communicate with the system shown. Communications involving the terminal 1 are carried by communication means 3 of the system shown. These means of communication differ according to the system used. For example, if the system uses a radio communication technology such as GPRS or UMTS, these communication means comprise a radio access subsystem connected to a core network consisting of switches meshed with each other. Similarly, if the system uses wireline communication technology, the means of communication will be chosen to be compatible with this technology.
  • the communication means use communications media to carry communications, such as communication radio resources in a GPRS or UMTS radio access subsystem and core network resources.
  • the system also comprises a gateway 2 as defined above. It provides communication management with terminals such as the terminal 1 represented.
  • the communications carried by the communication means 3 are carried out within the framework of a bearer service established between the terminal concerned and the gateway 2.
  • this support service is called PDP context, as mentioned above.
  • the context PDP has characteristics relating in particular to the communication media used to implement the communications.
  • the gateway 2 is also connected to at least one external network 4 and it ensures the dialogue and formatting of the information exchanged between the communication means 3 and the network 4.
  • the network 4 may for example be a data network such as the Internet.
  • the gateway 2 (which is then a GGSN) also has an IP router function.
  • the system shown in FIG. 1 further comprises a server application 7 which offers one or more application services to terminals.
  • the services in question can be of any type, such as a voice service, a data transmission service, a web-like service, a data download service, a game service, a voice transmission service. over IP, etc.
  • TPF Traffic Plane Function
  • the selective processing function consists of analyzing the communication flows at the TPF 2, with a view to applying them an appropriate treatment, possibly different depending on the characteristics of the flows.
  • communication filtering rules can be predefined in the TPF 2.
  • a filtering unit 5, called CRF can itself contain predefined filtering rules, which it can send to TPF 2.
  • the filtering rules may include indications identifying a particular communication stream, such as an IP 5 tuple (or IP tuple) including at least some source IP address information, such as destination IP address, source port number, destination port number, and protocol identifier. They may also include other information such as billing rules, such as a billing key, a billing method such as billing by volume or elapsed time, and so on.
  • IP 5 tuple or IP tuple
  • source IP address information such as destination IP address, source port number, destination port number, and protocol identifier.
  • billing rules such as a billing key, a billing method such as billing by volume or elapsed time, and so on.
  • TPF 2 When TPF 2 has these filtering rules, which are example provided by the CRF 5, it is then able to apply differential treatment on certain communication flows corresponding to the specified rules. For example, upon receipt of such a rule from the CRF 5, the TPF 2 may apply a volume billing for a communication stream according to a voice over IP service offered by the server 7 between the terminal 1 and a remote terminal identified.
  • a volume billing for a communication stream according to a voice over IP service offered by the server 7 between the terminal 1 and a remote terminal identified.
  • OCS 6 Online Charging
  • a selective processing can be applied to the various communication flows taking into account the bearer services in which these communications occur. It is thus desired to be able to use different filtering rules for communication flows relating to identical services or of the same characteristics, and involving the same terminal on separate bearer services.
  • FIG. 2 A first embodiment of the invention is described below with reference to FIG. 2. This embodiment is advantageously implemented in a system of the type illustrated in FIG. 1.
  • the terminal 1 has two open bearer services in relation to the TPF 2
  • context PDPs are established between the terminal 1 and a GGSN of the system.
  • These context PDPs may have common characteristics and distinct ones. In particular, they can be provided, each, to frame communications according to a quality of determined service. Communication media for communications under a given context PDP are then selected to achieve the specified quality of service.
  • Other features may also be considered. For example, four classes of traffic are generally defined in a context PDP to characterize the quality of service, each of these classes reflecting a particular behavior of the traffic, particularly in terms of sensitivity to transmission delays.
  • an application session is first established between the terminal 1 and the application server 7 which offers the required service.
  • the terminal 1 requires a service to the server 7 by specifying certain information. For example, if the service concerned is a voice over IP service, the terminal 1 then specifies, in addition to its own IP address, the IP address of the remote terminal with which the terminal 1 wishes to communicate.
  • the establishment message of the application session is transmitted via the communication means 3 and the TPF 2.
  • the application server 7 Upon receipt of the establishment message of the application session, the application server 7 retransmits to the CRF 5 information identifying the service, such as the IP address of the terminal 1 and the IP address of the called remote terminal. In addition, the server 7 transmits to the CRF 5 additional parameters relating to the service required, which substantially correspond to the service support characteristics as defined above. For simplicity, these parameters are designated by the term "bearer service parameters" in Figure 2. The parameters in question are for example related to a quality of service desirable to implement the required service. Advantageously, these parameters may have an identical definition, or at least a similar one, traffic classes used for context PDPs.
  • the application server 7 can indicate to the CRF 5 that the resulting traffic will be of "conversational” type, that is to say a very sensitive traffic delays transmission .
  • the parameters used can take up the four classes of traffic mentioned above, namely “conversational”, “streaming”, “interactive” and “background”. This ensures an easy correspondence between the quality of service provided by the server 7 and the quality of service applied at the support service level.
  • ⁇ parameters may also be considered. Examples that may be mentioned include a transmission rate, a bandwidth, a mode of coding / decoding of communications, a constraint on the transmission delay, or any other parameter making it possible to retrieve a corresponding service bearer attribute without ambiguity. For example, if the considered parameter specifies a transmission delay below a given threshold, a corresponding traffic class can then be found at the PDP context level.
  • the CRF 5 which has the filtering rules as indicated above, informs the TPF 2 of the rules to be applied for the service required by the terminal 1, on the basis of the service identifiers received.
  • a particular billing mode may be specified for the service characterized by the IP addresses of the terminal 1 and the called remote terminal.
  • the CRF 5 retransmits to the TPF 2, in correspondence with the filtering rules, the bearer service parameters received from the application server 7. Due to the nature of the bearer service parameters, the TPF 2 is then capable on reception of these parameters, to deduce corresponding service support characteristics. The TPF 2 then applies the filtering rules received from the CRF 5 on the bearer services according to a correspondence between the characteristics of these bearer services and the parameters received.
  • the communication flows transmitted to implement the required service and involving the terminal 1 will then be filtered and possibly processed by the TPF 2 according to the filtering rules received possibly way differentiated according to the two open support services. This means that a first processing can be applied to the flows coming from the terminal 1 and carried out as part of the bearer service 1 (SS 1 in FIG. 2) and that a second processing can be applied to the flows coming from the terminal 1 and carried out in the context of bearer service 2 (SS2 in Figure 2).
  • FIG. 2 An example of an application is hereinafter described with reference to FIG. 2.
  • the support service 1 (or PDP context 1) supports the "conversational" traffic class and the support service 2 (or PDP context 2) supports the "streaming" traffic class.
  • the service required by the terminal 1 at the server 7 is a voice over IP service to a remote terminal and it must be implemented in the context of the PDP context 1.
  • the required service is defined as to be billed at elapsed time at CRF 5.
  • the server 7 indicates to the CRF 5 that a voice over IP service is required from the terminal 1 to a remote terminal, specifying the IP addresses of these two terminals.
  • the server 7 also informs the CRF 5 that the voice over IP service requires transmission with a minimum transmission delay, for example by transmitting a parameter whose value corresponds substantially to the "conversational" mode.
  • CRF 5 returns this parameter to TPF 2, further clarifying that the service required by terminal 1 must be billed at the elapsed time.
  • the TPF 2 can then apply the rule received from the CRF 5 selectively, after comparing the characteristics of the open context PDPs for the terminal 1 and the parameters received from the CRF 5. In this case, the TPF 2 therefore bill the elapsed time the communication flows exchanged with the terminal 1 in the context of PDP context 1 which is of the "conversational" type corresponding to the support service parameter transmitted by the CRF 5.
  • the selective processing thus obtained may be of different natures according to the filtering rules defined in CRF 5.
  • these rules may contain information on the billing to be applied to the flows of communications, they can also serve as a basis for example a statistical analysis of flows based on the information transmitted.
  • the TPF 2 can count on the flows it receives from the terminal according to the PDP context in which they are exchanged.
  • FIG. 3 A second embodiment of the invention will now be described with reference to FIG. 3, in which the selective treatment performed by the TPF 2 is different from the case previously described.
  • the opening of a bearer service is conditioned on the type of service envisaged.
  • the terminal 1 sends a request for establishment of a bearer service to TPF 2. Then, the terminal 1 transmits to the application server 7 an application session establishment message, as in the previous case , to implement a service offered by the server 7.
  • the application server 7 then transmits to the CRF 5 parameters identifying the required service, such as an IP address of the terminal 1.
  • the CRF 5 parameters identifying the required service such as an IP address of the terminal 1.
  • support service parameters as described above are transmitted from the server 7 to the CRF 5 according to the service required by the terminal 1.
  • TPF 2 derives the characteristics of support service to which these support service settings correspond. If the bearer service initially required by the terminal 1 has bearer service characteristics corresponding to the bearer service parameters received from the CRF 5, this means that the required bearer service will be able to frame communications according to the service required by the terminal 1. In this case, the TPF 2 therefore authorizes the establishment of the required bearer service and notifies it to the terminal 1. Otherwise, that is, if the bearer service initially required by the terminal 1 has service characteristics. Since support does not match the support service parameters received from CRF 5, TPF 2 rejects the establishment of the required bearer service and notifies it to Terminal 1.
  • the support service required by the terminal 1 is a context PDP with a traffic class of "streaming" type
  • a voice over IP service which is a service requiring a quality of service with very low transmission delays, ie a "conversational" quality of service according to the terminology used in the context of the PDP context
  • the establishment of the required context PDP will be rejected by the TPF 2.
  • the service required by the terminal 1 requires a quality of service of "streaming" type, for example a transmission of video in transit
  • the establishment of the PDP context required by the terminal 1 may be accepted by TPF 2.
  • the selective processing carried out by the TPF 2 consists of authorizing or, on the contrary, rejecting the establishment of a bearer service according to the service required within the framework of this support service.

Abstract

Un système comprenant des moyens de communication (3), au moins un serveur applicatif (7) et au moins une passerelle (2) entre les moyens de communication et le serveur applicatif, est agencé pour mettre en œuvre des communications avec des terminaux selon des services offerts par ledit serveur applicatif, chaque communication étant mise en œuvre par l’intermédiaire desdits moyens des communication dans le cadre d’un service support entre un terminal et ladite passerelle. Relativement à au moins un terminal (1) ayant ou requérant au moins une communication selon un service offert par ledit serveur applicatif: on détermine, au serveur applicatif, des paramètres dudit service correspondant sensiblement à des caractéristiques respectives de service support; on transmet, à la passerelle, lesdits paramètres déterminés ; et on effectue, à la passerelle, un traitement sélectif de ladite communication en fonction desdits paramètres reçus.

Description

PROCEDE DECONTROLEDECOMMUNICATIONSETEQUIPEMENTS POURLAMISE EN OEUVRE DU PROCEDE
La présente invention concerne le contrôle de communications.
Elle trouve une application particulièrement intéressante dans le cas où les communications mises en œuvre correspondent à des services de communication variés, tels que des communications vocales, des transmissions de données, des applications multimédia ou toute autre application.
Des systèmes de communication connus permettent un certain niveau de contrôle des communications. De tels systèmes comprennent typiquement des moyens de communication avec des terminaux, un ou plusieurs serveurs offrant des services de communication prédéfinis, ainsi qu'une passerelle entre les moyens de communication et les serveurs assurant à la fois une gestion des communications mises en œuvre par les moyens de communication et une analyse et/ou un traitement des éléments de service portés par lesdites communications.
A titre d'exemple, le système de radiocommunication GPRS ("General Packet Radio Service") permet la mise en œuvre de services de données impliquant des terminaux radio mobiles par l'intermédiaire d'une passerelle appelée GGSN ("Gateway GPRS Support Node"). Le GGSN constitue ainsi à la fois le dernier nœud du système de radiocommunication dans lequel il assure la gestion des communications avec les terminaux et le premier routeur IP ("Internet Protocol") vers des réseaux de données externes tels que le réseau Internet ou des réseaux de type Intranet. On notera que d'autres systèmes peuvent également être envisagés, comme le système UMTS ("Universal Mobile Télécommunications System"), des réseaux locaux sans fil (WLAN, pour " Wireless Local Area Network"), des systèmes de communication filaires, etc. A titre d'exemple complémentaire, lorsque le système de communication est un WLAN, la passerelle est alors un PDG ("Packet Data Gateway").
Dans certains cas, il peut être intéressant d'avoir un contrôle des communications différencié pour un même terminal. Cela est particulièrement vrai dans un contexte multimédia où le terminal est capable de mettre en œuvre des services variés. Un exemple de contrôle concerne la facturation des communications. En effet, des stratégies différentes peuvent être adoptées pour facturer le trafic selon le service mis en œuvre. Par exemple, le trafic voix peut être avantageusement facturé au temps écoulé, tandis que les transmissions de données peuvent être facturées de préférence en fonction du volume de données échangées. Bien d'autres exemples de contrôle des communications peuvent être envisagés, comme par exemple une analyse statistique des flux échangés selon différents services.
Lorsqu'une communication doit être établie entre un terminal et le système considéré, un service support ("bearer service") est préalablement établi en relation avec la passerelle évoquée plus haut. La communication se déroule ensuite dans le cadre de ce service support. Ce dernier comporte en particulier certaines caractéristiques relatives aux supports de communication susceptibles de porter la communication au sein du système, comme une classe de trafic par exemple, ou plus généralement une information de qualité de service. A titre d'exemple, un GGSN établit au moins un "PDP context" ("Packet Data Protocol context"), en tant que service support, pour chaque terminal susceptible de communiquer avec le système GPRS.
Il est ainsi connu d'effectuer un contrôle des communications au niveau de la passerelle, de façon différenciée selon les services supports établis. Par exemple, lorsque deux PDP context ont été établis pour un terminal GPRS, les communications effectuées dans le cadre de chacun de ces deux PDP context peuvent être contrôlées de façon différente entre elles par le GGSN. En revanche, si deux services distincts sont mis en oeuvre par le terminal dans le cadre d'un même PDP context, les deux communications correspondantes seront alors contrôlées de la même façon par le GGSN. Cela oblige par exemple à avoir un mode de facturation identique pour deux services potentiellement de nature très différente. Or, dans la plupart des cas, le choix de mettre en oeuvre un service donné dans le cadre d'un PDP context plutôt qu'un autre est laissé au terminal, si bien que le comportement des terminaux est très disparate sur ce point. Un autre niveau de contrôle a été introduit dans la spécification technique TS 23.125, V6.1.0, "Technical Spécification Group Services and System Aspects ; Overall High Level Functionality and Architecture Impacts of Flow Based Charging ; Stage 2 (Release 6)", publiée par le 3GPP ("3rd Génération Partnership Project") en juin 2004. Le contrôle y est en effet effectué en fonction des flux transmis vers ou depuis un réseau externe. Si l'on reprend l'exemple du GPRS, cela se traduit par le fait que le GGSN évoqué plus haut analyse les flux IP qu'il reçoit et effectue un contrôle de ces flux en fonction des résultats de son analyse. A titre illustratif, si un terminal GPRS effectue deux communications selon deux services distincts, le GGSN est informé des caractéristiques des services mis en œuvre pour chacune des communications et il contrôle les deux communications de façon différenciée. A titre d'exemple, une facturation différente peut être effectuée pour chacune des communications si les services mis en oeuvre le justifient. Dans l'exemple exposé ci-dessus, le GGSN peut effectuer le contrôle des communications à partir de règles de contrôle prédéfinies au niveau du GGSN lui-même. Il est également possible de définir des règles de contrôle au niveau d'une entité externe au GGSN. La spécification technique TS 23.125 précitée prévoit ainsi une unité de filtrage dite CRF ("Charging Rules Function"). Cette unité dispose de règles de filtrage prédéfinies qu'elle peut transmettre au GGSN. Les règles de filtrage permettent d'identifier les communications selon le service qu'elles mettent en œuvre. Sur réception de ces règles de filtrage de la part du CRF, le GGSN peut alors filtrer les différents flux de communication pour leur appliquer un traitement sélectif, c'est-à-dire individualisé. A titre d'exemple, les règles de filtrage peuvent comporter des informations de facturation, comme une clé de facturation ou un mode de facturation par exemple. Ces règles de facturation peuvent alors être prises en compte par le GGSN pour effectuer la facturation des différentes communications. Bien que le contrôle des communications prévu par la spécification technique TS 23.125 précitée soit relativement fin, il ne permet pas d'atteindre un contrôle différencié dans certains cas. Par exemple, lorsqu'un terminal GPRS a deux PDP context ouverts et communique selon un même service (ou bien selon deux services ayant des caractéristiques communes) sur chacun de ces PDP context, le GGSN recevra alors du CRF des règles de filtrage à appliquer indifféremment pour les deux communications conformément à ce qui a été indiqué plus haut. Ce fonctionnement manque de souplesse car il incite à dédier chaque
PDP context à un service donné. Il peut même être propice à des fraudes, par exemple dans le cas où un utilisateur d'un terminal ouvre plusieurs PDP context pour y mettre en œuvre des services de communication ayant normalement des règles de facturation différentes au CRF, de manière à bénéficier de la facturation la plus favorable sur tous ses PDP context.
Un but de la présente invention est de limiter les inconvénients susmentionnés en proposant un contrôle souple et efficace des communications.
Un autre but de l'invention est de contrôler des communications mettant en œuvre des services, de façon opportune vis-à-vis des caractéristiques des services supports utilisés dans le système.
Un autre but de l'invention est de conditionner l'ouverture d'un service support à l'application envisagée sur ce service support.
L'invention propose ainsi un procédé de contrôle de communications dans un système comprenant des moyens de communication, au moins un serveur applicatif et au moins une passerelle entre les moyens de communication et le serveur applicatif, le système étant agencé pour mettre en œuvre des communications avec des terminaux selon des services offerts par ledit serveur applicatif, chaque communication étant mise en œuvre par l'intermédiaire desdits moyens de communication dans le cadre d'un service support entre un terminal et ladite passerelle. Le procédé comprend les étapes suivantes relativement à au moins un terminal ayant ou requérant au moins une communication selon un service offert par ledit serveur applicatif :
- déterminer, au serveur applicatif, des paramètres dudit service correspondant sensiblement à des caractéristiques respectives de service support ; - transmettre, à la passerelle, lesdits paramètres déterminés ; et
- effectuer, à la passerelle, un traitement sélectif de ladite communication en fonction desdits paramètres reçus.
De cette manière, on peut effectuer un traitement séparé, éventuellement différent, pour des flux de communications utilisant des services ayant des caractéristiques communes, mais relevant de services supports différents entre le terminal et la passerelle.
Le traitement en question peut être de tout type. Par exemple, selon un mode de réalisation de l'invention, il comprend un filtrage des flux de communications en fonction du service support dans le cadre duquel ces flux sont échangés. Dans ce cas, une unité de filtrage délivre avantageusement des règles de filtrage à la passerelle pour permettre un tel filtrage. Un traitement supplémentaire peut en outre être réalisé, comme par exemple une facturation spécifique, sur la base de règles de facturation. En variante, le traitement sélectif des communications peut comprendre une acceptation ou un rejet d'établissement d'un service support pour lequel une requête d'établissement a été transmise par le terminal. Ainsi, le service support est avantageusement établi uniquement si lesdits paramètres déterminés correspondent à des caractéristiques du service support à établir.
Les paramètres considérés sont par exemple une information de qualité de service, une classe de service, une bande passante occupée par le service, un mode de codage/décodage ou une contrainte de délai de transmission. Les caractéristiques de service support auxquelles lesdits paramètres déterminés correspondent sensiblement sont par exemple une information de qualité de service ou une classe de trafic.
Quant aux indications identifiant le service de ladite communication en cours ou requise, il peut s'agir avantageusement de certaines des informations suivantes : une adresse IP source, une adresse IP de destination, un numéro de port source, un numéro de port de destination et un identifiant d'un protocole de communication.
L'invention propose aussi un serveur applicatif dans un système comprenant en outre des moyens de communication et au moins une passerelle entre les moyens de communication et le serveur applicatif, le système étant agencé pour mettre en œuvre des communications avec des terminaux selon des services offerts par ledit serveur applicatif, chaque communication étant mise en œuvre par l'intermédiaire desdits moyens de communication dans le cadre d'un service support entre un terminal et ladite passerelle, la passerelle étant en outre agencée pour effectuer un traitement sélectif des communications en fonction de paramètres de service reçus. Le serveur applicatif comprend, relativement à au moins un terminal ayant ou requérant au moins une communication selon un service offert par ledit serveur applicatif :
- des moyens pour déterminer des paramètres dudit service correspondant sensiblement à des caractéristiques respectives de service support ; et
- des moyens pour transmettre lesdits paramètres déterminés à la passerelle.
L'invention propose en outre une passerelle entre des moyens de communication et au moins un serveur applicatif d'un système agencé pour mettre en œuvre des communications avec des terminaux selon des services offerts par ledit serveur applicatif, chaque communication étant mise en œuvre par l'intermédiaire desdits moyens de communication dans le cadre d'un service support entre un terminal et ladite passerelle, le serveur applicatif étant agencé pour déterminer, pour chaque service offert, des paramètres correspondant sensiblement à des caractéristiques respectives de service support. La passerelle comprend les étapes suivantes relativement à au moins un terminal ayant ou requérant au moins une communication selon un service offert par ledit serveur applicatif : - des moyens pour recevoir les paramètres dudit service correspondant sensiblement à des caractéristiques respectives de service support déterminés par le serveur applicatif ; et - des moyens pour effectuer un traitement sélectif de ladite communication en fonction desdits paramètres reçus.
L'invention propose également une unité de filtrage dans un système comprenant en outre des moyens de communication, au moins un serveur applicatif et au moins une passerelle entre les moyens de communication et le serveur applicatif, le système étant agencé pour mettre en œuvre des communications avec des terminaux selon des services offerts par ledit serveur applicatif, chaque communication étant mise en œuvre par l'intermédiaire desdits moyens de communication dans le cadre d'un service support entre un terminal et ladite passerelle, le serveur applicatif étant agencé pour déterminer, pour chaque service offert, des paramètres correspondant sensiblement à des caractéristiques respectives de service support. L'unité de filtrage est reliée à la passerelle et au serveur applicatif et comprend, relativement à au moins un terminal ayant ou requérant au moins une communication selon un service offert par ledit serveur applicatif :
- des moyens pour obtenir du serveur applicatif des indications identifiant le service de ladite communication en cours ou requise ;
- des moyens pour obtenir des paramètres dudit service correspondant sensiblement à des caractéristiques respectives de service support ; et - des moyens pour délivrer à la passerelle des règles de filtrage des communications en fonction desdites indications obtenues, en correspondance avec lesdits paramètres obtenus.
D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :
- la figure 1 est un schéma simplifié de l'architecture d'un système dans lequel l'invention peut être mise en œuvre ;
- la figure 2 est une représentation d'échanges protocolaires selon un premier mode de réalisation de l'invention ; - la figure 3 est une représentation d'échanges protocolaires selon un second mode de réalisation de l'invention ; La figure 1 montre l'architecture simplifiée d'un système dans lequel l'invention peut être mise en œuvre. Un terminal 1 est agencé pour communiquer avec le système représenté. Les communications impliquant le terminal 1 sont portées par des moyens de communication 3 du système représenté. Ces moyens de communication diffèrent selon le système utilisé. Par exemple, si le système utilise une technologie de radiocommunication comme le GPRS ou l'UMTS, ces moyens de communication comprennent un sous-système d'accès radio relié à un réseau cœur constitué de commutateurs maillés entre eux. De même, si le système utilise une technologie de communication filaire, les moyens de communication seront choisis pour être compatibles avec cette technologie. Les moyens de communication utilisent des supports de communications pour porter les communications, comme par exemple des ressources radio de communication dans un sous-système d'accès radio de type GPRS ou UMTS et des ressources de réseau cœur. Le système comprend par ailleurs une passerelle 2 telle définie plus haut. Elle assure une gestion des communications avec des terminaux comme le terminal 1 représenté. En particulier, les communications portées par les moyens de communication 3 sont effectuées dans le cadre d'un service support ("bearer service") établi entre le terminal concerné et la passerelle 2. Dans le cas où le système utilise la technologie de communication GPRS ou UMTS par exemple, ce service support est appelé PDP context, comme indiqué plus haut. Le PDP context possède des caractéristiques relatives notamment aux supports de communication utilisés pour mettre en œuvre les communications. La passerelle 2 est par ailleurs connectée à au moins un réseau externe 4 et elle assure le dialogue et la mise au format adéquat des informations échangées entre les moyens de communication 3 et le réseau 4. Lorsque les moyens de communication 3 utilisent la technologie GPRS ou UMTS par exemple, le réseau 4 peut par exemple être un réseau de données comme le réseau Internet. Dans ce cas, la passerelle 2 (qui est alors un GGSN) possède en outre une fonction de routeur IP.
Le système représenté sur la figure 1 comprend en outre un serveur applicatif 7 qui offre un ou plusieurs services applicatifs à des terminaux. Les services en question peuvent être de tout type, comme par exemple un service de voix, un service de transmission de données, un service de type Web, un service de téléchargement de données, un service de jeux, un service de transmission de la voix sur IP, etc.
Lorsque le terminal 1 souhaite mettre en oeuvre un service offert par le serveur 7, il peut établir une communication portée par les moyens de communication 3 du système dans le cadre d'un service support avec la passerelle 2. Le système possède en outre une fonction de traitement sélectif des communications. Cette fonction, appelée TPF ("Traffic Plane Function"), est avantageusement assurée par la passerelle 2, bien qu'elle puisse également être mise en œuvre dans un équipement distinct de la passerelle. Dans la suite, pour simplifier l'exposé, on considère que cette fonction est assurée par la passerelle et on désigne par TPF cette passerelle dotée de la fonction de traitement sélectif.
La fonction de traitement sélectif consiste à analyser les flux de communications au TPF 2, en vue de leur appliquer un traitement approprié, éventuellement différent en fonction des caractéristiques des flux. A cet effet, des règles de filtrage des communications peuvent être prédéfinies dans le TPF 2. En variante, une unité de filtrage 5, appelée CRF, comme mentionnée en introduction, peut elle-même contenir des règles de filtrage prédéfinies, qu'elle peut transmettre au TPF 2.
Comme cela a été exposé en introduction, les règles de filtrage peuvent comprendre des indications identifiant un flux de communication particulier, comme un 5-uplet IP (ou "IP 5 tuple") comprenant certaines au moins des informations d'adresse IP source, d'adresse IP destination, de numéro de port source, de numéro de port de destination et d'identifiant de protocole. Elles peuvent également comprendre d'autres informations telles que des règles de facturation, comme un clé de facturation, un mode de facturation tel qu'une facturation au volume ou au temps écoulé, etc.
Lorsque le TPF 2 dispose de ces règles de filtrage, qui lui sont par exemple fournies par le CRF 5, il est alors capable d'appliquer un traitement différencié sur certains flux de communication correspondant aux règles spécifiées. A titre d'exemple, sur réception d'une telle règle depuis le CRF 5, le TPF 2 pourra appliquer une facturation au volume pour un flux de communication selon un service de voix sur IP offert par le serveur 7 entre le terminal 1 et un terminal distant identifié. Bien sûr, d'autres traitements sont également possibles grâce à l'architecture illustrée sur la figure 1 , comme par exemple une analyse statistique des flux échangés dans le système en fonction de leurs caractéristiques. Enfin, la figure 1 montre une entité dite OCS 6 (Online Charging
System") dont le rôle est également décrit en détail dans la spécification technique TS 23.125 précitée. Il s'agit d'une entité optionnelle qui coopère avec le CRF 5 et qui est utilisée dans le cas où les règles de filtrage susmentionnées comprennent des règles de facturation. Elle définit notamment une notion de crédit et fournit au TPF 2 des autorisations pour des communications impliquant un terminal donné en fonction d'un crédit restant.
Selon l'invention, un traitement sélectif peut être appliqué aux différents flux de communication en tenant compte des services supports dans le cadre desquels ces communications interviennent. On souhaite ainsi pouvoir utiliser des règles de filtrage différentes pour des flux de communication relatifs à des services identiques ou de mêmes caractéristiques, et impliquant un même terminal sur des services supports distincts.
Un premier mode de réalisation de l'invention est décrit ci-après en référence à la figure 2. Ce mode de réalisation est avantageusement mis en œuvre dans un système du type de celui illustré sur la figure 1. Dans l'exemple illustré, le terminal 1 a deux services supports ouverts en relation avec le TPF 2
("service support 1" et "service support 2" sur la figure 2).
Dans le cas où la technologie de communication utilisée est le GPRS ou l'UMTS, cela signifie donc que deux PDP context différents sont établis entre le terminal 1 et un GGSN du système. Ces PDP context peuvent avoir des caractéristiques communes et d'autres distinctes. En particulier, ils peuvent être prévus, chacun, pour encadrer des communications selon une qualité de service déterminée. Les supports de communication pour des communications effectuées dans le cadre d'un PDP context donné sont alors choisis pour atteindre la qualité de service spécifiée. D'autres caractéristiques peuvent également être envisagées. A titre d'exemple, quatre classes de trafic sont généralement définies dans un PDP context pour caractériser la qualité de service, chacune de ces classes traduisant un comportement particulier du trafic notamment en termes de sensibilité aux délais de transmission. Les quatre classes désignées respectivement par "conversational", "streaming", "interactive" et "background" sont détaillées, en ce qui concerne le système UMTS, à la section 6.3 de la spécification technique TS 23.107, V5.10.0, "Quality of Service (QoS) concept and architecture", Release 5, publiée en septembre 2003 par le 3GPP.
Lorsqu'un service doit être démarré pour le terminal 1 , par exemple à l'initiative du terminal, une session d'application est tout d'abord établie entre le terminal 1 et le serveur applicatif 7 qui offre le service requis. Dans le message d'établissement de la session d'application, le terminal 1 requiert un service au serveur 7 en lui précisant certaines informations. Par exemple, si le service visé est un service de voix sur IP, le terminal 1 précise alors, outre sa propre adresse IP, l'adresse IP du terminal distant avec lequel le terminal 1 souhaite communiquer. Le message d'établissement de la session d'application est transmis par l'intermédiaire des moyens de communication 3 et du TPF 2.
Sur réception du message d'établissement de la session d'application, le serveur applicatif 7 retransmet au CRF 5 les informations identifiant le service, comme par exemple l'adresse IP du terminal 1 et l'adresse IP du terminal distant appelé. En outre, le serveur 7 transmet au CRF 5 des paramètres complémentaires relatifs au service requis, qui correspondent sensiblement à des caractéristiques de service support telles que définies plus haut. Pour simplifier, ces paramètres sont désignés par l'expression "paramètres de service support" sur la figure 2. Les paramètres en question sont par exemple relatifs à une qualité de service souhaitable pour mettre en œuvre le service requis. Avantageusement, ces paramètres peuvent avoir une définition identique, ou du moins proche, des classes de trafic utilisées pour les PDP context. Ainsi, si le service requis par le terminal 1 est un service voix, le serveur applicatif 7 peut indiquer au CRF 5 que le trafic résultant sera de type "conversational", c'est-à-dire un trafic très sensible aux retards de transmission. Ainsi, les paramètres utilisés peuvent reprendre les quatre classes de trafic évoquées plus haut, à savoir "conversational", "streaming", "interactive" et "background". On assure ainsi une correspondance aisée entre la qualité de service prévue par le serveur 7 et la qualité de service appliquée au niveau service support.
D'autres paramètres peuvent également être envisagés. On peut citer à titre d'exemples un débit de transmission, une bande passante, un mode de codage/décodage des communications, une contrainte sur le délai de transmission, ou tout autre paramètre permettant de retrouver un attribut de service support correspondant sans ambiguïté. Par exemple, si le paramètre considéré spécifie un délai de transmission inférieur à un seuil donné, une classe de trafic correspondante peut alors être retrouvée au niveau PDP context.
Par la suite, le CRF 5 qui dispose des règles de filtrage comme indiqué plus haut, informe le TPF 2 des règles à appliquer pour le service requis par le terminal 1 , sur la base des identifiants du service reçus. Par exemple, un mode de facturation particulier peut être spécifié pour le service caractérisé par les adresses IP du terminal 1 et du terminal distant appelé.
Par ailleurs, le CRF 5 retransmet au TPF 2, en correspondance avec les règles de filtrage, les paramètres de service support reçus du serveur applicatif 7. De par la nature des paramètres de service support, le TPF 2 est alors capable sur réception de ces paramètres, d'en déduire des caractéristiques de service support correspondantes. Le TPF 2 applique alors les règles de filtrage reçues du CRF 5 sur les services supports en fonction d'une correspondance entre les caractéristiques de ces services supports et les paramètres reçus. Ainsi, les flux de communication transmis pour mettre en œuvre le service requis et impliquant le terminal 1 seront ensuite filtrés et éventuellement traités par le TPF 2 selon les règles de filtrage reçues de façon éventuellement différenciée selon les deux services supports ouverts. Cela signifie qu'un premier traitement peut être appliqué aux flux issus du terminal 1 et effectués dans le cadre du service support 1 (SS 1 sur la figure 2) et qu'un second traitement peut être appliqué aux flux issus du terminal 1 et effectués dans le cadre du service support 2 (SS2 sur la figure 2).
Un exemple d'application est ci-après décrit en référence à la figure 2. On se place dans l'exemple d'un système utilisant la technologie de communication GPRS ou UMTS. On prend par ailleurs l'hypothèse que le service support 1 (ou PDP context 1) supporte la classe de trafic "conversational" et le service support 2 (ou PDP context 2) supporte la classe de trafic "streaming". Par ailleurs, le service requis par le terminal 1 auprès du serveur 7 est un service de voix sur IP vers un terminal distant et il doit être mis en œuvre dans le cadre du PDP context 1. Enfin, on considère que le service requis est défini comme devant être facturé au temps écoulé au niveau du CRF 5.
Selon le schéma de la figure 2, le serveur 7 indique au CRF 5 qu'un service de voix sur IP est requis depuis le terminal 1 vers un terminal distant, en précisant les adresses IP de ces deux terminaux. Le serveur 7 informe en outre le CRF 5 que le service de voix sur IP nécessite une transmission avec un retard de transmission minimal, par exemple en lui transmettant un paramètre dont la valeur correspond sensiblement au mode "conversational". Le CRF 5 renvoie ce paramètre au TPF 2, en lui précisant en outre que le service requis par le terminal 1 doit être facturé au temps écoulé. Sur réception de ces informations, le TPF 2 peut alors appliquer la règle reçue du CRF 5 de façon sélective, après comparaison des caractéristiques des PDP context ouverts pour le terminal 1 et les paramètres reçus du CRF 5. Dans le cas présent, le TPF 2 facture donc au temps écoulé les flux de communication échangés avec le terminal 1 dans le cadre du PDP context 1 qui est du type "conversational" correspondant au paramètre de service support transmis par le CRF 5.
En revanche, si un autre service offert par le serveur 7 et ayant des caractéristiques différentes du service de voix sur IP, par exemple un service de "streaming" (lecture en transit), est établi entre les mêmes terminaux dans le cadre du PDP context 2, celui-ci ne sera pas facturé au temps écoulé, puisque les règles de filtrage reçues du CRF 5 ne s'étendent pas au PDP context 2 dont les caractéristiques diffèrent de la qualité de service indiquée dans le paramètre transmis par le CRF 5. Il est même possible d'appliquer un mode de facturation différent pour les flux effectués dans le cadre du PDP context 2, par exemple une facturation au volume transmis si les règles de filtrage et de facturation le précisent.
On notera que, conformément à ce qui a été indiqué plus haut, le traitement sélectif ainsi obtenu peut être de différentes natures selon les règles de filtrage définies au CRF 5. Bien que ces règles puissent contenir des informations sur la facturation à appliquer aux flux de communications, elles peuvent également servir de base par exemple à une analyse statistique des flux en fonction des informations transmises. Dans ce cas, le TPF 2 peut effectuer un comptage sur les flux qu'il reçoit du terminal en fonction du PDP context dans le cadre duquel ils sont échangés.
On décrit désormais un second mode de réalisation de l'invention en référence à la figure 3, dans lequel le traitement sélectif effectué par le TPF 2 est différent du cas précédemment décrit. Dans ce mode de réalisation, en effet, on conditionne l'ouverture d'un service support au type de service envisagé.
Ainsi, le terminal 1 émet une requête d'établissement d'un service support à l'attention du TPF 2. Ensuite, le terminal 1 transmet au serveur applicatif 7 un message d'établissement de session d'application, comme dans le cas précédent, pour mettre en œuvre un service offert par le serveur 7.
Comme dans le premier mode de réalisation de l'invention décrit ci- dessus, le serveur applicatif 7 transmet alors au CRF 5 des paramètres identifiant le service requis, comme par exemple une adresse IP du terminal 1. En outre, des paramètres de service support tels que décrits plus haut sont transmis du serveur 7 au CRF 5 en fonction du service requis par le terminal 1.
Puis, le CRF 5 retransmet ces paramètres de service support au TPF 2. Sur réception de ces paramètres, le TPF 2 déduit les caractéristiques de service support auxquels ces paramètres de service support correspondent. Si le service support requis initialement par le terminal 1 possède des caractéristiques de service support correspondant aux paramètres de service support reçus du CRF 5, cela signifie que le service support requis sera apte à encadrer des communications selon le service requis par le terminal 1. Dans ce cas, le TPF 2 autorise donc l'établissement du service support requis et il le notifie au terminal 1. Dans le cas contraire, c'est-à-dire si le service support requis initialement par le terminal 1 possède des caractéristiques de service support ne correspondant pas aux paramètres de service support reçus du CRF 5, le TPF 2 rejette alors l'établissement du service support requis et il le notifie au terminal 1.
A titre d'exemple, si le service support requis par le terminal 1 est un PDP context avec une classe de trafic de type "streaming", et si le terminal requiert, auprès du serveur applicatif 7, un service de voix sur IP, qui est un service nécessitant une qualité de service supportant des retards de transmission très faibles, c'est-à-dire une qualité de service de type "conversational" selon la terminologie utilisée dans le cadre des PDP context, l'établissement du PDP context requis sera rejeté par le TPF 2. Si, au contraire, le service requis par le terminal 1 nécessite une qualité de service de type "streaming", par exemple une transmission de vidéo en transit, l'établissement du PDP context requis par le terminal 1 pourra être accepté par le TPF 2.
Dans ce second mode de réalisation, on comprend donc que le traitement sélectif effectué par le TPF 2 consiste à autoriser ou, au contraire, à rejeter l'établissement d'un service support en fonction du service requis dans le cadre de ce service support.

Claims

R E V E N D I C A T I O N S
1. Procédé de contrôle de communications dans un système comprenant des moyens de communication (3), au moins un serveur applicatif (7) et au moins une passerelle (2) entre les moyens de communication et le serveur applicatif, le système étant agencé pour mettre en œuvre des communications avec des terminaux selon des services offerts par ledit serveur applicatif, chaque communication étant mise en œuvre par l'intermédiaire desdits moyens de communication dans le cadre d'un service support entre un terminal et ladite passerelle, le procédé comprenant les étapes suivantes relativement à au moins un terminal (1 ) ayant ou requérant au moins une communication selon un service offert par ledit serveur applicatif :
- déterminer, au serveur applicatif, des paramètres dudit service correspondant sensiblement à des caractéristiques respectives de service support ;
- transmettre, à la passerelle, lesdits paramètres déterminés ; et
- effectuer, à la passerelle, un traitement sélectif de ladite communication en fonction desdits paramètres reçus.
2. Procédé selon la revendication 1 , dans lequel ledit terminal (1 ) requiert une communication selon ledit service dans le cadre d'un service support à établir et dans lequel le traitement sélectif de ladite communication comprend les étapes suivantes :
- déduire desdits paramètres transmis à la passerelle les caractéristiques de service support correspondantes ; - comparer les caractéristiques de service support déduites avec certaines au moins des caractéristiques du service support à établir ; et
- autoriser l'établissement dudit service support à établir lorsque la comparaison révèle que les caractéristiques de service support déduites et certaines au moins des caractéristiques du service support à établir sont sensiblement identiques, et rejeter l'établissement dudit service support à établir sinon.
3. Procédé selon la revendication 1 ou 2, dans lequel le système comprend en outre une unité de filtrage (5) reliée à la passerelle (2) et au serveur applicatif (7), ladite unité de filtrage étant agencée pour obtenir du serveur applicatif des indications identifiant le service de ladite communication en cours ou requise et pour délivrer à la passerelle des règles de filtrage des communications en fonction desdites indications obtenues, et dans lequel la transmission à la passerelle desdits paramètres déterminés est effectuée par l'intermédiaire de ladite unité de filtrage.
4. Procédé selon la revendication 3, dans lequel le traitement sélectif de ladite communication comprend les étapes suivantes :
- recevoir à la passerelle (2) des règles de filtrage des communications en correspondance avec lesdits paramètres déterminés ; - déduire desdits paramètres reçus à la passerelle les caractéristiques de service support correspondantes ;
- pour chacune des règles de filtrage reçues à la passerelle, appliquer ladite règle de filtrage pour filtrer ladite communication dans le cadre des services supports établis entre le terminal et la passerelle et dont certaines au moins des caractéristiques sont sensiblement identiques auxdites caractéristiques de service support déduites des paramètres reçus en correspondance avec ladite règle de filtrage.
5. Procédé selon la revendication 4, dans lequel lesdites règles de filtrage des communications délivrées à la passerelle comprennent des règles de facturation des communications.
6. Procédé selon la revendication 4 ou 5, dans lequel lesdites indications identifiant le service de ladite communication en cours ou requise comprennent l'un au moins parmi : une adresse IP source, une adresse IP de destination, un numéro de port source, un numéro de port de destination et un identifiant d'un protocole de communication.
7. Procédé selon l'une quelconque des revendications précédentes, dans lequel lesdits paramètres déterminés comprennent l'un au moins parmi : une information de qualité de service, une classe de service, une bande passante occupée par le service, un mode de codage/décodage et une contrainte de délai de transmission.
8. Procédé selon l'une quelconque des revendications précédentes, dans lequel les caractéristiques de service support auxquelles lesdits paramètres déterminés correspondent sensiblement comprennent l'un au moins parmi : une information de qualité de service et une classe de trafic.
9. Serveur applicatif (7) dans un système comprenant en outre des moyens de communication (3) et au moins une passerelle (2) entre les moyens de communication et le serveur applicatif, le système étant agencé pour mettre en œuvre des communications avec des terminaux selon des services offerts par ledit serveur applicatif, chaque communication étant mise en œuvre par l'intermédiaire desdits moyens de communication dans le cadre d'un service support entre un terminal et ladite passerelle, la passerelle étant en outre agencée pour effectuer un traitement sélectif des communications en fonction de paramètres de service reçus, le serveur applicatif comprenant, relativement à au moins un terminal (1 ) ayant ou requérant au moins une communication selon un service offert par ledit serveur applicatif :
- des moyens pour déterminer des paramètres dudit service correspondant sensiblement à des caractéristiques respectives de service support ; et - des moyens pour transmettre lesdits paramètres déterminés à la passerelle.
10. Serveur applicatif (7) selon la revendication 9, dans lequel le système comprend en outre une unité de filtrage (5) reliée à la passerelle (2) et au serveur applicatif, agencée pour délivrer à la passerelle des règles de filtrage des communications, le serveur applicatif comprenant en outre des moyens pour transmettre à l'unité de filtrage des indications identifiant le service de ladite communication en cours ou requise, et dans lequel les moyens pour transmettre lesdits paramètres déterminés à la passerelle sont mis en oeuvre par l'intermédiaire de l'unité de filtrage.
11. Serveur applicatif (7) selon la revendication 10, dans lequel lesdites indications identifiant le service de ladite communication en cours ou requise comprennent l'un au moins parmi : une adresse IP source, une adresse IP de destination, un numéro de port source, un numéro de port de destination et un identifiant d'un protocole de communication.
12. Serveur applicatif (7) selon l'une quelconque des revendications 9 à 11 , dans lequel lesdits paramètres déterminés comprennent l'un au moins parmi : une information de qualité de service, une classe de service, une bande passante occupée par le service, un mode de codage/décodage et une contrainte de délai de transmission.
13. Serveur applicatif (7) selon l'une quelconque des revendications 9 à 12, dans lequel les caractéristiques de service support auxquelles lesdits paramètres déterminés correspondent sensiblement comprennent l'un au moins parmi : une information de qualité de service et une classe de trafic.
14. Passerelle (2) entre des moyens de communication (3) et au moins un serveur applicatif (7) d'un système agencé pour mettre en œuvre des communications avec des terminaux selon des services offerts par ledit serveur applicatif, chaque communication étant mise en œuvre par l'intermédiaire desdits moyens de communication dans le cadre d'un service support entre un terminal et ladite passerelle, le serveur applicatif étant agencé pour déterminer, pour chaque service offert, des paramètres correspondant sensiblement à des caractéristiques respectives de service support, la passerelle comprenant les étapes suivantes relativement à au moins un terminal (1 ) ayant ou requérant au moins une communication selon un service offert par ledit serveur applicatif :
- des moyens pour recevoir les paramètres dudit service correspondant sensiblement à des caractéristiques respectives de service support déterminés par le serveur applicatif ; et - des moyens pour effectuer un traitement sélectif de ladite communication en fonction desdits paramètres reçus.
15. Passerelle (2) selon la revendication 14, dans laquelle ledit terminal (1 ) requiert une communication selon ledit service dans le cadre d'un service support à établir et dans laquelle lesdits moyens pour effectuer un traitement sélectif de ladite communication en fonction desdits paramètres reçus comprennent :
- des moyens pour déduire desdits paramètres reçus à la passerelle les caractéristiques de service support correspondantes ; - des moyens pour comparer les caractéristiques de service support déduites avec certaines au moins des caractéristiques du service support à établir ; et
- des moyens pour autoriser l'établissement dudit service support à établir lorsque la comparaison révèle que les caractéristiques de service support déduites et certaines au moins des caractéristiques du service support à établir sont sensiblement identiques, et pour rejeter l'établissement dudit service support à établir sinon.
16. Passerelle (2) selon la revendication 14 ou 15, dans laquelle le système comprend en outre une unité de filtrage (5) reliée à la passerelle et au serveur applicatif (7), ladite unité de filtrage étant agencée pour obtenir du serveur applicatif des indications identifiant le service de ladite communication en cours ou requise, la passerelle comprenant en outre des moyens pour recevoir des règles de filtrage des communications délivrées par l'unité de filtrage en fonction desdites indications obtenues, et dans laquelle les moyens pour recevoir lesdits paramètres sont mis en œuvre par l'intermédiaire de ladite unité de filtrage.
17. Passerelle (2) selon la revendication 16, dans laquelle lesdits moyens pour effectuer un traitement sélectif de ladite communication en fonction desdits paramètres reçus comprennent : - des moyens pour recevoir des règles de filtrage des communications en correspondance avec lesdits paramètres déterminés ; - des moyens pour déduire desdits paramètres reçus à la passerelle les caractéristiques de service support correspondantes ;
- des moyens pour appliquer, pour chacune des règles de filtrage reçues à la passerelle, ladite règle de filtrage pour filtrer ladite communication dans le cadre des services supports établis entre le terminal et la passerelle et dont certaines au moins des caractéristiques sont sensiblement identiques auxdites caractéristiques de service support déduites des paramètres reçus en correspondance avec ladite règle de filtrage.
18. Passerelle (2) selon la revendication 17, dans laquelle lesdites règles de filtrage des communications délivrées à la passerelle comprennent des règles de facturation des communications.
19. Passerelle (2) selon la revendication 17 ou 18, dans laquelle lesdites indications identifiant le service de ladite communication en cours ou requise comprennent l'un au moins parmi : une adresse IP source, une adresse IP de destination, un numéro de port source, un numéro de port de destination et un identifiant d'un protocole de communication.
20. Passerelle (2) selon l'une quelconque des revendications 14 à 19, dans laquelle lesdits paramètres comprennent l'un au moins parmi : une information de qualité de service, une classe de service, une bande passante occupée par le service, un mode de codage/décodage et une contrainte de délai de transmission.
21. Passerelle (2) selon l'une quelconque des revendications 14 à 20, dans laquelle les caractéristiques de service support auxquelles lesdits paramètres déterminés correspondent sensiblement comprennent l'un au moins parmi : une information de qualité de service et une classe de trafic.
22. Unité de filtrage (5) dans un système comprenant en outre des moyens de communication (3), au moins un serveur applicatif (7) et au moins une passerelle (2) entre les moyens de communication et le serveur applicatif, le système étant agencé pour mettre en œuvre des communications avec des terminaux selon des services offerts par ledit serveur applicatif, chaque communication étant mise en œuvre par l'intermédiaire desdits moyens de communication dans le cadre d'un service support entre un terminal et ladite passerelle, le serveur applicatif étant agencé pour déterminer, pour chaque service offert, des paramètres correspondant sensiblement à des caractéristiques respectives de service support, ladite unité de filtrage étant reliée à la passerelle (2) et au serveur applicatif (7) et comprenant, relativement à au moins un terminal (1) ayant ou requérant au moins une communication selon un service offert par ledit serveur applicatif : - des moyens pour obtenir du serveur applicatif des indications identifiant le service de ladite communication en cours ou requise ;
- des moyens pour obtenir des paramètres dudit service correspondant sensiblement à des caractéristiques respectives de service support ; et
- des moyens pour délivrer à la passerelle des règles de filtrage des communications en fonction desdites indications obtenues, en correspondance avec lesdits paramètres obtenus.
23. Unité de filtrage (5) selon la revendication 22, dans laquelle lesdites règles de filtrage des communications délivrées à la passerelle comprennent des règles de facturation des communications.
24. Unité de filtrage (5) selon la revendication 22 ou 23, lesdites indications identifiant le service de ladite communication en cours ou requise comprennent l'un au moins parmi : une adresse IP source, une adresse IP de destination, un numéro de port source, un numéro de port de destination et un identifiant d'un protocole de communication.
25. Unité de filtrage (5) selon l'une quelconque des revendications 22 à
24, dans laquelle lesdits paramètres comprennent l'un au moins parmi : une information de qualité de service, une classe de service, une bande passante occupée par le service, un mode de codage/décodage et une contrainte de délai de transmission.
26. Unité de filtrage (5) selon l'une quelconque des revendications 22 à
25, dans laquelle les caractéristiques de service support auxquelles lesdits paramètres déterminés correspondent sensiblement comprennent l'un au moins parmi : une information de qualité de service et une classe de trafic.
PCT/EP2005/011205 2004-10-26 2005-10-18 Procede de controle de communications et equipements pour la mise en oeuvre du procede WO2006045497A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/577,991 US20080298300A1 (en) 2004-10-26 2005-10-18 Communication Control Method and System for Carrying Out Said Method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP04292542 2004-10-26
EP04292542.0 2004-10-26

Publications (1)

Publication Number Publication Date
WO2006045497A1 true WO2006045497A1 (fr) 2006-05-04

Family

ID=35892364

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/011205 WO2006045497A1 (fr) 2004-10-26 2005-10-18 Procede de controle de communications et equipements pour la mise en oeuvre du procede

Country Status (2)

Country Link
US (1) US20080298300A1 (fr)
WO (1) WO2006045497A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080310303A1 (en) * 2007-06-13 2008-12-18 Qualcomm Incorporated Quality of service information configuration
FR3101498A1 (fr) * 2019-09-30 2021-04-02 Orange Procédé de contrôle d’un flux de données associé à un processus au sein d’un réseau mutualisé

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090190471A1 (en) * 2008-01-10 2009-07-30 Mahendran Arungundram C Method and Apparatus for Optimized Session Setup with Network-Initiated QoS Policy Control
CN102547610B (zh) * 2010-12-31 2016-03-30 华为技术有限公司 消息处理方法、设备及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001091446A2 (fr) * 2000-05-24 2001-11-29 Nokia Corporation Identificateur de taxation commun pour reseaux de communications
US20040002324A1 (en) * 2000-03-14 2004-01-01 Sonera Oyj Transaction-based service billing in a telecommunication system
US6775267B1 (en) * 1999-12-30 2004-08-10 At&T Corp Method for billing IP broadband subscribers

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6621793B2 (en) * 2000-05-22 2003-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Application influenced policy
AU2003265043A1 (en) * 2002-09-27 2004-04-19 Nokia Corporation Enhanced qos control

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6775267B1 (en) * 1999-12-30 2004-08-10 At&T Corp Method for billing IP broadband subscribers
US20040002324A1 (en) * 2000-03-14 2004-01-01 Sonera Oyj Transaction-based service billing in a telecommunication system
WO2001091446A2 (fr) * 2000-05-24 2001-11-29 Nokia Corporation Identificateur de taxation commun pour reseaux de communications

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Overall high level functionality and architecture impacts of flow based charging; Stage 2 (Release 6); 3GPP TS 23.125", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. 3-CN, no. V620, September 2004 (2004-09-01), XP014021927, ISSN: 0000-0001 *
"Universal Mobile Telecommunications System (UMTS); Quality of Service (QoS) concept and architecture (3GPP TS 23.107 version 5.10.0 Release 5); ETSI TS 123 107", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. 3-SA2, no. V5100, September 2003 (2003-09-01), XP014016466, ISSN: 0000-0001 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080310303A1 (en) * 2007-06-13 2008-12-18 Qualcomm Incorporated Quality of service information configuration
TWI483599B (zh) * 2007-06-13 2015-05-01 Qualcomm Inc 服務品質資訊組態
US9681336B2 (en) 2007-06-13 2017-06-13 Qualcomm Incorporated Quality of service information configuration
FR3101498A1 (fr) * 2019-09-30 2021-04-02 Orange Procédé de contrôle d’un flux de données associé à un processus au sein d’un réseau mutualisé
WO2021064310A1 (fr) * 2019-09-30 2021-04-08 Orange Procede de controle d'un flux de donnees associe a un processus au sein d'un reseau mutualise

Also Published As

Publication number Publication date
US20080298300A1 (en) 2008-12-04

Similar Documents

Publication Publication Date Title
EP1665661B1 (fr) Procede de differenciation de la qualite de service dans les reseaux de communication mobile en mode paquets
EP1792447B1 (fr) Procede de preemption pour la gestion des ressources radio dans un reseau de communication mobile
CN101248685B (zh) 用于建立多媒体通信会话的方法和设备
EP2078412B1 (fr) Procédé d'accès à un service, via un réseau hétérogène où plusieurs types d'accès sont disponibles, à parti r d'un terminal d'un utilisateur
WO2005084061A1 (fr) Procede de gestion des ressources radio dans un reseau d’acces radio de type utran
FR2822320A1 (fr) Procede pour le controle de session d'appel multimedia dans un systeme cellulaire de radiocommunications mobiles
WO2010046598A2 (fr) Procede de configuration de parametres de gestion de paquets de donnees appartenant a un flux de donnees
WO2003105505A1 (fr) Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles
EP1602256B1 (fr) Procede pour la gestion de la qualite de service dans un systeme de communications mobiles en mode paquet
WO2019043324A1 (fr) Procédé de taxation de données d'une application acheminées sur une tranche d'un réseau de communication
WO2006045497A1 (fr) Procede de controle de communications et equipements pour la mise en oeuvre du procede
EP3162026B1 (fr) Procédé d'autorisation d'établissement d'un flux pair à pair dans un réseau de télécommunications mobiles
FR2882879A1 (fr) Procede de traitement de la qualite de service d'un canal de transport et noeud de gestion pour sa mise en oeuvre
WO2003081928A1 (fr) Systeme de communication et procede de supervision associe
EP1616450B1 (fr) Procede de controle du transfert entre reseau umts et gsm d' une demande de service en telephonie mobile et dispositif de controle correspondant
FR2823394A1 (fr) Point de decision d'autorisation modulaire pour traiter des requetes de reservations de ressources, au sein d'un reseau de donnees
EP1451986A1 (fr) Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service
EP2879431B1 (fr) Equipement de passerelle d'accès de mobiles à internet
EP3050275A1 (fr) Conversion de protocole enrichie dans un réseau de télécommunications pour la fourniture de services à qualité de service améliorée
EP3777309A1 (fr) Equipement orchestrateur dans un système de télécommunication cellulaire
FR2822007A1 (fr) Procede et dispositifs de securisation d'une session de communication
WO2009125150A1 (fr) Procede et dispositif de communication tenant compte d'un controle de la validite d'une demande d'allocation de bande passante dans une architecture reseau
FR2937818A1 (fr) Procede de configuration de parametres de gestion de messages de donnees appartenant a un flux de donnees
FR2923342A1 (fr) Verification d'un type d'acces genere par un terminal dans un reseau de telecommunications

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV LY MD MG MK MN MW MX MZ NA NG NO NZ OM PG PH PL PT RO RU SC SD SG SK SL SM SY TJ TM TN TR TT TZ UG US UZ VC VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SZ TZ UG ZM ZW AM AZ BY KG MD RU TJ TM AT BE BG CH CY DE DK EE ES FI FR GB GR HU IE IS IT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 11577991

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 05802867

Country of ref document: EP

Kind code of ref document: A1