FIELD OF INVENTION [001] The embodiments herein generally relate to communication networks, and, more particularly, to management of communication networks.
BACKGROUND AND PRIOR ART

[002] Telecommunication industries generate enormous amount of fault data routinely and it becomes unmanageable and there is no way an engineer can pinpoint an equipment failure or the actual cause of an alarm. Expert systems are considered for monitoring and maintaining the network elements in a network in telecommunication industry. When, designed appropriately, these expert systems in real time must use a combination of data mining, knowledge of the engineers and the rule based techniques to predict telecommunication equipment failures.
[003] With the increased use of computers and mobile phones in daily life the networks that connect these devices are becoming exponentially complex. A failure of a single component can affect the performance of the network drastically hampering productivity. Hence it is very important to ensure an almost 100 percent up time for these networks.
[004] Currently most networks are managed by layers of technicians. There is a network operating center staffed 24x7 to monitor the trouble tickets and help the field staff replace the faulted equipment. Even if there is a redundant element in the network that can take the load the switch has to be done manually and hence the human decision related errors and time lag impact the performance. Where there is no redundancy the field staff has to travel 24x7 and often they do not have sufficient resources to plan and optimize their travel.
[005] Our current invention describes architecture of a smart network

that can ensure 100 percent up time. It describes a unique expert system and a central station which collects metrics from various hardware and software sources within the network to enhance the predicted faults and automatically correct/replace defective equipment with a redundant one and as well control changes within the network.
SUMMARY OF INVENTION
[006] In view of the foregoing, an embodiment herein provides a design manager for predicting and correcting failures in a telecommunication network is disclosed. The manager comprises an interactive software module for displaying details of the elements of the network, capturing any modification made to the network and translating the modifications to an architect within the network. A network map analyzer for tracking and controlling any changes in the network and a network register for maintaining details regarding elements of the network, computing optimal redundancy based on the network factors and updating administrator on the optimal redundancy. The interactive software module of the manager is adapted to display details that include at least one of element name, default elements, location of the element. The interactive software module of the manager is adapted to capture modifications made in the network that may be due to failure or maintenance of at least one element in the network. The network map analyzer of the manager is adapted to control the changes in the network that include at least one of element repairs, element replacement, element upgrades. The network register of the manager is adapted to maintain details that include at least one of device type, precedence level, site id, load units and seasonality of load and its priority, reliability of a device, availability of a

device. The network register of the manager is adapted to maintain details of active network components and idle network components. The network register of said manager is adapted compute optimal redundancy based on network factors that include at least one of element type, load capacity of the element, location, priority, availability, service period of the element.
[007] An architect for predicting and correcting failures in a telecommunication network is disclosed. The architect is adapted for identifying a backup for at least one element on failure of element, instructing a switch to transfer a load from the failed element to the backup element on failure of the element and setting priority level for replacement of failed elements. The architect is adapted to set priority based on the criticality of replacement of failed element in network.
[008] A switch control for predicting and correcting failures in a telecommunication network is disclosed. The switch is adapted for swapping of elements on receiving instructions from an architect for replacement of faulty element in the network.
[009] A secondary data collector for predicting and correcting failures in a telecommunications network is disclosed. The collector adapted for collecting data from a plurality of environmental sources that add precision to analysis, predicting failure of an element based on data and correcting said network at failure location. The secondary data collector is adapted to collect data from environmental sources that include environmental factors, mechanical factors and power fluctuations.
[0010] A fault predictor for predicting and correcting failures in a telecommunications network is disclosed. The predictor adapted for monitoring the state of elements in network by employing a set of pre-defined rules, predicting the probability of occurrence of fault based on monitoring and

sending an alert to an architect if probability crosses a threshold value. The fault predictor is adapted to monitor said state based on pre-defined rules that include at least one of historic data, engineer experiences, secondary data, administrator input.
[0011] A redundancy manager for predicting and correcting failures in a telecommunications network is disclosed. The manager adapted for fetching primary signals from idle network elements and sending information to an architect of network elements when failure occurs. The redundancy manager is adapted to fetch primary signals that include at least one of element location, port id, type of device, priority, and load capacity. A method for predicting and correcting failures in a telecommunication network during re-design is disclosed. The method performing steps of an administrator informing a data manager of a list of elements subjected to re-design, data manager sending a list of active network components to an architect with details of elements, architect identifying idle network components based on list received from data manager, architect sending a message to fault predictor to stop collecting data from active network components, architect sending a message to a redundancy manger to stop simulation of idle network components and architect updating data manager to go ahead with re-design of the network. The method wherein data manager sends every detail of the components that include at least one of device type, physical location, port address. The method further indicates leverage that defines the measure of change of first component and determines the number of components that will be affected on failure of first component
[0012] A method for predicting and correcting failures in a telecommunication network when a fault predictor detects failure is disclosed. The method performing steps of an architect identifying an idle component in said network on failure of a component, a switch replacing failed components

with idle components, architect sending a message to redundancy manager to collect data from idle component, architect sending a message to fault predictor to stop simulating idle component, architect sending an indication of failed active network component to an administrator with details of the components and architect restoring connectivity with fault predictor and said redundancy manager on repair of failure. The architect informs details of components that include at least one of active network component type, idle network component and external components associated, location details from SATNAV, Leverage of component.
[0013] A method for predicting and correcting failures in a telecommunication network when there is no response from idle network component is disclosed. The method performs steps of a redundancy manager sending a message of failure of idle network component to an architect, architect informing said redundancy manager to not ping faulty idle network component, an administrator performing necessary action for restoration on failure and architect informing redundancy manager to start using idle network component for simulation after restoration. The method is further adapted for monitoring status of the network components periodically and reporting breakdown of architect if there is no message received from the architect during the monitoring.
[0014] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from

the spirit thereof, and the embodiments herein include all such modifications.
BRIEF DESCRIPTION OF DRAWINGS
[0015] The embodiments herein will be better understood from the following description with reference to the drawings, in which:
[0016] FIG. 1 depicts an architecture, according to embodiments disclosed herein;
[0017] Fig. 2 depicts the flow when there are enhancements to network, according to embodiments disclosed;
[0018] FIG. 3 depicts the cascading effect of a failure in a network, according to embodiments disclosed herein;
[0019] FIG. 4 depicts a process for dealing with failures in a network, according to embodiments disclosed herein;
[0020] FIG, 5 illustrates a process of dealing with an idle network component, according to embodiments disclosed herein;
[0021] Fig. 6 illustrates the process dealing with failure of components within the architecture, according to embodiments disclosed;
[0022] FIG. 7 depicts a design manager, according to embodiments disclosed herein;
[0023] FIG. 8 depicts an architect, according to embodiments disclosed herein;
[0024] FIG. 9 depicts a switch, according to embodiments disclosed herein;
[0025] FIG. 10 depicts a secondary data collector, according to embodiments disclosed herein;
[0026] FIG. 11 depicts a fault predictors, according to embodiments

disclosed herein;
[0027] FIG. 12 depicts a redundancy manager, according to embodiments disclosed herein; and
[0028] FIG. 13 depicts a messenger module, according to embodiments disclosed herein.

DESCRIPTION OF EMBODIMENTS [0029] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0030] The embodiments herein achieve a method and system for prediction and performing corrections to prevent errors in a communications network. Referring now to the drawings, and more particularly to FIGS. 1 through 13, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments. [0031 ] There are three tiers in the proposed architecture for our system


End-Users
• Administrators
[0032] Fig 1 depicts an architecture. All the components are connected to each other through standard electronic methods such that they can send inputs from one to the other and read outputs. Each one of these comprises of a combination of several hardware and software components as shown in the architecture.
[0033] There are three different scenarios where changes within the network crop either when the network is built/re-designed or when a failure is predicted. The process flow for each has been described and how components within the architecture handle the following scenarios:
1) Built/re-design network
2) Dealing with Failures

