WO2007122347A1 - Procede d'optimisation de la collecte d'evenements, procede de supervision, produits programmes d'ordinateur et dispositifs correspondants - Google Patents

Procede d'optimisation de la collecte d'evenements, procede de supervision, produits programmes d'ordinateur et dispositifs correspondants Download PDF

Info

Publication number
WO2007122347A1
WO2007122347A1 PCT/FR2007/051140 FR2007051140W WO2007122347A1 WO 2007122347 A1 WO2007122347 A1 WO 2007122347A1 FR 2007051140 W FR2007051140 W FR 2007051140W WO 2007122347 A1 WO2007122347 A1 WO 2007122347A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
type
collection
events
window
Prior art date
Application number
PCT/FR2007/051140
Other languages
English (en)
Inventor
Christophe Dousson
Pierre Le Maigat
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2007122347A1 publication Critical patent/WO2007122347A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
    • H04L41/0622—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time based on time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
    • H04L41/0609—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time based on severity or priority

Definitions

  • the field of the invention is that of system supervision, that is to say the monitoring of the evolutions of a system, in particular in real time.
  • the invention relates to the collection of data intended for a supervisor, for example in the field of telecommunications networks and services.
  • the invention applies in particular, but not exclusively, to the collection, possibly followed by correlation, of information from a mobile terminal (for example a mobile phone) for managing the transition from a current network to a network. neighbor, referred to as "handover".
  • a stream of observations is processed in a collector, which captures and / or retrieves data from the monitored system.
  • the data to be collected may be of alarm type (indicating a situation of failure, saturation of a network equipment, etc.), modification of states (occurring for example as a result of the connection of a mobile in a monitored network), or measurement of one or more parameters of the monitored system (for example a measurement of flow at a point in the network).
  • the data to be collected are time-stamped in order to allow their correlation or, more simply, their scheduling.
  • the data to be collected of the alarm type are accompanied by a date of transmission of the alarm
  • the data to be collected of the type of change of state are accompanied by a date of connection of a mobile to the network. monitored, etc.
  • the term "event" is used to designate data to be collected and / or correlated with its date of occurrence.
  • an event is characterized by a type, parameters, and an occurrence date.
  • a connection of a mobile in the monitored network can be identified in the network by the event:
  • CON_MOB [1234, Orange], 24Fev2006-l lh30ml5s
  • - CON MOB defines the type of the event, i.e. a change of state following the connection of a mobile in the network
  • 1234 and Orange define the parameters of the event, i.e. the identifier of the mobile and its operator in this example
  • - 24Fev2006-l lh30ml5s its date of occurrence i.e. the date of connection of the mobile 1234 to the monitored network.
  • each event of the observed flow is reassembled to a central collector, which is in charge of correlating the events.
  • the central collector thus groups the events (for example, the alerts between them) so as to reduce their number and not to overload unnecessarily.
  • the central collector keeps only the correlated events.
  • such a collection architecture is illustrated in the context of a communication network implementing a simple network management protocol noted SNMP ("Simple Network Management Protocol" in English).
  • SNMP Simple Network Management Protocol
  • the SNMP communication protocol allows an administrator of a network to manage network equipment and diagnose network problems.
  • SNMP protocol relies on an "agent” / "manager” architecture allowing SNMP events to be reported, called “traps”.
  • SNMP ", from an agent to a supervisor, named” manager "according to SNMP terminology.
  • the 113 are entities for connecting managed equipment ⁇ 2 ⁇ , 122 and I23, respectively, to the monitored network.
  • the administrator 13 of the monitored network includes a supervisor 14, in the form of a "console", allowing him to implement administration tasks.
  • connections 151, 152 e 153 t allow agents H i, 112 and 113 to retrieve information about managed devices 12 ⁇ , 122nd t I23, and inform the manager 14.
  • the agents retrieve all the information from the managed equipment, and thus trace all the events from the agent to the manager.
  • the correlation of the events is thus carried out at the level of the manager, that is to say at the highest level.
  • a major disadvantage of this first approach is that it generally generates an overload of the network and storage resources and / or calculation of the manager.
  • the invention proposes a solution that does not have all these drawbacks of the prior art, in the form of a method of optimizing the collection of events generated by at least one collection equipment and intended for a supervisor.
  • the collection equipment implements a step of managing at least one time focusing window associated with at least one type of event. At each reception of an event, it implements a step of checking the presence of said event in at least one of said time focusing windows associated with the type of said event, such that: in the case of positive verification, a specific processing associated with the event type of said time focusing window in which the presence of said event is verified is implemented; in the case of negative verification, storage of said event in a buffer of said collection equipment is implemented.
  • the invention is based on a completely new and inventive approach to the collection of events, in a monitored system, to minimize the number of events exchanged between the different collection equipment and the supervisor, so as not to convey events necessary for a correlation or any other event consuming task.
  • the invention makes it possible, according to a particular embodiment, to manage time focusing windows, making it possible to specifically deal with a type of event according to its occurrence or not in a temporal focusing window.
  • an event present in none of the time focusing windows is stored in a buffer, to delay processing (deletion of the event or transmission to the supervisor).
  • the temporal focusing windows are propagated step by step, for example from a supervisor to an intermediate collection equipment, then to a final collection equipment, associated for example with a mobile phone.
  • the collection equipment is a mobile phone
  • reducing the amount of information (number of events) transmitted to a supervisor reduces the energy consumption of the mobile phone.
  • this optimization of event collection increases the autonomy of mobile phones, compared to a conventional collection approach.
  • the management step manages, for at least one of the types of events, at least one of the time focusing windows of the type belonging to the group comprising: an exclusion window, such as when the presence said event is checked in said exclusion window, said specific processing implements a deletion of said event; a selection window, such that when the presence of said event is verified in said selection window, said specific processing implements a transmission of said event to said supervisor; a window of non-occurrence, defining a period during which no event of said type of event can occur.
  • said specific processing can implement a transmission of the event of said collection equipment to said supervisor via at least one intermediate collection equipment, as part of a hierarchical collection network.
  • said management step comprises a step of updating said at least one temporal focusing window and said buffer, according to a time focusing request from said supervisor.
  • said time focus request from said supervisor is a search request for a type of event over a time interval.
  • Said collection equipment then implements the following sub-steps: checking the presence of at least one event of said type of event sought in said buffer; in the event of positive verification and temporal correlation between said time interval and the date of said event or events of said type of wanted event present in said buffer: transmission of said one or more events to said supervisor and deletion of said one or more events transmitted from said buffer; updating said selection window.
  • said time focusing request from said supervisor is a request for filtering a type of event over a time interval.
  • Said collection equipment then implements the following sub-steps: checking the presence of at least one event of said type of event to be filtered in said buffer; in the case of positive verification and temporal correlation between said time interval and the date of said event (s) of said type of event to be filtered present in said buffer: deletion of said event (s) of said buffer; updating said exclusion window.
  • Such a request from the supervisor thus makes it possible to signal to the collection equipment that the events of said type of event over such a time interval no longer interest the supervisor, and that the collection equipment can delete them.
  • the buffer and the temporal focus windows associated with said event type can be updated, depending on the result of this request.
  • such a request for time focusing can be transmitted from said supervisor to said collection equipment via at least one intermediate collection equipment, as part of a hierarchical collection network.
  • the collection system can thus spread the temporal focusing windows step by step.
  • said collection equipment is a terminal equipment or an intermediate equipment of a radio communication network.
  • a cellular radio network may include three levels of hierarchy: a radiocommunication terminal corresponding to a terminal collection equipment, a base station corresponding to an intermediate collection equipment, and a decision manager corresponding to a supervisor, the base station acting as supervisor for the lower level radio terminal, and collection equipment for the higher level decision manager.
  • Another aspect of the invention also relates to a method of supervising the collection of events generated by at least one collection equipment and intended for a supervisor.
  • a supervision method comprises a step of transmitting said supervisor to at least one of said collection equipment of at least one piece of information making it possible to manage at least one time focusing window associated with at least one type an event receiving step transmitted by at least one of said collection equipment, said transmitted events being present in at least one of said time focusing windows of a predetermined type.
  • said at least one piece of information is a time-focussing request belonging to the group comprising at least: a search request for a type of event over a time interval; a request to filter an event type over a time interval.
  • the supervisor can thus inform the collection equipment of the type of events he wishes to receive (search request for an event type) or that he does not wish to receive and that the collection equipment can delete (filter request of an event type), over a chosen time interval.
  • Another aspect of the invention further relates to a computer program product downloadable from a communication network and / or recorded on a computer-readable and / or executable medium by a processor, including program code instructions for implementing implementing the method of optimizing the collection of events as described above, as well as a computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, comprising program code instructions for implementing the event collection monitoring method as previously described.
  • the invention in another embodiment, relates to equipment for collecting at least one event intended for a supervisor, comprising: means for managing at least one time focusing window associated with at least one type of event , means for checking the presence of an event in at least one of said time focusing windows associated with the type of said event, implemented at each reception of an event, specific processing means associated with the type of said window of temporal focusing in which the presence of said event is verified, implemented in case of positive verification, and means for storing said event in a buffer, implemented in case of negative verification.
  • Such collection equipment is particularly suitable for implementing the collection optimization method described above.
  • Another embodiment also relates to a device for monitoring the collection of events generated by at least one collection equipment and intended for a supervisor, comprising transmission means to at least one of said collection equipment of at least one item of information making it possible to manage at least one time focusing window associated with at least one type of event, and event receiving means transmitted by at least one of said collection equipment, said transmitted events being present in at least one of said time focusing windows of a predetermined type.
  • Such a supervisor is particularly adapted to implement the supervision method described above.
  • FIG. 1 shows an example of a collection architecture in the context of a communication network implementing the SNMP protocol
  • FIG. 2 illustrates the different types of messages transmitted between a collection equipment and a supervisor according to one embodiment of the invention
  • FIGS. 3A to 3D present four temporal focusing window management algorithms for implementing the method according to a particular embodiment of the invention
  • FIGS. 4A to 4E illustrate the contents of a buffer associated with e-type events, as a function of the management of temporal focusing windows;
  • FIG. 5A to 5C describe more precisely the update of the temporal focusing windows and the buffer
  • FIG. 6 shows an example of a hierarchical collection network for an application of the invention to the management of a handover
  • FIGS. 7A and 7B respectively show the structure of a collection equipment and the structure of a supervisor according to a method of particular embodiment of the invention.
  • the general principle of the invention is based on a selective collection of events generated by one or more collection equipment of a supervised system and intended for a supervisor of the system, among a stream of observations.
  • this selective collection is implemented from the management of one or more time focusing windows and the verification, on receipt of an event, of the presence of this event in at least one of the windows of temporal focus. In other words, it is verified that the date of occurrence of this event is included in the time interval (s) defined by the time focusing window (s).
  • this event actually belongs to a temporal focusing window
  • a specific processing associated with the type of this window is implemented: for example a deletion or transmission of this event to the supervisor.
  • this event is stored in a buffer of the collection equipment, also called "buffer". More specifically, each collection equipment may have several buffers, a buffer being associated with each type of event.
  • Such collection equipment is for example associated with a terminal of a communication network.
  • the invention thus makes it possible, according to at least one particular embodiment, to store certain events of the stream of observations in a buffer memory of the equipment of the collection network, while waiting to make the decision to transmit them to the supervisor (possibly by way of intermediary of intermediate collection equipment) or to eliminate them.
  • intermediate collection equipment can fulfill both the terminal collection equipment and the supervisor function: it receives lower layer events as a supervisor and transmits them to a higher level layer as a terminal collection equipment.
  • the invention can of course also be implemented in a system having a distributed architecture, for example P2P type (in English “peer-to-peer”).
  • the data collection is optimized and the number of events exchanged between two pieces of equipment of the collection network is minimized.
  • the invention makes it possible, for example, for a telecommunications network operator to implement an optimal data collection decision policy, in order to convey only the events necessary for a supervisor for the correlation of events or for any other reason. another task consuming events.
  • the number of events flowing in the collection network is reduced, which leads to a reduction in the bandwidth used.
  • the number of correlation processing to be performed on each of the nodes (intermediate collection equipment) of the collection network decreases, which leads to optimization of the calculation and memory resources of the supervisor.
  • the invention thus relies on a set of equipment responsible for collecting events (for example the agents in the context of the SNMP protocol), transmitting only certain events to a supervision center (for example the manager as part of the protocol
  • the invention can thus be applied to any collection network comprising one or more collection equipment.
  • the invention implements, according to this particular embodiment described: a mechanism for memorizing ("buffering") events between the different collection equipment, which makes it possible to postpone the transmission of certain events, a mechanism for exchanging messages between two collection equipments making it possible to keep and transmit only the useful events.
  • this embodiment of the invention relies on the one hand on specific collection requests exchanged between a collection agent and a manager, and on the other hand on the maintenance by the agent of a event buffer based on a specific management of temporal focus windows.
  • the agents can manage at least one time focus window associated with a specific event type.
  • the agents include a buffer for memorizing
  • an agent manages three windows of time focusing, each buffer based on a specific management of the three time windows (interval union): an exclusion window X (e), also called “exclusion window”, for each type of event e. More precisely, this exclusion window generally corresponds to a union of intervals.
  • an event of type e belongs to this window (that is to say, its date of occurrence is included in this window), it can be deleted (ie not transmitted and not stored).
  • an e-type event outside this exclusion window must be stored in the buffer (or sent to the manager, discretion of the agent according to its storage capacity), a non-occurrence window NM (e), also called “no more window”, for each type of event e.
  • this window of non-occurrence includes all the dates for which the agent must no longer receive e-type events to be transmitted (apart from those that are still present in the agent's buffer).
  • this window of non-occurrence is initiated by the reception of an event, and defines a period during which no other event of type e will be memorized and / or transmitted.
  • This window is updated by the agent according to the arrival mechanism of the events to be transmitted (FIFO command, in English).
  • a selection window F also called “focused window”
  • this window includes all the dates for which any event of type e (those already stored in the buffer as those arriving later) must be transmitted immediately to the manager. Any new e-type event received belonging to this selection window must therefore not be stored in the agent's buffer but transmitted as soon as possible to the manager.
  • the agent 11 can transmit two types of messages to the manager 14: either a message of the type "e [param], t", referenced 21, carrying an event of type e, param parameters, and date of occurrence t.
  • a message in which an agent sends an event to the manager, corresponds to the conventional operation of a collection agent; a message of type "no more e in [tj ⁇ ]", referenced 22, specifying that from the current instant, there will be no occurrence of the event type e with a date included in the time interval
  • the manager 14 can also send to the agent 11 temporal focus requests, to update the time focusing windows and buffers associated with an event type in at least one collection equipment.
  • the manager 14 can send to the agent 11 a search request for a type of event 23 over a time interval, also called "focus e on [t ⁇ , t2]", requiring the immediate transmission of the e-type events whose occurrence date belongs to the time interval [ti, t2].
  • the message "focus e on [t ⁇ , t2]" thus indicates to the agent over which time range the manager wishes to receive events of type e as soon as possible.
  • an e-type event outside this range may be stored by the agent, or sent to the manager if the agent wishes to lighten its buffer. It can be noted that the storage in the buffer of the agent or the transmission to the manager can be determined according to the storage capacity of the agent and / or the application context.
  • the manager 14 can also send to the agent 11 a request to delete an event type 24 over a time interval, also called “filter e on [t ⁇ ]", requiring the deletion of the e-type events. whose date of occurrence belongs to the time interval [t ⁇ , t2].
  • filter e on [tj, t2] signals to the agent that the events of type e over this time range no longer interest the manager and that the agent can eliminate them.
  • exclusion and selection windows are updated when the manager sends messages of filter and / or focus type.
  • the algorithm for the agent to take into account a new event to be transmitted to the manager, to memorize in a buffer, or to delete (that is to say to filter).
  • the presence of this event e in the exclusion window X is verified ( e) associated with the type of event e.
  • the date t belongs to the time window X (e).
  • the event (e, t) is deleted (313).
  • the presence of this event e in the selection window F (e) associated with the event type e is checked during a step 314.
  • the event (e, t) is sent to the manager
  • the event (e, t) is stored in a buffer of the collection equipment associated with the type of the event (316).
  • the storage can be replaced by a transmission of the event to the manager when the capabilities of the agent are reached.
  • FIG. 4A illustrates an example of the state of a buffer 41 associated with the events of type e, comprising three events of type e 411, 412, and 413, and dates t A , t ⁇ , and t ⁇ .
  • the three exclusion windows X (e), selection F (e) and non-occurrence NM (e) are such that:
  • F (e) [t 4 , t 5 ]; with t 0 ⁇ t A ⁇ t B ⁇ ti ⁇ t 2 ⁇ t 3 ⁇ t c ⁇ t 4 ⁇ t 5 .
  • the portions of the buffer 41 corresponding to the time focusing windows X (e) and F (e) are empty of events, since an event belonging to the exclusion window X (e) is immediately eliminated and an event belonging to the selection window F (e) is immediately transmitted to the supervisor, possibly via intermediate collection equipment.
  • the new event 42 is present in the selection window F (e), that is, if t e ⁇ F (e), then this new event 42 is immediately transmitted to the manager, without being previously stored in the buffer 41.
  • the new event 42 is present neither in the non-occurrence window NM (e) nor in the window exclusion X (e), nor in the selection window F (e), that is to say if t e £ (NM (e) uX (e) uF (e)), then this new event 42 is stored in the buffer 41.
  • the buffer 41 thus includes the events 411, 412, and 4I3, previously stored, and the new event 42, all of type e.
  • FIG. 4E illustrates a prohibited situation: indeed, if the collection network is indeed specified, the new event 42 can not belong to the non-occurrence window NM (e). It can not therefore have a date t e belonging to the non-occurrence window NM (e). An error message should be sent if such a situation occurs.
  • the second algorithm for managing the temporal focusing windows and the agent buffer when receiving a "no more e" type message over a predetermined interval, is returned.
  • the temporal focusing window of non-occurrence NM e
  • the updated non-occurrence window is defined by NM (e) uI.
  • Time exclusion windows X (e) and selection windows F (e) are then updated during a step 323.
  • the updated exclusion window is then defined by X (e) ⁇ NM (e) and the selection window updated by F (e ) ⁇ NM (e), where the operator ⁇ denotes the set difference.
  • an order of priority is thus defined for updating the time windows.
  • the non-occurrence window NM (e) has the highest priority, followed by the exclusion window X (e), followed by the selection window F (e).
  • the higher priority windows "absorb" all or part of the interval I.
  • FIG. 5A illustrates more precisely the update of the temporal focusing windows and of the buffer 41, the elements already described bearing the same references as those used in FIGS. 4A to 4E.
  • FIG. 3C illustrates the third management algorithm of the windows of temporal focusing and the buffer of the agent, when receiving a search request of type search for a type of event on a time interval (request type "focus").
  • the agent upon receipt 331 of a message "focus e on I", whereby the manager signals to the agent that he wishes to receive events of type e as soon as possible having an occurrence date belonging to the interval I, the agent checks whether a first event of type e and date t ⁇ , denoted (e, tj), is present in the buffer associated with the event type e (332).
  • the selection window F (e) is updated during a step 333, and the message "no more e in InNM (e)" is transmitted to the manager during a step 338 More specifically, the updated selection window is defined by F (e) u (I ⁇ (NM (e) uX (e)).
  • step 334 it is verified during a step 334 whether the date ti of the event (e, t ⁇ ) belongs to the interval I (temporal correlation between the date tj and the time interval I). If this condition is verified, the event (e, t ⁇ ) is transmitted to the manager during a step 335, and removed from the buffer (336). Next, it is checked whether another event of type e and of date t2, noted (e, t2), is present in the buffer associated with the type of event e, during a step 337. If this is the case, returns to step 334, and it is checked whether the date t2 of the event (e, t2) belongs to the interval I. If this is the case, the steps 335, 336 and 337 are repeated; otherwise, return to step 337.
  • the selection window F (e) is updated as previously described in relation with step 333: F (e) ⁇ - F (e) Lastly, the message "no more e in InNM (e)" is transmitted to the manager during the step 338 described above.
  • FIG. 5B illustrates more precisely the update of the temporal focusing windows and the buffer 41.
  • events 412 and 413 whose occurrence dates are tg and tc, with t ⁇ e I and t e I, are sent to the manager and then removed from buffer 41.
  • FIG. 3D finally illustrates the fourth management algorithm of the temporal focusing windows and the agent buffer, when receiving a filtering type of focusing request of a type of event over a time interval (query of type "filter").
  • the agent checks whether a first event of type e and date t ⁇ , denoted (e, t ⁇ ), is present in the buffer associated with the event type e (342).
  • the exclusion window X (e) is updated during a step 343. More specifically, the updated exclusion window is defined by X (e) u (I ⁇ ( Next, the selection window F (e) is updated in a step 344: F (e) ⁇ - F (e) ⁇ X (e) Finally, the message "no more e in I "is transmitted to the manager during a step 348.
  • step 345 it is checked during a step 345 if the date ti of the event (e, t ⁇ ) belongs to the interval I (temporal correlation between the date t ⁇ and the time interval I). If this condition is true, the event (e, t ⁇ ) is removed from the buffer (346). Then it is checked whether another event of type e and date t2, noted (e, t2), is present in the buffer associated with the event type e, during a step 347. If this is the case, returns to step 345, and it is checked whether the date t2 of the event (e, t2) belongs to the interval I. If this is the case, the steps 346 and 347 are repeated; otherwise, return to step 347.
  • the exclusion window X (e) and the selection window F (e) are updated as previously described in connection with steps 343 and 344. : X (e) ⁇ - X (e) u (I ⁇ (NM (e)) and F (e) ⁇ - F (e) ⁇ X (e).
  • step 348 the "no more e in I" message is finally transmitted to the manager.
  • FIG. 5C illustrates more precisely the update of the temporal focusing windows and the buffer 41.
  • the update of the exclusion window X (e) is followed by the update of the selection window F (e): X (e) fX (e) u (I ⁇ (NM ( e)) and F (e) ⁇ - F (e) ⁇ X (e), for example, if we consider again:
  • events 412 and 413 whose occurrence dates are t ⁇ and te, with t ⁇ e I and te e I, are removed from buffer 41.
  • the events of type e of the buffer such as date (e) el are deleted from the buffer.
  • the lower level elementary events are derived from mobile telephones (for example 611, 6I2 or 6I3) and, during the correlation of several events (by example of the type of signal quality, service used, type of customer, user preference ...), an operator wishes to be able to decide to switch this (these) mobile phone (s) to another network.
  • the events resulting from the mobile phones 611, 6I2 or 613, associated with collection equipment, for example agents, are transmitted to the higher level, that is to say to the intermediate collection equipment of the base stations 62 ⁇ and 622- These intermediate collection equipments also generate elementary events. Intermediate collection equipment associated with base stations 62 ⁇ and 622 therefore act both as terminal collection equipment and as supervisor. The set of events is then transmitted to the higher level, that is to say to the supervisor associated with the decision manager 63.
  • a correlation is performed at the base stations 62 1 and 622, and at the decision manager 63, and temporal focusing windows are positioned, so as to avoid that the mobile constantly sends information and the stations of base unnecessarily solicit the decision manager.
  • basel 62 ⁇ and base2 622 it is assumed that we seek to correlate handover requests between several base stations following a problem on one of the base stations (noted basel 62 ⁇ and base2 622), and therefore to a mobile rejection problem.
  • the scenario to be monitored is the following: when a base station, for example basel, has a problem ⁇ sending a BASE_HS alarm [basel] by a collection equipment to its supervisor) and starts rejecting connections ⁇ sending an alarm HANDOVER_OUT [basel] by each mobile impacted), the impacted mobiles try to connect to a neighboring base station, for example base2 ⁇ with alarms HANDOVER_IN [base2] sent by each of the mobiles actually tilted), the whole scenario taking place within a time ⁇ .
  • the supervisor continuously collects all BASE HS, HANDOVER IN and HANDOVER OUT events in order to be able to correlate and verify the realization of the scenario to be monitored.
  • HANDOVER_IN / OUT events are collected unnecessarily, just "in case” a problem occurs, even in cases where these events are issued by mobiles when they change the base station for reasons other than performing the scenario to be monitored (for example when the mobile phone user moves).
  • the invention implements the following steps:
  • the supervisor (intermediate collection equipment) of the base2 622 retransmits the request to the mobiles 6I 1, 6I2 and 6I3.
  • the collection system spreads the time-focusing windows step by step.
  • a hierarchical N-level collection node is assumed to take the role of manager for a lower-level NI node, and to act as an agent for an N + manager. l higher level.
  • a request of type search for an event type (message of type "focus") from the manager N + 1 of the node N is transmitted to (the) agent (s) NI of the node N, by the intermediary of the node N.
  • a request of filtering type of an event type (message of "filter” type) from the manager N + 1 of the node N is transmitted to the agent (s) N of the N node, through the N node.
  • an event from one of the NI agents is transmitted (or filtered or stored) to the N + 1 manager, through the N node.
  • a message of the type "focus” and / or "filter” can be adapted before being retransmitted to the lower level.
  • an agent N is responsible for counting the events of type e over a predetermined period of time (for example 1 hour), and to reassemble the information every 10 minutes (case of a counting on sliding window)
  • this agent receives a filtering request on the time interval [13h, 14h30], it can transmit to its sources (that is to say to the agents NI) the instruction "filter” on [12h50, 13h30] , to account for the counting range and slippage of the sliding window.
  • the optimization of the collection according to the invention is therefore spread throughout the collection hierarchy, and not only between two successive levels of the network. collection.
  • the reduction in the number of events circulating in the collection network is therefore all the more important.
  • the update of the different buffers of the collection agents implements the following steps:
  • the supervisor of basel 62 ⁇ retransmits the request to mobiles 61 ⁇ , 6I2 and 61 3 ; 5.
  • the base supervisor2 622 retransmits the request to mobiles 61 1, 61 2 and 61 3 .
  • a second example of application of the invention is also presented, allowing the statistics of the monitored network to be reported.
  • a mobile present in the network requires a video connection (or a connection to another available service), this mobile being able to connect to different types of network: for example, it can connect to network via WiFi or GPRS (handover capabilities).
  • the decision to switch to the WiFi or GPRS network depends on the policy implemented by an operator, and can rely on several criteria. It is considered, for example, that it relies solely on an average over a time ⁇ of the cumulative bit rate of all the mobiles already connected by Wi-Fi to the same radio frequency base station as the mobile requesting the video connection.
  • M the average of the cumulative bit rate of all the mobiles already connected by Wi-Fi to the same radio frequency base station as the mobile requesting the video connection.
  • M When a user activates the video service, it is therefore necessary to know this average, noted M.
  • the scenario to be monitored is therefore: if M is greater than the reference average, then it is necessary to switch to the GPRS network otherwise, it is necessary to connect by Wifi.
  • the particular embodiment described allows, on receiving a "video service request" type event at a time t, to automatically propagate the collection of data rates on a window [t- ⁇ , t], to calculate the average and transmit it to the next level.
  • the update of the buffers can be implemented at any time t by sending a filtering request on the interval] - ⁇ , t- ⁇ ] (message of type "filter”).
  • FIGS. 7A and 7B the simplified structure of a collection equipment and a supervision device implementing respectively a data collection technique and a collection supervision technique according to the invention are presented. the particular embodiment described above.
  • Such collection equipment comprises a memory 71 consisting of a buffer memory, a processing unit 72, equipped for example with a microprocessor ⁇ P, and driven by the computer program 73, implementing the optimization method of the collection according to the invention.
  • the code instructions of the computer program 73 are for example loaded into a RAM before being executed by the processor of the processing unit 72.
  • the processing unit 72 receives at least one input and information for managing at least one temporal focusing window. .
  • the microprocessor of the processing unit 72 implements the steps of the collection optimization method described above, according to the instructions of the computer program 73, to decide whether each of the received events must be stored in the equipment of the processor. collected, deleted, or passed on to a supervisor.
  • the collection equipment comprises, in addition to the buffer memory 71, means for managing at least one temporal focusing window associated with at least one type of event, means for checking the presence of an event in at least one of the focusing windows during the reception of this event, and specific processing means associated with the type of focusing window. These means are controlled by the microprocessor of the processing unit 72. The processing unit 72 therefore transmits to the supervisor the events necessary for the implementation of a correlation or any other event consuming task.
  • the invention proposes, according to the particular embodiment described, an automatic filtering system for information to be traced back to a supervisor, this filtering being obtained by positioning dynamic filters so as to guarantee the same final result as if no filter were available. positioned. Filters are only used to delete unnecessary information.
  • the supervision device also comprises a memory 74, a processing unit 75, equipped for example with a microprocessor ⁇ P, and driven by the computer program 76, implementing the collection supervision method according to the invention.
  • the code instructions of the computer program 76 are for example loaded into a RAM before being executed by the processor of the processing unit 75.
  • the processing unit 75 receives events transmitted by collection equipment, and issues information for managing at least one time focusing window, for example time focusing requests.
  • the microprocessor of the processing unit 75 implements the steps of the collection supervision method described above, according to the instructions of the computer program 76, to manage and update the different windows of time focusing.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé d'optimisation de la collecte d'événements, procédé de supervision, produits programmes d'ordinateur et dispositifs correspondants. L'invention concerne la collecte d'événements générés par au moins un équipement de collecte (11) et destinés à un superviseur (14). Selon l'invention, un équipement de collecte (11) met en oeuvre une étape de gestion d'au moins une fenêtre de focalisation temporelle associée à au moins un type d'événement. A chaque réception d'un événement, il met en oeuvre une étape de vérification de la présence dudit événement dans au moins une desdites fenêtres de focalisation temporelle associée au type dudit événement, telle que : en cas de vérification positive, un traitement spécifique associé au type de ladite fenêtre de focalisation temporelle dans laquelle la présence dudit événement est vérifiée est mis en oeuvre; en cas de vérification négative, une mémorisation dudit événement dans un tampon dudit équipement de collecte est mise en oeuvre.

Description

Procédé d'optimisation de la collecte d'événements, procédé de supervision, produits programmes d'ordinateur et dispositifs correspondants.
1. Domaine de l'invention
Le domaine de l'invention est celui de la supervision de système, c'est-à- dire de la surveillance des évolutions d'un système, notamment en temps réel.
Plus précisément, l'invention concerne la collecte de données destinées à un superviseur, par exemple dans le domaine des réseaux et services de télécommunications.
L'invention s'applique notamment, mais non exclusivement, à la collecte, éventuellement suivie de corrélation, d'informations issues d'un terminal mobile (par exemple un téléphone mobile) pour la gestion du passage d'un réseau courant à un réseau voisin, désigné par le terme anglais « handover ».
2. Art antérieur
Classiquement, dans le cadre de la supervision de système, un flux d'observations est traité dans un collecteur, qui capte et/ou récupère des données du système surveillé.
Notamment, les données à collecter, qui pourront être corrélées par la suite, peuvent être de type alarme (indiquant une situation de panne, de saturation d'un équipement du réseau, etc), modification d'états (survenant par exemple suite à la connexion d'un mobile dans un réseau surveillé), ou encore mesure d'un ou plusieurs paramètres du système surveillé (par exemple une mesure de débit en un point du réseau).
On rappelle notamment que dans une architecture classique de collecte et de corrélation de données, par exemple sur un réseau de télécommunications, les données à collecter sont horodatées afin de permettre leur corrélation ou, plus simplement, leur ordonnancement. Ainsi, par exemple, les données à collecter de type alarme sont accompagnées d'une date d'émission de l'alarme, les données à collecter de type modification d'état sont accompagnées d'une date de connexion d'un mobile au réseau surveillé, etc. Plus précisément, on désigne dans toute la suite du document par le terme « événement » une donnée à collecter et/ou à corréler munie de sa date d'occurrence.
Ainsi, un événement est caractérisé par un type, des paramètres et une date d'occurrence.
A titre d'exemple, une connexion d'un mobile dans le réseau surveillé peut être identifiée dans le réseau par l'événement :
CON_MOB[1234,Orange],24Fev2006-l lh30ml5s où : - CON MOB défini le type de l'événement, i.e. une modification d'état suite à la connexion d'un mobile dans le réseau ; 1234 et Orange (marque déposée) définissent les paramètres de l'événement, i.e. l'identifiant du mobile et son opérateur dans cet exemple ; et - 24Fev2006-l lh30ml5s sa date d'occurrence, i.e. la date de connexion du mobile 1234 au réseau surveillé.
Selon les techniques de l'art antérieur, chaque événement du flux observé est remonté vers un collecteur central, qui se charge de corréler les événements.
Le collecteur central regroupe ainsi les événements (par exemple, les alertes entre elles) de façon à diminuer leur nombre et ne pas se surcharger inutilement. Le collecteur central ne conserve donc que les événements corrélés.
On illustre par exemple, en relation avec la figure 1 , une telle architecture de collecte dans le cadre d'un réseau de communication mettant en œuvre un protocole simple de gestion de réseau noté SNMP (« Simple Network Management Protocol » en anglais).
On rappelle que le protocole de communication SNMP permet notamment à un administrateur d'un réseau de gérer les équipements du réseau et de diagnostiquer les problèmes du réseau.
Plus précisément, le protocole SNMP s'appuie sur une architecture « agent »/« manager » permettant la remontée d'événements SNMP, notés « traps SNMP », d'un agent vers un superviseur, nommé « manager » selon la terminologie SNMP.
Ainsi, comme illustré en relation avec la figure 1, les agents l l χ, I I2 et
113 sont des entités permettant de connecter des équipements managés \2\, 122 et I23, respectivement, au réseau surveillé. L'administrateur 13 du réseau surveillé comprend un superviseur 14, sous la forme d'une « console », lui permettant de mettre en œuvre des tâches d'administration.
Plus précisément, les liaisons 151, 152 et 153 permettent aux agents H i, 112 et 113 de récupérer des informations sur les équipements managés 12χ, 122 et I23, et d'en informer le manager 14.
Selon une première approche connue, les agents récupèrent toutes les informations issues des équipements managés, et remontent donc tous les événements de l'agent vers le manager. La corrélation des événements est donc effectuée au niveau du manager, c'est-à-dire au plus haut niveau. Un inconvénient majeur de cette première approche est qu'elle engendre généralement une surcharge du réseau et des ressources de stockage et/ou de calcul du manager.
Selon une seconde approche, il a été proposé, afin de limiter la remontée des événements des agents vers les managers, de filtrer la remontée des événements en insérant un dispositif de filtrage au niveau des agents.
Malheureusement, un tel dispositif de filtrage est systématique et irrémédiable. Autrement dit, tout événement filtré est définitivement perdu, si bien qu'on ne peut autoriser un tel dispositif de filtrage à ne filtrer que les événements que l'on sait par avance inutiles pour la tâche prévue par la collecte. Finalement, selon une troisième approche, la corrélation des événements est mise en œuvre au fur et à mesure de la remontée, afin de limiter le nombre d'événements remontants. Ainsi, dans le cas d'une structure hiérarchique de collecte par exemple, on peut compter le nombre d'alarmes d'un certain type et, au lieu de remonter les N alarmes, se contenter de remonter le fait que N alarmes d'un certain type ont eu lieu. Un inconvénient de cette troisième approche est que le nombre d'événements émis peut toujours être important. Par conséquent, il est de nouveau souhaitable d'insérer un dispositif de filtrage à chaque niveau de la collecte, afin de limiter le volume de données transitant sur le réseau. De nouveau, certaines informations filtrées sont donc définitivement perdues.
3. Exposé de l'invention
L'invention propose une solution qui ne présente pas tous ces inconvénients de l'art antérieur, sous la forme d'un procédé d'optimisation de la collecte d'événements générés par au moins un équipement de collecte et destinés à un superviseur.
Selon l'invention, l'équipement de collecte met en œuvre une étape de gestion d'au moins une fenêtre de focalisation temporelle associée à au moins un type d'événement. A chaque réception d'un événement, il met en œuvre une étape de vérification de la présence dudit événement dans au moins une desdites fenêtres de focalisation temporelle associée au type dudit événement, telle que : en cas de vérification positive, un traitement spécifique associé au type de ladite fenêtre de focalisation temporelle dans laquelle la présence dudit événement est vérifiée est mis en œuvre ; en cas de vérification négative, une mémorisation dudit événement dans un tampon dudit équipement de collecte est mise en œuvre.
Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la collecte d'événements, dans un système surveillé, permettant de minimiser le nombre d'événements échangés entre les différents équipements de collecte et le superviseur, afin de ne véhiculer que les événements nécessaires à une corrélation ou à tout autre tâche consommatrice d'événements.
Plus précisément, l'invention permet de gérer, selon un mode de réalisation particulier, des fenêtres de focalisation temporelle, permettant de traiter spécifiquement un type d'événement en fonction de son occurrence ou non dans une fenêtre de focalisation temporelle. Notamment, un événement présent dans aucune des fenêtres de focalisation temporelle est mémorisé dans un tampon, de manière à différer son traitement (suppression de l'événement ou transmission au superviseur).
On peut notamment remarquer que selon ce mode de réalisation particulier, les fenêtres de focalisation temporelle sont propagées de proche en proche, par exemple d'un superviseur à un équipement de collecte intermédiaire, puis à un équipement de collecte final, associé par exemple à un téléphone mobile.
Notamment, lorsque l'équipement de collecte est un téléphone mobile, la diminution de la quantité d'informations (nombre d'événements) transmise à un superviseur permet de diminuer la consommation énergétique du téléphone mobile. Par conséquent, cette optimisation de la collecte d'événements permet d'accroître l'autonomie des téléphones mobiles, par rapport à une approche de collecte classique.
Selon un mode de réalisation particulier, l'étape de gestion gère, pour au moins un des types d'événements, au moins une des fenêtres de focalisation temporelle du type appartenant au groupe comprenant : une fenêtre d'exclusion, telle que lorsque la présence dudit événement est vérifiée dans ladite fenêtre d'exclusion, ledit traitement spécifique met en œuvre une suppression dudit événement ; - une fenêtre de sélection, telle que lorsque la présence dudit événement est vérifiée dans ladite fenêtre de sélection, ledit traitement spécifique met en œuvre une transmission dudit événement audit superviseur ; une fenêtre de non occurrence, définissant une période durant laquelle aucun événement dudit type d'événement ne peut survenir. Ainsi, lorsque la présence d'un événement est détectée dans une fenêtre de sélection ou d'exclusion, c'est-à-dire que la date d'occurrence d'un événement est comprise dans un intervalle temporel défini par une telle fenêtre de sélection ou d'exclusion, un traitement spécifique du type transmission ou suppression de l'événement est mis en œuvre. On effectue ainsi une collecte sélective des événements générés par un ou plusieurs équipements de collecte, pour ne transmettre à un superviseur que les événements dont il a effectivement besoin.
Notamment, lorsque la présence d'un événement est vérifiée dans une fenêtre de sélection, ledit traitement spécifique peut mettre en œuvre une transmission de l'événement dudit équipement de collecte audit superviseur par l'intermédiaire d'au moins un équipement de collecte intermédiaire, dans le cadre d'un réseau de collecte hiérarchique.
Selon un aspect particulier de l'invention, ladite étape de gestion comprend une étape de mise à jour de ladite au moins une fenêtre de focalisation temporelle et dudit tampon, en fonction d'une requête de focalisation temporelle issue dudit superviseur.
La mise en œuvre d'un tel mécanisme d'échange de messages entre un élément de collecte et son superviseur permet ainsi de mémoriser et/ou de transmettre uniquement les information utiles. Selon un premier exemple, ladite requête de focalisation temporelle issue dudit superviseur est une requête de recherche d'un type d'événement sur un intervalle temporel. Ledit équipement de collecte met alors en œuvre les sous- étapes suivantes : vérification de la présence d'au moins un événement dudit type d'événement recherché dans ledit tampon ; en cas de vérification positive et de corrélation temporelle entre ledit intervalle temporel et la date du ou desdits événements dudit type d'événement recherché présents dans ledit tampon : transmission du ou desdits événements audit superviseur et suppression du ou desdits événements transmis dudit tampon ; mise à jour de ladite fenêtre de sélection.
Une telle requête issue du superviseur permet ainsi de signaler à l'équipement de collecte sur quel intervalle temporel ledit superviseur souhaite recevoir des événements d'un type d'événement donné, dès que possible. Finalement, le tampon et les fenêtres de focalisation temporelles associées audit type d'événement peuvent être mis à jour, en fonction du résultat de cette requête.
Selon un deuxième exemple, ladite requête de focalisation temporelle issue dudit superviseur est une requête de filtrage d'un type d'événement sur un intervalle temporel. Ledit équipement de collecte met alors en œuvre les sous- étapes suivantes : vérification de la présence d'au moins un événement dudit type d'événement à filtrer dans ledit tampon ; en cas de vérification positive et de corrélation temporelle entre ledit intervalle temporel et la date du ou desdits événements dudit type d'événement à filtrer présents dans ledit tampon : suppression du ou desdits événements dudit tampon ; mise à jour de ladite fenêtre d'exclusion.
Une telle requête issue du superviseur permet ainsi de signaler à l'équipement de collecte que les événements dudit type d'événement sur un tel intervalle temporel n'intéressent plus le superviseur, et que l'équipement de collecte peut les supprimer.
Finalement, le tampon et les fenêtres de focalisation temporelles associées audit type d'événement peuvent être mis à jour, en fonction du résultat de cette requête.
Notamment, une telle requête de focalisation temporelle peut être transmise dudit superviseur audit équipement de collecte par l'intermédiaire d'au moins un équipement de collecte intermédiaire, dans le cadre d'un réseau de collecte hiérarchique. Le système de collecte peut ainsi propager les fenêtres de focalisation temporelle de proche en proche.
Selon une caractéristique particulière de l'invention, ledit équipement de collecte est un équipement terminal ou un équipement intermédiaire d'un réseau de radiocommunication. Par exemple, un réseau cellulaire de radiocommunication peut comprendre trois niveaux de hiérarchie : un terminal de radiocommunication correspondant à un équipement de collecte terminal, une station de base correspondant à un équipement de collecte intermédiaire, et un gestionnaire de décisions correspondant à un superviseur, la station de base assurant le rôle de superviseur pour le terminal de radiocommunication de niveau inférieur, et d'équipement de collecte pour le gestionnaire de décision de niveau supérieur.
Un autre aspect de l'invention concerne également un procédé de supervision de la collecte d'événements générés par au moins un équipement de collecte et destinés à un superviseur. Selon cet aspect de l'invention, un tel procédé de supervision comprend une étape de transmission dudit superviseur à au moins un desdits équipements de collecte d'au moins une information permettant de gérer au moins une fenêtre de focalisation temporelle associée à au moins un type d'événement, et une étape de réception d'événements transmis par au moins un desdits équipements de collecte, lesdits événements transmis étant présents dans au moins une desdites fenêtres de focalisation temporelle d'un type prédéterminé.
Ainsi, selon cet aspect de l'invention, seuls les événements présents dans une des fenêtres de focalisation temporelle d'un type prédéterminé sont transmis d'un ou plusieurs équipements de collecte vers un superviseur. Une collecte sélective d'événements à destination du superviseur est donc mise en œuvre à partir de la gestion d'une ou plusieurs fenêtres de focalisation temporelle.
En particulier, ladite au moins une information est une requête de focalisation temporelle, appartenant au groupe comprenant au moins : - une requête de recherche d'un type d'événement sur un intervalle temporel ; une requête de filtrage d'un type d'événement sur un intervalle temporel.
Le superviseur peut ainsi informer les équipements de collecte du type d'événements qu'il souhaite recevoir (requête de recherche d'un type d'événement) ou qu'il ne souhaite pas recevoir et que l'équipement de collecte peut supprimer (requête de filtrage d'un type d'événement), sur un intervalle temporel choisi.
Un autre aspect de l'invention concerne encore un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour la mise en œuvre du procédé d'optimisation de la collecte d'événements tel que décrit précédemment, ainsi qu'un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour la mise en œuvre du procédé de supervision de la collecte d'événements tel que décrit précédemment.
Dans un autre mode de réalisation, l'invention concerne un équipement de collecte d'au moins un événement destiné à un superviseur, comprenant : des moyens de gestion d'au moins une fenêtre de focalisation temporelle associée à au moins un type d'événement, des moyens de vérification de la présence d'un événement dans au moins une desdites fenêtres de focalisation temporelle associée au type dudit événement, mis en œuvre à chaque réception d'un événement, des moyens de traitement spécifique associé au type de ladite fenêtre de focalisation temporelle dans laquelle la présence dudit événement est vérifiée, mis en œuvre en cas de vérification positive, et des moyens de mémorisation dudit événement dans un tampon, mis en œuvre en cas de vérification négative.
Un tel équipement de collecte est notamment adapté à mettre en œuvre le procédé d'optimisation de la collecte décrit précédemment.
Un autre mode de réalisation concerne également un dispositif de supervision de la collecte d'événements générés par au moins un équipement de collecte et destinés à un superviseur, comprenant des moyens de transmission à au moins un desdits équipements de collecte d'au moins une information permettant de gérer au moins une fenêtre de focalisation temporelle associée à au moins un type d'événement, et des moyens de réception d'événements transmis par au moins un desdits équipements de collecte, lesdits événements transmis étant présents dans au moins une desdites fenêtres de focalisation temporelle d'un type prédéterminé.
Un tel superviseur est notamment adapté à mettre en œuvre le procédé de supervision décrit précédemment.
4. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un exemple d'architecture de collecte dans le cadre d'un réseau de communication mettant en œuvre le protocole SNMP ; la figure 2 illustre les différents types de messages transmis entre un équipement de collecte et un superviseur selon un mode de réalisation de l'invention ; les figures 3A à 3D présentent quatre algorithmes de gestion de fenêtres de focalisation temporelle pour la mise en œuvre du procédé selon un mode de réalisation particulier de l'invention ; les figures 4A à 4E illustrent le contenu d'un tampon associé aux événements de type e, en fonction de la gestion des fenêtres de focalisation temporelles ; - les figures 5A à 5C décrivent plus précisément la mise à jour des fenêtres de focalisation temporelle et du tampon ; la figure 6 présente un exemple de réseau de collecte hiérarchique pour une application de l'invention à la gestion d'un handover ; et les figures 7A et 7B présentent respectivement la structure d'un équipement de collecte et la structure d'un superviseur selon un mode de réalisation particulier de l'invention.
5. Description d'un mode de réalisation de l'invention
5.7 Principe général de l'invention
Le principe général de l'invention repose sur une collecte sélective d'événements générés par un ou plusieurs équipements de collecte d'un système supervisé et destinés à un superviseur du système, parmi un flux d'observations.
Plus précisément, cette collecte sélective est mise en œuvre à partir de la gestion d'une ou plusieurs fenêtres de focalisation temporelle et de la vérification, à la réception d'un événement, de la présence de cet événement dans au moins une des fenêtres de focalisation temporelle. Autrement dit, on vérifie que la date d'occurrence de cet événement est comprise dans le ou les intervalles de temps définis par la ou les fenêtres de focalisation temporelle.
Si cet événement appartient effectivement à une fenêtre de focalisation temporelle, un traitement spécifique associé au type de cette fenêtre est mis en œuvre : par exemple une suppression ou une transmission de cet événement au superviseur.
Si cet événement n'appartient à aucune fenêtre de focalisation temporelle, cet événement est mémorisé dans un tampon de l'équipement de collecte, encore appelé « buffer ». Plus précisément, chaque équipement de collecte peut posséder plusieurs tampons, un tampon étant associé à chaque type d'événement.
Un tel équipement de collecte est par exemple associé à un terminal d'un réseau de communication.
L'invention permet ainsi, selon au moins un mode de réalisation particulier, de mémoriser certains événements du flux d'observations dans une mémoire tampon des équipements du réseau de collecte, en attendant de prendre la décision de les transmettre au superviseur (éventuellement par l'intermédiaire d'équipements de collecte intermédiaires) ou de les éliminer.
En effet, un tel système supervisé peut notamment présenter une structure hiérarchique. Dans ce cas, un équipement de collecte intermédiaire peut remplir à la fois la fonction d'équipement de collecte terminal et de superviseur : il reçoit des événements de la couche inférieure en tant que superviseur et les transmet à une couche de niveau supérieure en tant qu'équipement de collecte terminal.
L'invention peut bien entendu également être mise en œuvre dans un système présentant une architecture distribuée, par exemple de type P2P (en anglais « peer-to-peer »).
Selon ce mode particulier de réalisation, on optimise ainsi la collecte des données, en minimisant le nombre d'événements échangés entre deux équipements du réseau de collecte. Autrement dit, l'invention permet par exemple à un opérateur de réseaux de télécommunications de mettre en œuvre une politique optimale de décision de collecte de données, afin de ne véhiculer que les événements nécessaires à un superviseur pour la corrélation d'événements ou pour tout autre tâche consommatrice d'événements.
Ainsi, selon le mode particulier de réalisation décrit, le nombre d'événements circulant dans le réseau de collecte est réduit, ce qui conduit à un allégement de la bande passante utilisée. De plus, notamment dans le cas de l'utilisation de l'invention pour la corrélation d'événements, le nombre de traitement de corrélation à effectuer sur chacun des nœuds (équipements de collecte intermédiaires) du réseau de collecte diminue, ce qui conduit à une optimisation des ressources de calcul et de mémoire du superviseur. L'invention s'appuie ainsi, selon ce mode de réalisation, sur un ensemble d'équipements responsables de la collecte d'événements (par exemple les agents dans le cadre du protocole SNMP), transmettant uniquement certains événements vers un centre de supervision (par exemple le manager dans le cadre du protocole
SNMP). L'invention peut ainsi s'appliquer à tout réseau de collecte comprenant un ou plusieurs équipements de collecte.
Plus précisément, l'invention met en œuvre, selon ce mode de réalisation particulier décrit : un mécanisme de mémorisation (« bufferisation ») d'événements entre les différents équipements de collecte, qui permet de différer la transmission de certains événements, un mécanisme d'échange de messages entre deux équipements de collecte permettant de ne conserver et transmettre que les événements utiles. 5.2 Mise en œuvre d'un mode de réalisation particulier On décrit ci-après un exemple de mise en œuvre de l'invention dans le cadre de l'utilisation d'un protocole SNMP destiné à gérer des équipements d'un réseau de communication, selon un mode de réalisation particulier.
Comme indiqué précédemment, ce mode de réalisation de l'invention s'appuie d'une part sur des requêtes spécifiques de collecte échangées entre un agent de collecte et un manager, et d'autre part sur le maintien par l'agent d'un tampon d'événements s'appuyant sur une gestion spécifique de fenêtres de focalisation temporelle.
A) Définitions des fenêtres de focalisation temporelle
Afin de sélectionner uniquement les événements nécessaires au superviseur, pour effectuer une corrélation d'événements ou tout autre tâche consommatrice d'événements, les agents peuvent gérer au moins une fenêtre de focalisation temporelle, associée à un type d'événement spécifique.
De plus, les agents comprennent un tampon permettant de mémoriser
(stocker) des événements pouvant être transmis au manager, mais dont le manager n'a pas besoin immédiatement. On rappelle qu'un agent de collecte peut posséder plusieurs tampons ou « buffers », un buffer par type d'événement.
Plus précisément, dans le mode de réalisation particulier décrit, un agent gère trois fenêtres de focalisation temporelle, chaque buffer s'appuyant sur une gestion spécifique des trois fenêtres temporelles (union d'intervalles) : une fenêtre d'exclusion X(e), encore appelée « exclusion window », pour chaque type d'événement e. Plus précisément, cette fenêtre d'exclusion correspond généralement à une union d'intervalles. Lorsqu'un événement de type e appartient à cette fenêtre (c'est-à-dire que sa date d'occurrence est comprise dans cette fenêtre), il peut être supprimé (i.e. non transmis et non stocké). À l'opposé, un événement de type e hors de cette fenêtre d'exclusion doit être mémorisé dans le tampon (ou transmis au manager, à discrétion de l'agent suivant sa capacité de stockage), une fenêtre de non occurrence NM(e), encore appelée « no more window », pour chaque type d'événement e. Plus précisément, cette fenêtre de non occurrence comprend l'ensemble des dates pour lesquelles l'agent ne doit plus recevoir d'événements de type e à transmettre (hormis qui sont encore présents dans le tampon de l'agent). Autrement dit, cette fenêtre de non occurrence est amorcée par la réception d'un événement, et définit une période durant laquelle aucun autre événement de type e ne sera mémorisé et/ou transmis. Cette fenêtre est mise à jour par l'agent en fonction du mécanisme d'arrivée des événements à transmettre (ordre FIFO, en anglais
« first in first out », si les événements arrivent dans leur ordre d'occurrence, avec délai de gigue, retard...). une fenêtre de sélection F(e), encore appelée «focused window », pour chaque type d'événement e. Plus précisément, cette fenêtre comprend l'ensemble des dates pour lesquelles tout événement de type e (ceux déjà mémorisés dans le tampon comme ceux arrivant par la suite) doit être transmis immédiatement au manager. Tout nouvel événement de type e reçu appartenant à cette fenêtre de sélection ne doit donc pas être mémorisé dans le tampon de l'agent mais transmis dès que possible au manager.
Selon ce mode de réalisation décrit, on considère que ces trois fenêtres sont exclusives, c'est-à-dire que leur intersection deux à deux donne un ensemble vide.
B) Présentations des messages échangés entre un agent et un manager On présente désormais, en relation avec la figure 2, différents types de messages pouvant être échangés entre un agent 11 et son manager 14.
Plus précisément, l'agent 11 peut transmettre deux types de messages au manager 14 : soit un message de type « e[param],t », référencé 21, portant un événement de type e, de paramètres param, et de date d'occurrence t. Un tel message, dans lequel un agent envoie un événement au manager, correspond au fonctionnement classique d'un agent de collecte ; soit un message de type « no more e in [tj^] », référencé 22, précisant qu'à partir de l'instant courant, il n'y aura plus d'occurrence de l'événement de type e avec une date comprise dans l'intervalle temporel
[ti,t2]. Par exemple, si les événements arrivent dans leur ordre d'occurrence (ordre FIFO), l'agent peut faire suivre chaque événement
« e[param],t » du message « no more event e in ]-∞,t] ». De manière plus générale, si les messages arrivent avec un délai de gigue borné par Δ, chaque événement peut être suivi du message « no more event e in ] -∞ , t -
Δ ] », avec le cas Δ = 0 correspondant au cas FIFO.
Le manager 14 peut également émettre à destination de l'agent 11 des requêtes de focalisation temporelle, permettant de mettre à jour les fenêtres de focalisation temporelle et les tampons associés à un type d'événement, dans au moins un équipement de collecte.
Par exemple, le manager 14 peut envoyer à destination de l'agent 11 une requête de recherche d'un type d'événement 23 sur un intervalle temporel, encore appelée « focus e on [tχ,t2] », requérant la transmission immédiate des événements de type e dont la date d'occurrence appartient à l'intervalle temporel [ti,t2]. Le message « focus e on [tχ,t2] » signale donc à l'agent sur quelle plage temporelle le manager souhaite recevoir des événements de type e dès que possible. Ainsi, un événement de type e hors de cette plage peut être mémorisé par l'agent, ou bien envoyé au manager si l'agent souhaite alléger son tampon. On peut remarquer que la mémorisation dans le tampon de l'agent ou la transmission au manager peut être déterminée en fonction de la capacité de stockage de l'agent et/ou du contexte d'application.
Le manager 14 peut également envoyer à destination de l'agent 11 une requête de suppression d'un type d'événement 24 sur un intervalle temporel, encore appelée « filter e on [t^] », requérant la suppression des événements de type e dont la date d'occurrence appartient à l'intervalle temporel [tχ,t2]. Le message « filter e on [tj ,t2] » signale donc à l'agent que les événements de type e sur cette plage temporelle n'intéresse plus le manager et que l'agent peut les éliminer.
Ainsi, les fenêtres d'exclusion et de sélection sont mises à jour lorsque le manager envoie des messages de type filter et/ou focus.
On peut notamment remarquer que l'utilisation de ces nouvelles requêtes de focalisation permet également de remonter toutes les informations au superviseur par l'envoi par le manager d'un (et d'un seul) message « focus e on ]- oo,+∞[". À l'opposé, le filtrage absolu de tous les événements de type e est réalisé par l'envoi du message « filter e on ]-∞,+∞[ ».
C) Gestion des fenêtres de focalisation temporelle et des tampons
On présente ci-après quatre algorithmes de gestion des fenêtres de focalisation temporelle et du buffer de l'agent dans les quatre cas suivants :
1. lors de la réception d'un message de type « e[param],t » (21), c'est-à- dire la réception d'un nouvel événement à traiter ;
2. lors de la réception d'un message de type « no more e in [tχ,t2] » (22), permettant notamment de gérer la fenêtre de non occurrence NM(e) ;
3. lors de la réception d'une requête de recherche d'un type d'événement sur un intervalle temporel (requête de type « focus » 23) de la part du manager, permettant notamment de gérer la fenêtre de sélection F(e) ;
4. lors de la réception d'une requête de filtrage d'un type d'événement sur un intervalle temporel (requête de type « filter » 24) de la part du manager, permettant notamment de gérer la fenêtre d'exclusion X(e).
On présente ainsi, en relation avec la figure 3 A, l'algorithme de prise en compte par l'agent d'un nouvel événement à transmettre au manager, à mémoriser dans un tampon, ou à supprimer (c'est-à-dire à filtrer).
Ainsi, lors de la réception 311 d'un nouvel événement de type e et de date t, noté (e,t), on vérifie au cours d'une étape 312 la présence de cet événement e dans la fenêtre d'exclusion X(e) associée au type d'événement e. Autrement dit, on vérifie que la date t appartient bien à la fenêtre temporelle X(e). En cas de détermination positive, l'événement (e,t) est supprimé (313). En cas de détermination négative, on vérifie au cours d'une étape 314 la présence de cet événement e dans la fenêtre de sélection F(e) associée au type d'événement e. En cas de détermination positive, l'événement (e,t) est envoyé au manager
(315).
En cas de détermination négative, l'événement (e,t) est mémorisé dans un tampon de l'équipement de collecte associé au type de l'événement (316).
On rappelle notamment que la mémorisation peut être remplacée par une transmission de l'événement au manager lorsque les capacités de l'agent sont atteintes.
Plus précisément, on présente en relation avec les figures 4A à 4E le contenu du tampon en fonction de la gestion des fenêtres de focalisation temporelles. Ainsi, la figure 4A illustre un exemple de l'état d'un tampon 41 associé aux événements de type e, comprenant trois événements de type e 411, 412, et 413, et de dates tA, tβ, et t^. A l'instant courant, les trois fenêtres d'exclusion X(e), de sélection F(e) et de non occurrence NM(e) sont telles que :
NM(e) = [to, ti] ; - X(e) = [t2, t3] ;
F(e) = [t4, t5] ; avec t0 < tA < tB < ti < t2 < t3 < tc < t4 < t5.
On peut constater sur cette figure 4A que les portions du buffer 41 correspondant aux fenêtres de focalisation temporelle X(e) et F(e) sont vides d'événements, puisqu'un événement appartenant à la fenêtre d'exclusion X(e) est immédiatement éliminé et un événement appartenant à la fenêtre de sélection F(e) est immédiatement transmis au superviseur, éventuellement par l'intermédiaire d 'équipements intermédiaires de collecte.
Plus précisément, lorsqu'un nouvel événement de type e (c'est-à-dire du même type que le tampon 41 illustré) et de date te est reçu, quatre cas sont pris en compte, respectivement illustrés par les figures 4B à 4E.
Ainsi, comme indiqué en relation avec la figure 4B, si un nouvel événement 42 est présent dans la fenêtre d'exclusion X(e), c'est-à-dire si te <≡ X(e), alors ce nouvel événement 42 est immédiatement éliminé. En effet, le manager 14 n'aura jamais besoin de cet événement 42.
Comme illustré en relation avec la figure 4C, si le nouvel événement 42 est présent dans la fenêtre de sélection F(e), c'est-à-dire si te <≡ F(e), alors ce nouvel événement 42 est immédiatement transmis au manager, sans être préalablement stocké dans le tampon 41. En revanche, comme illustré en relation avec la figure 4D, si le nouvel événement 42 n'est présent ni dans la fenêtre de non occurrence NM(e), ni dans la fenêtre d'exclusion X(e), ni dans la fenêtre de sélection F(e), c'est-à-dire si te £ (NM(e)uX(e)uF(e)), alors ce nouvel événement 42 est mémorisé dans le tampon 41. Le tampon 41 comprend donc les événements 411, 412, et 4I3, précédemment mémorisés, et le nouvel événement 42, tous de type e.
Finalement, la figure 4E illustre une situation interdite : en effet, si le réseau de collecte est bien spécifié, le nouvel événement 42 ne peut pas appartenir à la fenêtre de non occurrence NM(e). Il ne peut donc pas avoir une date te appartenant à la fenêtre de non occurrence NM(e). Un message d'erreur doit donc être envoyé si une telle situation se produit.
On revient désormais, en relation avec la figure 3B, au deuxième algorithme de gestion des fenêtres de focalisation temporelle et du buffer de l'agent, lors de la réception d'un message de type « no more e » sur un intervalle prédéterminé. Ainsi, lors de la réception 321 d'un message « no more e in I », signifiant que l'agent ne doit plus recevoir d'événement de type e avec une date t appartenant à l'intervalle I, on met à jour, au cours d'une étape 322, la fenêtre de focalisation temporelle de non occurrence NM(e). Plus précisément, la fenêtre de non occurrence mise à jour est définie par NM(e)uI. Les fenêtres de focalisation temporelle d'exclusion X(e) et de sélection F(e) sont ensuite mises à jour au cours d'une étape 323. La fenêtre d'exclusion mise à jour est alors définie par X(e)\NM(e) et la fenêtre de sélection mise à jour par F(e)\NM(e), où l'opérateur \ désigne la différence ensembliste.
Selon ce mode de réalisation particulier, on définit ainsi un ordre de priorité pour la mise à jour des fenêtres temporelles. Ainsi, la fenêtre de non occurrence NM(e) a la priorité la plus forte, suivie de la fenêtre d'exclusion X(e), suivie de la fenêtre de sélection F(e).
Ainsi, à réception d'un ordre de mise à jour pour une fenêtre I, suivant la nature de la mise à jour, les fenêtres de priorité plus forte « absorbent » tout ou partie de l'intervalle I.
La figure 5 A illustre plus précisément la mise à jour des fenêtres de focalisation temporelle et du tampon 41, les éléments déjà décrits portant les mêmes références que celles utilisées dans les figures 4A à 4E.
Comme indiqué précédemment, la mise à jour de la fenêtre de non occurrence NM(e) est suivie de la mise à jour des fenêtres d'exclusion et de sélection :
NM(e)^NM(e)uI ; X(e)<-X(e)\NM(e) ; F(e)<-F(e)\NM(e) ; où l'opérateur \ désigne la différence ensembliste (par exemple, [5,10] \ [2,7] = [8,10] dans les entiers naturels). A titre d'exemple, si on considère : NM(e) = [0,10] ; X(e) = [11,13] ; - F(e) = [15,20] ; et
I = [4,17] ; alors la mise à jour de la fenêtre de non occurrence conduit à
NM(e) = [0,10]u[4,17] = [0,17], et la mise à jour des fenêtres d'exclusion et de sélection conduit à X(e) = [11,13] \ [0,17] = 0 et F(e) = [15,20] \ [0,17] = [18,20]. La figure 3 C illustre le troisième algorithme de gestion des fenêtres de focalisation temporelle et du buffer de l'agent, lors de la réception d'une requête de focalisation de type recherche d'un type d'événement sur un intervalle temporel (requête de type « focus »).
Ainsi, lors de la réception 331 d'un message « focus e on I », par lequel le manager signale à l'agent qu'il souhaite recevoir des événements de type e dès que possible ayant une date d'occurrence appartenant à l'intervalle I, l'agent vérifie si un premier événement de type e et de date t\, noté (e,tj), est présent dans le tampon associé au type d'événement e (332).
En cas de vérification négative, la fenêtre de sélection F(e) est mise à jour au cours d'une étape 333, et le message « no more e in InNM(e) » est transmis au manager au cours d'une étape 338. Plus précisément, la fenêtre de sélection mise à jour est définie par F(e)u(I\(NM(e)uX(e)).
En cas de vérification positive, on vérifie au cours d'une étape 334 si la date ti de l'événement (e,tχ) appartient à l'intervalle I (corrélation temporelle entre la date tj et l'intervalle temporel I). Si cette condition est vérifiée, l'événement (e,tχ) est transmis au manager au cours d'une étape 335, et supprimé du tampon (336). On vérifie ensuite si un autre événement de type e et de date t2, noté (e,t2), est présent dans le tampon associé au type d'événement e, au cours d'une étape 337. Si tel est le cas, on retourne à l'étape 334, et on vérifie si la date t2 de l'événement (e,t2) appartient à l'intervalle I. Si tel est le cas, on réitère les étapes 335, 336 et 337 ; sinon, on retourne à l'étape 337.
Une fois que tous les événements de type e du tampon ont été transmis au manager, on met à jour la fenêtre de sélection F(e), comme décrit précédemment en relation avec l'étape 333 : F(e)<— F(e)u(I\(NM(e)uX(e)). Finalement, le message « no more e in InNM(e) » est transmis au manager au cours de l'étape 338 décrite précédemment.
La figure 5B illustre plus précisément la mise à jour des fenêtres de focalisation temporelle et du tampon 41.
Comme indiqué précédemment, on met à jour la fenêtre de sélection F(e), telle que F(e)<-F(e)u(I\(NM(e)uX(e)). Ainsi, à titre d'exemple, si on considère : NM(e) = [0,10] ; X(e) = [11,13] ; F(e) = [15,20] ; et - I = [4,17] ; alors la mise à jour de la fenêtre de sélection conduit à :
F(e) = [15,20]u([4,17]\([0,10]u[l 1,13]) = [15,20]u([4,17] \ [0,13]) F(e) = [15,20]u[14,17] = [14,20].
Les fenêtres de non occurrence NM(e) et d'exclusion X(e) ne sont pas modifiées.
De plus, les événements 412 et 413, dont les dates d'occurrence sont tg et tç, avec tβ e I et tç e I, sont envoyés au manager, puis supprimés du tampon 41.
Autrement dit, les événements du tampon tels que date(e)el sont envoyés au manager et supprimés du buffer. La figure 3D illustre finalement le quatrième algorithme de gestion des fenêtres de focalisation temporelle et du buffer de l'agent, lors de la réception d'une requête de focalisation de type filtrage d'un type d'événement sur un intervalle temporel (requête de type « filter»).
Ainsi, lors de la réception 341 d'un message « filter e on I », par lequel le manager signale à l'agent que les événements de type e ayant une date d'occurrence appartenant à l'intervalle I ne l'intéresse plus, l'agent vérifie si un premier événement de type e et de date t\, noté (e,tχ), est présent dans le tampon associé au type d'événement e (342).
En cas de vérification négative, la fenêtre d'exclusion X(e) est mise à jour au cours d'une étape 343. Plus précisément, la fenêtre d'exclusion mise à jour est définie par X(e)u(I\(NM(e)). Ensuite, la fenêtre de sélection F(e) est mise à jour au cours d'une étape 344 : F(e)<— F(e)\X(e). Finalement, le message « no more e in I » est transmis au manager au cours d'une étape 348.
En cas de vérification positive, on vérifie au cours d'une étape 345 si la date ti de l'événement (e,tχ) appartient à l'intervalle I (corrélation temporelle entre la date t\ et l'intervalle temporel I). Si cette condition est vérifiée, l'événement (e,tχ) est supprimé du tampon (346). On vérifie ensuite si un autre événement de type e et de date t2, noté (e,t2), est présent dans le tampon associé au type d'événement e, au cours d'une étape 347. Si tel est le cas, on retourne à l'étape 345, et on vérifie si la date t2 de l'événement (e,t2) appartient à l'intervalle I. Si tel est le cas, on réitère les étapes 346 et 347 ; sinon, on retourne à l'étape 347.
Une fois que tous les événements de type e du tampon ont été supprimé, on met à jour la fenêtre d'exclusion X(e), puis la fenêtre de sélection F(e), comme décrit précédemment en relation avec les étapes 343 et 344 : X(e)<-X(e)u(I\(NM(e)) et F(e)<-F(e)\X(e).
De plus, comme décrit précédemment en relation avec l'étape 348, le message « no more e in I » est finalement transmis au manager.
La figure 5 C illustre plus précisément la mise à jour des fenêtres de focalisation temporelle et du tampon 41.
Comme indiqué précédemment, la mise à jour de la fenêtre d'exclusion X(e) est suivie de la mise à jour de la fenêtre de sélection F(e) : X(e)f-X(e)u(I\(NM(e)) ; et F(e)<- F(e)\X(e). A titre d'exemple, si on considère de nouveau :
NM(e) = [0,10] ; X(e) = [11,13] ; F(e) = [15,20] ; et I = [4,17] ; alors la mise à jour de la fenêtre d'exclusion conduit à X(e) = [l l,13]u([4,17] \ [0,10]) = [l l,13]u[l l,17] = [11,17] , et la mise àjour de la fenêtre de sélection conduit à F(e) = [15,20] \ [11,17] = [18,20]. La fenêtre de non occurrence n'est pas modifiée.
De plus, les événements 412 et 413, dont les dates d'occurrence sont tβ et te, avec tβ e I et te e I, sont supprimés du buffer 41. Autrement dit, les événements de type e du tampon tels que date(e)el sont supprimés du buffer.
D) Exemples d'application de l'invention à la gestion du « handover » On présente finalement, en relation avec la figure 6, un exemple d'application de l'invention, permettant la collecte d'informations sur des téléphones mobiles 611, 6I2 et 6I3, pour la gestion du « handover » (autrement dit, pour la réalisation d'un module de décision (ou de politique) de handover).
Selon cet exemple, dans lequel le réseau de collecte comprend une structure hiérarchique sur trois niveaux, les événements élémentaires de plus bas niveau sont issus de téléphones mobiles (par exemple 611, 6I2 ou 6I3) et, lors de la corrélation de plusieurs événements (par exemple du type qualité du signal, service utilisé, type du client, préférence de l'utilisateur...), un opérateur souhaite pouvoir décider de basculer ce(s) téléphone(s) mobile(s) vers un autre réseau.
Classiquement, les événements issus des téléphones mobiles 611, 6I2 ou 613, associés à des équipements de collecte, par exemple des agents, sont transmis au niveau supérieur, c'est-à-dire aux équipements de collecte intermédiaire des stations de base 62χ et 622- Ces équipements de collecte intermédiaires génèrent également des événements élémentaires. Les équipements de collecte intermédiaires associés aux stations de base 62χ et 622 jouent donc à la fois le rôle d'équipement de collecte terminal et de superviseur. L'ensemble des événements est ensuite transmis au niveau supérieur, c'est-à-dire au superviseur associé au gestionnaire de décision 63.
En revanche, selon cet exemple de réalisation de l'invention, plutôt que de remonter l'ensemble des événements au gestionnaire de décision 63 (i.e. autant qu'il y a de mobiles connectés au réseau via l'ensemble des bases), une corrélation est effectuée au niveau des stations de base 62 \ et 622 , et au niveau du gestionnaire de décision 63, et des fenêtres de focalisation temporelles sont positionnées, de façon à éviter que le mobile n'envoie en permanence des informations et que les stations de base sollicitent inutilement le gestionnaire de décision. Par exemple, à titre d'illustration, on suppose que l'on cherche à corréler des demandes de handover entre plusieurs stations de base suite à un problème sur une des stations de base (notées basel 62χ et base2 622), et donc à un problème de rejet de mobiles. Le scénario à surveiller est le suivant : lorsqu'une station de base, par exemple basel, a un problème {émission d'une alarme BASE_HS[basel] par un équipement de collecte à destination de son superviseur) et commence à rejeter des connexions {émission d'une alarme HANDOVER_OUT[basel ] par chaque mobile impacté), les mobiles impactés tentent de se connecter sur une station de base voisine, par exemple base2 {avec émission d'alarmes HANDOVER_IN[base2] par chacun des mobiles effectivement basculés), l'ensemble du scénario se déroulant dans un délai Δ.
Selon une approche classique, telle que proposée en relation avec l'art antérieur, le superviseur collecte en permanence tous les événements BASE HS, HANDOVER IN et HANDOVER OUT afin de pouvoir réaliser une corrélation et vérifier la réalisation du scénario à surveiller. Autrement dit, même lorsque aucune station de base n'est hors service, les événements HANDOVER_IN/OUT sont collectés inutilement, juste « au cas où » un problème surviendrait, et ce même dans les cas où ces événements sont émis par les mobiles lorsqu'ils changent de station de base pour des raisons autres que la réalisation du scénario à surveiller (par exemple lorsque l'utilisateur du téléphone mobile se déplace).
En revanche, selon le mode de réalisation particulier décrit précédemment l'invention met en œuvre les étapes suivantes :
1. réception d'une alarme BASE_HS[basel] par le superviseur du gestionnaire de décision 63 à l'instant t ;
2. le gestionnaire de décision 63 demande à la basel 62 \ l'envoi (message de type « focus ») des événements de type HANDOVER_OUT[basel] sur un intervalle temporel I = [t, t+ Δ] ;
3. le gestionnaire de décision 63 demande à la base2 622 (station de base voisine) l'envoi (message de type « focus ») des événements de type HANDO VER_IN[base2] sur un intervalle temporel I = [t, t+ Δ] ;
4. le superviseur (équipement de collecte intermédiaire) de la basel 62 \ retransmet la demande aux mobiles 61 i, 6I2 et 6l3 ;
5. le superviseur (équipement de collecte intermédiaire) de la base2 622 retransmet la demande aux mobiles 6I 1, 6I2 et 6I3.
On constate ainsi que selon ce mode de réalisation particulier de l'invention, le système de collecte propage les fenêtres de focalisation temporelle de proche en proche.
Par exemple, dans le cadre de l'utilisation du protocole SNMP, on considère un nœud de collecte de niveau N de hiérarchie tenant le rôle de manager pour un nœud N-I de niveau inférieur, et tenant le rôle d'agent pour un manager N+l de niveau supérieur. Dans ce cas, une requête de type recherche d'un type d'événement (message de type « focus ») en provenance du manager N+l du nœud N est transmis à (aux) agent(s) N-I du nœud N, par l'intermédiaire du nœud N. De même, une requête de type filtrage d'un type d'événement (message de type « filter ») en provenance du manager N+l du nœud N est transmis à (aux) agent(s) N-I du nœud N, par l'intermédiaire du nœud N. A l'inverse, un événement en provenance d'un des agents N-I est transmis (ou filtré ou stocké) vers le manager N+l, par l'intermédiaire du nœud N, en accord avec les algorithmes présentés en relation avec les figures 3A,3B, 3C et 3D.
En particulier, un message de type « focus » et/ou « filter » peut être adapté avant d'être retransmis au niveau inférieur. Par exemple, si un agent N est chargé de compter les événements de type e sur une période de temps prédéterminée (par exemple 1 heure), et de remonter l'information toutes les 10 minutes (cas d'un comptage sur fenêtre glissante), alors si cet agent reçoit une requête de filtrage sur l'intervalle temporel [13h,14h30], il peut transmettre à ses sources (c'est-à-dire aux agents N-I) l'instruction « filter » sur [12h50,13h30], pour tenir compte de la plage de comptage et du glissement de la fenêtre glissante.
L'optimisation de la collecte selon l'invention se propage donc dans toute la hiérarchie de collecte, et pas seulement entre deux niveaux successifs du réseau de collecte. La réduction du nombre d'événements circulant dans le réseau de collecte en est donc d'autant plus importante.
Ainsi, en revenant à l'exemple présenté, pour la station de base « basel »
621, seuls les événements de type HANDO VER OUT compris dans l'intervalle [t,t+Δ] ont besoin de transiter dans le réseau de collecte, et pour la station de base
« base2 » 622, seuls les événements de type HANDOVER_IN compris dans l'intervalle [t,t+Δ] sont nécessaires au superviseur.
En revanche, lorsque le superviseur ne reçoit pas d'événements de type BASE HS, la mise à jour des différents tampons des agents de collecte met en œuvre les étapes suivantes :
1. l'horloge du superviseur du gestionnaire de décision 63 passe à l'instant t ;
2. envoi à la basel 621 d'une requête de filtrage (message de type filter) des événements de type HANDOVER_OUT[basel] sur l'intervalle temporel
]-∞, t] ; 3. envoi à la base2 622 d'une requête de filtrage (message de type filter) des événements de type HANDOVER_IN[base2] sur l'intervalle temporel ]-∞, t] ;
4. le superviseur de la basel 62 \ retransmet la demande aux mobiles 61 \, 6I2 et 613 ; 5. le superviseur de la base2 622 retransmet la demande aux mobiles 61 \, 6I2 et 613.
On présente également un deuxième exemple d'application de l'invention, permettant la remontée de statistiques du réseau surveillé.
On considère selon ce deuxième exemple qu'un mobile présent dans le réseau requiert une connexion vidéo (ou une connexion à un autre service disponible), ce mobile étant apte à se connecter à différents types de réseau : par exemple, il peut se connecter au réseau soit par WiFi, soit par GPRS (capacités de handover).
La décision de bascule vers le réseau WiFi ou GPRS dépend de la politique mise en œuvre par un opérateur, et peut s'appuyer sur plusieurs critères. On considère par exemple qu'elle s'appuie uniquement sur une moyenne sur un temps Δ du débit cumulé de tous les mobiles déjà connectés par Wifi à la même station de base radiofréquence que le mobile requérant la connexion vidéo. Lorsqu'un utilisateur active le service vidéo, il faut donc connaître cette moyenne, notée M. Le scénario à surveiller est donc : si M est supérieure à la moyenne de référence, alors il faut basculer sur le réseau GPRS sinon, il faut se connecter par Wifi.
Selon l'art antérieur, il faut donc collecter régulièrement toutes les informations de débit nécessaires, afin qu'un gestionnaire de décision ait l'information lorsqu'un utilisateur active le service vidéo. Comme déjà indiqué en relation avec les inconvénients de l'art antérieur, on obtient une collecte d'informations inutiles, dans la mesure où le débit est systématiquement calculé, même lorsque cette information n'est pas pertinente.
Selon l'invention, le mode de réalisation particulier décrit permet, sur réception d'un événement de type « demande de service vidéo » à un instant t, de propager automatiquement la collecte des débits sur une fenêtre [t-Δ, t], d'en calculer la moyenne et de la transmettre au niveau supérieur. La mise à jour des tampons peut être mise en œuvre à chaque instant t par l'envoi d'une requête de filtrage sur l'intervalle ]-∞,t-Δ] (message de type « filter »). 5.3 Structure des dispositifs de collecte et de supervision
On présente finalement, en relation avec les figures 7A et 7B, la structure simplifiée d'un équipement de collecte et d'un dispositif de supervision mettant respectivement en œuvre en œuvre une technique de collecte de données et une technique de supervision de la collecte selon le mode de réalisation particulier décrit ci-dessus.
Un tel équipement de collecte comprend une mémoire 71 constituée d'une mémoire tampon, une unité de traitement 72, équipée par exemple d'un microprocesseur μP, et pilotée par le programme d'ordinateur 73, mettant en œuvre le procédé d'optimisation de la collecte selon l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 73 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 72. L'unité de traitement 72 reçoit en entrée au moins un événement et des informations permettant de gérer au moins une fenêtre de focalisation temporelle. Le microprocesseur de l'unité de traitement 72 met en œuvre les étapes du procédé d'optimisation de la collecte décrit précédemment, selon les instructions du programme d'ordinateur 73, pour décider si chacun des événements reçus doit être mémorisé dans l'équipement de collecte, supprimé, ou transmis à un superviseur. Pour cela, l'équipement de collecte comprend, outre la mémoire tampon 71, des moyens de gestion d'au moins une fenêtre de focalisation temporelle associée à au moins un type d'événement, des moyens de vérification de la présence d'un événement dans au moins une des fenêtres de focalisation lors de la réception de cet événement, et des moyens de traitement spécifique associé au type de fenêtre de focalisation. Ces moyens sont pilotés par le microprocesseur de l'unité de traitement 72. L'unité de traitement 72 transmet donc au superviseur les événements nécessaires à la mise en œuvre d'une corrélation ou de tout autre tâche consommatrice d'événements.
Ainsi, l'invention propose selon le mode de réalisation particulier décrit un système de filtrage automatique des informations à remonter à un superviseur, ce filtrage étant obtenu en positionnant des filtres dynamiques de façon à garantir le même résultat final que si aucun filtre n'était positionné. Les filtres ne servent donc qu'à supprimer de l'information inutile.
Le dispositif de supervision comprend également une mémoire 74, une unité de traitement 75, équipée par exemple d'un microprocesseur μP, et pilotée par le programme d'ordinateur 76, mettant en œuvre le procédé de supervision de la collecte selon l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur 76 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 75. L'unité de traitement 75 reçoit des événements transmis par un équipement de collecte, et émet des informations permettant de gérer au moins une fenêtre de focalisation temporelle, par exemple des requêtes de focalisation temporelle. Le microprocesseur de l'unité de traitement 75 met en œuvre les étapes du procédé de supervision de la collecte décrit précédemment, selon les instructions du programme d'ordinateur 76, pour gérer et mettre à jour les différentes fenêtres de focalisation temporelle.

Claims

REVENDICATIONS
1. Procédé d'optimisation de la collecte d'événements générés par au moins un équipement de collecte (11) et destinés à un superviseur (14), caractérisé en ce qu'au moins un desdits équipements de collecte (11) met en œuvre une étape de gestion d'au moins une fenêtre de focalisation temporelle associée à au moins un type d'événement, et en ce que, à chaque réception d'un événement, ledit au moins un équipement de collecte (11) met en œuvre une étape de vérification de la présence dudit événement dans au moins une desdites fenêtres de focalisation temporelle associée au type dudit événement, telle que : en cas de vérification positive, un traitement spécifique associé au type de ladite fenêtre de focalisation temporelle dans laquelle la présence dudit événement est vérifiée est mis en œuvre ; en cas de vérification négative, une mémorisation dudit événement dans un tampon dudit équipement de collecte est mise en œuvre.
2. Procédé d'optimisation de la collecte d'événements selon la revendication 1, caractérisé en ce que ladite étape de gestion gère, pour au moins un desdits types d'événements, au moins une des fenêtres de focalisation temporelle du type appartenant au groupe comprenant : - une fenêtre d'exclusion, telle que lorsque la présence dudit événement est vérifiée dans ladite fenêtre d'exclusion, ledit traitement spécifique met en œuvre une suppression dudit événement ; une fenêtre de sélection, telle que lorsque la présence dudit événement est vérifiée dans ladite fenêtre de sélection, ledit traitement spécifique met en œuvre une transmission dudit événement audit superviseur ; une fenêtre de non occurrence, définissant une période durant laquelle aucun événement dudit type d'événement ne peut survenir.
3. Procédé d'optimisation de la collecte d'événements selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite étape de gestion comprend une étape de mise à jour de ladite au moins une fenêtre de focalisation temporelle et dudit tampon, en fonction d'une requête de focalisation temporelle issue dudit superviseur.
4. Procédé d'optimisation de la collecte d'événements selon les revendications 2 et 3, caractérisé en ce que ladite requête de focalisation temporelle issue dudit superviseur est une requête de recherche d'un type d'événement sur un intervalle temporel, et en ce que ledit équipement de collecte met en œuvre les sous-étapes suivantes : vérification de la présence d'au moins un événement dudit type d'événement recherché dans ledit tampon ; - en cas de vérification positive et de corrélation temporelle entre ledit intervalle temporel et la date du ou desdits événements dudit type d'événement recherché présents dans ledit tampon : transmission du ou desdits événements audit superviseur et suppression du ou desdits événements transmis dudit tampon ; - mise à jour de ladite fenêtre de sélection.
5. Procédé d'optimisation de la collecte d'événements selon les revendications 2 et 3, caractérisé en ce que ladite requête de focalisation temporelle issue dudit superviseur est une requête de filtrage d'un type d'événement sur un intervalle temporel, et en ce que ledit équipement de collecte met en œuvre les sous-étapes suivantes : vérification de la présence d'au moins un événement dudit type d'événement à filtrer dans ledit tampon ; en cas de vérification positive et de corrélation temporelle entre ledit intervalle temporel et la date du ou desdits événements dudit type d'événement à filtrer présents dans ledit tampon : suppression du ou desdits événements dudit tampon ; mise à jour de ladite fenêtre d'exclusion.
6. Procédé d'optimisation de la collecte d'événements selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit équipement de collecte est un équipement terminal ou un équipement intermédiaire d'un réseau de radiocommunication.
7. Procédé de supervision de la collecte d'événements générés par au moins un équipement de collecte (11) et destinés à un superviseur (14), caractérisé en ce qu'il comprend une étape de transmission dudit superviseur à au moins un desdits équipements de collecte d'au moins une information permettant de gérer au moins une fenêtre de focalisation temporelle associée à au moins un type d'événement, et une étape de réception d'événements transmis par au moins un desdits équipements de collecte, lesdits événements transmis étant présents dans au moins une desdites fenêtres de focalisation temporelle d'un type prédéterminé.
8. Procédé de supervision de la collecte d'événements selon la revendication 7, caractérisé en ce que ladite au moins une information est une requête de focalisation temporelle, appartenant au groupe comprenant au moins : une requête de recherche d'un type d'événement sur un intervalle temporel ; une requête de filtrage d'un type d'événement sur un intervalle temporel.
9. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre du procédé d'optimisation de la collecte d'événements selon l'une au moins des revendications 1 à 6.
10. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre du procédé de supervision de la collecte d'événements selon l'une au moins des revendications 7 et 8.
11. Equipement de collecte (11) d'au moins un événement destiné à un superviseur (14), caractérisé en ce qu'il comprend : - des moyens de gestion d'au moins une fenêtre de focalisation temporelle associée à au moins un type d'événement, des moyens de vérification de la présence d'un événement dans au moins une desdites fenêtres de focalisation temporelle associée au type dudit événement, mis en œuvre à chaque réception d'un événement, - des moyens de traitement spécifique associé au type de ladite fenêtre de focalisation temporelle dans laquelle la présence dudit événement est vérifiée, mis en œuvre en cas de vérification positive, et des moyens de mémorisation dudit événement dans un tampon, mis en œuvre en cas de vérification négative.
12. Dispositif de supervision (14) de la collecte d'événements générés par au moins un équipement de collecte (11) et destinés à un superviseur, caractérisé en ce qu'il comprend des moyens de transmission à au moins un desdits équipements de collecte d'au moins une information permettant de gérer au moins une fenêtre de focalisation temporelle associée à au moins un type d'événement, et des moyens de réception d'événements transmis par au moins un desdits équipements de collecte, lesdits événements transmis étant présents dans au moins une desdites fenêtres de focalisation temporelle d'un type prédéterminé.
PCT/FR2007/051140 2006-04-20 2007-04-19 Procede d'optimisation de la collecte d'evenements, procede de supervision, produits programmes d'ordinateur et dispositifs correspondants WO2007122347A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0603514 2006-04-20
FR0603514 2006-04-20

Publications (1)

Publication Number Publication Date
WO2007122347A1 true WO2007122347A1 (fr) 2007-11-01

Family

ID=37695527

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2007/051140 WO2007122347A1 (fr) 2006-04-20 2007-04-19 Procede d'optimisation de la collecte d'evenements, procede de supervision, produits programmes d'ordinateur et dispositifs correspondants

Country Status (1)

Country Link
WO (1) WO2007122347A1 (fr)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014113273A3 (fr) * 2013-01-15 2015-01-29 Oracle International Corporation Fenêtres à durée variable sur des flux continus de données
US9047249B2 (en) 2013-02-19 2015-06-02 Oracle International Corporation Handling faults in a continuous event processing (CEP) system
US9058360B2 (en) 2009-12-28 2015-06-16 Oracle International Corporation Extensible language framework using data cartridges
US9098587B2 (en) 2013-01-15 2015-08-04 Oracle International Corporation Variable duration non-event pattern matching
US9110945B2 (en) 2010-09-17 2015-08-18 Oracle International Corporation Support for a parameterized query/view in complex event processing
US9189280B2 (en) 2010-11-18 2015-11-17 Oracle International Corporation Tracking large numbers of moving objects in an event processing system
US9244978B2 (en) 2014-06-11 2016-01-26 Oracle International Corporation Custom partitioning of a data stream
US9256646B2 (en) 2012-09-28 2016-02-09 Oracle International Corporation Configurable data windows for archived relations
US9262479B2 (en) 2012-09-28 2016-02-16 Oracle International Corporation Join operations for continuous queries over archived views
US9305238B2 (en) 2008-08-29 2016-04-05 Oracle International Corporation Framework for supporting regular expression-based pattern matching in data streams
US9329975B2 (en) 2011-07-07 2016-05-03 Oracle International Corporation Continuous query language (CQL) debugger in complex event processing (CEP)
US9390135B2 (en) 2013-02-19 2016-07-12 Oracle International Corporation Executing continuous event processing (CEP) queries in parallel
US9418113B2 (en) 2013-05-30 2016-08-16 Oracle International Corporation Value based windows on relations in continuous data streams
US9430494B2 (en) 2009-12-28 2016-08-30 Oracle International Corporation Spatial data cartridge for event processing systems
US9712645B2 (en) 2014-06-26 2017-07-18 Oracle International Corporation Embedded event processing
US9756104B2 (en) 2011-05-06 2017-09-05 Oracle International Corporation Support for a new insert stream (ISTREAM) operation in complex event processing (CEP)
US9886486B2 (en) 2014-09-24 2018-02-06 Oracle International Corporation Enriching events with dynamically typed big data for event processing
US9934279B2 (en) 2013-12-05 2018-04-03 Oracle International Corporation Pattern matching across multiple input data streams
US9972103B2 (en) 2015-07-24 2018-05-15 Oracle International Corporation Visually exploring and analyzing event streams
US10120907B2 (en) 2014-09-24 2018-11-06 Oracle International Corporation Scaling event processing using distributed flows and map-reduce operations
CN112083958A (zh) * 2020-08-14 2020-12-15 陕西千山航空电子有限责任公司 一种基于RapidIO的飞参数据的存储结构及存储方法
US10956422B2 (en) 2012-12-05 2021-03-23 Oracle International Corporation Integrating event processing with map-reduce

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995033352A2 (fr) * 1994-06-01 1995-12-07 Ericsson A/S Systeme de controle de reseaux telephoniques et/ou de reseaux de communication de donnees, en particulier, des reseaux de telephones mobiles
US5781703A (en) * 1996-09-06 1998-07-14 Candle Distributed Solutions, Inc. Intelligent remote agent for computer performance monitoring
WO2002005154A2 (fr) * 2000-07-10 2002-01-17 It Masters Technologies S.A. Systeme et procede de gestion de systemes d'entreprise et d'incidence sur les activites commerciales
US6629139B1 (en) * 1999-09-01 2003-09-30 International Business Machines Corporation Reactive detection of conditions of interest in distributed systems

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995033352A2 (fr) * 1994-06-01 1995-12-07 Ericsson A/S Systeme de controle de reseaux telephoniques et/ou de reseaux de communication de donnees, en particulier, des reseaux de telephones mobiles
US5781703A (en) * 1996-09-06 1998-07-14 Candle Distributed Solutions, Inc. Intelligent remote agent for computer performance monitoring
US6629139B1 (en) * 1999-09-01 2003-09-30 International Business Machines Corporation Reactive detection of conditions of interest in distributed systems
WO2002005154A2 (fr) * 2000-07-10 2002-01-17 It Masters Technologies S.A. Systeme et procede de gestion de systemes d'entreprise et d'incidence sur les activites commerciales

