Detroit

LNP

Field Test

FINAL REPORT

Compiled under the supervision of

Dick Dowd

Detroit LNP Field Test Coordination Manager

MCI Telecom Inc.

2250 Lakeside Blvd.

Richardson, Texas 75082

972-498-5069

972-498-5022 (fax)

2584443@MCIMAIL.COM

CONTRIBUTORS:

Rick Arzadon (TCG)

Robert Bartenstein (Ameritech)

Nancy DeRoo (Ameritech)

Dick Dowd (LLC)

Anne Driscoll (MCI)

Clyde C. Hamby (ATT)

Hampton Oberle (MCI)

Steve Markowski (LHM)

Detroit LNP Field Test

Executive Summary

The Detroit Local Number Portability (LNP) Field Test has been conducted by the Service Providers (Ameritech, MCI and TCG) in Detroit, Michigan.. The Detroit LNP

Field Test built upon the Illinois LNP FCC Field Test and further verified the viability of the Location Routing Number (LRN) method and ensured that the technology intended for long-term service provider number portability was consistent with the performance criteria established by the FCC. ATT performed several tests by calling ported numbers in the Detroit, Michigan area but did not take part in porting.

The objective of the Detroit LNP Field Test was to further demonstrate the feasibility of a long term database Local Number Portability solution (LRN) in a functional network situation using participant equipment and personnel to determine network and operational impacts. The Field Test successfully demonstrated that LNP could be achieved via the LRN database industry chosen solution in Detroit, Michigan.

The Detroit LNP Field Test provided an opportunity for participants in the Detroit area to implement and test the technical and operational requirements in connection with an LNP database solution. The Detroit LNP Field Test was conducted using the LRN local number portability routing scheme.

Using a committee developed test plan, based upon the Illinois LNP FCC Field Test Plan, which guided participants through the execution of intra- network and inter-network testing of the LRN database LNP solution. The tests were conducted by the participants and their vendors utilizing test telephone numbers that reside within live NPA-NXXs to emulate the moving of live customers. Actual customers and their working dialed numbers (DNs) were not involved.

Testing involved the establishment of portable NPA-NXXs, making translation updates to the participant’s switch and SS7 network for routing of ported calls between participants’ switches. Additionally, the operational processes were performed in order to emulate the moving a customer from one Local Service Provider (LSP) to another LSP, and ensuring that the phone service was functioning properly without loss of functionality.

Lessons Learned

• Careful coordination and sequencing of inter-company LNP operational process flows is essential for seamless service to the customer.
• The new Local Service Provider should initiate the coordination of the LNP request from customer contact through service activation.
• It is extremely important that the associations between each Local Service Management System (SMS) and Number Portability Administration Center (NPAC) have a high degree of availability.
• The entire trunking, Signaling System 7 (SS7) arrangements and signaling paths for all services (ISDN User Part (ISUP), LIDB/ABS, Calling Name (CNAM), and CLASS) need to be mutually agreed upon by LSPs and accurately documented by both interconnecting companies prior to testing and/or service introduction. These should be identified in interconnection agreements between local service providers.

TABLE OF CONTENTS

INTRODUCTION *

• Purpose of Document *

  Detroit LNP Field Test Description *

  Overview of the Field Test *

OBJECTIVE OF THE FIELD TEST *

PARTICIPANTS *

• REQUIREMENTS FOR PARTICIPATION *

PRE-TEST ACTIVITIES *

• SCHEDULE OF PRE-FIELD TEST ACTIVITIES *

  PRE-TEST ACTIVITIES *

  READINESS TO TEST STATEMENTS *

  NPAC CERTIFICATION *

  INTEROPERABILITY VERIFICATION AND TURN-UP TESTING *

  SOA/LSMS Preparation for Interoperability Testing and Certification *

  SOA/LSMS Interoperability Testing and System Validation with the Test Lab *

  NPAC SMS Turn-up Testing *

  PORTING PROCESS *

  BASIC MESSAGE INTERACTION *

  CLASS *

  911 *

  OPERATOR HANDLED CALLS *

  WIRELESS *

  ISDN (Integrated Services Digital Network) *

  CUSTOM CALLING *

  BILLING *

OTHER TECHNICAL PROBLEMS *