• Active Network component (ANC)
• Idle Network component (INC)
3) Failure of components within the architecture
1) Build/re-designed network
[0034] The Administrator updates any change in the network to DM. The DM manages the network topology, along with details of all the components, list of associated external components, their physical location or ports from where the log data is collected and several other properties of every component.
[0035] When there is re-design or update to the existing network components, the administrator informs the DM a list of components subject to

update. The DM sends a structured message to Architect listing the ANC and every detail of the components like device type, physical location, and port/address, etc. The Architect acknowledges the message and uses the list of ANC to identify the corresponding INC and external components associated with it. The Architect sends message to FP, not to collect data from ANC which needs update and associated external components. The Architect sends message to RM, not to simulate INC of the associated ANC and external components. The FP and RM acknowledges the message sent by Architect. The Architect updates the DM that they can go ahead with re-design/updates to the network.
[0036] After the re-design/update is complete, the administrator informs the DM about completion. The DM sends a structured message to Architect listing the ANC updated and every detail of the components like device type, physical location, and port/address, etc. The Architect acknowledges the message to administrator and uses the list of ANC to identify the corresponding INC and external components associated with it. The architect sends message to FP, to start collecting data from updated ANC and associated external components. The architect sends message to RM, to simulate INC of the associated updated ANC and external components. The FP and RM acknowledges changes to Architect. The Architect updates the DM after restoration
[0037] To understand the impact of changes within the network when a component fails, we define the term 'leverage' which is a measure of change. It is denoted by Ly = ||d|| where d is the number of components it will impact if it fails. It will thus compute Leverage of every component. Other inputs provided by the SME like location, availability and service life DM computes weights and assigns weight to every component. Based on the both leverage

and weights, it periodically estimates optimal redundancy required in a network and updates the administrator.
[0038] During planned shutdown or restorations, the administrator updates DM. The topological changes or updates sent by administrator are acknowledged by DM and in turn sends a message to Architect and the above process is followed thereon.
2) Dealing with Failures
[0039] The administrator interacts with Design manager and Architect in the architecture. The DM sends the updated network map to Architect along with the port details of the active network components, idle component and the external components from where the data is being collected. Architect has a principal control of all the network components.
[0040] When a FP predicts failure of ANC, the Architect identifies the idle component and instructs the Switch to change the default component. The Switch acknowledges the instruction and after swapping informs the Architect. The Architect then acknowledges the message from Switch. The Architect sends message to FP not to collect the log data from the failed active component and instead collect the log data from the replaced idle component. The FP acknowledges the message from Architect. The Architect simultaneously informs RM to temporarily stop simulating the idle component used in switch. RM acknowledges the message from Architect. Architect informs of the failed ANC to administrator. Architect sends a detailed message with detail like ANC type, INC and external components associated, location details from SATNAV and Leverage etc. After the administrator repairs the ANC, it sends a message to Architect. Architect then sends the message to FP and RM to restore connectivity. FP and RM acknowledges the message from

Architect and make changes. Once changes are complete both FP and RM send message to Architect. Architect acknowledges the message to Administrator about restoration. Acknowledgements are shown as dotted lines. Thus, this process helps NOC to review a less number of alarms.
[0041] If there is no response from INC during simulation, the RM sends a message to Architect of the failed INC via Messenger. The Architect acknowledges RM and sends a message to Administrator. Architect informs RM not to ping the faulty INC temporarily. The Administrator acknowledges the message from Architect and takes necessary corrective actions. After restoration, administrator updates the Architect. The Architect sends message to RM to start using the INC for simulation. The RM acknowledges Architect and it in turn acknowledges the administrator. Thus, this process helps NOC to review a less number of alarms.
3) Failure of components within the architecture
[0042] One of the primary tasks of Architect is to ensure FP, RM and Switch is active and periodically informs the status to administrator thru Messenger. If there is no message then it is apparently due to breakdown of Architect itself.
[0043] The Design Manager is a standards based interface that talks to the other elements in the network. The Design manger has a central control of all the changes made to the existing network. The Design manager has three important components to manage all the network changes; the interactive interface for administrator, network map analyzer and network register.
[0044] Based on the networks being managed the administrator generally need a highly intuitive and interactive interface to make the changes to the network. The interactive interface for administrator displays all the network element names, default elements, location, etc and during a planned

