PDF of this tutorialNetwork Elements
Architecturally, there are seven basic components required to deploy LNP: the SSP, the STP, the SCP, the SCP management server (SCP MS), the local service management system (LSMS), the NPAC, and service order administration (SOA) capability. Figure 1 illustrates the telecommunications management network (TMN) reference architecture for the seven LNP components.
Figure 1. LNP Architecture
SOA
SOA provides the necessary functionality to interface to carriers’ order and provisioning systems to update the NPAC with ported TN data for access by all other carriers. The SOA’s primary functions may include the following: subscription audit request/management, data administration, data transfer to the NPAC, report generation, bulk file parse and upload, subscription tracking, legacy order entry interface, and logging. Depending on an individual service provider’s requirements, the SOA may interface with multiple NPACs to allow for nationwide number portability. The carrier-to–SOA connection may be custom-designed to interface with existing carrier order-entry systems. However, the SOA interface to the NPAC is a common management information service element (CMISE), providing subscription-management functions as well as logging, error reporting, and alarm functions. Specific industry-approved interface requirements are contained in the NANC Functional Requirements Specifications (FRS) and Interoperable Interface Specification (IIS).
NPAC
On July 2, 1996, the FCC issued an order in Docket No. 95-116 describing the third-party, neutral database administration function in support of number portability. This database is designed to receive information from both the incumbent and new service providers, validate the information received, and download the new routing information when an “activate” message is received indicating that the customer has been physically connected to the new service provider’s network. Each ported number is a “subscription version” within NPAC that contains the new service provider’s I.D., the LRN associated with the new switch, and routing data associated with additional services the customer may request (i.e., line information database [LIDB], calling name delivery [CNAM]). The NPAC also maintains a record of all ported numbers and a history file of all transactions relating to the porting of a number. The NPAC provides audit functionality and the ability to retransmit subscription version information to local service-management systems under certain conditions. The NPAC is not involved in real-time call processing.
The NPAC provides management, administration, oversight for and integration of the NPAC operations, hardware and software development, and all maintenance-related functions. It has responsibility for achieving performance standards established by the industry and providing user and technical support services and training for industry participants on an ongoing basis.
LSMS
The LSMS is a fault-tolerant hardware and software platform that contains the database of information required to enable routing and call completion to ported telephone numbers. The primary functions of the LSMS are subscription management, network data management, service provider data management, error processing and notification, transaction event logging and reporting, transmission of activation/deactivation events to the network elements, and audits.
The LSMS interface with the NPAC provides real-time activation/deactivation information upon download from the NPAC and can send responses to the NPAC once a message or subscription version is processed. Similar to the SOA, the interface between the LSMS and the NPAC is CMISE and contains capabilities for event logging, security, and alarming. The LSMS is expected to mirror NPAC ported routing information and has the functionality to request updates from the NPAC in a variety of ways if database synchronization is in question. Specific industry-approved interface requirements are contained in the NANC FRS and IIS.
SCP MS
The SCP management system provides interface services between the LSMS and the SCP. The SCP MS may or may not be physically integrated with the SCP.
Number Portability Database (NPDB)
The NPDB is the network element that contains the routing information necessary to support number portability. The NPDB provides the association between the called party and the carrier LRN, identifying the switch to which the call should now be routed. The NPDB stores all ported numbers within the ported domain. Carriers today have the option of choosing between two different LNP database architectures for accessing the LRN associated with a particular DN: an integrated STP/SCP configuration or an STP with an adjunct SCP.
This NPDB provides the LRN for a particular DN. The correct routing information for SCP–based services, including LIDB, CNAM, custom local-area signaling services (CLASS), interswitch voice messaging (ISVM), and wireless short message service (SMS) for a ported DN, is determined by 10-digit global title translation (GTT), also stored in the NPDB.
The SCP is a high-transaction–oriented server that receives intelligent network (IN) and advanced intelligent network (AIN) 0.1 LNP transactional capabilities application part (TCAP) messages or number portability request (NPREQ) messages from the SSPs/MSCs using the SS7 network. As an alternative, some providers deploy an integrated STP/SCP platform, which may also provide for a high transaction rate capability but requires less infrastructure (links and ports).
STP
The STP receives the LRN query from the SSP/MSC, routes the query to the appropriate NPDB, and returns a response to the originating SSP/MSC. While the need for a new translation type and the possible need for additional tables were previously identified by Alliance for Telecommunications Industry Standards (ATIS), the basic core functionality of the STP as a network message router has not been impacted.
SSP/MSC
The SSP/MSC is owned and operated by the exchange carrier. These switch points must be able to generate an SS7 LNP query to the NPDB when a call is placed to a telephone number in a ported domain. A ported domain is an MSA that has implemented number portability. A query is generated on any call to an NPA–NXX that has been designated as portable in the local-exchange routing guide (LERG) and NPAC with at least one ported number and marked as such in the switch routing tables.
Call Flow: Wireline to Ported Wireline Number
- A wireline customer dials a wireline number that is ported. The SSP queries an internal table that identifies all NPA–NXXs that are portable.
- If the dialed NPA–NXX is marked as portable, the originating SSP will determine if an SSP query should be launched. A query is not required when the following conditions exist: a) if the called party DN is served by the switch; b) if the call is routed to an operator system or interexchange carrier; c) if an NP query was already made for the call; or d) if the serial triggering limit is exceeded. If none of the preceding conditions exist, the SSP formulates and launches an SS7 TCAP query to the NPDB.
- The originating switch receives the NPDB response and analyzes the data. The LRN is translated in the NP routing tables and an ISUP route out of the switch is determined. The LRN is stored in the called party number (CdPN) parameter, and the dialed digits are stored in the generic address parameter (GAP) of the ISUP initial address message (IAM). In addition, the forward call indicator (FCI) or number translated indicator is set to indicate a query has been done (set to “translated number”).
- The call is routed to the recipient switch based on the LRN. The recipient switch receives and processes the contents of the IAM and completes the call to the subscriber.
- If, after the originating switch initiated a query and analyzed the response data, determines the dialed number has not ported the call is routed to donor switch based on the original dialed digits. As with a ported TN, the dialed number is translated in the NP routing tables and an ISUP route out of the switch is determined. The dialed number is stored in the CdPN parameter and the FCI indicator is set to indicate a query has been done. The GAP is not included in the IAM for this scenario. The donor switch receives and processes the contents of the IAM, does digit analysis on the dialed digits, finds the subscriber on the switch, and completes the call.
Figure 2. Wireline to Ported Wireline Number
