Browse Prior Art Database

Method and apparatus to determine the configuration change(s) which caused a network problem Disclosure Number: IPCOM000200496D
Publication Date: 2010-Oct-15
Document File: 4 page(s) / 113K

Publishing Venue

The 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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 29% of the total text.

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.