SWITCH BASED FAULT FAILURES *

DATABASE FAILURES *

SUMMATION *

ATTACHMENTS *

1. MCI Test Matrix

2. TCG Test Matrix

3. Ameritech Test Matrix
4. AT&T Test Matrix

INTRODUCTION

Purpose of Document

The purpose of this document is to report the test results of the Detroit LNP Field Test (here after referred to as "Field Test"]. This report will not be updated.

Detroit LNP Field Test Description

This section provides an overview of the Field Test and information on pre-field test logistics.

Overview of the Field Test

The Field Test took place in Detroit, Michigan and included working NXXs that were currently supported by participating companies’ switching systems. These switching systems included DMS®, EWSD and 5ESS®. The Field Test exercised the LRN technology and operational processes which enable customers to be moved between LSP switches while keeping the same phone number. During the Field Test, Inter-exchange Carriers (IXCs) systems tested ported call routing to ensure delivery of ported numbers to the correct local service provider switch.

The Field Test allowed for platform testing with live traffic. This experience enabled participants to identify any database or other network modifications that might be necessary for large scale deployment of LRN. The Field Test provided insights into areas for future systems enhancements.

The Field Test commenced on September 8, 1997 by porting a telephone number from an Ameritech end office switch in the Detroit area to an MCI end office switch, also in the Detroit area. Testing was successfully completed on October 23, 1997 The Detroit, Michigan area is serviced by the Mid West Number Portability Administration Center (NPAC) located at 200 South Wacker Chicago, Illinois. Number Portability Administrative Services are provided by Lockheed Martin.

OBJECTIVE OF THE FIELD TEST

The objective of the Field Test was to further demonstrate the feasibility of LRN as a long term database LNP solution in a functional network situation using participant equipment and personnel and to determine network and operational impacts. The Detroit LNP Field Test built upon the work completed in the Illinois LNP FCC Field Test.

All participants in the Detroit testing had already tested in the Chicago area. Areas impacted by LNP included back-office systems, operations, and networks. Having been tested in Chicago by the same service providers, billing was not tested in Detroit.

Specifically, the Field Test was tasked to include the following:

• Evaluate accurately the ability of various service providers to implement LRN or another technically feasible long term number portability method for providing LNP.
• Encompass issues relating to both network capability and ordering systems, as well as maintenance arrangements.
• Test each provider’s public switched networks’ capability of providing number portability.
• Identify technical problems in advance of widespread deployment of LRN or another technically feasible long term number portability method, thereby ensuring the integrity of the public switched network as a long term number portability solution is deployed nationwide.

PARTICIPANTS

The following companies participated in the Field Test:

Ameritech

Lockheed Martin

MCI

TCG

*ATT

(ATT did not take part in the Detroit Field Test, however they did place calls from Chicago to Detroit ported numbers, their name is added here to reflect that they did perform some testing.)

The following table represents the primary technical contacts during the Field Test.

REQUIREMENTS FOR PARTICIPATION

In order to establish the processes and identify impacts to network equipment, all participants needed to be familiar with:

• The LRN method of providing number portability
• All Field Test documentation
• The Mid-West NPAC’s functions, Methods and Procedures
• Their own LSMSs/Service Order Administration (SOA) operations and Methods and Procedures
• The approved Operational Process Flows

In order to participate in the Field Test, each participant was required to:

• Modify switching and signaling equipment to accommodate the LRN solution.
• Work together in a spirit of cooperation and proactive communication.
• Develop their interface to the NPAC developed by ESI and administered by Lockheed Martin.
• Satisfactorily complete Inter-Operability testing with DSET corporation.
• Satisfactorily complete turn up testing with the Mid-West NPAC.
• Satisfactorily complete end-to-end baseline functionality testing within their own networks.
• Provide an LSMS that conformed to the Functional Requirements Specification (FRS) and the Interoperability Interface Specifications (IIS) for Illinois as well as a Service Order Administration system (SOA).
• Each Field Test participant was responsible for documenting the results from their test scripts on a daily basis and submitting them to the Test Coordination Manager (Dick Dowd) on a weekly basis.
• Each participant was also required to provide input to the Final Report.

Additionally, the Detroit Single Point Of Contact Team asked participants to:

