Classifications

• • 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/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
• • 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/0654—Management of faults, events, alarms or notifications using network fault recovery
  • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
• • 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/08—Configuration management of networks or network elements

Definitions

• the present invention relates to communication networks and applies in particular but not exclusively to packet-oriented communication networks. It relates more particularly to the management of communication networks. It is known to associate with communication networks, network management systems (or NMSs for "Network Management System”) whose purpose is to collect alarms from the network equipment, to make a synthesis, including the means of correlation methods, and display this summary or its alarms to an operator so that it can implement a corrective action in case of failure of one or more of these equipment.
• the notion of "failure” must be understood in a very general sense meaning any type of malfunction, whether hardware or software. Thus, a bad configuration of a network element can be likened to a failure (software), as well as an error in a routing table of an IP router or a port inadvertently closed.
• Network management systems can also configure network equipment.
• the operator can enter new parameters through a human-machine interface and the network management system passes these new parameters on the equipment. In this way, the operator can correct a network failure in response to the display of alarms.
• Such centralized analysis relies on the collection of a large number of information and alarm data from the many elements of the communication network.
• These elements can be devices such as routers within the framework of a network of Internet Protocol (IP) communication, but they can also be Voice, Optical, Private Branch Exchange (PABX), Media Gateway (Media Gateway) switches in an NGN (Next Generation Network) network, and so on.
• a network element can also be a part of such equipment, such as a map for example.
• a failure on a card of an equipment can generate an alarm from all the cards of other equipment, connected to one of the ports of this card, as well as from the cards of the equipment in which the breakdown occurred.
• diagnostic systems which, based on this large number of alarms, determine the most likely cause (s). These diagnostic systems are based for example on sets of rules, such as those based on the product llogRules TM from the company Ilog. They can also rely on neural networks, Bayesian networks, expert systems or other techniques, including artificial intelligence.
• the object of the invention is to automate the correction of failures of the managed communication network, while ensuring that the problems detected are corrected or, at least, that the general situation of the telecommunication network is improved.
• the invention firstly relates to a management system of a communication network comprising a diagnostic module capable of determining a diagnosis from information provided by elements of the communication network.
• This diagnosis identifies a failure within the communication network.
• This management system is characterized in that it further comprises a repair module arranged to determine one or more corrective actions from at least the diagnostic received from the diagnostic module and to transmit one or more commands corresponding to the action or actions corrective, to one or more elements of the communication network, to correct the fault, to transmit a diagnostic request to the diagnostic module to trigger the determination of a new diagnosis by the diagnostic module.
• the management system can comprise the following characteristics, individually or in combination: an iteration counter is incremented each time a new diagnosis is triggered, and the management system stops the modules of diagnosis and repair when the iteration counter has reached a predetermined threshold.
• the command or commands are transmitted via a mediation module capable of transforming the command or commands formulated in a generic language, into specific commands conforming to control languages specific to the different equipment of the communication network.
• the repair module is arranged to communicate with a traffic optimization module if corrective actions can not be satisfactorily determined to correct the fault, in order to eliminate or limit the influence of this fault on the behavior of the network of communication.
• the diagnostic module implements a Bayesian network to determine the diagnosis.
• the diagnosis contains at least the designation of the fault, the location of the fault, and possibly an estimate of the probability associated with the diagnosis.
• the diagnostic module communicates the diagnostics to the repair module using an SNMP compliant message.
• the repair module has a repair rule base.
• the rules may depend on the iteration counter.
• the repair module has a history of the diagnostics and corrective actions determined at each iteration and is able to return to the state of the communication network for a given iteration, if when the threshold is reached, the diagnosis is worse than what he was for this given iteration.
• the invention also has as a second object a method for managing a communication network comprising a first step of determining a diagnosis based on information provided by elements of the communication network.
• This method is characterized in that it further comprises a second determination step, if the diagnosis identifies a failure, one or more corrective actions from at least the diagnosis and transmission of one or more commands ( C) corresponding to this or these corrective actions, to one or more elements of the communication network, in order to correct the failure; the first step being automatically triggered at the end of the second step, to form a treatment cycle
• the management method may comprise the following characteristics, individually or in combination: an iteration counter is incremented each time a new diagnosis is triggered, the treatment cycle being interrupted when this iteration counter has reached a predetermined threshold.
• the command or commands are transmitted via a mediation module capable of transforming the command or commands formulated in a generic language, into specific commands conforming to control languages specific to the different equipment of the communication network.
• a command can be transmitted to a traffic optimization module if corrective actions can not be satisfactorily determined to correct the fault, in order to eliminate or limit the influence of this fault on the behavior of the communication network.
• the first step implements a Bayesian network to determine the diagnosis.
• the diagnosis contains at least the designation of the fault, the location of the fault, and possibly an estimate of the probability associated with the diagnosis.
• a history of the diagnoses and corrective actions determined at each iteration is constituted and if when the threshold is reached the diagnosis is less good than it was for a previous iteration, it returns to the state of the communication network for this iteration earlier.
• the repair module makes it possible to automatically repair (or semi-automatically, after validation of the operator) the failures of the communication network and / or to undertake actions corrective measures limiting the consequences of failures, and in particular their impact on the Service Level Agreements (SLAs) deployed on the communication network.
• SLAs Service Level Agreements
• a new diagnosis is requested from the diagnostic module to ensure that this repair has not caused a new failure, and if so, to correct them in turn.
• a treatment cycle can thus be implemented which must converge towards the repair of the diagnosed breakdown.
• a threshold can be set for the number of iterations of the loop.
• FIG 1 shows schematically the management system according to the invention.
• FIG. 2 represents an internal architecture of the repair module according to one implementation of the invention.
• FIG. 3 illustrates the sequence of steps of the method according to the invention.
• the network management system comprises two main modules which are on the one hand a diagnostic module MD and on the other hand a repair module MR.
• the diagnostics module receives inbound complaints from the CC clients and network A information. Customer complaints may be caused by a decrease in the performance of the network or the services implemented on the network. Upon receipt of such a complaint, the MD diagnostic system may trigger a diagnostic search to determine the technical cause that led to the complaint. It can then take advantage of information from network elements. A diagnostic search can also be triggered by this information from the elements of the communication network themselves (that is, independently of the presence of a customer complaint). The information A resulting from the elements of the network can be mainly of two natures:
• They can be alarms, ie asynchronous notifications transmitted by the elements of the network to the network management system. These alarms are transmitted when an anomaly is detected by the element, when a measured value reaches a predetermined threshold or, more generally, during any type of event that has been planned, by configuration. , that the appearance should trigger an alarm. These alarms can therefore indicate a failure, whether it is software or hardware.
• MIB Management Informat ion
• the diagnostic module MD can determine that these represent a probable failure or failure. As a result of such a determination, it triggers the determination of the diagnosis, that is to say, the search for the failure. As mentioned earlier, when a failure occurs, it can cause alarms not only from the failed network element, but also from "neighboring" network elements. The determination of the diagnosis is precisely to identify the failed network element (it is the location of the failure), as well as the type of failure (the title of the failure), from this set of alarms from a multitude of network elements. Generally, the diagnosis can not be certain, and the diagnosis module MD will then provide the diagnosis D most probable by associating a probability value. It can also provide a list of several diagnostics, each associated with a probability value, and each identifying a failure within the communication network N.
• the diagnostic module can be a known module of the state of the art. As previously described, the technologies used can be diverse: neural networks, expert systems, rule-based systems, and so on. These may be the aforementioned commercial products. However, the diagnostic module MD must preferably respect two criteria:
• the diagnostic search can be initiated other than by receiving alarms A from the communications network.
• this search must be triggered by an external event that can be either a customer complaint CC or a diagnostic request (CD), transmitted by the repair module MR and will be explained later.
• an external event can be either a customer complaint CC or a diagnostic request (CD), transmitted by the repair module MR and will be explained later.
• this diagnostic module implements Bayesian networks and is similar to the "5530 - Network Analyzer” product from Alcatel.
• the operation of an implementation of this module is therefore described in the technical document of the product "5530".
• the Bayesian network technology and its application to the diagnosis determination are for example described in F. Jensen's "An introduction to Bayesian Networks", LJCL Press, 1996 or in the article “IP VPN Network Diagnosis: Technologies and Perspectives "by incident Délègue, Stéphane Betgé-Brezetz, Emmanuel Marilly and Olivier Martinot, 3rd International Conference on Networking, March 2004.
• Bayesian networks uses probability theory which defines a rule to refine a hypothesis by taking into account additional evidence and background information and thus lead to a number representing the degree of probability that the hypothesis be true.
• a Bayesian diagram therefore defines all the test actions to be undertaken, associated with a probability and a cost, the cost serving for example to define which tests require more time than the others.
• Figure 3 illustrates an extremely simplified example of a Bayesian diagram. It shows that the "LossPacket" entity depends on several other entities, "HighCPUUtilization”, “Interface IN Status”, “InterfaceOutStatus” (Status of the outgoing interface).
• This model therefore allows the system to represent the causal chains and thus to indicate the tests to be performed, and to calculate a probability value for each possible diagnosis and to determine a most probable diagnosis.
• a diagnosis D determined it is transmitted to the repair module MR, in the form of one or more messages.
• These messages are, for example, compliant with the Simple Network Management Protocol (SNMP) defined by the Internet Engineering Task Force (IETF) in RFCs 1 157 and 1592 for versions 1 and 2 respectively. It can be a single SNMP message (or "trap") or multiple messages. In the latter case, the messages must be clearly identified so that the repair module MR can easily determine that they are related to the same diagnosis D.
• the first message contains the general information on the diagnosis, while the following message (s) contain details information.
• the first message may contain the diagnostic information relating to the LSP itself, while the subsequent messages contain information relating to the equipment (or routers) traversed by the LSP.
• This determination can be made using the ticket which will be explained below: all the SNMP messages carrying the same diagnosis D will have the same ticket.
• the two modules can communicate via a software bus CORBA type (Common Object Reqüest Broker Architecture) as defined by the OMG (Open Management Group) or COM / DCOM company Microsoft.
• CORBA type Common Object Reqüest Broker Architecture
• OMG Open Management Group
• COM / DCOM company Microsoft COM / DCOM company Microsoft
• a ticket which is a number that identifies a session for finding the correct diagnosis for a given problem. As said before, if the same diagnosis is carried by several messages, in particular because the volume of information is too important, each of these messages will have the same ticket.
• OIDs SNMP Object IDentifiers
• the left part (1 .3.6.1.4.1.637.) Corresponds to the Alcatel identifier, the next part (4.) corresponds to the application (ie the module of MD diagnosis) and the last part corresponds to the attributes specific to the SNMP trap fields.
• the repair module D Upon receipt of a message containing a diagnosis D, the repair module D will seek to determine one or more corrective actions.
• Figure 2 shows a possible functional architecture of the MR repair module. This architecture is functional, it can give rise to different achievements.
• the repair module MR comprises a main module MP, an HMI human-machine interface, a database B and a configuration module MC.
• the D diagnostics are received by the main module MP, whose purpose is to determine the corrective actions and to transmit the commands corresponding to these corrective actions either to a mediation module MED, or directly to the elements of the network, not represented on the Fig.
• This determination is therefore made from the diagnosis D and the information it contains and that we have seen previously. However, it may also depend on other such information - an internal logic, ie a formalization in a particular language, of the policy that makes it possible to determine a corrective action from at least one diagnosis.
• This internal logic is stored in a database B.
• parameters determined by the user in particular by means of the interface HMI and the configuration module MC and stored in the database B (or possibly in another database separate data).
• Information transmitted by the user via the HMI interface during the development of the diagnosis in particular in response to a proposal made by the main module MP.
• the internal logic is formalized in the form of a set of rules. These rules make it possible to associate the diagnostics C that can be received from the diagnostic module MD with corrective actions. They can be entered in base B via the MC configuration module and the HMI interface. These rules can typically be expressed as:
• the HMI interface can display them on the screen and allow the user to choose the one that seems most appropriate.
• the repair module MR will then transmit to the elements of the communication network, the commands C corresponding to the corrective actions chosen by the operator.
• other implementations are also possible.
• the advantage of using neural networks is their ability to learn and operate in the uncertain. For example, they may be able to apply the most likely corrective action to the most likely outage, even if a certain amount of information is missing.
• the problem is the difficulty of apprehension of such a technology by the operators of the communication networks.
• the commands C can be transmitted to the elements of the communication network N, via a mediation module MED.
• the aim of this mediation module is to transform commands C formulated in a generic language by the repair module MR into specific commands C 1 , C 2 conforming to control languages specific to the different equipment of the communication network.
• the equipment items N 1 and N 2 may be of a different type, for example an IP router and a media gateway. to connect this communication network N to another network, not shown. It may also be equipment of similar types but manufactured by different suppliers. In these two situations, the commands to be used to configure them must be adapted to the command language understood by the equipment.
• the same generic command C (for example, "open an interface”) will therefore give rise to different specific commands for the two devices N 1 and N 2 , each of these specific commands being in accordance with the equipment's own language, and in particular with their CLI interface (Commancf An Interface). Different products and technologies can be used to realize this MED mediation module.
• a policy-based management architecture can be used.
• the repair module MR makes it possible to automate the repair of the communication network or to semi-automate it in the case where an intervention of the operator is requested.
• the complexity of communication networks is such that it is almost impossible to fully control the impact of corrective actions.
• the repair can be ineffective to solve the problem (for example, because the diagnosis was not good, but also because the corrective actions were not fully adapted), and secondly , it is also possible that the actual repair of the fault can cause a new failure. For example, by repairing a first failure, the transmission of traffic to network elements that until then were isolated, and in doing so, we can highlight a breakdown among these network elements.
• the Applicant therefore considered the additional technical problem of minimizing the insufficient or unwanted impacts on the communication network.
• a diagnostic request CD is transmitted to the diagnostic module MD, so that it determines a new diagnosis.
• This diagnostic request CD can contain the value of the ticket, so that this new diagnosis (and any subsequent) is linked to the first diagnosis within a session determined by the same ticket. Thanks to this re-looping to the diagnostic module MD, it can check the correction of the fault and detect the appearance of a new failure. It can then trigger a new repair by the repair module MR, and so on.
• This preferred embodiment of the invention therefore makes it possible to carry out a control loop of the actions performed on the managed communication network.
• this embodiment may pose the additional problem of causing infinite loops, that is to say that each repair causes a new failure cyclically.
• an iteration counter can be implemented. For example, this iteration counter is incremented each time a new diagnosis is triggered. When this iteration counter reaches a certain predefined threshold, the loop is stopped and the system can indicate to the operator through the HMI interface that no solution has been found.
• the counter can be initialized to the value of this threshold and decremented each time the new diagnosis is triggered. The stop criterion is then the transition to 0 of this iteration counter.
• this iteration counter can influence the internal logic of the repair module. For example, in the situation where this internal logic is implemented as a set of rules, these rules may depend on the value of the iteration counter.
• the operator can configure these dependencies according to the constraints he sets. For example, on an unimportant LSP, the operator can associate a high iteration threshold (notably because the resulting cost is less than the triggering of the traffic optimization module, which we will see later). For a very important LSP with an SLA with strong penalties, the iteration threshold can be very low and the operator wishes above all to maintain the service even if it is necessary to trigger the traffic optimization module. Eventually, if in the end, the diagnostics are more serious problems on the communication network than they were at a given moment, a back tracking mechanism can be implemented to return to this configuration of the network. . To do this, the repair module contains a history of corrective actions and / or commands issued and diagnostics received.
• the repair module can use this history to return the network in the state corresponds to this iteration. It is enough then to transmit the inverse commands to restore this previous situation. Failing to truly resolve the failure, this implementation provides a compromise by improving the state of the network.
• a message is sent to the operator via the human-machine interface HMI to indicate that the problem could not be solved and the situation of the network.
• a traffic optimization module TE (or Traffic Engineering, in English) can be used. The purpose of this traffic optimization module is to redirect traffic so that it avoids the problem, rather than truly solving the problem.
• the TE module can modify the routing tables of other routers, the LSPs passing through this router, and so on. so that no more traffic is directed to this router.
• the equipment in question remains inoperative, the behavior of the network can become fully operational.
• a diagnosis identifying a breakdown can lead to four conclusions: either it has repair or there is no repair and the operator is warned, or there is no repair but triggering of the tool.
• traffic optimization the MR repair module places the network in the "minus" bad state by using the rollback function and warns the operator.
• FIG. 3 schematizes the progress of the steps of the method according to the invention.
• a first step “Diag” is to trigger the determination of a diagnosis. This step is triggered, typically, as a result of receiving a communication network alarm or a customer complaint. Then, the system determines whether the diagnosis identifies a fault (box "P"). If there is no fault, the process stops (box “Fl") If there is a fault, the process consists in determining certain criteria of stops ("Stop?"). It is a matter of determining whether the iteration number has reached the predefined threshold, or whether the diagnosis corresponds to a diagnosis already established during an earlier iteration. If these stop criteria are met, the system stops (box "F2"). If not, the method implements a "Rep” step of determining corrective actions and deploying commands associated with these corrective actions to the communication network.
• a new diagnostic step "Diag” is triggered and the process then goes through the various steps and tests described above.
• the diagnostic module is put into operation by receiving alarms from the communication network or by a complaint from a client.
• a complaint from a customer CC or alarms A received from the communication network have highlighted a problem within this network.
• a first diagnosis reveals that the interface X of a router Y is out of service ("down" in English).
• the diagnostic module MD transmits this diagnosis to the repair module, with a ticket value and an iteration value of 1.
• the repair module MR determines the corrective action associated with this diagnosis.
• the corrective action is, in this example, to put the interface X in service (" ⁇ p" in English).
• a generic command associated with this corrective action is transmitted to the mediation module MED, which determines the appropriate command in the language specific to the router Y.
• the repair module MR transmits a diagnostic request CD to the diagnostic module MD, specifying the same ticket value.
• the diagnostic module MD redoes a diagnosis of the communication network and determines that the interface X of the router Y is indeed operational (" ⁇ p") and that the network is operating normally. He can then transmit a diagnostic D to the repair module to signal that the network is functioning normally. After which, the problem being solved, the repair module MR does not trigger any action and the method of the invention ends.
• the diagnostic module also determines that the interface X of the router Y is down ("down").
• the diagnosis D is transmitted to the repair module with a ticket, and the repair module MR determines a corrective action.
• the generic command associated with this corrective action is transmitted to the MED mediation module which converts it into a command conforming to the specific language of the router Y.
• the MR repair module transmits a CD diagnostic request to the diagnostic module MD, with the same ticket.
• the diagnostic module MD triggers a new diagnostic determination.
• the new diagnostic D notes that the X interface of the Y router is still out of service ("cfown"). This diagnosis D is transmitted to the repair module MR with the same ticket, and an iteration value equal to 2.
• the MR repair module can see that although the iteration is 2, the problem remains the same. He can then decide to transmit a command to the traffic optimization module TE (Traffic Engineering).
• TE Traffic Engineering
• This TE traffic optimization module can then modify the paths in place in the communication network so that they avoid the interface X of the router Y. In this way, although the interface in question is out of order, the communication network can behave normally.
• the diagnostic module MD also determines that the interface X of the router Y is out of order ("cfown").
• the diagnosis D is transmitted to the repair module with a ticket number and an iteration value equal to 1.
• the repair module determines the generic command to be transmitted to the mediation module MED which converts it into a command according to the language specific to the router Y in order to put the interface X in service (" ⁇ p").
• the MR repair module transmits a CD diagnostic request to the diagnostic module MD, with the same ticket number.
• the diagnostic module then triggers a new diagnostic determination and a new problem emerges, for example a misconfiguration of the Border Gateway Protocol (BGP).
• BGP Border Gateway Protocol
• This diagnosis D is transmitted to the repair module with an iteration number equal to 2 and the same ticket value.
• the repair module MR determines the appropriate corrective actions, which may be here to reconfigure the BGP protocol. Generic commands are then passed to the mediation module MED which converts them into specific commands.
• the repair module MR transmits a diagnostic request CD to the diagnostic module MD, specifying the same ticket number. It appears from the new diagnosis D that the same interface X of the router Y is out of service ("down").
• This diagnosis D is transmitted to the repair module MR with an iteration value equal to 3 and always the same ticket value.
• the repair module can see that the iteration value is equal to 3 and that the diagnosis is the same as that of iteration 1. He can then determine that he is unable to solve the problem and transmit to the human-machine interface HMI a command causing the display of a message expressing this disability as well as information relating to the diagnosis.
• the repair module MR of the invention can adopt different behaviors, such as to warn the operator , trigger a traffic optimization module, trigger repair commands, etc.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Artificial Intelligence (AREA)
• Computer Vision & Pattern Recognition (AREA)
• Databases & Information Systems (AREA)
• Evolutionary Computation (AREA)
• Medical Informatics (AREA)
• Software Systems (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Telephonic Communication Services (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=34947039

Family Applications (1)

Country Status (6)

Families Citing this family (47)

Family Cites Families (18)

• 2004
  • 2004-07-30 FR FR0408505A patent/FR2873879B1/fr not_active Expired - Fee Related
• 2005
  • 2005-07-01 JP JP2007523126A patent/JP2008508760A/ja active Pending
  • 2005-07-01 US US11/572,904 patent/US8149718B2/en not_active Expired - Fee Related
  • 2005-07-01 WO PCT/FR2005/050530 patent/WO2006021702A1/fr not_active Ceased
  • 2005-07-01 CN CNA2005800323261A patent/CN101027872A/zh active Pending
  • 2005-07-01 EP EP05787400A patent/EP1774705A1/fr not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events