network upgrade the administrators can easily select or drag and drop the changes required which will then be reflected in the blue print of the network (Network map analyzer). It is mainly responsible to capture all the required modifications within the network and translate it back to the Architect via Messenger.
[0045] The Network map analyzer has a blue print of the entire network. It tracks and controls network elements repairs, replacements and upgrades. It sends messages about the repair, replacement and upgrades to the Architect, the Fault Predictor and Redundancy Manager through the Messenger after the change is accomplished. During planned network upgrades the administrator sends a message to the Design Manager and that in turn is communicated to the Fault Predictor via Messenger to ignore the signals from those elements that are being worked on. This avoids unnecessary switching.
[0046] A Network register maintains all the information about active network components and idle network components. The details include: device type, precedence level, site identification, load units and seasonality of load and its priority; performance measures like reliability of a device, availability of a device. It computes optimal redundancy based on the mentioned factors like the element type, load it can handle, its location, priority, availability, service period of an element, etc and constantly updates the Administrators on required optimal redundancy. This input is essential as networks evolve in the due course and it eventually becomes necessary to understand optimal redundancy.
[0047] The Architect runs on a dedicated server and is an interface that talks to the other elements in the network. The Architect has the topological information of the network elements along with the associated external components from where the data is collected. It identifies the backup for the

element that is predicted to fail. It then instructs the Switch to transfer the load from the component that is likely to fail to its backup via messenger. As the Architect knows the criticality of the replacement it automatically sets the priority level for the alert and acts accordingly. The architect comprises of a Network map analyzer (SW), a Network elements register (SW), an Instruction Module (SW) and a Central Processing Unit (SW).
[0048] The Network register maintains all the information about all devices, device type, precedence level, site id, load units and seasonality of load and its priority, reliability of a device, availability of a device, a list of backup devices and their specifications. The priority level of alerts decided based on the above factors is shared by DM to Architect.
[0049] When a faulty component is predicted the Instruction module within the Architect analyzes the default components in the network and sends instruction to the Switch for replacement via messenger. The switch acknowledges the message and completes the task of swapping and informs the Messenger. Upon receiving the message the Architect acknowledges the completion and sends a message to appropriate group of administrators based on the defined user roles. During the process of switching, the Architect also instructs the FP to stop collecting log data temporarily from the failed component (ANC) and start collecting the log data from the replaced component (INC). The Architect also informs the RM to stop using the INC during simulation temporarily. After the repair is complete, the Architect instructs the Switch to rearrange the components and simultaneously informs FP to collect data from ANC and stop data collection from INC. The RM again pings the INC along with other redundant components in the network.
[0050] A network consists of active network components (ANC) and idle network components (INC). The Switch control is designed to collect

instructions from the Architect via Messenger and perform some simple operation of switching components. It acknowledges every instruction received from Messenger and performs a swap. After completion it notifies the Architect via Messenger. The Switch control receives instructions from the Architect to change the default component. Once the administrator replaces the failed network component the Messenger communicates the information to the Architect. Architect then instructs the Switch to switch back to the original configuration.
[0051] Typical network architecture has a data pooling system which collects primary signal data generated by various network elements. Based on deviations from the predefined performance measures of a network component like the load it can handle, service time, etc, signals are generated. Standard procedures of analysis, predicting faults and subsequently correcting networks are also generally based on the primary signal data. But, there are several other factors that could cause faulty behavior of a network element. Embodiments herein describe an architecture which includes a Secondary Data Controller (SDC) that collects secondary data from various important locations within network in addition to primary signal data. Secondary data is essential in the sense that it collects data from other sources that adds precision to analysis, predicting failure of a component and subsequently correcting network. Networks are huge and spread across in various locations and are affected by environmental factors, mechanical factors, and power fluctuations. At the identified strategic locations, sensors are placed to collect live data from these locations. For environmental sensing, we collect data from Humidity meters, liquid sensors and Transducers. For Mechanical sensing, we collect data from images of network components, and motion sensors. For Power fluctuations, we collect data from the main as well as intermediate power generating

