LNP LSR/FOC Process Automation Whitepaper
Submitted by Telecom Software Enterprises, LLC
Draft Version 1.0
(06-24-97)
Executive Summary……………………………………………………………1
The Progression of LNP Planning Activities………………………………….. 1
Planning Activities In Progress……………………………………………….. 2
LNP LSR/FOC Process Automation Solution…………………………………3
Current Situation Analysis……………………………………………………..4
The LNP LSR/FOC Process…………………………………………………….4
Key Variables Affecting the Service Provider LNP LSR/FOC Process……….. 7
Volume of Ported Numbers In a Region………………………………………..8
Different Interconnection Agreements………………………………………….9
Differing Levels of Technology……………………………………………….10
High Level I-SP Process Server Requirements……………………………….. 11
LSR Functions…………………………………………………………………12
FOC Interface ……………………………Error! Bookmark not defined.
Potential Solution ……………………………………………………………...10
Overview………………………………………………………………………10
LSR/FOC Low-Tech Interface………………………………………………….11
I-SP Process Server Advanced Interface…………………………………..…...11
Guaranteed Message Delivery………………………………………………….11
Responses to Transactions………………………………………………….….11
Coordination of Porting Activity with the NPAC………………………………12
Business Arrangements Between Service Providers………………………..…..12
Access to Marketplace LSR/FOC Information………………………………....13
I-SP Process Server System Architecture……………………………………….13
Access and Presentation Subsystem……………………………………………..14
Application Subsystem…………………………………………………………..14
Messaging and Queuing Subsystem……………………………………………..15
Relational Database Management System ………………………………………16
Inter-Service Provider Process Example………………………………………...16
Inter-Service Provider Process Server Deployment……………………………..19
Inter-Service Provider Process Server Administration………………………….19
To enable the implementation of Local Number Portability (LNP), the telecommunications industry is deploying new systems capable of managing the changes in network routing information required when a customer changes their local service provider. The industry has conducted formal planning activities to define the LNP requirements for industry-level systems and processes.
Formal LNP implementation planning activities began in the Network Element Layer (NEL) of the Telecommunications Management Network (TMN) model as the industry defined the new network capabilities required to enable call completion of ported numbers. Upon selection of Location Routing Number (LRN) to route calls, the industry turned its focus to the Network Management Layer (NML) of the TMN model and defined the requirements for centralized management of the LRN routing notifications.
The NPAC SMS was conceived as the system to manage ported number notifications for all service providers in a given region. The NPAC SMS downloads updated routing data to each service provider via a Local Service Management System (LSMS).
The next step in the LNP planning process was to define the order capture and NPAC update processes in the Service Management Layer (SML) of TMN. Service providers capture LNP order data and update the NPAC via a Local Service Order Administration (SOA) system.
Compared to the formal, LNP-specific planning activities that defined the NPAC system and processes, the definition of the inter-service provider processes necessary to support LNP are proceeding informally. Industry bodies such as the Orders and Billing Forum (OBF) are defining standards for the process, but the service providers are not conducting implementation planning with the same rigor as was evident with the NPAC system and processes. It could be argued that formal planning activities for the LNP LSR/FOC process automation where kicked off on June 11th 1997 when Telecom Software Enterprises presented a high level overview of the LNP LSR/FOC system and processes contained in this document to the Illinois Operations Subcommittee workshop in Chicago, Illinois.
This report provides a high level analysis of industry requirements for the initial inter-service provider processes necessary for the generation of LNP LSR and FOC documents. This report also offers an automated solution in support of the inter-service provider LNP LSR and FOC processes.
The solution is a centralized application that supports LSR and FOC creation and administration activities between all the new service providers in a region. Without the benefit of process automation offered by this type of application, all service providers within a given region would rely on manual tracking and communication between service providers. As with any high volume process reliant upon manual effort, many opportunities exist for the breakdown of the processes.
Figure 2-1 illustrates the initial steps in the
process of porting a customer's service from one service provider
to another. The process flow models steps 1 through 8 in the
Inter-Service Provider LNP Operations Flows <Provisioning>
as defined by the North American Numbering Council (NANC).
Figure 2-1 Inter-Service Provider LNP
Operations Process Flow
| Inter-Service Provider LNP LSR/FOC Process Flow Descriptions | |
| Step | Description |
| 1 | Customer interaction. The service provider and the customer have initial discussions. |
| 2 | Switching service provider? The customer decides whether or not to change service provider. |
| 3 | If the customer decides to change service providers. The new service provider creates and sends an LSR to the current service provider. The information required on an LSR is defined by the OBF. This is the first step in the process that could be effectively automated. Representatives of the new service provider could capture the LSR data using the LNP LSR/FOC application. The LNP LSR/FOC application would validate the order content and submit the validated LSR to the current service provider via the current service provider's preferred method of transmission. When the LSR is submitted, the LNP LSR/FOC application would start a timer to track the current service provider's response time. |
| 4 | The LNP LSR/FOC application monitors the responses from all the service providers. If the current service provider does not respond within the allowable window the LNP LSR/FOC application notifies the new service provider. |
| 5 | If the current service provider does not respond within the allowable window, or the response is not valid, the LNP LSR/FOC application notifies the new service provider. |
| 6 | If the current service provider responds within the allowable window, and the response is valid, the new service provider creates and processes their internal service order. |
| 7 | When the current service provider responds with a valid response, their next action is to create and process their internal service order. |
| 8 | If the current service provider does not respond within the allowable window, or the response is not valid, the new service provider receives the notification from the LNP LSR/FOC application and can contact the current service provider to expedite the order. |
Initially, the LNP LSR process appears to be simple. Further analysis of several key variables demonstrates areas for concern:
The shear volume of activities can overload even the simplest process. The following information quantifies ported number activities for a generic region:
Each service provider in a region could potentially negotiate
different business arrangements with every other service provider
in the region. If this occurs the service provider's
representatives would have to have knowledge of the terms of each
business agreement. For example: the service provider's
representative would have to be aware of, and track different LSR
response times. This variable alone could increase the complexity
of the process by seven to ten times. Figure 2-2 illustrates the
complexity of the interconnection agreements. The relationships
resemble a network without a switch.
Figure 2-2 Current Service Provider
Interconnection Relationships
Just as the business agreements could vary from service provider to service provider, so will each service provider's technical capabilities. Each service provider's representative would have to be aware of all the other service providers' technical capabilities. For example: One service provider might request that they receive all LSRs via fax. Another service provider might wish to receive LSRs via e-mail. Not only will the service provider's representatives be required to track the differences in technical capabilities, they will be required to track changes to every service provider's technical capabilities. None of these methods guarantees delivery of facilitates tracking.
Process automation is required to effectively create and administer LNP LSRs/FOCs in a high-volume environment where many participants have disparate technical capabilities. Automation of this procedure enables the service providers to concentrate their efforts on the marketplace. Once a service provider generates the requisite information, a centralized application will route the information to the appropriate parties. The application will also track the timing of all activities in the region.
As an added benefit to all service providers within the region, the centralized application could provide access to information concerning all porting activity in the region. With manual LNP LSR/FOC processes, only the service providers involved in porting a customer have access to the porting activity of that customer. The other service providers do not have access to this information until the request is activated from the NPAC. This type of information could prove to be valuable strategic marketing information.
Figure 2-3 illustrates the service provider
relationships when managed by a central application or server.
Figure 2-3 Service Provider
Relationships Managed By a Central Application
The LSR/FOC process application must provide the following LSR functionality:
To address the Industry's LSR and FOC coordination activities, TSE suggests the deployment of a UNIX-based intelligent process automation server to provide for the receipt, routing, and management of LSR/FOC documents. The server should be referred to as the "I-SP Process Server". The I-SP Process Server enables intelligent messaging between disparate computing systems and is designed to address the following LNP LSR/FOC process requirements:
I-SP Process Server is an intelligent server that enables high volume, distributed processing of LNP LSR/FOC documents across service provider networks. The I-SP Process Server uses a set of system rules and message formats to control the processing and delivery of LNP LSR/FOC documents. I-SP Process Server is designed to interface and adapt both new and legacy applications by facilitating the routing, transmission, interpretation, and coordination of data flow to both "like" and "unlike" destinations. I-SP Process Server provides transaction synchronization, persistent guaranteed delivery, content-based routing, and formatting to multiple destinations.
The architecture of I-SP Process Server is based on functional layers, providing persistent messaging, rules-based LNP LSR/FOC documents processing and web browser enabled user access. The I-SP Process Server leverages modern database and transaction technology to synchronize LNP LSR/FOC document transactions. The I-SP Process Server design permits convenient portability to a wide range of hardware, operating systems, and RDBMSs.
The I-SP Process Server is initially designed to run on a single CPU server running UNIX. The I-SP Process Server is designed to take advantage of a symmetrical multi-processing machine/OS environment but does not require such an architecture initially.
Each service provider has access to the I-SP Process Server Low-Tech Interface (LTI). The LTI allows a user to create, modify, delete, and monitor the progress of LSR/FOC activity within the region. The LTI is based on web browser technology and can be accessed using commercially available web browsers.
Each service provider can also communicate electronically with the I-SP Process Server via an electronic interface. The electronic interface supports communication with existing systems via the I-SP Process Server open API. System-to-systems communications capabilities include manager-agent protocol support as well as peer-to-peer messaging.
The I-SP Process Server is built on the architecture of guaranteed message delivery. Each message received into the I-SP Process Server will be stored and queued until the destination system has acknowledged receipt of the message. This feature allows for a service provider to focus their energy and efforts to the marketplace and letting the I-SP Process Server handle the mundane task of routing and receiving responses to message requests.
Additionally, each LSR and FOC received by the I-SP Process Server will be given a unique identifier. This identifier can be used throughout the lifecycle of a porting request as a tie back to the supporting LSR and FOC documents.
As LSRs or FOCs are sent to a particular service providers, the I-SP Process Server sets a timer associated with the transaction. If a response to the LSR or FOC is not received within the time period allotted, the I-SP Process Server can take any (or all) of the following actions:
As a response is received by the I-SP Process Server, it is examined and the appropriate path of action is implemented. For example, if a request for an FOC is not agreed upon by the current service provider, the I-SP Process Server will route the appropriate information to the new service provider and track the resolution process. If a concurring FOC is received, then the I-SP Process Server sends a message to both the new and current service providers indicating that a porting service order can be created and sent to the NPAC.
Utilizing data downloads from the NPAC, the I-SP Process Server will update LSR and FOC documents with the porting status of the request. This allows for the I-SP Process Server data to reflect the reality of the network. For example, if a porting request is cancelled in the NPAC, then the corresponding LSR and FOC documents will be updated to indicate that the customer was not ported.
Each service provider defined in the I-SP Process Server can be configured to reflect business arrangements between other service providers. For example, a service provider may agree that the incumbent service provider has X days to respond to a LSR due to the high level of volume the incumbent is likely to encounter. However, the other service providers in the region may only have X-3 days to respond to a LSR. The I-SP Process Server has designed in the flexibility to handle these types of arrangements on a SP-to-SP basis.
To deliver the functionality described above, I-SP Process Server system is constructed of four major components:
The logical architecture of the system is shown
in Figure 3-1.
Figure 3-1. The I-SP Process Server
System Architecture
The I-SP Process Server is highly scalable due to the nature of its core components. Because the communication mechanism employed by the system uses asynchronous messaging and an RDBMS as the primary means of performing operations, the system can easily be reconfigured to distribute components of the application to different hardware platforms.
The I-SP Process Server Access and Presentation Subsystem provides for user access into the I-SP Process Server via a user friendly GUI utilizing current web browser technology. The Access and Presentation Subsystem provides:
The application subsystem consists of three primary modules:
The message formatting and routing module provides a flexible method to define and maintain message formats. I-SP Process Server message formatting capabilities allow users to describe the form of messages, both input and output, rather than the process of conversion. Based on these format definitions, I-SP Process Server dynamically decomposes (parses) input messages into fields. It then assembles (reformats) output messages based on format definitions.
The formatting module supports the creation and dispatch of multiple new, independently formatted and delivered messages to multiple destinations or processes from a single input message. The formatting module can be used for message and transaction routing, duplication, replication, and as a trigger for propagation mechanisms.
The I-SP Process Server provides a flexible rule definition capability that supports a variety of system actions and capabilities. The application module is designed to support:
The reporting module allows for the generation and distribution of defined report formats. Users can select to receive the reports online, by fax, or by email.
The messaging and queuing subsystem, supports inter-process and cross-platform communication and provides a high degree of stability, synchronization, and recoverability.
The persistence mechanism that will be employed for all data storage is a comercially available RDBMS. The messaging and queuing subsystem and application subsystem make independent use of the RDBMS storage facilities. The initial system deployment will have a single database instance serving both system components. As the system expands and capacity demands, the system can be easily modified to move either subsystem to a different database server or instance.
Figure 3-2 illustrates the possibilities for process automation using the I-SP Process Server. Figure 3-2 also illustrates the coordination challenges associated with automating the LNP LSR/FOC process. To facilitate end-to-end automation, service providers will be required to coordinate:
Figure 3-2 Inter-Service Provider
Process Example
| Fully Automated LSR/FOC Process | |
| Step | Description |
| 1 | The new service provider (SP #2) uses the order entry GUI of their existing Service Order Entry (SOE) system to capture data for the new customer. The data is submitted by the GUI to the SOE. |
| 2 | The SOE sends a message to the I-SP Process Server requesting the creation and submission of an LSR document. |
| 3 | The I-SP
Process Server:
|
| 4 | The LSR document is delivered to the current service provider's (service provider #6) SOE via asynchronous messaging. |
| 5 | The current service provider's GUI receives notification of the LSR document from their receiving system. |
| 6 | The current service provider responds with a request to create a Firm Order Confirmation (FOC) document. |
| 7 | The FOC document is delivered to the I-SP Process Server via asynchronous messaging. |
| 8 | The current service provider's SOE also notifies their LSOA of the FOC. |
| 8.1 | The current service provider's LSOA sends a 'subscription version create' request to the NPAC. |
| 9 | The I-SP
Process Server:
|
| 10 | The I-SP Process Server can provide third parties, such as law enforcement agencies, with updates on LSR/FOC activities in the region. |
| 11 | The FOC document is delivered to service provider that originated the LSR via asynchronous messaging. |
| 12 | The new service provider's GUI receives notification of the FOC from their receiving system. |
| 13 | The new service provider's SOE also notifies their LSOA of the FOC document. |
| 13.1 | The new service provider's LSOA sends a 'subscription version create' request to the NPAC. |
| 14 | The I-SP Process Server could receive subscription version updates from the NPAC. |
The I-SP Process Server is intended to address the industry's LNP LSR and FOC requirements. Because the system is designed to serve the entire industry it has in several different deployment scenarios:
No matter which the deployment scenario is chosen, an entity needs to be identified and authorized to implement and administer the I-SP Process Server. Telecom Software Enterprises will continue to work with the industry to refine the system requirements and define the system administrator's roles responsibilities.