Browse Prior Art Database

System and Method to Identify Most Urgent Service Problem-Resolutions

IP.com Disclosure Number: IPCOM000235517D
Publication Date: 2014-Mar-05
Document File: 6 page(s) / 146K

Publishing Venue

The IP.com Prior Art Database

Abstract

Traditionally, in network and service management alarms are viewed as indications of bad things. And so alarm-prioritisation has traditionally tended to prioritise the alarm which is "worst" from a number of perspectives, whether it be a severity indicated by the reporting component, or informed by reference to some configuration data, or based on the number and nature of impacted customers, or the impacted services, etc. The solution described in this publication arises from instead considering alarms as opportunities (opportunities to improve something), and then viewing alarm-prioritisation as sorting by greatest opportunity. When looking at it this way, it is not the alarm indicating the worst condition that is prioritised, but rather the alarm that indicates the greatest opportunity. How bad the condition is but one factor contributing to opportunity - the system also has to consider the project of improving the condition (how long will it take, how much will it cost, are staff available, etc.). So the solution combines known alarm-prioritisation techniques with known project management techniques in order to prioritise alarms by greatest opportunity - i.e. the highest-priority alarm is the one which the enterprise will get the greatest return from working on.

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

Page 01 of 6

System and Method to Identify Most Urgent Service Problem-Resolutions

Background

A very common business arrangement in telecommunications service delivery is that the service provider is responsible for keeping certain measures of the service

within certain desirable ranges. For example, a service provider contracted by different enterprises to provide voice call service (among other services) might be responsible for maintaining the Average Weekly Voice Call MOS > 3.2 at EnterpriseA's building, and Average Weekly Voice Call MOS > 3.0 at EnterpriseB's building.

    The service provider has a system that delivers to these service-delivery requirements, and the service provider needs to take course-correction action at times to ensure that the system continues to so-deliver. At any given time, the latest service-level-measures are available to the service provider's operations personnel

who needs to identify which course-correction they need to first begin addressing -
i.e. potential course-corrections need to be prioritised based on urgency.

There are well known solutions to this: The system can allow the operator to configure a warning level for a service measure, that the system warns the operator when the service measure value has breached the warning level (but not necessarily yet gone outside of the required range). Then the operator can first begin addressing the problem it is first warned about upon reception of that warning.

The system can present the historical trend of the service measure values to

2.

the operator, allowing the operator to visually judge which service measure will likely first fall outside of its required range, and the operator can first begin addressing that problem.

The system can automate the extrapolation-judgement in the above solution

and thus automatically indicate to the operator which problem the operator should first begin addressing.

The problem is that there are a lot more considerations in determining which future-problem to first initiate avoidance-of. For example:

The service that is measured as closest to falling outside of its requirements might not be the one to first begin avoiding as the consequences of it falling outside of its requirements might be relatively low.


The service that is trending to soonest fall outside of its requirements might not

be the one to first begin avoiding as the time-to-resolve it may be so low that the resolution can be postponed in order to address a more urgent problem in this regard.


The service with the most costly consequences associated with not delivering

as required might not be the one to first begin avoiding, since the cost of resolution might be so high that its better financial decision to first go after a number of lower-hanging-fruit.

    In a large system, it is very important to quickly make these priority calls, but equally in a large system it is not feasible to do so effectively without a simply configured model to do so. This publication describ...