resources. The system collects metrics like relative humidity RH from Humidity meters and temperature in degrees Celsius or Fahrenheit from Transducers, data measuring liquid levels from Liquid sensors are all placed at various strategic locations within the network video/images of important components to identify physical damage, motion-based hardware which reads distances continuously indicating equipment motion deviation. The voltage reading from intermediate power suppliers like UPS and so on will be good measure of power fluctuation within the network. The system gathers and converts all the heterogeneous analog data like RH, temperature, load, voltage and amperes to digital data and sends it to FP which adds that information to the secondary data in FP. A threshold value is determined based on inputs from the field engineers and are incorporated in the Rule base. This data is useful to enhance the accuracy of predictions.
[0052] The Fault Predictor is a server with a database that aggregates historic fault data and secondary Data. It is also an interface that talks to the other elements in the network. The fault aggregator has a Rule based Engine and a Diagnostic Module. The Rule based engine is a collection of all the rules derived out of historic data, engineer experiences and secondary data. Secondary data includes, but is not limited to messages from the NOC Administrator via Messenger about upgrades to the network, corrected faulty devices, etc. The Fault predictor application uses these built in business rules and identifies the probability of occurrence of a failure. When this probability crosses a threshold value it sends an alert to the Architect through its messaging interface. It also has set of patterns either known or discovered using Diagnostic modules that are correlated to the predicted event. All of these form reference rules within the Rule based engine for validating every incoming signal.

[0053] The Diagnostic module inspects every incoming signal and validates it with the reference rules. Based on historic data this module has a complete understanding of the normal behavior of all the elements in the network. It continuously monitors the signal data and notes the occurrences of abnormality using sophisticated pattern recognition techniques. For every pattern indicated, produce the root cause of the predicted fault. In a very large network where there are a million signals generated per day and each signal carrying at most 400 bytes of information the estimated data storage capacity for one year is approximately 270 GB.
[0054] If a signal being validated does not match any of the reference rules defined then the Administrator is informed about it and analysis is performed externally and once the Administrator identifies a pattern or a business rule the same is updated to FP through the messaging interface.
[0055] In general a network has a good number of idle or back up components that can be utilized when necessary. In embodiments disclosed herein, the Redundancy Manager (RM) collects primary details of the idle elements like location, port id, type of device, priority, load it handles, etc. RM is organized as clusters of network elements based on the factors mentioned. RM not only keeps track of every idle network element but also has a capability to send messages to the Architect about which component needs immediate attention. RM has simulators that periodically simulate the operations to make sure the idle components can be used instantly. It thus gathers primary signals from idle network components and when there is a failure, it then sends the information to the Architect via messenger. If any idle network component fails to respond it sends a message to Messenger to either repair or to replace the component. The Administrators after making necessary updates sends a message through Messenger to Architect, Design Manager and

