Fault Management CROME Wireless Performance Management

Performance Alarms for Fault Management

The CROME system provides a real-time PM variance Open Reporting API for integration into to any consuming application including many OSS Fault Engines. CROME has been integrated directly into the following third party Fault Management (FM) systems.

• HP OpenView
• Agilents' netEXPERT
• Micromuse's NETCOOL

CROME's integration into NETCOOL and netEXPERT is as simple as writing a few rules for each product to process CROME's easily parseable data stream. For HP OpenView, QuantumSI provides a custom high performance HPOV agent. QuantumSI customers have been able to plug CROME into their Fault systems in a matter of hours. Other future FM system can also be quickly be supported using the CROME Open Reporting API.

This same real-time out of variance information is also available though specilized Quantum applications through the following methods which also rely on Quantum's open PM variance Open Reporting API:

• Via an interactive live, self-updating web enabled Geographic/MAP display
• Via live, self-updating web report
• Via wireless phones which enables any packet data HDML/WAP/HTML compliant phone to be a CROME data browser.

Third Party Fault Engine Integration

HP OpenView Operations

Below is a screen shot from a live customer installation of HP Openview, use for an entire nation's fault management. The "crome" alerts shown come directly from the CROME real time variance stream, via a QuantumSI supplied CROME HPOV "agent".

Agilents' netEXPERT

Below is another vender's fault engine, Agilent's netEXPERT, also used with reports and thresholds made to the exact requirements and specifications of a national carrier.

Micromuse's NETCOOL

Below are screen Images from CROME after being integrated into the Micromuse Netcool®, another fault management environment.

Please note the power of the CROME Open Reporting API. This initial Netcool integration task was accomplished by a non-developer from Micromuse in a few hours via simple E-mail instructions (i.e. no manual was required).

Sample Web Variance Report

The above sample section of a variance report shows several sectors that were out of variance for the latest real-time period for two different "variance" formulas, in this case High Dispatch Queueing and High Interconnect Blocking. In addition, the small bar graph on the left indicates how many times during the previous 48 reporting periods this same sector was out of variance. In this example, sector identified as 3 1 6 0 1 304 59 of EBTS 5777-FontanaEast had a High Dispatch Queuing rate of 9.25925%, and was out of variance for 1 of the past 48 reporting periods (i.e., the last 48 half hours, or last 24 hours). This historical information gives a quick visual on whether the problem has been frequently recurring, an almost green bar might indicate a one time occurance

If you click on the bar graph, you will get further detail showing the information for this item for the last 48 reporting periods.

Once the URL CromeVariance is visited it will automatically update every 1/2 hour to provide the latest variance report. As with most CROME products the variance report can be exported directly into Excel or Star Office.

CROME can be configured for any number of arbitrary variances. These are simply CROME "formulas" that can be created by the CROME administrator and configured for reporting on the company's CROME webpage.

Here are some typical examples of real-time variances used in a CROME system. These particular examples come from an iDEN system.

Sector Level Variances

1. Subrate Mismatch (IBCR > IBQR)

IBCR is Interconnect Block Clear Rate defined as

           t_tch_failed - h_failed_rscr - h_failed_thres
       -------------------------------------------
        t_tch_reqs - h_failed_rscr - h_failed_thres - h_chan_alloc

and IBQR is Interconnect Blocking Queue Rate defined as:

                     t_tch_queued
        ----------------------------------------------------------
        t_tch_reqs - h_failed_rscr - h_failed_thres - h_chan_alloc


2. High Intererconnect Blocking (IBCR > 5%)

where IBCR is the Interconnect Blocked Clear Rate defined as:

           t_tch_failed - h_failed_rscr - h_failed_thres
        -----------------------------------------------------------
        t_tch_reqs - h_failed_rscr - h_failed_thres - h_chan_alloc


3. High Interconnect Drop Rate (IDCR > 4% and IMOU > 100)

where IDCR is the Interconnect Dropped Call Rate defined as:

           t_lost_calls
          ---------------
         t_tch_hold_times

and IMOU is the Interconnect Minutes of Use defined as:

        i3_tch_c_secs + tel_i6_tch_c_secs
        ---------------------------------
                     6000


4. High Dispatch Queueing (DBR > 5%)

where DBR is the Dispatch Blocking Rate defined as:

        d_tch_queued + d_tch_failed
        ---------------------------
                  d_tch_reqs


5. No Interconnect or Dispatch Traffic (IMOU = 0 or DMOU = 0)

IMOU is the Interconnect Minutes of Use defined as:

        i3_tch_c_secs + tel_i6_tch_c_secs
        ---------------------------------
                     6000

and DMOU is the Dispatch Minutes of Use defined as

        dis_i6_tch_c_secs
        -------------------
              6000

NOTE: This variance (No Interconnect or Dispatch Traffic) is only captured between 7 A.M. and 7 P.M., because too many sites are simply quiet overnight.

Carrier Level Variances

6. Carrier Low INI

The OMC has reported that the given Carrier from a BR has recently reported a "mean_ini" level in the range of -0db to -120db (note the OMC records -120db as a positive integer i.e. 120).

        mean_ini < 120

This number is shown as "worst_ini" in the various real-time displays. CROME will synthetically generate worst_ini as the lowest positive number for any network element (or child elements) across any time range. Thus if you run a CROME report on worst_ini at the EBTS level you will uncover the worst value that a Carrier exhibited for any element below a particular EBTS.

Note that although "mean_ini" is the same as "worst_ini" at the Carrier level, at higher levels (like a BSC or OMC) "mean_ini" will be presented as an average of an average, thus losing statistical validity.

---

If you have any questions about this real-time reporting or custom development and integration of other sub-systems please contact the wireless products division at wp@quantumsi.com.

Select an Area: