WO2011001075A1 - Procédé et dispositif d'acquittement d'une requête de signalisation périodique dans un réseau de télécommunications - Google Patents

Procédé et dispositif d'acquittement d'une requête de signalisation périodique dans un réseau de télécommunications Download PDF

Info

Publication number
WO2011001075A1
WO2011001075A1 PCT/FR2010/051302 FR2010051302W WO2011001075A1 WO 2011001075 A1 WO2011001075 A1 WO 2011001075A1 FR 2010051302 W FR2010051302 W FR 2010051302W WO 2011001075 A1 WO2011001075 A1 WO 2011001075A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
request
raps
requests
cscf
Prior art date
Application number
PCT/FR2010/051302
Other languages
English (en)
Inventor
Bertrand Bouvet
Fabrice Petesch
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
Priority to EP10745323A priority Critical patent/EP2449747A1/fr
Priority to US13/381,546 priority patent/US20120106335A1/en
Publication of WO2011001075A1 publication Critical patent/WO2011001075A1/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/1066—Session management
    • H04L65/1073—Registration or de-registration

Definitions

  • the present invention is in the field of signaling traffic management in telecommunications networks.
  • This procedure starts with the sending of a first request. SIP REGISTER, acknowledged by a 401 (Nonce) message, then by sending an acknowledged REGISTER (Authentication) request, if successful by a 200 OK message.
  • the acknowledgment message 200 OK has an EXPIRES duration by which the CSCF defines the period that the terminal UA must respect between two successive sendings of REGISTER requests. It is important to note that the regular sending of these REGISTER messages is mandatory to maintain the AU terminal context within the CSCF. This duration EXPIRES is fixed, and is of the order of 3600 seconds. Upon receipt of such a message, the UA terminal determines a renewal value. It can for example be chosen equal to:
  • the procedure for subscribing an AU terminal to a service brick requires the regular sending of SUBSCRIBE SIP requests to this service brick, the period between two requests. consecutive, defined by the brick service, being fixed and of the order of 86400s (24H) for a service type MWI ("Message Waiting Indicator").
  • the terminal UA determines a chosen renewal value, for example equal to:
  • the renewal time is determined equal to 24H - 600s.
  • the signaling traffic associated with the regular sending of SIP REGISTER and SIP SUBSCRIBE requests in the network should tend to smoothly smooth out at the CSCF backbone level and service bricks.
  • the number of users imparted and seeking to re-register simultaneously can be very important in the latter case, for example of the order of a few million.
  • the SIP renewal procedure defined in RFC 3261, provides that a terminal must reissue an unacknowledged SIP REGISTER request ten times, according to a preset rate, in phases of 32s, which are repeated according to a non-standardized protocol.
  • the equipment of the core network and in particular the CSCFs and HSSs (in English "Home Subscriber Server"), have, by nature, a capacity enabling them to process a maximum number of SIP REGISTER registration requests per second. Seen from the network operator, it is very important to seek to maintain a signaling traffic allowing it to absorb, the variations likely to occur. In the event of a breakdown, it is also crucial to be able to set up a fault exit procedure to return as quickly as possible to a stable situation offering a satisfactory quality of service to the users.
  • the invention relates to a method that can be implemented in an entity of a telecommunications network, to acknowledge a request of a specific type sent by a terminal and received by this entity, a request of the same type being able to be re-transmitted by this terminal after a period of time defined by this entity and sent to the terminal in an acknowledgment message to this request.
  • This process comprises:
  • a step of receiving a request of this type called the current request
  • the invention relates to an entity of a telecommunications network, comprising:
  • estimating means for at least a future time range, of the number of requests of this type likely to be received by this entity during this future time range;
  • the invention proposes to no longer systematically pay a periodic request with a fixed period, but to adjust this period, according to a forecast of the future traffic generated by these requests.
  • an "acknowledgment message” may be a positive acknowledgment message or a negative acknowledgment message, namely a rejection message.
  • the response codes 200 and 503 of the SIP protocol are acknowledgment messages within the meaning of the invention.
  • the acknowledgment method according to the invention also comprises an observation step, consisting in counting, for each time slot of an observation phase, the number of requests of a type determined by this entity during this time, an estimate of the number of requests of this type that may be received by that entity over a future time period is made from this observation.
  • the future time range selected by the entity to receive the next request sent by a terminal may for example be a range such that the estimated number of requests is less than an average value calculated over the entire observation phase.
  • the invention can advantageously be implemented by a CSCF entity or a service brick to smooth SIP REGISTER requests or SIP SUBSCRIBE requests issued by the terminals managed by these entities.
  • CSCF entity comprising:
  • observation means able to count, the number of SIP REGISTER requests received per second during an observation phase; means for receiving a current SIP REGISTER request from a terminal;
  • an acknowledgment message comprising a period chosen so that the next SIP REGISTER request sent by the terminal is transmitted during a time range, such as the estimated number SIP REGISTER requests that can be received by said CSCF entity during this time range, which is less than or equal to the average value of the number of SIP REGISTER requests received during the observation phase.
  • RAPS REGISTER ATTEMPTS PER SECOND
  • the invention also provides a service brick in a SIP signaling network comprising:
  • observing means able to count, the number of SIP SUBSCRIBE requests received per second during an observation phase
  • an acknowledgment message comprising a period chosen so that the next SIP request SUBSCRIBE sent by this terminal is sent during a time range such as the estimated number of SUBSCRIBE SIP requests that may be received by this service brick during this time range, is less than or equal to the average value of the number of SIP SUBSCRIBE requests received during the observation phase.
  • SAPS SIP SUBSCRIBER ATTEMPTS PER SECOND
  • SIP REGISTER or SIP SUBSCRIBE requests can be implemented at any time to avoid a drift in the network.
  • they can be implemented at the end of the morning to smooth the signaling traffic induced by powering up the terminals early in the morning.
  • the invention also proposes solutions for quickly returning to a satisfactory state at the output of the fault.
  • the invention relates to an acknowledgment method implemented by an entity and comprising:
  • the period sent to the terminal transmitting this request is:
  • This method can for example be implemented by a CSCF entity out of failure of a core network equipment, to prioritize the processing of SIP REGISTER requests at the expense of SUBSCRIBE SIP requests.
  • CSCF type entity comprising:
  • the RAPS number of SIP REGISTER requests received by this CSCF entity, during the second preceding the receipt of the current request being greater than the maximum number of SIP REGISTER requests that can be processed by this CSCF entity in one second.
  • the first and second values can be chosen empirically. They can in particular be respectively equal to two and three times the nominal period.
  • Another solution according to the invention for managing a fault output consists in pushing the requests of the terminals already registered with an entity, in a sufficiently long time range to allow the other terminals managed by this entity, but not yet registered, to register themselves.
  • the invention aims at an acknowledgment method that can be implemented by an entity in a telecommunications network and comprising:
  • a computation step as a function of a maximum number of requests of a priority type that can be processed by this entity during a determined period of time, of a minimum duration for processing the first requests of said priority type that can be received in from terminals managed by this entity but not registered in the network;
  • This method can for example be implemented by an entity
  • CSCF out of failure of a network equipment heart, to delay the signaling traffic of the SIP REGISTER and SIP SUBSCRIBE requests of the terminals managed by the CSCF and not yet registered in the network.
  • CSCF type entity comprising:
  • calculation means as a function of the maximum number of SIP REGISTER requests that can be processed by this CSCF entity per second, of a minimum duration for processing the first SIP REGISTER requests likely to be received from terminals managed by this CSCF but not registered in the network;
  • the various steps of the acknowledgment method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a CSCF entity, a service brick, or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of the acknowledgment process as mentioned above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1, already described, represents a procedure for registering a terminal in an IMS network, this procedure known from the state of the art;
  • FIG. 2 already described, represents a procedure for subscribing a terminal to a service brick in an IMS network, this procedure being known from the state of the art;
  • FIG. 3 schematically shows a CSCF entity according to the invention in a particular embodiment
  • FIG. 4 schematically shows a service brick according to the invention in a particular embodiment
  • FIG. 5 represents a signaling traffic that can be observed in an IMS network in the current state of the art
  • FIGS. 6A and 6B represent, in flowchart form, the main steps of an acknowledgment process that can be implemented by the CSCF entity of FIG. 3;
  • FIG. 7 represents the effect of the acknowledgment method of FIG. 6 on the signaling traffic of FIG. 5;
  • FIGS. 8A and 8B represent, in flowchart form, the main steps of an acknowledgment method that can be implemented by the service brick of FIG. 4;
  • FIG. 9 and 10 show, in flowchart form, the main steps of an acknowledgment method according to the invention, which can be implemented by the CSCF entity of Figure 3 at the output of a failure ;
  • FIG. 11 shows, in flowchart form, the main steps of a variant of this method.
  • FIG. 3 represents a CSCF entity according to a particular embodiment of the invention.
  • the CSCF entity has the hardware architecture of a computer. It comprises in particular a processor 11, a RAM type RAM 12, a ROM type ROM 13, communication means 14 and a FLASH type rewritable non-volatile memory 15.
  • the read-only memory 13 constitutes a recording medium according to the invention on which three computer programs PG1, PG3 and PG4 are recorded, which will be described later with reference to FIGS. 6, 8 and 9.
  • the ROM 13 further includes a register RAPS_MAX which stores the maximum number of REGISTER requests that can be processed by the CSCF entity per second.
  • RAM 12 has registers for executing programs PG1, PG3 and PG4 by processor 11.
  • the rewritable non-volatile memory 15 comprises, in a particular embodiment, two registers NB_TOT and NB_REG which will also be described with reference to FIG. 11.
  • Figure 4 shows a service brick BS according to the invention, in a particular embodiment.
  • This service brick BS comprises a processor 21, a random access memory RAM 22, a read-only memory ROM 23 and communication means 24.
  • the read-only memory 23 constitutes a recording medium in accordance with the invention on which a computer program PG2 is recorded, the main steps of which will be described with reference to FIG. 8.
  • the read-only memory 23 also includes an SAPS_MAX register comprising the maximum number of SUBSCRIBE requests that can be processed by the service brick BS in one second.
  • the RAM 22 includes registers for the execution of the program PG2 by the processor 21. It comprises in particular an SAPS register comprising the number of subscription requests SUBSCRIBE received by the brick BS during the last second.
  • a CSCF entity can implement an acknowledgment method according to the invention for smoothing the signaling traffic associated with the REGISTER requests transmitted by the UA terminals. managed by this entity.
  • the CSCF entity observes, during a step ElO, the aforementioned signaling traffic.
  • this observation phase has a duration of 10s, counted between the moments Os and 10s.
  • the CSCF entity counts, for each one second slot, the number RAPS of REGISTER requests received by the CSCF entity.
  • the CSCF entity calculates the average value RAPS_AVG of the number of REGISTER requests received per second during the entire observation phase.
  • this average number RAPS_AVG is equal to 101.
  • the traffic would repeat identically, for each period of 10s.
  • the equipment method according to the invention comprises a step E30 during which the CSCF entity estimates future future traffic by making the assumptions explained above (no new record, no De-registration).
  • the CSCF considers that the number of REGISTER requests received between the fifteenth and the sixteenth seconds is the same as the number received between the fifth and the sixth seconds, namely 130.
  • the purpose of the acknowledgment method described here is to smooth the REGISTER signaling request traffic at the end of the observation phase, the result of this method being illustrated in FIG. 7.
  • the CSCF entity initializes a stopwatch P to 0, this chronometer P being used to measure the duration of the observation period.
  • the CSCF entity initializes a stopwatch T to 0, this stopwatch T being used to measure the duration of one second, and initializes a value RAPS stored in the random access memory 12, to the value zero.
  • Step E40 is followed by a step E50 during which the CSCF entity checks whether or not it has received a request of type REGISTER. If this is not the case, the E50 test is followed by an E60 test in which the CSCF entity checks if more than one second has elapsed since the T chronometer was triggered.
  • step E65 The chronometer P is then incremented by one unit (step E65). Then during an E67 test, it is determined whether the observation period has elapsed. If this is the case the process ends. Otherwise, it loops back to step E40 for resetting the timer T and the RAPS register.
  • the E50 test result is positive. This test is then followed by a step E70 during which the variable RAPS is incremented by one unit.
  • the RAPS register always has the number of REGISTER requests received in the current second.
  • Step E70 is followed by a step E80 in which the entity CSCF checks whether the number RAPS of REGISTER requests received during the last second is less than or equal to the average number RAPS_AVG of REGISTER requests calculated in step E20 .
  • step E90 the entity CSCF sets the EXPIRES parameter to the nominal period, namely 20s in this example.
  • an initialized array E [i] is used, for each second i of the observation phase, with the number of REGISTERs observed during the 1 st second of the observation phase.
  • step KlO one initializes to 0, a variable I, and one looks, in the table E [I], by a loop K20, K30, K40, the first "hollow" of the period of observation by ratio to the average value RAPS_AVG calculated in step E20.
  • the result of the K20 test is positive, and it fills this trough of one unit, during a step K50.
  • the EXPIRES value which is to be returned to the terminal UA is calculated, taking into account the position I of the trough and the temporal location P of the REGISTER being processed. This calculation must take into account the internal processing of the EXPIRES parameter by the terminal UA.
  • the CSCF sets the EXPIRES parameter to:
  • Step K60 completes the general step ElOO.
  • An acknowledgment message is sent to the concerned UA terminal, during a step EI10, with the parameter EXPIRES calculated in step E90 or El00.
  • This acknowledgment method smooths the REGISTER requests issued by the UA terminals managed by the CSCF entity.
  • This method very advantageously smooths the signaling traffic associated with the REGISTER requests sent by the UA terminals managed by the CSCF entity.
  • a similar method can be implemented by the service brick BS, to smooth SUBSCRIBE subscription requests issued by the terminals accessing the services offered by this brick.
  • the service brick BS counts (step FlO), for each second of an observation phase, the number of SAPS SUBSCRIBE requests received by this brick BS.
  • the service brick BS estimates that the number of requests that can be received by the service brick BS after the observation phase reproduces exactly that of the observation phase. Then, upon reception (step F50) of a SUBSCRIBE request, the fixed service brick:
  • step F90 a nominal EXPIRES period in step F90 if the number of SAPS subscription requests received during the last second is less than or equal to the average number SAPS_AVG of SUBSCRIBE requests calculated in step F20;
  • This acknowledgment method smooths SUBSCRIBE subscription requests sent by the UA terminals accessing a service offered by the BS service brick.
  • Steps F35, F40, F60, F65, F67, F70 and F80 are similar to steps E35, E40, E60, E65, E67, E70 and E80 and will not be described here.
  • this method comprises a step GlO for starting an observation phase of a duration P corresponding to a nominal period set by the entity CSCF to acknowledge the REGISTER requests received by this entity.
  • this request can be of the REGISTER or SUBSCRIBE type.
  • the CSCF entity calculates the current number RAPS of REGISTER requests received by the CSCF entity during the last second.
  • the CSCF entity determines whether the current request RC is a SUBSCRIBE request or a REGISTER request. If the current request is a SUBSCRIBE request, the fixed CSCF entity (step G40) the EXPIRES parameter to a first value, chosen in this example as being equal to twice the nominal period P.
  • step G30 If it is determined, in step G30, that the current request is a REGISTER request, the CSCF determines, during a step
  • the fixed CSCF entity (step G60) the EXPIRES parameter to a second value, greater than the first value, and equal, in this example, to three times the nominal period 3P.
  • the CSCF entity sets the EXPIRES parameter to the nominal value P (step G70) .
  • the entity CSCF then sends (step G75) to the terminal UA at the origin of this request REGISTER, an acknowledgment message of the type 503 Service Unavailable having the value P in the field Retry After.
  • FIG. 10 illustrates the evolution of signaling traffic in the network by implementing the method described above with reference to FIG. 9.
  • the upper part of this diagram represents the processing of REGISTER requests, and the lower part the processing of SUBSCRIBE requests.
  • the RAPS_MAX first REGISTER queries are acquitted
  • the observation phase stops after the period 3P. It then returns to a normal situation, the REGISTER requests being acknowledged with the parameter P and the subscription requests being accepted by a message 200 OK after application of the acknowledgment method as described in FIGS. 5 to 8 to smooth the traffic in the IMS network.
  • the CSCF entity uses three parameters
  • NB_TOT, NB_REG and RENG stored in the flash memory 15, namely:
  • - NB_TOT total number of UA terminals managed by the CSCF entity
  • - NB_REG number of AU terminals registered, at a given instant, in this entity
  • REG_ENG number of REGISTER requests per second sent by the already registered terminals. This number can be obtained by NB_REG / P_DEF, where P_DEF is the default period of the REGISTER request.
  • NJTOT - NB_REG (NBJTOT - NB_REG) represents the number of terminals remaining to be recorded
  • RAPS_MAX - REG_ENG represents the maximum number of requests that can be processed per second, this number taking into account the already registered terminals that will try to re-register.
  • This method comprises a step H10, typically implemented at the output of a fault, for calculating the minimum duration TMIN necessary for the entity CSCF to process the first REGISTER requests that would be sent by all the UA terminals managed by the entity CSCF, but not already registered.
  • TMIN (NBJOT - NB_REG) / (RAPS_MAX- REG_ENG).
  • the CSCF entity When the CSCF entity receives a current request RC (of type SUBSCRIBE or REGISTER), in step H20, it calculates, in step H25, the number RAPS of REGISTER requests received since the last second or during a period of time defined in the system configuration.
  • RC of type SUBSCRIBE or REGISTER
  • the CSCF entity determines whether this RAPS number is less than or equal to the maximum number RAPS_MAX of REGISTER requests that can be processed per second by the CSCF entity.
  • the CSCF entity sets the EXPIRES parameter to the nominal value P (step H30), and sends (step H35) a positive acknowledgment message (200 OK) with this parameter to the terminal UA issuing the request. current RC.
  • the invention also applies when the UA accesses the CSCF entity via an intermediate device, for example a SBC (Session Border Control) equipment, such equipment allowing the establishment of a mechanism called " "Registration Caching", so that different registration periods can be used at the access network level and at the core network level.
  • SBC Session Border Control
  • the mechanism of the invention is implemented in a distributed manner at the level of the CSCF and the SBC, to take into account the EXPIRES values fixed by the CSCF.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Ce procédé peut être mis en œuvre dans une entité CSCF pour acquitter une requête de type REGISTER émise par un terminal. Il comporte - une étape (E30) d'estimation, pour au moins plage de temps future du nombre de requêtes REGISTER susceptibles d'être reçues par l'entité CSCF pendant cette plage de temps future; - une étape de sélection d'une plage de temps future; et - une étape (E110) d'envoi, au terminal émetteur, d'un message d'acquittement (200, 503) comportant une période (EXPIRES) choisie pour que la prochaine requête REGISTER, émise par ce terminal, soit émise pendant ladite plage future sélectionnée.

