LNP Database Synchronization Overview

2 LNP Database Synchronization Overview

This chapter presents an overview of the various methods available, depending on the features installed, for synchronizing the LNP database on the network element with the LNP database on the local service management system.

Introduction

Local Number Portability (LNP) provides the ability to change (port) the telephone service from one service provider to another service provider without changing the telephone number.

LNP is managed by Number Portability Administration Centers (NPACs), which serve different geographical regions. NPACs distribute LNP data to local service management systems (LSMSs) which, in turn, distribute the LNP data to network elements, for example, EAGLE STPs. The Oracle Communications LSMS can service up to eight NPACs and up to eight pairs of network elements, as represented in Figure 2-1.

Figure 2-1 Local Number Portability Network

This user's guide describes the various methods used to keep data synchronized between the LSMS and the network element.

This user's guide does not describe synchronization activities between the NPAC and the LSMS. For information about how data is synchronized between the NPAC and the LSMS, refer to Database Administrator's Guide for LSMS.

LSMS Connectivity

The main function of the LSMS is to provision LNP data to the EAGLE. In order to perform this task, the LSMS maintains active connections with one or more NPAC region servers and one or more EAGLE nodes. While it is the goal of the LSMS to maintain active connections to each NPAC server and EAGLE node as nearly full-time as possible, the more important goal is to reliably forward the data from the NPAC to the EAGLE as quickly as possible. To that end, a number of protective problem detection and recovery mechanisms are built into the LSMS design. Several of these protections actually allow for the termination of application connectivity in order to gracefully restore full connectivity and guarantee total recovery of data.

In the following situations, the LSMS proactively terminates and re-establishes application connectivity with the NPAC and EAGLEs:

If the LSMS detects network level connectivity failures with either the NPAC or EAGLE, the respective LSMS processes terminate the socket level connection and then reconnect. This disconnect and reconnect occurs in a matter of seconds. Built-in re-synchronization mechanisms ensure data recovery. The data transmission is delayed by the time required to disconnect and reconnect, but the execution of the recovery procedures prevents data loss.
If the LSMS detects critical internal errors that would cause system outages, the LSMS processes are designed to terminate and allow the LSMS sentry process to restart them. This is only done for significant internal errors that jeopardize internal LSMS communications. Once the sentry process restarts the LSMS processes, re-synchronization provides full data recovery. The restart time for processes by sentry consists of the detection time plus the restart time. Processes typically are restarted within 30 seconds.

LSMS to ELAP Connection

All normal LNP provisioning is conducted through the LSMS. Localized retrieval of data can be accomplished through the ELAP user interface.

The LSMS communicates only with the HA-Active ELAP in the MPS system using a Virtual IP (VIP) address interface. The LSMS connects to the HA-active ELAP at initialization. Although there are three ELAP states (HA-Active, HA-Standby, and Down) only the HA-Active member of the ELAP HA pair is connected to the VIP and listens for provisioning, audit and bulk download connections from the LSMS. The LSMS provisions LNP data to the HA-Active ELAP across a TCP/IP connection in the customer network.

LSMS Functions

The LSMS is responsible for the following functions:

Sending normal updates to network elements
Ensuring that supported network element’s LNP database is synchronized with the LSMS LNP database

Sending Normal Updates

Normal updates sent by the LSMS consist of:

NPAC data that is received from NPACs and forwarded to the network elements. The LSMS keeps data for each NPAC region in a separate regional database. The NPAC, LSMS, and the network elements all must have the same LNP data for a given region.
Locally provisioned data that is entered by the customer in a centralized place (the LSMS) and then forwarded to one or more network elements. The LSMS stores locally provisioned data in the supplemental database, which is separate from the regional databases. The LSMS sends the locally provisioned data in the supplemental database to multiple network elements. Locally provisioned data must also be the same between the LSMS and the network elements.

Normal updates are sent from the LSMS to the active ELAP at a rate of 25 TNs per second over a connection that uses the High-Speed Operations Protocol (HSOP) over TCP/IP. The ELAP forwards the messages to all Service Module cards using an IP multicast protocol (for more information, refer to Administration and LNP Feature Activation Guide for ELAP).

Synchronizing LNP Databases

In this book, the term LNP database is used to mean a combination of regional and locally provisioned data:

At the LSMS the LNP database is considered to be the combination of regional data and locally provisioned data that corresponds to the network element to be synchronized.
At a network element the LNP database is considered to be one database which contains both regional data and data that was provisioned at the LSMS. The network element’s LNP database usually has multiple copies at the network element; each configuration described in this manual specifies where in the network element the main LNP database is located. Synchronization methods between the main network element LNP database and its copies within a network element are described in other manuals; references are stated where appropriate.

The LSMS synchronizes with only a single copy of the network element’s LNP database. Usually the synchronization occurs with the main network element LNP database; exceptions are noted as appropriate.

The LSMS is responsible for ensuring that the network element’s LNP database is synchronized with the LNP database at the LSMS. If the LNP databases of the LSMS and network element get out of synchronization (for example, after an outage), the network element’s LNP database must be synchronized to match the LSMS LNP database, which is considered to be the master database.