Redundancy Manager about the corrections. At any instance all the elements disclosed herein have instant access to the latest information.
[0056] The signals generated by the network components carry some information about the component, component type, location and which component produced an alarm. If a component stops sending signals then it becomes very difficult for an engineer to locate the failed component within the network and make the corrections instantly. Hence, it may lead to significant delay in bringing back the component active. Embodiments herein identify a cluster of strategic components within the network and tags with RFID. Standard SATNAV devices are used which functions based on three parts: a network of (satellites) which has pre-determined locations of strategic network elements, a control station and a receiver device. A network of satellites constantly sends radio-waves to the control station and the receiver pick these signals and indicate the closest network element. All the signals are collected and displayed by the Messenger to the administrators. The administrator within the proximity of the detected faulty cluster/network element then uses a hand-held antenna to scan the network element and hence ensures that the detected faulty equipment is corrected appropriately. These signals are also collected as part of SDC to enhance the accuracy of prediction. Once a correction is made the administrator sends message to all the other elements in our architecture through the Messenger.
[0057] The Messenger is an interface that collects the messages from Switch, FP and RM and transmits to Architect. It then displays it on the administrators PC. During planned network upgrades administrator communicates to the Fault Predictor via Messenger to ignore the signals from those elements that are being worked on. This avoids unnecessary switching.
[0058] The foregoing description of the specific embodiments will so

fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the appended claims.

CLAIMS

1. A design manager for controlling all the changes made to the existing
telecommunication network, said manager comprising:
an interactive module comprising at least one means adapted for displaying details of the elements of said network; capturing any modification made to said network; and translating said modifications to an architect within said
network.
a network map analyzer for tracking and controlling any changes in the said network; and
a network register comprising at least one means adapted for: maintaining details regarding elements of said network; computing optimal redundancy based on said network
factors; and updating administrator on said optimal redundancy.

2. The design manager as in claim 1, wherein said interactive software module of said manager is adapted to display details that include at least one of element name, default elements, location of said element.

3. The design manager as in claim 1, wherein said interactive software module of said manager is adapted to capture modifications made in said network that may be due to failure of at least one element in said network.

4. The design manager as in claim 1, wherein said interactive software module of said manager is adapted to capture modifications made in said network that may be due to at least one element subjected to maintenance in said network,

5. The design manager as in claim 1, wherein said network map analyzer of said manager is adapted to control said changes in said network that include at least one of element repairs, element replacement, element upgrades.

6. The design manager as in claim 1, wherein said network register of said manager is adapted to maintain details that include at least one of device type, precedence level, site id, load units and seasonality of load and its priority, reliability of a device, availability of a device.

7. The design manager as in claim 1, wherein said network register of said manager is adapted to maintain details of
active network components; and idle network components.

8. The design manager as in claim 1, wherein said network register of said manager is adapted compute optimal redundancy based on network factors that include at least one of element type, load capacity of said element, location, priority, availability, service period of said element.

9. An architect for maintaining the topological information and enable smooth switching within network, said architect comprising at least one means adapted for:
identifying a backup for at least one element on failure of said element;
instructing a switch to transfer a load from said failed element to said backup element on failure of said element; and setting priority level for replacement of said failed elements.
10. The architect as in claim 9, wherein said architect is adapted for setting priority based on the criticality of replacement of said failed element in said network.

11. A switch control for predicting and correcting failures in a telecommunication network, said switch comprising at least one means adapted for swapping of elements on receiving instructions from an architect for replacement of said faulty element in said network.

12. A secondary data collector to collect essential secondary data from various network resources a telecommunications network, said collector comprising at least one means adapted for:
collecting data from a plurality of environmental sources that add precision to analysis;
predicting failure of a element based on said data; and correcting said network at said failure location.

13. The secondary data collector as in claim

12, wherein said collector is
adapted for collecting data from environmental sources that include:
environmental factors; mechanical factors; and
power fluctuations.

14. A fault predictor for predicting and correcting failures in a
telecommunications network, said predictor comprising at least one
means adapted for:
monitoring the state of elements in said network by employing a
set of pre-defined rules;
predicting the probability of occurrence of fault based on said
monitoring; and
sending an alert to an architect if said probability crosses a
threshold value.

15. The fault predictor as in claim 14, wherein said predictor is adapted to monitor said state based on pre-defined rules that include at least one of historic data, engineer experiences, secondary data, administrator input.

16. A redundancy manager to maintain idle or back up components in a telecommunications network, said manager comprising at least one means adapted for;
fetching primary signals from idle network elements; and sending information to an architect of said network elements when failure occurs.

17. The redundancy manager as in claim 16, wherein said manager is
adapted to fetch primary signals that include at least one of element
location, port id, type of device, priority, load capacity.

18. A method for predicting and correcting failures in a telecommunication
network during re-design, said method performing steps of:
an administrator informing a data manager of a list of elements
subjected to re-design;
said data manager sending a list of active network components
to an architect with details of said elements;
said architect identifying idle network components based on
said list received from said data manager;
said architect sending a message to fault predictor to stop
collecting data from said active network components;
said architect sending a message to a redundancy manger to
stop simulation of idle network components; and
said architect updating said data manager to go ahead with said
re-design of said network.

19. The method as in claim 18, wherein said data manager sends every detail of the components that include at least one of device type, physical location, port address.

20. The method as in claim 18, wherein said method further indicates leverage that defines the systematic measure of change of said first component and determines the number of components that will be affected on failure of said first component.

21. A method for predicting and correcting failures in a telecommunication network when a fault predictor detects failure, said method performing steps of:
an architect identifying an idle component in said network on
failure of a component;
a switch replacing said failed components with said idle
components;
said architect sending a message to redundancy manager to
collect data from said idle component;
said architect sending a message to fault predictor to stop
simulating said idle component;
said architect sending an indication of failed active network
component to an administrator with details of the components;
and
said architect restoring connectivity with said fault predictor
and said redundancy manager on repair of said failure.

22. The method as in claim 21, wherein said architect informs details of components that include at least one of active network component type, idle network component and external components associated, location details from SATNAV, Leverage of said component.

23. A method for predicting and correcting failures in a telecommunication network when there is no response from idle network component, said method performing steps of:
a redundancy manager sending a message of failure of said idle
network component to an architect;
said architect informing said redundancy manager to not ping
said faulty idle network component;
an administrator performing necessary action for restoration on said failure; and
said architect informing said redundancy manager to start using
said idle network component for simulation after said
restoration.

24. The method as in claim 23, wherein said method is further adapted for:
monitoring status of said network components periodically; and reporting breakdown of architect if there is no message received from said architect during said monitoring.

25. A system for predicting and correcting failures in a telecommunication
network during re-design, said system performing steps of:
informing a data manager of a list of elements subjected to re¬design;
sending a list of active network components to an architect with details of said elements;
identifying idle network components based on said list received from said data manager;
sending a message to fault predictor to stop collecting data from said active network components;
sending a message to a redundancy manger to stop simulation of idle network components; and
updating said data manager to go ahead with said re-design of said network.

26. The system as in claim 25, wherein said data manager is further adapted to send every detail of the components that include at least one of device type, physical location, port address.

27. The system as in claim 25, wherein said data manager is further adapted to indicate leverage that defines the measure of change of said first component and determines the number of components that will be affected on failure of said first component.

28. A system for predicting and correcting failures in a telecommunication network when a fault predictor detects failure, said system is adapted for:
identifying an idle component in said network on failure of a
component;
replacing said failed components with said idle components;
sending a message to redundancy manager to collect data from
said idle component;
sending a message to fault predictor to stop simulating said idle
component;
sending an indication of failed active network component to an
administrator with details of the components; and
restoring connectivity with said fault predictor and said
redundancy manager on repair of said failure.

29. The system as in claim 28, wherein said system is adapted to inform
details of components that include at least one of active network
component type, idle network component and external components associated, location details from SATNAV, Leverage of said
component.

30. A system for predicting and correcting failures in a telecommunication
network when there is no response from idle network component, said
system is adapted for:
sending a message of failure of said idle network component to
an architect;
informing said redundancy manager to not ping said faulty idle
network component;
performing necessary action for restoration on said failure; and
informing said redundancy manager to start using said idle
network component for simulation after said restoration.

31. The system as in claim 30, wherein said system is further adapted for:
monitoring status of said network components periodically; and reporting breakdown of architect if there is no message received from said architect during said monitoring.