1. EAGLE LNP Application Processor Administration and LNP Feature Activation Guide
  2. ELAP Functional Description
  3. MPS/Service Module Card RTDB Audit Overview

3.4 MPS/Service Module Card RTDB Audit Overview

3.4.1 General Description

The fact that the ELAP advanced services use several databases creates the need for an audit that validates the contents of the different databases against each other. The audit runs on both MPS platforms to validate the contents of the Real Time databases (RTDBs). The active ELAP machine validates the database levels for each of the Service Module cards.

3.4.2 Functional Description

MPS RTDB Audit

This audit maintains the integrity of the RTDB Database on the MPS. This audit cycles through the entire RTDB within a 24-hour period and reports any anomalies in the form of an alarm. Once the RTDB is determined to be corrupt, provisioning is stopped and a data reload is required.

The audit is controlled through the RTDB Audit item on the MPS GUI Maintenance Menu. The state of the audit can be viewed and Enabled or Disabled through the Maintenance Menu.

When the RTDB Audit is enabled, an audit is automatically performed daily at 6:00 a.m. This audit file is stored in the ELAP system backup directory. Only the five most recent audits are stored and the older ones are automatically deleted . The stored audits can be viewed through the View Logs item in the Debug Menu.

When the RTDB Audit is enabled, the RTDB validates the CRC32 values per record entry within all tables. If corruption is encountered, an alarm is set on the MPS scrolling banner. All provisioning from the LSMS is halted until the condition is corrected via RTDB Reload.

ELAP-to-Service Module Card DB Level

Each Service Module card validates its own database level against the received ELAP database level. An inconsistent alarm is generated at the EAGLE for every inconsistent Service Module card. The EAGLE command rept-stat-db displays the LNP database on the Service Module card as Diff level. See Table 3-4.

Table 3-4 Inconsistent Service Module Card Alarm

UAM# Severity Message Text Output Group (UI Output Direction)

444

Major

RTDB database is inconsistent 

card

EAGLE Service Module Card Audit of MPS Databases

This audit is responsible for maintaining the integrity of the RTDB on the Service Module card. It cycles though the entire RTDB within a 24-hour period, reporting any anomalies in the form of alarms and possibly attempts to repair any found corrupted records with those from a mate Service Module card.

The EAGLE STP Options (chg-stpopts) command is used to set this audit. The DSMAUD parameter has two states, OFF and ON. When the DSMAUD parameter is set to OFF the auditing capabilities on each of the Service Module cards is disabled from auditing the RTDBs. Setting the DSMAUD parameter to ON enables the auditing capabilities, producing corruption alarms when corruption is detected. Setting the DSMAUD parameter to CCC enables the cross correction capabilities, providing a method for repairing corruption as it is encountered.

When corruption is encountered, several events occur:

  • The RTDB is set to Corrupt Status

  • A UAM (Corrupted RTDB Database Alarm) is sent to the OAM

  • The Corruption is logged and stored in a memory array and contains:

    • Table ID

    • Record Number

    • Table High-water-mark

    • Old CRC32 value

    • New CRC32 value

    • Record Address in memory

    • Record entry Contents

Table 3-5 Corrupted RTDB Database Alarm

UAM# Severity Message Text Output Group (UI Output Direction)

443

Minor

RTDB database corrupted

card

A maximum of 250 Log entries are permitted within an audit cycle. When this maximum is exceeded, the first 25 corrected records are output to the DB output group, and the card initiates a Full Re-Load.

Service Module cards in the corrupted state continue to receive updates from the MPS and continue to service MSU traffic.

All records received from the MPS are validated through the CRC32 routines prior to being written to memory. If a corrupted record is encountered, data is collected and depending upon the loading phase state, events will differ:

Table 3-6 Effect of Corrupted record received from MPS

MPS Loading Phase Effect of Corrupted Record Received

Phase I - Loading

Booting of Card and Full Reload Requested

Phase II - Resynchronization

Booting of Card and Full Reload Requested

Load Complete

Alarm Incoherent and Reload Required

Corruption Cross Correction

If a record within the RTDB database on any card should become corrupted, a mate Service Module card can supply the corrected data. Corruption Cross Correction occurs across the IMT and for each corrupted record encountered a single broadcast message is sent from the affected Service Module card to all mate Service Module cards. When a Service Module card receives a request for corruption correction, the current DB Level and requested record is evaluated for consistency. If the request is validated, a response is sent to the original card. Otherwise, the request is simply discarded. This would occupy 26 messages, at most, on the IMT bus for each corrupted record encountered. When a Corruption Correction Response is received, it is evaluated for correctness and applied once passed. Any subsequent messages received for the same correction are simply discarded.