Description

Procédé et dispositif d'acquittement d'une requête de signalisation périodique dans un réseau de télécommunications
Arrière-plan de l'invention
La présente invention se situe dans le domaine de la gestion du trafic de signalisation dans les réseaux de télécommunications.
Elle s'applique en particulier, mais de façon non limitative, aux réseaux mettant en œuvre le protocole de signalisation SIP (en anglais « Session Initiation Protocol », et par exemple aux réseaux IMS (« IP Multimedia Subsystem »).
De façon connue, l'accès par un terminal aux services offerts dans un réseau IMS, nécessite un enregistrement du terminal auprès d'un équipement CSCF (« CaII Session Control Function ») du cœur de réseau
IMS, puis la souscription éventuelle, par le terminal à une ou plusieurs briques de service mettant en œuvre ces services.
La procédure d'enregistrement d'un terminal UA (en anglais « User Agent ») auprès d'une plateforme de service cœur IMS CSCF est maintenant décrite en référence à la figure 1. Cette procédure démarre par l'envoi d'une première requête SIP REGISTER, acquittée par un message de type 401(Nonce), puis par l'envoi d'une requête REGISTER(Authentication) acquittée, en cas de succès par un message de type 200 OK.
On rappelle que dans le contexte du protocole SIP, les messages de type 401(Nonce) et de type 200 OK sont aussi appelés « codes de réponse ».
De façon remarquable, le message d'acquittement 200 OK comporte une durée EXPIRES par laquelle le CSCF définit la période que doit respecter le terminal UA entre deux envois successifs de requêtes REGISTER. Il est important de noter que l'envoi régulier de ces messages REGISTER est obligatoire pour maintenir le contexte du terminal UA au sein du CSCF. Cette durée EXPIRES est fixe, et est de l'ordre de 3600 secondes. Sur réception d'un tel message, le terminal UA détermine une valeur de renouvellement. Elle peut par exemple être choisie égale à :
EXPIRES - 600s, si EXPIRES > 1200s ; ou
- EXPIRES / 2, si EXPIRES < 1200s. Dans l'exemple de la figure 1, la durée de renouvellement est donc déterminée égale à 3000s.
De façon tout à fait comparable, la procédure de souscription d'un terminal UA auprès d'une brique de service, représentée à la figure 2, nécessite l'envoi régulier de requêtes SIP SUBSCRIBE à cette brique de service, la période entre deux requêtes consécutives, définie par la brique de service, étant fixe et de l'ordre de 86400s (24H) pour un service de type MWI (« Message Waiting Indicator »). Sur réception d'un message de réponse 200 OK (EXPIRES), le terminal UA détermine une valeur de renouvellement choisie par exemple égale à :
EXPIRES - 600s, si EXPIRES > 1200s ; ou
EXPIRES / 2, si EXPIRES < 1200s.
Dans l'exemple de la figure 2, la durée de renouvellement est déterminée égale à 24H - 600s.
Compte tenu du nombre très important de terminaux UA, le trafic de signalisation lié à l'envoi régulier de requêtes SIP REGISTER et SIP SUBSCRIBE dans le réseau devrait avoir tendance à se lisser naturellement au niveau de cœur de réseau CSCF et des briques de service.
En pratique ce n'est pas le cas, la Demanderesse ayant remarqué des fortes variations dans ce trafic.
A titre d'exemple, il est connu de constater des demandes très fortes de réenregistrement le matin (une proportion non négligeable d'utilisateurs ayant pour habitude d'éteindre leurs terminaux pendant la nuit) ou en cas de panne d'un équipement central du réseau cœur.
Le nombre d'utilisateurs impartes et cherchant à se ré enregistrer simultanément pouvant être très important dans ce dernier cas, par exemple de l'ordre de quelques millions.
On notera que la procédure SIP de renouvellement, définie dans le document RFC 3261, prévoit qu'un terminal doit réémettre dix fois une requête SIP REGISTER non acquittée, selon un rythme pré établi, dans des phases de 32s, celles-ci se répétant selon un protocole non normalisé.
Par ailleurs, les équipements du réseau cœur, et notamment les CSCF et HSS (en anglais « Home Subscriber Server »), ont par nature, une capacité leur permettant de traiter un nombre maximum de requêtes d'enregistrement SIP REGISTER par seconde. Vu de l'opérateur de réseau, il est très important de chercher à maintenir un trafic de signalisation lui permettant d'absorber, les variations susceptibles de se produire. En cas de panne, il est aussi crucial de pouvoir mettre en place une procédure de sortie de panne permettant de revenir au plus vite à une situation stable offrant une qualité de service satisfaisante aux utilisateurs.
Malheureusement, aucune solution satisfaisante n'est connue à ce jour. Objet et résumé de l'invention
Selon un premier aspect, l'invention concerne un procédé pouvant être mis en œuvre dans une entité d'un réseau de télécommunications, pour acquitter une requête d'un type déterminé émise par un terminal et reçue par cette entité, une requête du même type étant susceptible d'être réémise par ce terminal après une période de temps définie par cette entité et envoyée au terminal dans un message d'acquittement à cette requête. Ce procédé comporte :
- une étape de réception d'une requête de ce type, dite requête courante ; - une étape d'estimation, pour au moins plage de temps future, du nombre de requêtes du même type susceptibles d'être reçues par cette entité pendant cette plage de temps future ;
- une étape de sélection d'une de ces plages de temps futures ; et
- une étape d'envoi, au terminal émetteur de la requête courante, d'un message d'acquittement comportant une période choisie pour que la prochaine requête de ce type, émise par le terminal, soit émise pendant la plage future sélectionnée.
Corrélativement, l'invention concerne une entité d'un réseau de télécommunications, comportant :
- des moyens de réception d'une requête d'un type déterminé émise par un terminal, dite requête courante, cette requête étant susceptible d'être réémise par ce terminal après une période de temps définie par cette entité et envoyée au terminal dans un message d'acquittement à cette requête ; - des moyens d'estimation, pour au moins plage de temps future, du nombre de requêtes de ce type susceptibles d'être reçues par cette entité pendant cette plage de temps future ;
- des moyens de sélection d'une de ce plages de temps futures; et
- des moyens d'envoi, au terminal, d'un message d'acquittement comportant une période choisie pour que la prochaine requête du même type, émise par ce terminal, soit émise pendant la plage future sélectionnée.
Autrement dit, et d'une façon très générale, l'invention propose de ne plus acquitter systématiquement une requête périodique avec une période fixe, mais d'ajuster cette période, en fonction d'une prévision du trafic futur engendré par ces requêtes.
On notera que dans ce document, un « message d'acquittement » peut être un message d'acquittement positif ou un message d'acquittement négatif, à savoir un message de rejet. Par exemple, les codes de réponses 200 et 503 du protocole SIP sont des messages d'acquittement au sens de l'invention.
Dans un mode particulier de réalisation, le procédé d'acquittement selon l'invention comporte en outre une étape d'observation, consistant à comptabiliser, pour chaque tranche de temps d'une phase d'observation, le nombre de requêtes d'un type déterminé reçues par cette entité pendant cette tranche de temps, l'estimation du nombre de requêtes de ce type, susceptibles d'être reçues par cette entité pendant une plage de temps future, étant faite à partir de cette observation.
La plage de temps future sélectionnée par l'entité pour recevoir la prochaine requête émise par un terminal peut par exemple être une plage telle que le nombre estimé de requêtes est inférieur à une valeur moyenne calculée sur toute la phase d'observation.
L'invention peut avantageusement être mise en œuvre par une entité CSCF ou par une brique de service pour lisser les requêtes SIP REGISTER ou les requêtes SIP SUBSCRIBE émises par les terminaux gérés par ces entités.
Par conséquent, l'invention vise une entité CSCF comportant :
- des moyens d'observation aptes à comptabiliser, le nombre de requêtes SIP REGISTER reçues par seconde pendant une phase d'observation ; - des moyens pour recevoir une requête courante SIP REGISTER en provenance d'un terminal ; et
- des moyens pour envoyer à ce terminal, en réponse à cette requête courante, un message d'acquittement comportant une période choisie pour que la prochaine requête SIP REGISTER émise par le terminal, soit émise pendant une plage de temps, telle que le nombre estimé de requêtes SIP REGISTER susceptibles d'être reçues par ladite entité CSCF pendant cette plage de temps, soit inférieur ou égal à la valeur moyenne du nombre de requêtes SIP REGISTER reçues pendant la phase d'observation.
Le nombre de requêtes SIP REGISTER reçues par seconde est souvent connu sous l'acronyme anglais RAPS (REGISTER ATTEMPTS PER SECOND).
L'invention vise aussi une brique de service dans un réseau de signalisation SIP comportant :
- des moyens d'observation aptes à comptabiliser, le nombre de requêtes SIP SUBSCRIBE reçues par seconde pendant une phase d'observation ;
- des moyens pour recevoir une requête courante SIP SUBSCRIBE en provenance d'un terminal ; et
- des moyens pour envoyer à ce terminal, en réponse à cette requête courante, un message d'acquittement comportant une période choisie pour que la prochaine requête SIP SUBSCRIBE émise par ce terminal, soit émise pendant une plage de temps telle que le nombre estimé de requêtes SIP SUBSCRIBE susceptibles d'être reçues par cette brique de service pendant cette plage de temps, est inférieur ou égal à la valeur moyenne du nombre requêtes SIP SUBSCRIBE reçues pendant la phase d'observation.
Le nombre de requêtes SIP SUBSCRIBER reçues par seconde est souvent connu sous l'acronyme anglais SAPS (SUBSCRIBE ATTEMPTS PER SECOND).
Ces procédés de lissage ou de rééquilibrage des requêtes SIP REGISTER ou SIP SUBSCRIBE peuvent être mis en œuvre à tout moment pour éviter une dérive dans le réseau. Ils peuvent en particulier être mis en œuvre en fin de matinée pour lisser le trafic de signalisation induit par la mise sous tension des terminaux en tout début de matinée. L'invention propose aussi des solutions pour revenir rapidement à un état satisfaisant en sortie de panne.
A cet effet, l'invention concerne un procédé d'acquittement mis en œuvre par une entité et comportant :
- une étape de démarrage d'une phase d'observation d'une durée égale à une période de temps nominale définie par cette entité pour des requêtes d'un type prioritaire ;
- une étape de calcul du nombre courant de requêtes de ce type prioritaire reçues par cette entité au cours d'une durée déterminée précédant la réception d'une requête courante.
La période envoyée au terminal émetteur de cette requête étant :
- une première valeur, supérieure à la valeur nominale, si la requête courante n'est pas de type prioritaire ;
- une deuxième valeur, supérieure à la première valeur, si la requête courante est de type prioritaire, le nombre courant de requêtes de type prioritaire étant inférieur ou égal à un nombre maximum de requêtes de type prioritaire pouvant être traitées par l'entité pendant cette durée déterminée ; et
- la valeur nominale, si la requête courante est une requête de type prioritaire, le nombre courant de requêtes de type prioritaire étant supérieur à ce nombre maximum.
Ce procédé peut par exemple être mis en œuvre par une entité CSCF en sortie de panne d'un équipement du réseau cœur, pour privilégier le traitement des requêtes SIP REGISTER au détriment des requêtes SIP SUBSCRIBE.
Par conséquent, l'invention concerne une entité de type CSCF comportant :
- des moyens pour démarrer une phase d'observation, d'une durée égale à une période de temps nominale, définie par le CSCF, pour les requêtes SIP REGISTER ;
- la période envoyée à un terminal en réponse à une requête SIP SUBSCRIBE ou SIP REGISTER étant :
- une première valeur, supérieure à la valeur nominale, si la requête courante est une requête SIP SUBSCRIBE ;
- une deuxième valeur, supérieure à la première valeur, si la requête courante est une requête SIP REGISTER, le nombre RAPS de requêtes SIP REGISTER reçues par l'entité CSCF, pendant la seconde précédent la réception de la requête courante étant inférieur ou égal au nombre maximum de requêtes SIP REGISTER pouvant être traitées par cette entité CSCF en une seconde ; et - la valeur nominale, si la requête courante est une requête SIP
REGISTER, le nombre RAPS de requêtes SIP REGISTER reçues par cette entité CSCF, pendant la seconde précédent la réception de la requête courante étant supérieur au nombre maximum de requêtes SIP REGISTER pouvant être traitées par cette entité CSCF en une seconde.
Les première et deuxième valeurs peuvent être choisies de façon empirique. Elles peuvent en particulier être respectivement égales à deux et à trois fois la période nominale.
Une autre solution selon l'invention pour gérer une sortie de panne consiste à repousser les requêtes des terminaux déjà enregistrés auprès d'une entité, dans une plage de temps suffisamment lointaine pour permettre aux autres terminaux gérés par cette entité, mais non encore enregistrés, de s'enregistrer eux-mêmes.
Par conséquent, l'invention vise un procédé d'acquittement pouvant être mis en œuvre par une entité dans un réseau de télécommunications et comportant :
- une étape de calcul, en fonction d'un nombre maximum de requêtes d'un type prioritaire pouvant être traité par cette entité pendant une durée déterminée, d'une durée minimum pour traiter les premières requêtes dudit type prioritaire susceptibles d'être reçues en provenance de terminaux gérés par cette entité mais non enregistrés dans le réseau;
- une étape de calcul du nombre courant de requêtes du type prioritaire reçues par cette entité au cours d'une durée déterminée précédant la réception d'une requête courante, la période envoyée au terminal dans le message d'acquittement à cette requête étant :
- une valeur nominale, si ce nombre courant est inférieur au nombre maximum précité ; et
- la durée minimum, si ce nombre courant est supérieur audit nombre maximum.
Ce procédé peut par exemple être mis en œuvre par une entité
CSCF en sortie de panne d'un équipement du réseau cœur, pour retarder le trafic de signalisation des requêtes SIP REGISTER et SIP SUBSCRIBE des terminaux gérés par le CSCF et non encore enregistrés dans le réseau.
Par conséquent, l'invention concerne une entité de type CSCF comportant :
- des moyens de calcul, en fonction du nombre maximum de requêtes SIP REGISTER pouvant être traitées par cette entité CSCF par seconde, d'une durée minimum pour traiter les premières requêtes SIP REGISTER susceptibles d'être reçues en provenance de terminaux gérés par cette CSCF mais non enregistrés dans le réseau ;
- des moyens de calcul du nombre courant RAPS de requêtes SIP REGISTER reçues par l'entité CSCF au cours de la seconde précédent la réception de la requête courante ;
- la période envoyée au terminal dans message d'acquittement à cette requête étant :
- une valeur nominale, si le nombre courant RAPS est inférieur au nombre maximum précité ; et
- la durée minimum, si ledit nombre courant RAPS est supérieur à ce nombre maximum.
Dans un mode particulier de réalisation, les différentes étapes du procédé d'acquittement sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans une entité CSCF, une brique de service, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes du procédé d'acquittement tel que mentionné ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
- la figure 1, déjà décrite, représente une procédure d'enregistrement d'un terminal dans un réseau IMS, cette procédure connue de l'état de la technique ;
- la figure 2, déjà décrite, représente une procédure de souscription d'un terminal à une brique de service dans un réseau IMS, cette procédure étant connue de l'état de la technique ;
- la figure 3 représente de façon schématique une entité CSCF conforme à l'invention dans un mode particulier de réalisation ;
- la figure 4 représente de façon schématique une brique de service conforme à l'invention dans un mode particulier de réalisation ;
- la figure 5 représente un trafic de signalisation pouvant être observé dans un réseau IMS dans l'état actuel de la technique ; - les figures 6A et 6B représentent, sous forme d'organigramme, les principales étapes d'un procédé d'acquittement pouvant être mis en œuvre par l'entité CSCF de la figure 3 ;
- la figure 7 représente l'effet du procédé d'acquittement de la figure 6 sur le trafic de signalisation de la figure 5;
- les figures 8A et 8B représentent, sous forme d'organigramme, les principales étapes d'un procédé d'acquittement pouvant être mis en œuvre par la brique de service de la figure 4 ;
- les figures 9 et 10 représentent, sous forme d'organigramme, les principales étapes d'un procédé d'acquittement conforme à l'invention, pouvant être mis en œuvre par l'entité CSCF de la figure 3 en sortie d'une panne ; et
- la figure 11 représente, sous forme d'organigramme, les principales étapes d'une variante de ce procédé.
Description détaillée de plusieurs modes de réalisation de l'invention
La figure 3 représente une entité CSCF conforme à un mode particulier de réalisation de l'invention.
Dans l'exemple de réalisation décrit ici, l'entité CSCF a l'architecture matérielle d'un ordinateur. Elle comporte notamment un processeur 11, une mémoire vive de type RAM 12, une mémoire morte de type ROM 13, des moyens de communication 14 et une mémoire non volatile réinscriptible de type FLASH 15.
La mémoire morte 13 constitue un support d'enregistrement conforme à l'invention sur lequel sont enregistrés trois programmes d'ordinateurs PGl, PG3 et PG4 qui seront décrits ultérieurement en référence aux figures 6, 8 et 9.
La mémoire morte 13 comporte en outre un registre RAPS_MAX qui mémorise le nombre maximum de requêtes REGISTER pouvant être traitées par l'entité CSCF par seconde.
La mémoire vive 12 comporte des registres permettant l'exécution des programmes PGl, PG3 et PG4 par le processeur 11.
Elle comporte en particulier :
- un registre RAPS pour mémoriser le nombre de requêtes
REGISTER reçues au cours de la dernière seconde ; et - un registre TMIN qui sera décrit ultérieurement en référence à la figure 11.
La mémoire non volatile réinscriptible 15 comporte, dans un mode de réalisation particulier, deux registres NB_TOT et NB_REG qui seront eux aussi décrits en référence à la figure 11.
La figure 4 représente une brique de service BS conforme à l'invention, dans un mode particulier de réalisation.
Cette brique de service BS comporte un processeur 21, une mémoire vive de type RAM 22, une mémoire morte de type ROM 23 et des moyens de communication 24.
La mémoire morte 23 constitue un support d'enregistrement conforme à l'invention sur lequel est enregistré un programme d'ordinateur PG2 dont les principales étapes seront décrites en référence à la figure 8.
La mémoire morte 23 comporte également un registre SAPS_MAX comportant le nombre maximum de requêtes SUBSCRIBE pouvant être traitées par la brique de service BS en une seconde.
La mémoire vive 22 comporte des registres permettant l'exécution du programme PG2 par le processeur 21. Elle comporte notamment un registre SAPS comportant le nombre de requêtes de souscription SUBSCRIBE reçues par la brique BS au cours de la dernière seconde.
En référence aux figures 5 à 7, nous allons maintenant décrire comment une entité CSCF conforme à l'invention peut mettre en œuvre un procédé d'acquittement conforme à l'invention pour lisser le trafic de signalisation associé aux requêtes REGISTER émises par les terminaux UA gérés par cette entité.
Dans ce premier mode de réalisation, l'entité CSCF observe, pendant une étape ElO, le trafic de signalisation précité.
En référence à la figure 5, nous supposerons que cette phase d'observation a une durée de 10s, comptée entre les instants Os et 10s.
Au cours de cette phase d'observation, l'entité CSCF comptabilise, pour chaque tranche d'une seconde, le nombre RAPS de requêtes REGISTER reçues par l'entité CSCF.
Ces valeurs sont reportées dans le diagramme de la figure 5. Puis, au cours d'une étape E20, l'entité CSCF calcule la valeur moyenne RAPS_AVG du nombre de requêtes REGISTER reçues par seconde pendant toute la phase d'observation.
Dans l'exemple décrit ici, ce nombre moyen RAPS_AVG est égal à 101.
Nous supposerons, dans cet exemple, que la durée de 10s de la phase d'observation correspond à une période fixe EXPIRES de 20s, qui serait envoyée par l'entité CSCF, dans les messages d'acquittement aux requêtes REGISTER si l'invention n'était pas mise en œuvre.
Si tel était le cas, et si, aucun autre terminal ne s'enregistrait auprès de l'entité CSCF, le trafic de signalisation, pour les plages de temps futures suivant la phase d'observation, serait parfaitement prédictible, en supposant encore qu'aucun terminal ne se dés-enregistre.
Plus précisément, et comme représenté à la figure 5, le trafic se répéterait à l'identique, pour chaque période de 10s.
Dans l'exemple de réalisation décrit ici, le procédé d'équipement selon l'invention comporte une étape E30 au cours de laquelle l'entité CSCF estime le futur trafic à venir en faisant les hypothèses explicitées ci- dessus (aucun nouvel enregistrement, aucun dés-enregistrement).
Par conséquent, et à titre d'exemple, l'entité CSCF estime que le nombre RAPS de requêtes REGISTER reçues entre la quinzième et la seizième seconde est le même que le nombre reçu entre la cinquième et la sixième seconde, à savoir 130.
Le but du procédé d'acquittement décrit ici est de lisser le trafic des requêtes de signalisation REGISTER à l'issue de la phase d'observation, le résultat de ce procédé étant illustré à la figure 7.
Au cours d'une étape E35, l'entité CSCF initialise un chronomètre P à 0, ce chronomètre P étant utilisé pour mesurer la durée de la période d'observation.
Au cours d'une étape E40, l'entité CSCF initialise un chronomètre T à 0, ce chronomètre T étant utiliser pour mesurer la durée d'une seconde, et initialise une valeur RAPS mémorisée dans la mémoire vive 12, à la valeur zéro.
L'étape E40 est suivie par une étape E50 au cours de laquelle l'entité CSCF vérifie si elle a ou non reçu une requête de type REGISTER. Si tel n'est pas le cas, le test E50 est suivi par un test E60 au cours duquel l'entité CSCF vérifie si plus d'une seconde s'est écoulée depuis le déclenchement du chronomètre T.
Si tel est le cas, le résultat du test E60 est positif. Le chronomètre P est alors incrémenté d'une unité (étape E65). Puis au cours d'un test E67, on détermine si la période d'observation s'est écoulée. Si tel est le cas le procédé se termine. Sinon, il reboucle à l'étape E40 pour réinitialisation du chronomètre T et du registre RAPS.
Lorsque l'entité CSCF reçoit une requête REGISTER, le résultat de test E50 est positif. Ce test est alors suivi par une étape E70 au cours de laquelle la variable RAPS est incrémentée d'une unité.
Par conséquent, le registre RAPS comporte, en permanence, le nombre de requêtes REGISTER reçues dans la seconde courante.
L'étape E70 est suivie par une étape E80 au cours de laquelle l'entité CSCF vérifie si le nombre RAPS de requêtes REGISTER reçues au cours de la dernière seconde est inférieur ou égal au nombre moyen RAPS_AVG de requêtes REGISTER calculé à l'étape E20.
Si tel est le cas, le résultat du test E80 est positif, et l'entité CSCF fixe le paramètre EXPIRES à la période nominale, à savoir 20s dans cet exemple (étape E90).
En revanche, s'il est déterminé, au cours du test E80, que le nombre RAPS de requêtes REGISTER reçues au cours de la dernière seconde dépasse la valeur maximum RAPS_MAX, alors l'entité CSCF fixe, au cours d'une étape générale ElOO, le paramètre EXPIRES en prenant en compte l'estimation effectuée à l'étape E30.
Cette étape générale va maintenant être décrite en référence à la figure 6B.
Dans l'exemple de réalisation décrit ici, on utilise un tableau E[i] initialisé, pour chaque seconde i de la phase d'observation, avec le nombre de REGISTER observés pendant la ieme seconde de la phase d'observation.
Au cours d'une étape KlO, on initialisé à 0, une variable I, et on recherche, dans le tableau E[I], par une boucle K20, K30, K40, le premier « creux » de la période d'observation par rapport à la valeur moyenne RAPS_AVG calculée à l'étape E20. Lorsqu'un tel creux est identifié, le résultat du test K20 est positif, et on comble ce creux d'une unité, au cours d'une étape K50.
On calcule ensuite, au cours d'une étape K60, la valeur EXPIRES qui doit être renvoyée au terminal UA, en tenant compte de la position I du creux et de l'emplacement temporel P du REGISTER en cours de traitement. Ce calcul doit prendre en compte le traitement interne du paramètre EXPIRES par le terminal UA. En l'espèce, dans l'exemple de réalisation décrit ici, le CSCF fixe le paramètre EXPIRES à:
- EXPIRES NOMINAL + (I-P) si EXPIRES NOMINAL est strictement supérieur à 1200 ; et
- EXPIRES NOMINAL + 2.(1-P) si EXPIRES NOMINAL est inférieur ou égal à 1200.
L'étape K60 termine l'étape générale ElOO.
Un message d'acquittement est envoyé au terminal UA concerné, au cours d'une étape EIlO, avec le paramètre EXPIRES calculé à l'étape E90 ou ElOO. Ce procédé d'acquittement permet de lisser les requêtes REGISTER émises par les terminaux UA gérés par l'entité CSCF.
Ce procédé permet très avantageusement de lisser le trafic de signalisation associé aux requêtes REGISTER émises par les terminaux UA gérés par l'entité CSCF.
Un procédé similaire dont les principales étapes sont représentées aux figures 8A et 8B, peut être mis en œuvre par la brique de service BS, pour lisser les requêtes de souscription SUBSCRIBE émises par les terminaux accédant aux services offerts par cette brique.
Ce procédé se déroule exactement de la même façon que le procédé d'acquittement décrit précédemment en référence aux figures 6A et 6B.
Ainsi, et en résumé, la brique de service BS comptabilise (étape FlO), pour chaque seconde d'une phase d'observation, le nombre SAPS de requêtes SUBSCRIBE reçues par cette brique BS.
Puis, la moyenne SAPS_AVG de ces nombres est calculée au cours d'une étape F20.
Au cours d'une étape F30, la brique de service BS estime que le nombre de requêtes susceptibles d'être reçues par la brique de service BS après la phase d'observation reproduit exactement celle de la phase d'observation. Puis, sur réception (étape F50) d'une requête SUBSCRIBE, la brique de service fixe :
- une période EXPIRES nominale à l'étape F90 si le nombre de requêtes de souscription SAPS reçues au cours de la dernière seconde est inférieur ou égal au nombre moyen SAPS_AVG de requêtes SUBSCRIBE calculé à l'étape F20;
- une période EXPIRES ajustée calculée au cours d'une étape générale FlOO et dont le détail, représenté à la figure 8B, comporte des étapes LlO à L60, similaires aux étapes KlO à K60 décrites en référence à la figure 6A.
Un message d'acquittement est envoyé au terminal UA concerné, au cours d'une étape FIlO, avec le paramètre EXPIRES calculé à l'étape
F90 ou FlOO. Ce procédé d'acquittement permet de lisser les requêtes de souscription SUBSCRIBE émises par les terminaux UA accédant à un service offert par la brique de service BS.
Les étapes F35, F40, F60, F65, F67, F70 et F80 sont similaires aux étapes E35, E40, E60, E65, E67, E70 et E80 et ne seront pas décrites ici.
En référence aux figures 9 et 10, nous allons maintenant décrire un procédé pouvant être mis en œuvre par une entité CSCF après réparation d'une panne touchant un élément central du cœur d'un réseau IMS.
Dans le mode de réalisation décrit ici, ce procédé comporte une étape GlO de démarrage d'une phase d'observation d'une durée P correspondant à une période nominale fixée par l'entité CSCF pour acquitter les requêtes REGISTER reçues par cette entité.
Nous supposerons que l'entité CSCF reçoit, au cours d'une étape G20, une requête courante RC, cette requête pouvant être du type REGISTER ou SUBSCRIBE.
Au cours d'une étape G25, l'entité CSCF calcule le nombre courant RAPS de requêtes REGISTER reçues par l'entité CSCF au cours de la dernière seconde.
Puis, au cours d'une étape G30, l'entité CSCF détermine si la requête courante RC est une requête SUBSCRIBE ou une requête REGISTER. Si la requête courante est une requête SUBSCRIBE, l'entité CSCF fixe (étape G40) le paramètre EXPIRES à une première valeur, choisie dans cet exemple comme étant égale au double de la période nominale P.
L'entité CSCF envoie alors au terminal UA à l'origine de cette requête SUBSCRIBE, un message de rejet 503 Service Unavailable comportant la valeur Retry After = 2P (étape G45).
S'il est déterminé, au cours de l'étape G30, que la requête courante est une requête REGISTER, l'entité CSCF détermine, au cours d'une étape
G50, si le nombre RAPS de requêtes REGISTER courantes reçues au cours de la dernière seconde est inférieur ou non au nombre maximum
RAPS_MAX de requêtes REGISTER pouvant être traitées par cette entité.
Si tel est le cas, l'entité CSCF fixe (étape G60) le paramètre EXPIRES à une deuxième valeur, supérieure à la première valeur, et égale, dans cet exemple à trois fois la période nominale 3P.
L'entité CSCF envoie alors au terminal UA à l'origine de cette requête REGISTER, un message d'acquittement 200 OK comportant la valeur EXPIRES=3P (étape G65).
S'il est déterminé, au cours du test G50, que le nombre RAPS de requêtes REGISTER reçues au cours de la dernière seconde est supérieur au nombre maximum RAPS_MAX, l'entité CSCF fixe le paramètre EXPIRES à la valeur nominale P (étape G70).
L'entité CSCF envoie alors (étape G75) au terminal UA à l'origine de cette requête REGISTER, un message d'acquittement du type 503 Service Unavailable comportant la valeur P dans le champ Retry After.
La figure 10 illustre l'évolution du trafic de signalisation dans le réseau par la mise en œuvre du procédé décrit précédemment en référence à la figure 9.
La partie haute de ce diagramme représente le traitement des requêtes REGISTER, et la partie basse le traitement des requêtes SUBSCRIBE.
Il apparaît sur ces diagrammes que les requêtes SUBSCRIBE reçues pendant la première période nominale (entre les instants 0 et P), sont rejetées avec un paramètre EXPIRES=2P, de sorte qu'elles sont réémises ultérieurement entre les instants 2P et 3P.
Les RAPS_MAX premières requêtes REGISTER sont acquittées
(message 200 OK) avec un paramètre 3P, si bien que les prochaines requêtes REGISTER émises par les terminaux concernés sont émises entre les instants 3P et 4P.
Les requêtes REGISTER reçues après la RAPS_MAXlème requête sont rejetées (message 503) avec un paramètre EXPIRES=P dans le champ Retry After, si bien que les terminaux réémettent une requête REGISTER dans la plage P, 2P.
Dans l'exemple de la figure 10, la phase d'observation s'arrête après la période 3P. On revient alors à une situation normale, les requêtes REGISTER étant acquittées avec le paramètre P et les requêtes de souscription étant acceptées par un message 200 OK après application du procédé d'acquittement tel que décrit aux figures 5 à 8 pour lisser le trafic dans le réseau IMS.
En référence à la figure 11, nous allons maintenant décrire une variante de ce procédé.
Dans ce mode de réalisation, l'entité CSCF utilise trois paramètres
NB_TOT, NB_REG et RENG, mémorisés dans la mémoire 15 de type flash, à savoir :
- NB_TOT : nombre total de terminaux UA gérés par l'entité CSCF ;
- NB_REG : nombre de terminaux UA enregistrés, à un instant donné, dans cette entité ;
- REG_ENG : nombre de requêtes REGISTER par seconde émises par les terminaux déjà enregistrés. Ce nombre peut être obtenu par NB_REG/P_DEF, où P_DEF est la période par défaut de la requête REGISTER.
Selon ces définitions :
- (NBJTOT - NB_REG) représente le nombre de terminaux restant à enregistrer ; et
- (RAPS_MAX - REG_ENG) représente le nombre de requêtes maximum pouvant être traitées par seconde, ce nombre tenant compte des terminaux déjà enregistrés qui essaieront de se réenregistrer.
Ce procédé comporte une étape HlO, typiquement mise en œuvre en sortie de panne, pour calculer la durée TMIN minimum nécessaire à l'entité CSCF pour traiter les premières requêtes REGISTER qui seraient émises par tous les terminaux UA gérés par l'entité CSCF, mais non déjà enregistrés.
Cette valeur peut être calculée par la formule suivante : TMIN = (NBJOT - NB_REG) / (RAPS_MAX- REG_ENG).
Lorsque l'entité CSCF reçoit une requête courante RC (de type SUBSCRIBE ou REGISTER), à l'étape H20, elle calcule, à l'étape H25, le nombre RAPS de requêtes REGISTER reçues depuis la dernière seconde ou durant un laps de temps défini dans la configuration du système.
Puis, au cours d'une étape H28, l'entité CSCF détermine si ce nombre RAPS est inférieur ou égal ou non au nombre maximum RAPS_MAX de requêtes REGISTER pouvant être traitées par seconde par l'entité CSCF.
Si tel est le cas, l'entité CSCF fixe le paramètre EXPIRES à la valeur nominale P (étape H30), et envoie (étape H35) un message d'acquittement positif (200 OK) avec ce paramètre au terminal UA émetteur de la requête courante RC.
Au contraire, s'il est déterminé, à l'étape H28, que le nombre RAPS_MAX a déjà été atteint, l'entité CSCF fixe la valeur EXPIRES à la valeur TMIN (étape H40), et envoie (étape H45) un message de rejet 503 Service Unavailable avec Retry After = TMIN (étape H45) au terminal UA.
Les procédés d'acquittement décrits aux figures 9 à 11 permettent de faire retomber le trafic très rapidement en sortie d'une panne.
Ils peuvent bien entendu être suivis par un procédé d'acquittement tel que décrit aux figures 5 à 8 pour lisser le trafic dans le réseau IMS.
Dans la description qui vient d'être faite, on a considéré le cas où le terminal UA accédait directement à l'entité CSCF du réseau IMS.
Bien entendu, l'invention s'applique également lorsque le terminal UA accède à l'entité CSCF via un équipement intermédiaire, par exemple un équipement SBC (Session Border Contrôler), un tel équipement permettant la mise en place d'un mécanisme dit "de Registration Caching", de sorte que des périodes d'enregistrement différentes peuvent être utilisées au niveau du réseau d'accès et au niveau du réseau cœur. Dans ce cas, le mécanisme de l'invention est mis en œuvre de façon répartie au niveau du CSCF et du SBC, pour prendre en compte les valeurs EXPIRES fixées par le CSCF.

Claims

REVENDICATIONS
1. Procédé pouvant être mis en œuvre dans une entité (CSCF, BS) d'un réseau de télécommunications, pour acquitter une requête d'un type (REGISTER, SUBSCRIBE) déterminé émise par un terminal (UA) et reçue par ladite entité (CSCF, BS), une requête du même type étant susceptible d'être réémise par ledit terminal (UA) après une période de temps
(EXPIRES) définie par ladite entité (CSCF, BS) et envoyée audit terminal
(UA) dans un message d'acquittement (200, 503) à ladite requête, ce procédé comportant :
- une étape (E50, F50, G20, H20) de réception d'une requête (RC) dudit type, dite requête courante ;
- une étape (E30, F30, G40, G60, G70, HlO) d'estimation, pour au moins plage de temps future du nombre de requêtes dudit type susceptibles d'être reçues par ladite entité (CSCF, BS) pendant cette plage de temps future ; et
- une étape de sélection d'une plage de temps future parmi ladite au moins une plage de temps future ; et
- une étape (EIlO, FIlO, H35, H45, G45, G65, G75) d'envoi, au terminal émetteur de ladite requête courante (RC), d'un message d'acquittement
(200, 503) comportant une période (EXPIRES) choisie pour que la prochaine requête dudit type, émise par ledit terminal, soit émise pendant ladite plage future sélectionnée.
2. Procédé d'acquittement selon la revendication 1, caractérisé en ce qu'il comporte en outre :
- une étape (ElO, FlO) d'observation, consistant à comptabiliser, pour chaque tranche de temps (TlS) d'une phase d'observation, le nombre de requêtes (RAPS, SAPS) dudit type reçues par ladite entité pendant ladite tranche de temps ;
ladite étape d'estimation (EIlO, FIlO) du nombre de requêtes dudit type susceptibles d'être reçues par ladite entité pendant une plage de temps future étant faite à partir de ladite observation.
3. Procédé d'acquittement selon la revendication 2, caractérisé en ce que ladite étape de sélection consiste à sélectionner une plage de temps future pour laquelle le nombre de requêtes (RAPS, SAPS) est inférieur ou égal à une valeur moyenne (RAPS_AVG, SAPS_AVG) calculée sur toute ladite phase d'observation.
4. Procédé d'acquittement selon la revendication 1, caractérisé en ce qu'il comporte :
- une étape (GlO) de démarrage d'une phase d'observation, d'une durée égale à une période (P) de temps nominale, définie par ladite entité, pour lesdites requêtes d'un type prioritaire (REGISTER) ;
- une étape (G25) de calcul du nombre courant (RAPS) de requêtes du type prioritaire reçues par ladite entité (CSCF) au cours d'une durée déterminée (TlS) précédent la réception de ladite requête courante (RC) ;
- la période envoyée au terminal (UA) dans ledit message d'acquittement étant :
- une première valeur (2P), supérieure à ladite valeur nominale (P), si ladite requête courante (RC) n'est pas du type prioritaire ;
- une deuxième valeur (3P), supérieure à ladite première valeur (2P), si ladite requête courante (RC) est de type prioritaire, ledit nombre courant (RAPS) étant inférieur ou égal à un nombre maximum (RAPS_MAX) de requêtes dudit type prioritaire
(REGISTER) pouvant être traitées par ladite entité (CSCF) pendant ladite durée déterminée (TlS) ; et
- ladite valeur nominale (P), si ladite requête courante (RC) est une requête du type prioritaire, ledit nombre courant (RAPS) étant supérieur audit nombre maximum (RAPS_MAX).
5. Procédé d'acquittement selon la revendication 1, caractérisé en ce qu'il comporte :
- une étape (HlO) de calcul, en fonction d'un nombre maximum (RAPS_MAX) de requêtes d'un type prioritaire (REGISTER) pouvant être traité par ladite entité (CSCF) pendant une durée déterminée (TlS), d'une durée (TMIN) minimum pour traiter les premières requêtes dudit type prioritaire (REGISTER) susceptibles d'être reçues en provenance de terminaux (UA) gérés par ladite entité, mais non enregistrés dans le réseau ; - une étape (H25) de calcul du nombre courant (RAPS) de requêtes du type prioritaire (REG) reçues par ladite entité (CSCF) au cours d'une durée déterminée (TlS) précédent la réception de ladite requête courante (RC) ;
- la période envoyée au terminal (UA) dans ledit message d'acquittement étant :
- une valeur nominale (P), si ledit nombre courant (RAPS) est inférieur ou égal audit nombre maximum (RAPS_MAX) ; et
- ladite durée minimum (TMIN), si ledit nombre courant (RAPS) est supérieur audit nombre maximum (RAPS_MAX).
6. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé d'acquittement selon l'une quelconque des revendications 1 à 5 lorsque ledit programme est exécuté par un ordinateur.
7. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'acquittement selon l'une quelconque des revendications 1 à 5.
8. Entité (CSCF, BS) d'un réseau de télécommunications, comportant :
- des moyens (14, 24) de réception d'une requête (RC) d'un type déterminé (REGISTER, SUBSCRIBE) émise par un terminal (UA), dite requête courante, ladite requête étant susceptible d'être réémise par ledit terminal (UA) après une période de temps (EXPIRES) définie par ladite entité et envoyée audit terminal dans un message d'acquittement à ladite requête (RC) ;
- des moyens (11, 21) d'estimation, pour au moins plage de temps future du nombre de requêtes dudit type susceptibles d'être reçues par ladite entité pendant cette plage de temps future ; et
- des moyens (11, 21) de sélection plage de temps future parmi ladite au moins une plage de temps future (pf); et
- des moyens (14, 24) d'envoi, audit terminal (UA), d'un message d'acquittement (200, 503) comportant une période (EXPIRES) choisie pour que la prochaine requête dudit type, émise par ledit terminal (UA), soit émise pendant ladite plage future sélectionnée.
9. Entité selon la revendication 8, caractérisée en ce qu'elle est une entité de type CSCF et en ce qu'elle comporte :
- des moyens (11) d'observation aptes à comptabiliser, le nombre (RAPS) de requêtes SIP REGISTER reçues par seconde pendant une phase d'observation; et
- des moyens (14) pour recevoir une requête courante SIP REGISTER en provenance d'un terminal (UA) ; et
- des moyens (14) pour envoyer audit terminal, en réponse à ladite requête courante, un message d'acquittement (200, 503) comportant une période (EXPIRES) choisie pour que la prochaine requête SIP REGISTER émise par ledit terminal, soit émise pendant une plage de temps, telle que le nombre estimé de requêtes SIP REGISTER susceptibles d'être reçues par ladite entité CSCF pendant cette plage de temps, est inférieur ou égal à une valeur moyenne (RAPS_AVG) du nombre des requêtes SIP REGISTER reçues pendant la phase d'observation.
10. Entité selon la revendication 8, caractérisée en ce qu'elle est une brique de service (BS) dans un réseau de signalisation SIP et en ce qu'elle comporte :
- des moyens (21) d'observation aptes à comptabiliser, le nombre (SAPS) de requêtes SIP SUBSCRIBE reçues par seconde pendant une phase d'observation ;
- des moyens (24) pour recevoir une requête courante SIP SUBSCRIBE en provenance d'un terminal (UA) ; et
- des moyens (24) pour envoyer audit terminal, en réponse à ladite requête courante, un message d'acquittement comportant une période choisie pour que la prochaine requête SIP SUBSCRIBE émise par ledit terminal, soit émise pendant une plage de temps, telle que le nombre estimé de requêtes SIP SUBSCRIBE susceptibles d'être reçues par ladite brique de service pendant cette plage de temps, est inférieur ou égal à une valeur moyenne (SAPS_AVG) du nombre des requêtes SIP SUBSCRIBE reçues pendant la phase d'observation.
11. Entité selon la revendication 8, caractérisée en ce qu'elle est une entité de type CSCF et en ce qu'elle comporte :
- des moyens (11) pour démarrer une phase d'observation, d'une durée égale à une période (P) de temps nominale, définie par ladite entité CSCF, pour les requêtes SIP REGISTER ;
- la période envoyée au terminal dans ledit message d'acquittement étant :
- une première valeur (2P), supérieure à ladite valeur nominale (P), si la requête courante (RC) est une requête SIP SUBSCRIBE ;
- une deuxième valeur (3P), supérieure à ladite première valeur
(2P), si la requête courante (RC) est une requête SIP REGISTER, le nombre (RAPS) de requêtes SIP REGISTER reçues par ladite entité CSCF, pendant la seconde précédent la réception de ladite requête courante (RC) étant inférieur ou égal au nombre maximum (RAPS_MAX) de requêtes SIP REGISTER pouvant être traitées par ladite entité CSCF en une seconde ; et
- la valeur nominale (P), si ladite requête courante (RC) est une requête SIP REGISTER, le nombre (RAPS) de requêtes SIP REGISTER reçues par ladite entité CSCF, pendant la seconde précédent la réception de ladite requête courante (RC) étant supérieur au nombre maximum (RAPS_MAX) de requêtes SIP REGISTER pouvant être traitées par ladite entité CSCF en une seconde.
12. Entité selon la revendication 11, caractérisée en ce que ladite première valeur (2P) est égale à deux fois la période nominale, et ladite troisième valeur est égale à trois fois la période nominale.
13. Entité selon la revendication 8, caractérisée en ce qu'elle est une entité de type CSCF et en ce qu'elle comporte :
- des moyens (11) de calcul, en fonction du nombre maximum (RAPS_MAX) de requêtes SIP REGISTER pouvant être traitées par ladite entité CSCF par seconde, d'une durée (TMIN) minimum pour traiter les premières requêtes SIP REGISTER susceptibles d'être reçues en provenance des terminaux (UA) gérés par l'entité CSCF mais non enregistrés dans le réseau ; - des moyens (11) de calcul du nombre courant (RAPS) de requêtes SIP REGISTER reçues par l'entité (CSCF) au cours de la seconde précédent la réception de la requête courante (RC) ;
- la période envoyée au terminal (UA) dans ledit message d'acquittement étant :
- une valeur nominale (P), si ledit nombre courant (RAPS) est inférieur ou égal audit nombre maximum (RAPS_MAX) ; et
- ladite durée minimum (TMIN), si ledit nombre courant (RAPS) est supérieur audit nombre maximum (RAPS_MAX).
PCT/FR2010/051302 2009-06-30 2010-06-25 Procédé et dispositif d'acquittement d'une requête de signalisation périodique dans un réseau de télécommunications WO2011001075A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP10745323A EP2449747A1 (fr) 2009-06-30 2010-06-25 Procédé et dispositif d'acquittement d'une requête de signalisation périodique dans un réseau de télécommunications
US13/381,546 US20120106335A1 (en) 2009-06-30 2010-06-25 Method and device for acknowledging a periodic signaling request in a telecommunication network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0954447 2009-06-30
FR0954447 2009-06-30

Publications (1)

Publication Number Publication Date
WO2011001075A1 true WO2011001075A1 (fr) 2011-01-06

Family

ID=41664563

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2010/051302 WO2011001075A1 (fr) 2009-06-30 2010-06-25 Procédé et dispositif d'acquittement d'une requête de signalisation périodique dans un réseau de télécommunications

Country Status (3)

Country Link
US (1) US20120106335A1 (fr)
EP (1) EP2449747A1 (fr)
WO (1) WO2011001075A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013037251A1 (fr) * 2011-09-16 2013-03-21 中兴通讯股份有限公司 Procédé et système d'authentification d'équipement d'utilisateur d'un réseau ils intégré à un réseau ims

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080108348A1 (en) * 2006-11-07 2008-05-08 Sudeep Ravi Kottilingal Registration timer adjustment based on wireless network quality

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3602972B2 (ja) * 1998-07-28 2004-12-15 富士通株式会社 通信性能測定装置及びその測定方法
US7113986B2 (en) * 2000-07-14 2006-09-26 Business Signatures Corporation System and method for modeling information system capacity and accepting sessions in an information system
US7434258B2 (en) * 2002-05-07 2008-10-07 Nokia Corporation Method and communication system for controlling security association lifetime
JP4438510B2 (ja) * 2004-05-25 2010-03-24 株式会社日立製作所 通信システム及び通信制御装置
US7502615B2 (en) * 2004-07-16 2009-03-10 Bridgeport Networks, Inc. Handoff for cellular and internet protocol telephony
US7929419B2 (en) * 2006-08-04 2011-04-19 Tekelec Methods, systems, and computer program products for inhibiting message traffic to an unavailable terminating SIP server
US7693526B2 (en) * 2006-08-16 2010-04-06 Cisco Technology, Inc. Enhanced load based wireless call admission control
US8064342B2 (en) * 2006-10-27 2011-11-22 Verizon Patent And Licensing Inc. Load balancing session initiation protocol (SIP) servers
EP2100473B1 (fr) * 2006-12-05 2019-10-16 Telefonaktiebolaget LM Ericsson (publ) Procédés pour commander une commutation de domaine d'accès, noeuds de réseau, terminal utilisateur et produit de programme informatique apparenté
EP2119177B1 (fr) * 2006-12-19 2012-07-25 Telefonaktiebolaget LM Ericsson (publ) Technique pour fournir des services dans un réseau IMS
US7826390B2 (en) * 2008-01-15 2010-11-02 At&T Intellectual Property I, L.P. Method and apparatus for providing a distributed subscriber load distribution
JP4915622B2 (ja) * 2008-03-31 2012-04-11 Ｋｄｄｉ株式会社 サーバ輻輳制御方法およびシステム
US8806630B2 (en) * 2008-05-13 2014-08-12 At&T Intellectual Property, I, L.P. Methods and apparatus for intrusion protection in systems that monitor for improper network usage
WO2009155978A1 (fr) * 2008-06-25 2009-12-30 Telefonaktiebolaget Lm Ericsson (Publ) Affectation dynamique de serveurs d'application dans un réseau ims
US8548467B2 (en) * 2008-09-12 2013-10-01 Qualcomm Incorporated Ticket-based configuration parameters validation
US8144732B2 (en) * 2008-12-31 2012-03-27 Mediatek Inc. Method for boosting downlink transmission to mobile station and system utilizing the same
US8341265B2 (en) * 2009-01-09 2012-12-25 Sonus Networks, Inc. Hybrid server overload control scheme for maximizing server throughput
KR20140023419A (ko) * 2009-03-17 2014-02-26 노키아 지멘스 네트웍스 오와이 물리 업링크 공유 채널（ｐｕｓｃｈ） 상의 주기적 피드백 정보의 전송 구성

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080108348A1 (en) * 2006-11-07 2008-05-08 Sudeep Ravi Kottilingal Registration timer adjustment based on wireless network quality

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Adaptive load-based expiration of pending messages in a publish/subscribe messaging system", IP.COM JOURNAL, IP.COM INC., WEST HENRIETTA, NY, US, 23 December 2008 (2008-12-23), pages 1 - 2, XP013128632, ISSN: 1533-0001 *
AI-CHUN PANG ET AL: "A study on SIP session timer for wireless voip", WIRELESS COMMUNICATIONS AND NETWORKING CONFERENCE, 2005 IEEE NEW ORLEANS, LA, USA 13-17 MARCH 2005, PISCATAWAY, NJ, USA,IEEE, vol. 4, 13 March 2005 (2005-03-13), pages 2306 - 2311, XP010791537, ISBN: 978-0-7803-8966-3 *
DONOVAN J ROSENBERG CISCO SYSTEMS S: "Session Timers in the Session Initiation Protocol (SIP); rfc4028.txt", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 April 2005 (2005-04-01), XP015041971, ISSN: 0000-0003 *
ROSENBERG J ET AL: "SIP: Session Initiation Protocol", 20020601; 20020600, 1 June 2002 (2002-06-01), pages 1 - 269, XP015009039 *
SHARMA P ET AL: "Scalable timers for soft state protocols", INFOCOM '97. SIXTEENTH ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER AN D COMMUNICATIONS SOCIETIES. DRIVING THE INFORMATION REVOLUTION., PROCE EDINGS IEEE KOBE, JAPAN 7-11 APRIL 1997, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, vol. 1, 7 April 1997 (1997-04-07), pages 222 - 229, XP010252006, ISBN: 978-0-8186-7780-9 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013037251A1 (fr) * 2011-09-16 2013-03-21 中兴通讯股份有限公司 Procédé et système d'authentification d'équipement d'utilisateur d'un réseau ils intégré à un réseau ims