• Prepare their networks as needed to support the Field Test.
• Jointly develop the Field Test Plan, test scenarios, and test scripts through their participant representatives on the Illinois Testing Committee.
• Provide a Single Point of Contact (SPOC) for the duration of the Field Test.
• Provide a task force of support personnel, coordinated by the SPOC during test execution.
• Contribute to documenting the results of their portion of the Field Test.

PRE-TEST ACTIVITIES

SCHEDULE OF PRE-FIELD TEST ACTIVITIES

• Single Point of Contact named by August, 1997.
• NPA/NXXs to be opened for porting submitted to the Local Exchange Routing Guide (LERG) prior to June 9, 1997
• Satisfactorily complete Interoperability and turn up testing by August, 1997
• Service Provider (SP) to SP testing complete by August 28, 1997.

PRE-TEST ACTIVITIES

• Determine Field Test Topography.
• Order all circuits to connect with NPAC.
• Install and test all interconnection circuits.
• Determine the SP to 911 Network and database connectivity.
• Determine NPA/NXXs to be opened.
• Determine Sub System Numbers, Point Codes, Translation Types, phone numbers, addresses, and LRNs.
• Select test cases to be performed.
• Prepare overall test matrix.
• Submit company registration to NPAC.
• Submit extracts to 911 databases.
• Establish SS7 interconnection requirements.
• Provision test phone numbers.
• Apply for a company ID through the National Emergency Number Association (NENA).

READINESS TO TEST STATEMENTS

Readiness to test statements were not required in the Detroit LNP Field Test because each service provider had already completed a statement for the Chicago, Illinois LNP FCC Field Test

NPAC CERTIFICATION

Being that all participating company’s in the Detroit Field Test had previously tested in the Illinois LNP FCC Field Test their connectivity to the NPAC had already been certified. The following in included for informational purposes only.

INTEROPERABILITY VERIFICATION AND TURN-UP TESTING

To prepare for the Field Test, service provider connectivity and software required testing to verify interoperability and to verify functionality up to the application level. The NPAC SMS Interoperability Test Plan and the Turn Up Test Plan were executed in accordance with the NPAC SMS Functional Requirements Specification (FRS) and the Interoperable Interface Specification (IIS) documents. The scope of the test plans were as follows:

• • • • Provided service support documents that identified specific interoperability and turn up testing responsibilities to participating service providers and their respective SOA and LSMS vendor(s).
      • Identified the minimum test set required to verify interoperability and application functionality.
      • Interpreted the results of the tests.

SOA/LSMS Preparation for Interoperability Testing and Certification

Participating service providers were required to internally test their LSMS/SOA systems prior to initiating testing with the NPAC SMS. It was also required that the service provider OSI/RFC1006 compliant stack be CTS-3 certified. After internal testing was completed interoperability testing was initiated with the NPAC SMS. Scripted LSMS/SOA initiated test cases and drivers (defined in the Interoperability Test Plan), were created to be executed by the service providers for interoperability testing. Once interoperability testing was complete as described below actual testing with the NPAC SMS could begin.

SOA/LSMS Interoperability Testing and System Validation with the Test Lab

Interoperability testing between the service provider LSMS/SOAs and the NPAC/SMS test lab ensured that each service provider could meet the technical and operational processing requirements for the transactional exchange of ported service provider information. Test phases included: Connectivity, Managed Objects, Security and Recovery, and Application to Application.

Interoperability test scenarios addressed general areas of LSMS/SOA conformance to the ISO/ITU standards for OSI Conformance Testing Methodology and Framework. LSMS/SOA conformance was validated through:

• • • • Basic Interconnection Tests (S2S and limited Security tests)
      • Capability Tests (MOC)
      • Behavior Tests (Security, MOC, and Recovery)

The four mandatory test sets for interoperability are described below:

The following vendor SOAs and LSMSs passed interoperability testing by meeting exit criteria.

Interoperability Test Reports

After completion of NPAC/SMS interoperability testing, a test report was created by the Test Center. The test results included a matrix describing the test cases successfully completed by each participating vendor. This matrix, is available at www.npac.com and is titled the Interoperability Test Results Matrix. Additional information following the Test Results Matrix, is a second matrix listing the test cases required to fulfill exit criteria for interoperability testing. It is also available at www.npac.com.

NPAC SMS Turn-up Testing

When service providers obtained LSMS and/or SOA interoperability verification, connection to the production NPAC/SMS was made to conduct Turn-up Testing. The Turn-up Test Plan addressed issues specific to interaction of the NPAC SMS and service provider systems within the production environment. The Turn Up Test Plan validated that the SOA and LSMS systems and the NPAC provided the elements necessary for local number portability. It also verified the functionality of the CMIP interfaces, ensuring interactivity with the NPAC SMS, the LSMS, and other service provider SOAs. The scope of this testing allowed service providers to test and repair problems with LSMS or SOA functionality.

Turn up Testing verified the following functionality:

• Network Data - Create, modify, delete and query
• Subscription Data - Create, modify, delete, activate, cancel, conflict resolution, and query
• Audit Subscription Data
• Recovery
• Performance
• Service Provider to Service Provider Integrated Testing
• NPA Splits

Turn Up Testing Report

A summary that names and briefly describes the minimum required Turn Up Test Cases is available on www.npac.com. It is a matrix titled NPAC SMS Exit Criteria. a second matrix titled NPAC SMS Turn Up Test Results, which describes the results of each test case for each service provider participating in the FCC Field Test, is also available at www.npac.com.

DETROIT LNP FIELD TEST EXECUTION

PORTING PROCESS

The participants utilized the inter-service provider LNP operations flows approved by North American Numbering Council (NANC) to guide the SPs through the service order processing. Each SP generated service orders. After service orders were written, the appropriate Local Service Requests (LSR) were generated. The corresponding SP responded with the Firm Order Confirmations (FOC). The ability to interact with each other via the NPAC was validated.

The following processes were confirmed:

• • Code opening
  • Basic porting
  • Conflict resolution
  • Cancel pending port
  • Disconnect

Technical issues encountered:

NONE

Procedural issues encountered:

• LSRs were not always accurate or complete resulting in some ports being put into unnecessary conflicts. (Recommendation – Ensure all personnel follow the LSR process and completely fill out the LSR.)

BASIC MESSAGE INTERACTION

Prior to porting, participants validated that calls could be completed to each of the other service providers. This tested the ability to make calls between non-ported numbers.

Throughout the Test, all participants successfully completed call through testing in the categories listed in the test matrix.

Technical issues encountered:

NONE

Procedural issues encountered:

NONE

CLASS

Once the networks were properly set up, CLASS was successfully tested. Experience gained testing CLASS in the Illinois LNP FCC Field Test helped greatly with setting up the Detroit Network for the testing of CLASS Features.

Technical issues encountered:

None

Procedural issues encountered:

None

911

Each participant successfully completed calls from numbers that were ported into them to 911. Service Providers also issued migrate and unlock records for porting of numbers. These records included the company’s 3 - 5 digit company ID (as required and defined by National Emergency Number Association). The 911 tests that were performed by all service providers during the field test passed successfully. All participants utilized the new function codes of "U & M", instead of disconnects and installs, thereby alleviating the record removal from the 911 database. This adheres to the new N.E.N.A recommended standards. All of the service providers have received a 3-5 digit code, as a Company Id, from N.E.N.A. and that identifier was put on the individual record in the 911 database.

All service providers experienced a little difficulty with the function codes and getting orders completed, the same time as the porting process took place. This is probably the area that most companies will experience their difficulty. It is believed that this difficulty was due to the processes being new to the user rather than that there are problems with the processes.

911 calls were made, transferred, and called back to, by the PSAPs. Verification of the ALI screen data, customer name, address and Company Id was made during the calls. The calls were made from different rate centers, affecting different PSAPs.

The SPOC Team recommends that the NENA standards be adopted nation widel

Technical issues encountered:

Procedural issues encountered:

• All service providers experienced minor difficulties initiating the new U & M process. It is believed that as the service providers gain experience with the new process that this will go much smoother. There doesn’t appear to be any problem with the actual process.
• One service provider experienced problems with internal systems that feed the 911 database, once the problem was resolved tests were completed.

OPERATOR HANDLED CALLS

Operator services platforms were tested in Detroit, by at least one participant.

Technical issues encountered:

NONE

Procedural issues encountered:

