Transition from Interim to LRN LNP

Intra-Service Provider LNP Operations Flows

-Provisioning-

Draft 2

End-user customers may be served by Interim Number Portability (INP), prior to their previous end-office being made LRN LNP capable. As determined by specific Interconnection Agreements, these INP methods could typically include Remote Call Forward (RCF), Flex-DID, or Route-Index Portability-Hub (RI-PH).

The method of this process flow supports any of the typical INP methods. The key to this process flow relies on the Current Service Provider's end-office switch being a modern switch, capable of multi-ring or other similar methods which allow two telephone numbers (the directory number, and the "shadow" number) to point to the same piece of line equipment. It has the following advantages:

1. It reduces the number of LSR/FOCs exchanged between Service Providers.
2. It removes the need for coordination,
3. It allows calls originating on the INP switch destined to the End-user customer to complete, instead of failing, during the time that the LRN routing is activated. In other words, the End-user customer experiences no loss of service while transitioning from INP to LRN LNP.
4. And it lends itself well to batch transitioning of customers from INP to LRN LNP.

If desired, for instance in the case where a 10 digit unconditional trigger is used in the Donor Switch, the Current Service Provider may instead seek to treat this as an Inter-Service Provider port, so that 10 digit trigger application and removal is performed. If that is the case, they should follow the "Inter-Service Provider Provisioning Process Flow."

1. End Office providing INP is now LRN Capable

The process begins with the Current Service Provider noting the conversion of the INP Provider's end-office switch to LRN LNP capability. The Current Service Provider will know when the end-office is converted based on the information contained in the LERG, or provided from NPAC SMS's LRN Data.

1. Current SP initiates transition from INP to LRN LNP

The Current SP initiates the transition of the customer(s) from INP to LRN LNP, for the INP switch in question.

1. Current SP sends INP Provider a LSR, requesting de-provision of INP

The Current Service Provider sends the INP Provider a LSR requesting the de-provision of INP. Note that this LSR is not the LSR used for LRN porting; it is a LSR requesting the de-provisioning of INP, per applicable Interconnection Agreements.

1. INP Provider provides FOC to Current SP within 24 hours

The INP Provider sends the FOC via electronic gateway or FAX to the Current Service Provider, within 24 hours of receipt of the completed LSR, or as specified in the applicable Interconnection Agreement.

1. Current Service Provider and INP Provider create and process Service Orders

The Current Service Provider and INP Provider create and process the service orders through their internal service order systems.

1. Current Service Provider sends Subscription Version Create message to NPAC, LNP type = LISP

The Current Service Provider uploads Subscription Version data to NPAC SMS via the SOA interface to create the Subscription Version. The Current Service Provider uploads:

1. NPAC Performs Data Validation

NPAC SMS validates the above data to ensure value formats and consistency are correct.

1. Is Data Valid?

If yes, go to step 11; if no, go to step 9.

1. Return Data to Service Provider

If the data is not valid, the NPAC SMS will return notification to the Current Service Provider for correction of the uploaded data.

1. Data corrected & forwarded

The Current Service Provider corrects its data, and uploads it again to NPAC SMS.

1. Current Service Provider coordinates de-provision of INP with INP Provider

The Current Service Provider coordinates the de-provisioning of INP with the INP Provider. The extent of the coordination needed is addressed in the LSR/FOC which schedules the de-provisioning of INP.

1. Current Service Provider activates (their) C.O. translations, if not already done

The Current Service Provider will activate their own Central Office translations. These would have already been done to support the INP-ported customer, i.e., both the true number and shadow number may already be active on the Current Service Provider's switch.

1. Current Service Provider notifies NPAC to Activate routing number

The Current Service Provider sends an activate message via the SOA interface to the NPAC SMS.

1. NPAC SMS downloads (real time) to all Service Providers (includes GTTs as appropriate)

The NPAC SMS broadcasts new Subscription Version data to all Service Providers in the serving area. The broadcast data will include:

• Ported TN
• LRN
• CLASS DPC
• CLASS SSN
• LIDB DPC
• LIDB SSN
• CNAM DPC
• CNAM SSN
• ISVM DPC
• ISVM SSN
• SPID

1. NPAC SMS records date and time in history file

The NPAC SMS will record the current date and time as the Activation Date- and Time-stamp, after all local SMSs have successfully acknowledged receipt of the activation message.

1. NPAC SMS logs failures and non-responses. Sent to NPAC SMS System Administrator for investigation and/or correction. Also notification to Current Service Provider via SOA of which system(s) failed.

The NPAC SMS will resend the activation to a Local SMS that has not acknowledged receipt of the request. The number of NPAC SMS attempts to resend is a tunable parameter for which the current default is 3 attempts. Once this cycle is completed, the NPAC personnel will investigate possible problem areas. In addition, the NPAC will send a notice to the Current Service Provider with a list of Local SMS(s) that failed to acknowledge receipt.

1. All Service Providers update routing data bases (real-time download)

This is a process internal to each participating provider.

1. INP Provider removes translations in Central Office based on LSR/FOC

As specified on the INP De-Provisioning LSR, the INP Provider removes the INP translations at the specified date and time.

De-provisioning the INP translations after the LRN download results in no lost calls destined to the End-user customer. Additionally, the transition can be done as an "un-coordinated" order.

If the Current Service Provider desires, for example, if they can not have both the Dialed and Shadow numbers active on the Current Service Provider's switch at the same time, then they should schedule the INP de-provisioning at the same time the LRN activation message is sent; or treat the transition as a "coordinated" order; or follow the "Inter-Service Provider Provisioning Process Flow" using 10 digit triggers.

19. Current Service Provider makes test calls to verify completion

The Current Service Provider should make a test call to verify that calls to the LRN ported number complete as expected.

20. Do all test calls complete?

If yes, go to step 19; If no, go to step 20.

21. END

The End-user customer is now LRN LNP ported.

22. 2^nd time through this decision?

If yes, go to step 24; if no, go to step 23.

23. Verify all provisioning steps are complete

If the test calls did not complete, the Current Service Provider verifies all provisioning steps are correct and complete.

1. Call technical support

If all provisioning steps are correct and complete, and test calls still do not complete, the Current Service Provider contacts their technical support organization.