The LSMS and the network element use the following methods to synchronize their LNP databases. For information about which method to choose, see Choosing a Database Maintenance Procedure. Some methods permit synchronization from another network element LNP database that is known to be synchronized with the LSMS LNP database.

Resynchronizing—the LSMS resends all transactions that were previously sent from the LSMS to the network element up to a maximum number of transactions or a maximum period of time. The following types of resynchronization are available (for a more detailed overview, see Resynchronizing LSMS and Network Element Data):After any outage between the LSMS and a network element, the LSMS and the network element automatically attempt to resynchronize. If the number of transactions that needs to be retransmitted is less than the maximum number of transactions that can be stored in the LSMS resynchronization database (which can store a maximum of one million transactions), automatic resynchronization occurs without operator intervention. For more information, see Automatic Resynchronization Process
- Automatic resynchronization—.
- User-initiated resynchronization—User-initiated resynchronization can be performed as long as the database time stamp (DBTS) on the network element’s database is no more than seven days earlier than the current date at the LSMS. If the DBTS is within seven days, the user-initiated resynchronization retransmits all transactions that were previously sent in the last seven days.
Reconciling—after an audit of network element LNP data, the user can reconcile any differences discovered by the audit. Reconciling allows the user to update only the LNP database records that are found to be different during an audit. An audit compares certain types of LNP data at the LSMS with the same types of data at the network element.

The user can choose to perform only an audit or to perform an audit and reconcile; the options are described later in this manual (see Auditing and Reconciling Network Elements from the LSMS). Although auditing without reconciling does not result in synchronized LNP databases, that option is also described in this manual.

The LSMS allows various types of audit and also allows the user to choose to reconcile any discrepancies found during the audit. Reconcile records are sent as normal updates and are available after any kind of audit. For a more detailed overview, see Auditing and Reconciling Network Element Data.
Bulk loading—completely replaces a network element LNP database. Sometimes so much data needs to be corrected that neither reconciling audited data nor resynchronizing the data is sufficient. The following types of bulk loading are available (for a more detailed overview, see Bulk Loading LNP Data):
- Support ELAP reload via database image—Introduced in ELAP 9.0. Improves the bulk data download time by using a snapshot of the database.
- Electronic bulk load from the LSMS—Available if certain optional features are installed at the LSMS and at the network element.
- Bulk load (reload) from RTDB on mated network element’s standby ELAP—Available if certain optional features are installed at the network element and if both network elements are treated similarly by the LSMS. This choice requires steps to be performed at the LSMS to determine whether the network elements are treated similarly by the LSMS, but actual loading of data involves only the mated network elements.

Additional information about synchronization methods is available in overview form in Overview of Synchronization Methods, and more detailed information about each synchronization method is presented in the remaining chapters of this manual.

LNP Configuration

Figure 2-2 shows the LNP configuration of the LSMS, MPS, and EAGLE.

Figure 2-2 LNP Configuration

Overview of Synchronization Methods

The following sections provide an overview of the basic resynchronization methods. More detailed information is available in the remainder of this manual.

Resynchronizing LSMS and Network Element Data

The LSMS stores data that is sent to network elements in the following ways; this stored data enables the LSMS and network element to resynchronize, either automatically or by user initiation:.

A resynchronization database that stores all NPAC and locally provisioned data sent to any network element. This database holds a maximum of one million entries. This database is used for automatic resynchronization, as described in Automatic Resynchronization.

For each network element, a log file that records all NPAC and locally provisioned data sent to that network element for the last seven days. These log files are used for user-initiated resynchronization, as described in User-Initiated Resynchronization.

While resynchronization is occurring, any new updates received at the LSMS are stored in the pending queue. When an automatic resynchronization is complete and normal traffic between the LSMS and network element resumes, the updates in the pending queue are transmitted as normal updates.

Automatic Resynchronization

The LSMS and network element attempt to resynchronize automatically after any outage between the LSMS and a network element. When the LSMS and network element reconnect, the network element sends the LSMS the Database Time Stamp (DBTS) of the last update it received before the outage. If the LSMS finds that DBTS in the LSMS resynchronization database, it begins automatic resynchronization using the same protocol as is used for normal updates.

For information about the actions performed by the LSMS and network element during automatic resynchronization, see Automatic Resynchronization Process. If the LSMS determines that automatic resynchronization cannot be performed because the DBTS is not found in the resynchronization database, notifications are posted at both the LSMS and the network element (see “Notifications that Database Maintenance Is Required”). If those notifications are posted, you can choose among various options for proceeding with synchronization (see “Choosing a Synchronization Procedure”).

Automatic resynchronization uses the same protocol as is used for normal updates.

User-Initiated Resynchronization

This optional method of resynchronization can be initiated by the LSMS user when automatic resynchronization cannot be performed because more transactions need to be retransmitted than can be accommodated by automatic resynchronization. The number of transactions accommodated by user-initiated resynchronization is limited only by the fact that the log files are maintained only for seven days.

Auditing and Reconciling Network Element Data