NONE

WIRELESS

Calls were successfully completed between ported numbers and cellular numbers. No wireless service providers took part in the Detroit LNP Field Test.

Technical issues encountered:

NONE

Procedural issues encountered:

NONE

ISDN (Integrated Services Digital Network)

ISDN was not tested in Detroit, having already been tested by the participants in Illinois.

Technical issues encountered:

NONE

Procedural issues encountered:

NONE

CUSTOM CALLING

Custom Calling Features were tested in Detroit.

Technical issues encountered:

NONE

Procedural issues encountered:

NONE

BILLING

Billing was not tested in Detroit having already been tested by the participants in Illinois.

Technical issues encountered:

NONE

Procedural issues encountered:

NONE

MAINTENANCE ARRANGEMENTS

There is nothing to report regarding maintenance for the Detroit LNP Field Test.

OTHER TECHNICAL PROBLEMS

NONE

SWITCH BASED FAULT FAILURES

The Test Committee determined that we should not introduce faults into the Public Switched Network during the Field Test.

DATABASE FAILURES

No database failures were noted during test execution. The SPOC Team determined that we would not introduce failures into the live public switched network. These types of failure testing should be performed in a controlled environment.

SUMMATION

In summary, the Single Point of Contact Team concludes that the Field Test adequately tested the long term database LNP, (LRN) solution. Though several procedural issues were encountered, the SPOC team feels that these will be corrected with experience. No technical issues were identified by the team that would prevent the deployment of LRN.

Detroit will be ready to initiate commercial services as soon as the Mid West NPAC goes

Live, currently scheduled for November 3, 1997.

ATTACHMENTS

1. MCI Test Matrix

While AT&T did not take part in the Detroit Field Test by porting in or out any numbers, they did perform the following tests by dialing from Chicago, Illinois to ported numbers in the Detroit Michigan area, for that reason their Test Matrix is added here.

2. AT&T Test Matrix

3. TCG Test Matrix

4. Ameritech Test Matrix

Ameritech has successfully tested LNP/LRN in Michigan. All that remains is to test E911 and then to issue disconnect orders for the ported in TNs.

Below are the tests that Ameritech has sucessfully completed and the dates the

test were performed:

TEST CASE # DATE TESTED

4.5.1.1.1 10/6/97

4.5.1.1.2 10/6/97

4.5.1.1.3 10/6/97

4.5.1.1.4 10/6/97

4.5.1.1.5 10/6/97

4.5.1.1.6 10/6/97

4.5.1.1.7 10/6/97

4.5.1.1.8 10/6/97

4.5.1.1.9 10/6/97

4.5.1.1.10 10/6/97

4.5.1.1.11 10/6/97

4.5.1.1.12 10/6/97

4.5.1.1.13 10/6/97

4.5.1.1.14 10/6/97

4.5.1.1.15 10/7/97

4.5.1.1.16 10/7/97

4.5.1.1.17 10/7/97

4.5.1.1.26 10/7/97

4.5.1.1.27 10/7/97

4.5.2.1.2 10/7/97

4.5.2.1.3 10/7/97

4.5.2.1.7 10/7/97

4.5.2.1.8 10/7/97

4.5.2.1.11 10/7/97

4.5.2.2.1 10/7/97

4.5.2.2.4 10/7/97

4.5.2.2.5 10/7/97

4.5.2.2.6 10/7/97

4.5.2.2.7 10/7/97

4.5.2.2.8 10/7/97

4.5.2.2.9 10/7/97

4.5.2.4.2 10/7/97

4.5.2.4.3 10/7/97

4.5.2.4.6 10/7/97

4.5.2.4.7 10/7/97

4.5.3.1.1 10/8/97

4.5.3.1.2 10/8/97

4.5.3.2.1 10/8/97

4.5.3.2.2 10/8/97

4.5.3.3.1 10/8/97

4.5.3.7.1 10/8/97

4.5.3.7.2 10/8/97

4.5.4.1 10/8/97

4.5.4.2 10/8/97

4.5.3.1.7 10/9/97

4.5.3.2.7 10/9/97

4.5.3.2.13 10/9/97

4.5.3.1.8 10/10/97

4.5.3.1.13 10/10/97

4.5.3.2.8 10/10/97