Method and apparatus to determine the configuration change(s) which caused a network problem
Publication Date: 2010-Oct-15
The IP.com Prior Art Database
Not all network problems are due to faults in equipment. Many network problems (some say more than 70%) are caused by configuration changes in one or more network elements. This disclosure describes a method and apparatus to determine a candidate list of the configuration change(s) that may have caused the network problem.
Page 01 of 4
Method and apparatus to determine the configuration change (s) which caused a network problem
Configuration changes include
(a) Modifying a Configuration Item (CI) in a network element,
(b) Introducing a new software version
(c) Performing administrative actions (e.g. lock a device),
(d) Rehoming a network element under a new parent.
Networks are very complex and may be made up of multiple segments (access, aggregation, and core) with multiple technologies (wireless/wireline) and multiple vendors' equipment.
Network problems due to configuration changes are more often detected by degradation in service or performance rather than equipment failures.
When a problem occurs in a network, it can be extremely difficult to find out the cause of the problem if it is due to a configuration change.
This is because
·Changing a Configuration item (CI) in one segment may affect :
(a) Network element (or part of) and/or
(b) Service and/or
(c) Customer in the same or other segment in the end-to-end service delivery chain.
(d) The change in Operating System Parameters in any of the service delivering application servers can impact the overall service quality & service delivery.
(e) The change in any of the Key Configuration attribute of a cell site can cause degradation in the service on the cell site where a change was made or in neighboring cell sites and causing overall service degradatio
(f)The change in the core network elements serving a particular regional access network can trigger service degradation for example not configuring correct access network ids in core switches.
·These relationships may be represented by modelling relationships between Configuration Items (CIs) and Key Quality Indicators (KQIs) and key Performance Indicators (KPIs)
Current Manual Approach:
There is a lot of manual effort in detecting the problem due to configuration change.
problem unless there is performance degradation.
within its domain when a change is made on a N
change as there is a possibility of multiple configuration changes being done across domain & within its neighboring NE
. The impact on the neighboring elements and across domain is not monitored until a trouble ticket is generated. There are situations where configuration changes are performed at the application layer and the impact is realized by the en
d-user in the service
& multiple changes are happening in the network, it's hard to detect that a particular change has triggered this problem. The following are the steps typically followed.
1. Detect problem (e.g. degradation in service) via alarms, Operational Support System (OSS) monitoring systems [Service Quality Management (SQM), Performance Management (PM)] or customer/network trouble tickets.
2. Perform historical analysis to find out when problem started
3. Gather other Key Performance Indicator (KPI) /Key Quality Indicator (KQI)/ Fault Management (FM) information that 'may' be relevant which has occurred in the timeframe.