The user can initiate from the LSMS an audit of various types of data at any time except as noted in “Audit and Reconcile Function Summary”. An audit compares the record for the specified data type at the network element with that at the LSMS. The user can also choose to reconcile any discrepancies found during an audit.

The following types of audit and reconcile are available; the first type can be performed simultaneously for a given network element with either of the other two types:

Audit and optional reconcile of a single SV or NPB —This type of audit uses the normal update channel to compare a specified subscription version or number pool block record in the LSMS LNP database to the corresponding record in the LNP database. If any discrepancies are found, they can be reconciled immediately.

Note:

This type of audit is not available for LSMS releases prior to 8.X.
Audit and optional reconcile of SVs and/or NPBs by NPA-NXX range, or of SVs and/or NPBs by time range —This type of audit uses the normal update channel to compare a checksum for each subscription version or number pool block record within a range of numbers or within a time range in the LSMS LNP database to the checksum of the corresponding record in the LNP database. If the checksums match, it is assumed that the records are the same.

After the audit completes, if differences were found, the LSMS user can choose to view the full records of each encountered difference. In addition, the LSMS user can specify whether any differences found should be reconciled.
All other audit and optional reconcile (for example of DGTT, OGTT, and NPA Splits, of all TNs and/or NPBs) —This type of audit compares the checksum for each specified record in the LSMS LNP database to the checksum of the corresponding record in the LNP database. If the checksums match, it is assumed that the records are the same. For information about the types of data that can be audited with this type of audit, see Types of Data to Audit and Reconcile.

After the audit has completed, the LSMS user can specify whether differences found should be reconciled.

Note:

For LSMS releases prior to 8.X, any reconcile must be done as soon as the audit completes. For LSMS Release 8.X, aA reconcile for a Single SV/NPB audit must be performed as soon as the audit is complete, but reconciles for the other types of audits can be performed immediately or can be postponed for reconciling later. The postponement can be up to seven days.

Bulk Loading LNP Data

Bulk loading completely replaces the main LNP database at a network element. The LNP database consists of regional and locally provisioned data. Bulk loading is required if the network element is being initialized for one of the following reasons:

Bringing the network element into the system for the first time
Modifying the network element’s area of service by reconfiguring EMS routing

The following types of bulk loading are available:

Support ELAP reload via database image (SERVDI)—creates an RTDB file directly from the LSMS LNP database. This file is then transferred to the ELAP backup directory and activated using the GUI Restore from Backup menu. The amount of data transmitted over the customer WAN is significantly reduced as well as the time to reload the database.
Electronic bulk load from the LSMS to ELAP—extracts the LNP database from the LSMS and downloads it to the RTDB of the active ELAP at the network element. The transmission from the LSMS to the ELAP requires about one hour for each million numbers in the LNP database. The distribution of the RTDB from the active ELAP to the standby ELAP and to the Service Module cards is part of a separate procedure (see Distributing an RTDB to Service Module Cards).
Bulk load (reload) from RTDB on mated ELAP—copies the RTDB on the ELAP mate to the RTDB that needs restoration. This type of bulk loading usually takes under ten minutes.

Bulk load (reload) from RTDB on mated network element’s standby ELAP—copies the RTDB on standby ELAP at the mated network element to the RTDB that needs restoration. This choice requires steps to be performed at the LSMS to determine whether the network elements are treated similarly by the LSMS, but actual loading of data involves only the mated network elements.

Both network elements must be treated similarly by the LSMS.

Table 2-1 compares the various bulk load options available.

Table 2-1 Bulk Load Options

Bulk Load Type	See Chapter:	User Action at LSMS	User Action at NE
Bulk Load Type	See Chapter:	Support ELAP reload via database image	6	Yes	Yes
Electronic bulk load from the LSMS to ELAP	6 and 8	Yes	Yes
Reload from mated ELAP RTDB	7 and 8	No	Yes
Reload from standby ELAP's RTDB on mated network element	7 and 8	Yes	Yes

Maximum Number of Simultaneous Synchronization Operations

The LSMS supports the following maximum number of simultaneous synchronization operations:

Maximum Number of Simultaneous Synchronization Operations for LSMS

With ELAP, the following synchronization operations can run simultaneously, of which only one operation is allowed at a time per network element:

Bulk loads (a maximum of two bulk loads, of different network elements, can occur simultaneously)
Range audits (with or without reconcile) for each supported network element (the LSMS can support up to sixteen network elements)

Table 2-2 illustrates the maximum number of simultaneous operations for LSMS.

Table 2-2 Maximum Number of Simultaneous Synchronization Operations for LSMS

Synchronization Operation	Maximum Number Running Simultaneously (to different network elements)
Bulk Load	2
Range Audit (with or without reconcile)	8
Single SV/NPB Audit (with or without reconcile)	16

For example, you can perform a bulk load of STP1, a bulk load of STP2, a user-initiated resynchronization to STP3, Range Audits of STP 3, STP4, STP5, STP6, STP7, and STP8, as well as a Single SV/NPB Audit of each network element, all at the same time, for a total of 16 synchronization operations.