Cited By (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9305238B2 (en) 2008-08-29 2016-04-05 Oracle International Corporation Framework for supporting regular expression-based pattern matching in data streams
US9058360B2 (en) 2009-12-28 2015-06-16 Oracle International Corporation Extensible language framework using data cartridges
US9430494B2 (en) 2009-12-28 2016-08-30 Oracle International Corporation Spatial data cartridge for event processing systems
US9305057B2 (en) 2009-12-28 2016-04-05 Oracle International Corporation Extensible indexing framework using data cartridges
US9110945B2 (en) 2010-09-17 2015-08-18 Oracle International Corporation Support for a parameterized query/view in complex event processing
US9189280B2 (en) 2010-11-18 2015-11-17 Oracle International Corporation Tracking large numbers of moving objects in an event processing system
US9756104B2 (en) 2011-05-06 2017-09-05 Oracle International Corporation Support for a new insert stream (ISTREAM) operation in complex event processing (CEP)
US9804892B2 (en) 2011-05-13 2017-10-31 Oracle International Corporation Tracking large numbers of moving objects in an event processing system
US9535761B2 (en) 2011-05-13 2017-01-03 Oracle International Corporation Tracking large numbers of moving objects in an event processing system
US9329975B2 (en) 2011-07-07 2016-05-03 Oracle International Corporation Continuous query language (CQL) debugger in complex event processing (CEP)
US9990401B2 (en) 2012-09-28 2018-06-05 Oracle International Corporation Processing events for continuous queries on archived relations
US10102250B2 (en) 2012-09-28 2018-10-16 Oracle International Corporation Managing continuous queries with archived relations
US9286352B2 (en) 2012-09-28 2016-03-15 Oracle International Corporation Hybrid execution of continuous and scheduled queries
US11288277B2 (en) 2012-09-28 2022-03-29 Oracle International Corporation Operator sharing for continuous queries over archived relations
US9262479B2 (en) 2012-09-28 2016-02-16 Oracle International Corporation Join operations for continuous queries over archived views
US9361308B2 (en) 2012-09-28 2016-06-07 Oracle International Corporation State initialization algorithm for continuous queries over archived relations
US11093505B2 (en) 2012-09-28 2021-08-17 Oracle International Corporation Real-time business event analysis and monitoring
US9292574B2 (en) 2012-09-28 2016-03-22 Oracle International Corporation Tactical query to continuous query conversion
US9256646B2 (en) 2012-09-28 2016-02-09 Oracle International Corporation Configurable data windows for archived relations
US10042890B2 (en) 2012-09-28 2018-08-07 Oracle International Corporation Parameterized continuous query templates
US9563663B2 (en) 2012-09-28 2017-02-07 Oracle International Corporation Fast path evaluation of Boolean predicates
US9703836B2 (en) 2012-09-28 2017-07-11 Oracle International Corporation Tactical query to continuous query conversion
US10025825B2 (en) 2012-09-28 2018-07-17 Oracle International Corporation Configurable data windows for archived relations
US9715529B2 (en) 2012-09-28 2017-07-25 Oracle International Corporation Hybrid execution of continuous and scheduled queries
US9990402B2 (en) 2012-09-28 2018-06-05 Oracle International Corporation Managing continuous queries in the presence of subqueries
US9805095B2 (en) 2012-09-28 2017-10-31 Oracle International Corporation State initialization for continuous queries over archived views
US9953059B2 (en) 2012-09-28 2018-04-24 Oracle International Corporation Generation of archiver queries for continuous queries over archived relations
US9852186B2 (en) 2012-09-28 2017-12-26 Oracle International Corporation Managing risk with continuous queries
US9946756B2 (en) 2012-09-28 2018-04-17 Oracle International Corporation Mechanism to chain continuous queries
US10956422B2 (en) 2012-12-05 2021-03-23 Oracle International Corporation Integrating event processing with map-reduce
US10644932B2 (en) 2013-01-15 2020-05-05 Oracle International Corporation Variable duration windows on continuous data streams
WO2014113273A3 (fr) * 2013-01-15 2015-01-29 Oracle International Corporation Fenêtres à durée variable sur des flux continus de données
US10298444B2 (en) 2013-01-15 2019-05-21 Oracle International Corporation Variable duration windows on continuous data streams
US9098587B2 (en) 2013-01-15 2015-08-04 Oracle International Corporation Variable duration non-event pattern matching
US9262258B2 (en) 2013-02-19 2016-02-16 Oracle International Corporation Handling faults in a continuous event processing (CEP) system
US9047249B2 (en) 2013-02-19 2015-06-02 Oracle International Corporation Handling faults in a continuous event processing (CEP) system
US9390135B2 (en) 2013-02-19 2016-07-12 Oracle International Corporation Executing continuous event processing (CEP) queries in parallel
US10083210B2 (en) 2013-02-19 2018-09-25 Oracle International Corporation Executing continuous event processing (CEP) queries in parallel
US9418113B2 (en) 2013-05-30 2016-08-16 Oracle International Corporation Value based windows on relations in continuous data streams
US9934279B2 (en) 2013-12-05 2018-04-03 Oracle International Corporation Pattern matching across multiple input data streams
US9244978B2 (en) 2014-06-11 2016-01-26 Oracle International Corporation Custom partitioning of a data stream
US9712645B2 (en) 2014-06-26 2017-07-18 Oracle International Corporation Embedded event processing
US9886486B2 (en) 2014-09-24 2018-02-06 Oracle International Corporation Enriching events with dynamically typed big data for event processing
US10120907B2 (en) 2014-09-24 2018-11-06 Oracle International Corporation Scaling event processing using distributed flows and map-reduce operations
US9972103B2 (en) 2015-07-24 2018-05-15 Oracle International Corporation Visually exploring and analyzing event streams
CN112083958A (zh) * 2020-08-14 2020-12-15 陕西千山航空电子有限责任公司 一种基于RapidIO的飞参数据的存储结构及存储方法
CN112083958B (zh) * 2020-08-14 2023-01-17 陕西千山航空电子有限责任公司 一种基于RapidIO的飞参数据的存储结构及存储方法

Similar Documents

Publication Publication Date Title
WO2007122347A1 (fr) Procede d&#39;optimisation de la collecte d&#39;evenements, procede de supervision, produits programmes d&#39;ordinateur et dispositifs correspondants
EP3066565B1 (fr) Procédé et programme d&#39;ordinateur pour l&#39;exécution déportée de tâches informatiques d&#39;un équipement sans fil
US8954571B2 (en) System and method for implementing histogram controlled mobile devices
KR102418969B1 (ko) 딥러닝 기반 통신망 장비의 장애 예측 시스템 및 방법
EP3533183B1 (fr) Procédé de sélection d&#39;une passerelle pour l&#39;émission d&#39;une trame
FR2906950A1 (fr) Procede et dispositifs pour adapter le debit de transmission d&#39;un flux de donnees en presence d&#39;interferences.
EP2061194A1 (fr) Procédé et système de gestion de communication
FR2988972A1 (fr) Procede de traitement de la reception d&#39;un signal de communication par voie radio, procede de traitement de l&#39;emission, dispositifs et programmes d&#39;ordinateur associes
FR2900529A1 (fr) Gestion de ressources radio dans un reseau de telecommunications radio
EP2832037B1 (fr) Procédés pour l&#39;application de règles de traitement de session en fonction d&#39;une carte de présence de terminaux mobiles dans des zones spéciales
EP1995932A2 (fr) Système et procédé de traitement d&#39;informations d&#39;état de presence à fiabilité améliorée
FR2996391A1 (fr) Mise en veille d&#39;un equipement connecte a un reseau a liens multiples
FR3016108A1 (fr)
FR3081238A1 (fr) Mise en memoire cache de base de donnees
EP2341728A1 (fr) Système et procédé de contrôle des communications dans un réseau ad-hoc mobile
EP3375169B1 (fr) Procédé de gestion du trafic réseau relatif à un mécanisme de signalisation de présence d&#39;un terminal
WO2022023670A1 (fr) PROCÉDÉ DE FOURNITURE DE DONNÉES RELATIVES À AU MOINS UN ÉQUIPEMENT D&#39;UN UTILISATEUR D&#39;UN RÉSEAU, PROCÉDÉ D&#39;OBTENTION DE DONNÉES, ET ENTITÉS METTANT EN œUVRE CES PROCÉDÉS
EP1952599B1 (fr) Procede de diffusion maitrisee d&#39;informations
FR2802675A1 (fr) Procede de supervision distribuee d&#39;indicateurs et agent de supervision d&#39;un systeme informatique
FR3090262A1 (fr) Procédé de détermination d’un chemin de transmission de données, et dispositif correspondant.
EP2464068B1 (fr) Système de gestion globale de filtrage personnalisé basé sur un circuit d&#39;échange d&#39;informations sécurisé et procédé associé
EP4380228A1 (fr) Procédé et dispositif de communication dans un réseau de communication sans fil
FR3133721A1 (fr) Procede ameliore de selection d’un canal de communication entre un aeronef et une station distante, et systeme de communication executant le procede.
EP4287052A1 (fr) Procédé et dispositif de génération d&#39;alerte
CA3141585A1 (fr) Procede et systeme de detection d&#39;incidents dans au moins un reseau local de communication

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07731915

Country of ref document: EP

Kind code of ref document: A1