Also Published As

Publication number Publication date
US20120106335A1 (en) 2012-05-03
EP2449747A1 (fr) 2012-05-09

Similar Documents

Publication Publication Date Title
EP3238406B1 (fr) Procédé de traitement d&#39;une requête de livraison de données
EP3329645B1 (fr) Procede de gestion de bande passante par un dispositif d&#39;interconnexion de reseaux de communication
WO2014049258A1 (fr) Procede de communication, procede de gestion de communication, dispositifs et nœuds associes
WO2010061119A1 (fr) Procede et systeme de regulation du trafic de redemarrage dans un reseau de telecommunications
WO2011064492A1 (fr) Procede de basculement d&#39;un hss primaire sur un hss de secours dans un reseau ip
EP2386169B1 (fr) Procédé et système de regulation du trafic de redémarrage dans un réseau de télécommunications
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
WO2011001075A1 (fr) Procédé et dispositif d&#39;acquittement d&#39;une requête de signalisation périodique dans un réseau de télécommunications
WO2007012767A1 (fr) Mesure d&#39;audience de flux ip multicast
FR3079710A1 (fr) Procede de gestion d&#39;une pluralite de flux media, et dispositif associe
EP3053321A1 (fr) Technique de restauration d&#39;un service dans un réseau
WO2016091874A1 (fr) Procédé et dispositifs permettant une transmission d&#39;un flux de données selon un mode de transmission multipoint
EP2171967B1 (fr) Serveur de configuration d&#39;enregistrement de clients a un service deploye sur un reseau ip, terminal client et reseau ip associes
WO2008096086A2 (fr) Procede de traitement de perte de paquets
FR2933261A1 (fr) Procede de traitement d&#39;une requete, passerelle d&#39;acces et systeme de controle d&#39;admission a un service
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP1964369B1 (fr) Procédé, appareils et programme d&#39;ordinateur de gestion de flux entre équipements fonctionnant selon le protocole sip sur un réseau de télécomunications
EP2365686B1 (fr) Procédé et dispositif de traitement d&#39;appels dans un réseau de communication comprenant des terminaux nomades tels que des terminaux de téléphonie de type softphone
WO2011144845A1 (fr) Administration d&#39;un reseau maille sans fil
FR2926179A1 (fr) Memorisation d&#39;informations contextuelles entre transmissions de messages de signalisation.
EP2448235B1 (fr) Entité électronique gérant un crédit d&#39;utilisation d&#39;une ressource dont l&#39;accès est contrôlé par un dispositif de contrôle
EP1367845B1 (fr) Procédé de contrôle d&#39;admission pour une transmission de données entre un serveur et un terminal mobile, à un moment privilégié de la journée, pour réduire la durée de transmission.
EP3632078A1 (fr) Procédé de contrôle d&#39;une communication comprenant des transactions multiples
WO2011101576A1 (fr) Gestion d&#39;acces a un service dans un reseau
EP3646578A1 (fr) Procédé de synchronisation d&#39;état média

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: 10745323

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13381546

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010745323

Country of ref document: EP