------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Notice:

Effective August 1, 2017 the role of Change Management Administrator (CMA) of the Local Number Portability Administration Working Group (LNPAWG) for all US Regions was transferred to Telcordia Technologies, Inc., d/b/a iconectiv.

To contact the iconectiv CMA or to be added/removed from the LNPAWG distribution list please email cma@iconectiv.numberportability.com.

Please note that on or about September 30, 2017 the collection and history of industry documents will be transferred to https://numberportability.com/. Stay tuned for further updates at upcoming LNPAWG meetings and conference calls.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Local Number Portability Best Practices

The members of the Local Number Portability Administration Working Group (LNPA WG) have created "Best Practices" for porting between and within telephony carriers. These Best Practices have not been mandated entirely, and in many cases are considered a gentleman's agreement on porting between carriers.  However, many of the Best Practices have been presented to the North American Number Council (NANC) for approval and, after NANC's approval, forwarded on to the FCC.  Several of these Best Practices are flagged with asterisks to indicate which have been endorsed by the NANC (*) and which have been adopted by the FCC(**).

The Best Practices reflect the consensus of the LNPA WG regarding the preferred processes for porting.  The LNPA WG meetings are open meetings.  Anyone attending the meetings may bring a suggested Best Practice to the LNPA WG for discussion and possible inclusion in the LNPA WG approved Best Practices.  The LNPA WG periodically reviews the Best Practices to determine whether each remains applicable to the current porting environment.  Based on these reviews, a practice may be modified or deleted.  If a Best Practice is deleted, the number of a Best Practice remains on the web site with explanation that it was deleted.

Please Note: Best Practices 0001 - 0044 were developed and agreed to by the Wireless Number Portability Operations (WNPO) team.

The following is an index of the existing LNP Best Practices. Click on the Best Practice name for more detail.

Best Practice

0001  Due Date Time Stamp on SV Create

Submitted By Team: | Date Logged: 10/9/01

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

For intermodal and wireline-wireline ports, the Due Date time stamp on an SV create sent to the NPAC must be set to midnight GMT on a 24-hour clock.  For wireless-to-wireless SV creates, specific times can be set.  For one-day porting, please refer to Best Practice 66.

Back to Top

0002  DELETED -- Type 1 Trunk Conversion

Submitted By Team: | Date Logged: 10/9/01

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

Team consensus was to remove this issue at the January 2011 meeting.

Back to Top

0003  BFR Contact Information

Submitted By Team: | Date Logged: 12/10/01

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

Sending the BFR (Bonafide Request) form to the recipient contact information in the Telcordia LERG Routing Guide guarantees that you have made the request for another Service Provider to support long-term Local Number Portability (LNP) and open ALL codes for porting within specified Metropolitan Statistical Areas (MSAs) and the specified wireline switch CLLI (Common Language Location Identifier) codes.  The intended recipient is responsible for opening all the codes indicated in the BFR for porting.  It is the responsibility of all Service Providers to ensure that the contact information in the Telcordia LERG Routing Guide is correct.

Back to Top

0004  N-1 Carrier Methodology Clarification

Submitted By Team: | Date Logged: 12/10/01 | Date Modified: 9/13/16

Background:

Recommend Change to Requirements: Yes

Related Issue:

Decisions/Recommendations

The N-1 carrier (i.e. company) is responsible for performing the dip, not the N-1 switch.  Please refer to the attached document for the definition of the N-1 carrier under specific call scenarios, including local, toll, e.g., IXC-routed calls, and Extended Area Service (EAS) calls.

Best Practice 4 and the attached “0004 LNPA WG N-1 Interpretation V5.doc” was the result of a request in 2004 by then NANC Chair Robert Atkinson for the LNPA WG to address in part, the various EAS call routing situations and recommend the parties who would perform the LNP dips necessary to insure proper call routing.  Page 11 of the “0004 LNPA WG N-1 Interpretation V5.doc” is where these EAS-related call scenarios are explained.  As shown in the January 19, 2005 NANC meeting Minutes, this LNPA WG document was reviewed with the full NANC.  These meeting Minutes also document that Page 11 would be submitted by Chair Atkinson to the FCC’s WCB for further action.  Chair Atkinson sent the letter to the WCB on 7/25/2005 as seen on the FCC’s website in the NANC 2005 Correspondence archives.

On Page 11 of the “0004 LNPA WG N-1 Interpretation V5.doc” (in the third bullet) the term “donor carrier” is used.  To clarify the meaning of this term, the LNPA WG confirms the donor carrier in this scenario is the A-Block Code Holder designated in the LERG for the NPA-NXX of the called number.  The A-Block holder is the default carrier for routing calls based on the NPA-NXX of the called number.  In the instance where a TN is ported out of a pooled thousands block, the thousands block holder is not the A-Block Code Holder nor the donor carrier in the context of these EAS N-1 responsibilities.  The call is default routed to the actual A-Block Code Holder, who is responsible for performing the LNP dip.

At its September 13, 2016 meeting, the LNPA WG approved the attached v6 of the LNPA WG N-1 Interpretation paper, specifically the section on pages 10-11 addressing Extended Areas Service (EAS) call scenarios.  Although v5 of the paper is still accessible from BP 4 due to the historical references to it in BP 4, the attached v6 paper completely supersedes v5 in its entirety.

Back to Top

0005  DELETED -- FCC 3rd Report and Order (FCC 01-362)

Submitted By Team: | Date Logged:1/7/02

Background:

Documentation Referenced:

Related Issue: Issue 3

Recommend Change to Requirements: Yes

Decisions/Recommendations

 Team consensus was to remove this issue at the January 2011 meeting.

Back to Top

0006  Testing Prior to Turn-Up

Submitted By Team: | Date Logged:1/9/02

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

Service Providers must test all LNP-related hardware, software, and processes prior to turning it up in production.  If Service Providers are unable to complete testing they must not turn up LNP-related hardware, software, and processes that have not been fully tested and determined to be ready for production use.

Back to Top

0007  Wireless Database Query Priority

Submitted By Team: | Date Logged:2/4/02

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

Number portability queries should be performed prior to Home Location Register (HLR) queries for call originations on a wireless Mobile Switching Center (MSC).

Back to Top

0008  DELETED

Team consensus was to remove this issue.

Back to Top

0009  Ensuring Timely Updates to Network Element Subsequent to NPAC Broadcasts

Submitted By Team: | Date Logged:3/4/02

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

The appropriate network elements should be updated with the routing information broadcast from the NPAC SMS within 15 minutes of the receipt of the broadcast.

Back to Top

0010  DELETED -- No NPAC Porting Activities During the SP Maintenance Windows

Submitted By Team: | Date Logged:3/4/02

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

Team consensus was to remove this issue at the September 2012 LNPA WG meeting.

Back to Top

0011  Neustar User Application Process

Submitted By Team: | Date Logged:3/4/02

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

At a minimum, Neustar recommends that all Service Providers start the User application process (all paperwork associated with a Non-Disclosure Agreement, and a valid OCN that can be entered into the NPAC as a new SPID) no later than 30 calendar days prior to the start of any certification testing for this new SPID.  A carrier cannot begin participation in any NPAC certification testing until the User application process is completed.

Back to Top

0012  DELETED -- Wireless Reseller Flows

Submitted By Team: | Date Logged:4/8/02

Background:

Documentation Referenced:

Recommend Change to Requirements: Yes

Documentation Referenced: NANC Inter-Service Provider LNP Operations Flows

Decisions/Recommendations

Team consensus was to remove this issue at the January 2011 meeting.

Back to Top

0013  DELETED -- FCC 3rd Order on Reconsideration and NPRM (FF 02-73)

Submitted By Team: | Date Logged:4/9/02

Background:

Recommend Change to Requirements: Yes

Documentation Referenced:

• FCC 3rd Order on Reconsideration and NPRM (FCC 02-73)

• FCC 3rd Report and Order (FCC 01-362)

Decisions/Recommendations

Team consensus was to remove this issue at the January 2011 meeting.

Back to Top

0014  Paging Codes

Submitted By Team: | Date Logged:4/23/02 | Date Modified: 3/12/09

Background:

Recommend Change to Requirements: Yes

Documentation Referenced: INC Central Office Code Assignment Guidelines (COCAG) Forms Part 2 Job Aid http://www.atis.org/inc/incguides.asp
FCC 96-286, pp156 and FCC 00-104, CC Docket 99-200, pp129

Decisions/Recommendations

End Users of Paging Company numbers are not allowed to port the Paging Company Number, since Paging Companies are not subject to LNP requirements of any kind. (FCC 96-286 and 00-104).

However, the Paging Companies themselves  can port their pager numbers from one Service Provider to another, should they choose to do so and the pager codes are assigned to a switch that is LNP-capable and will process terminating traffic appropriately.

Paging Codes used exclusively for paging services should not be marked as portable in the Telcordia LERGTM Routing Guide. (Refer to the TelcordiaTM Routing Administration (TRA) Central Office Code Assignment Guidelines (COCAG) Forms Part 2 Job Aid for additional information.)

Back to Top

0015  Deleted

Submitted By Team: | Date Logged:5/14/02

Team consensus was to remove this issue.

Back to Top

0016  DELETED -- LRN Assignments

Submitted By Team: | Date Logged:5/14/02

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

Team consensus was to remove this issue at the September 2012 LNPA WG meeting.

Back to Top

0017  LNP Troubleshooting Contacts

Submitted By Team: | Date Logged:5/14/02

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

Service Providers should update their LNP troubleshooting contact information on the NGIIF (Next Generation Interconnection Interoperability Forum) website under http://www.atis.org/ngiif/contactdir.asp.  A password is required to update the document and ATIS should be contacted to obtain one.

Back to Top

0018  DELETED -- LSOG Version

Submitted By Team: | Date Logged:5/14/02

Background:

Decisions/Recommendations

Team consensus was to remove this issue.

Back to Top

0019  DELETED -- Clearinghouse Maintenance Windows

Submitted By Team: | Date Logged:6/10/02

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

Team consensus was to remove this issue at the September 2012 LNPA WG meeting.

Back to Top

0020  DELETED -- NPDI Field on LSR

Submitted By Team: | Date Logged:8/13/02

Background:

Recommend Change to Requirements: Yes

Documentation Referenced: OBF Local Service Request (LSR)

Decisions/Recommendations

Team consensus was to remove this issue at the January 2011 meeting.

Back to Top

0021  DELETED -- Permissive Dialing Periods

Submitted By Team: | Date Logged:11/25/02

Background:

Recommend Change to Requirements: Yes

Decisions/Recommendations

Team consensus was to remove this issue at the January 2011 meeting.

Back to Top

0022  Wireless customers impacted by Telemarketers

Submitted By Team: | Date Logged:11/25/02

Background:

Recommend Change to Requirements: No

Documentation Referenced: Rules and Regulations for Implementing the Telephone Consumer Protection Act of 1991

• CG Docket No. 02-278

• CC Docket No. 92-90 located here: http://transition.fcc.gov/Bureaus/Common_Carrier/Orders/1997/fcc97117.txt

Decisions/Recommendations

With the introduction of wireless service providers involved in pooling and porting, there are impacts on wireless customers from telemarketers who do not reference NPAC.  As required by current law, it remains the responsibility of the Telemarketing Industry to ensure that wireless customers are not adversely impacted (see Rules and Regulations for Implementing the Telephone Consumer Protection Act of 1991, CG Docket No. 02-278 and CC Docket No. 92-90).

When a Wireless SP becomes aware of Telemarketer calls to wireless pooled or ported customers, the SP should contact the Telemarketer to cease this activity immediately and reference the FCC Docket.

Back to Top

0023  DELETED -- Vertical Services Database Updates

Submitted By Team: | Date Logged: 2/25/03

Background:

Recommend Change to Requirements: No

Decisions/Recommendations

Team consensus was to remove this issue at the January 2011 meeting.

Back to Top

0024  DELETED -- WICIS 2.0

Submitted By Team: | Date Logged: 3/10/03

Background:

Documentation Referenced:  OBF Wireless Intercarrier Interface Specifications (WICIS) (http://www.atis.org/obf/wicissummv3.1.0.asp)

Decisions/Recommendations

Team consensus was to remove this issue.

Back to Top

0025  In-Vehicle Services, M2M and Telmatics

Submitted By Team: | Date Logged: 4/07/03

Background:

Recommend Change to Requirements: No

Decisions/Recommendations

Because of the complexity and the possible sensitive nature of the services involved (e.g. vehicular emergency assistance, location tracking systems, medical informatics), porting of numbers attached to in-vehicle modems, machine-to-machine connections and various telematic devices requires certain safeguards to be in place.  In fact, if some of these numbers are ported inadvertently, there could be life-threatening situations involved.  In order to port such numbers, all impacted partners must be fully aware of and completely agree to the transaction to prevent unexpected out of service conditions.

It is the position of the LNPA WG that telephone numbers used to connect in-vehicle modems, machine-to-machine devices, and various telematics equipment to telecommunications networks may be ported as long as all impacted parties are aware of and agree to the porting arrangements made.  This Best Practice does not apply to non-portable numbers used for these purposes, such as 5YY NXX numbers.

Back to Top

0026  DELETED -- 10-Digit Trigger

Submitted By Team: | Date Logged: 7/10/03

Background:

Documentation Referenced: OBF Local Service Request (LSR)

Decisions/Recommendations

Team consensus was to remove this issue at the March 2011 meeting.

Back to Top

0027  DELETED -- Retail Holiday Hours

Submitted By Team: | Date Logged: 7/10/03

Background:

Decisions/Recommendations

Team consensus at the May 2011 LNPA WG meeting was to remove this issue.

Back to Top

0028  DELETED -- Supplemental Type 2 Usage

Submitted By Team: | Date Logged: 10/14/03

Documentation Referenced:

•  OBF Wireless Intercarrier Interface Specifications (WICIS) located here: http://www.atis.org/obf/wicissummv3.1.0.asp

Background: 

The OBF Wireless Workshop has learned that some implementations of the Wireless Intercarrier Communications Interface Specifications, (WICIS), may automatically kick off SOA/NPAC activity prior to the full customer validation process being completed. When a confirmed Port Response is sent for a Supplement Type 2 request, which only changes the Due Date or Time, prior to confirming the original port request or Supplement Type 3 (other), the SOA/NPAC activity may begin pre-maturely. We ask that the following recommendation be added to the WNPO Decision Matrix as an operational guideline to assist in limiting inadvertent ports.

Recommendation Title: Limit the usage of a Supplement Type 2.
 
 A Supplement Type 2 should not be sent unless the NSP has received a confirmed response to the original port request or subsequent Supplement Type 3. If the original request or a Supplement Type 3 has not been confirmed, the only viable Resolution Required Response Type is RT="R" (Resolution Required), and the only valid RCODEs (Response Codes) would be:

• 1M - Requested Due Date less than Published interval
• 1N - Due date and time can not be met
• 6E - Due date can't be met 
• 6F - Due Time can't be met
• 1P - Other (remarks must be DD/T specific)

A Supplement Type 3 should be utilized by the New Service Provider to convey any change in the requested Due Date & Time, when they have not received a Confirmed Response to the original port request or Supplement Type 3.

11-15 Update: This functionality is slated for the next WICIS version. However, there is no date available

Decisions/Recommendations

Team consensus was to remove this issue.

Back to Top

0029  DELETED -- ICP Hours of Operation

Submitted By Team: FORT | Date Logged: 12/8/03

Background:

Decisions/Recommendations

Team consensus at the May 2011 LNPA WG meeting was to remove this issue.

Back to Top

0030  NPA Splits

Submitted By Team: WNPO | Date Logged: 2/2/04 | Date Modified: 11/04/14

Background:

Decisions/Recommendations

It is the recommendation of the OBF Wireless Committee (Issue 2570) that beginning at the start of permissive dialing the New Service Provider would initiate the port request using the new NPA/NXX.  The Old Service Provider must do the translation to the Old NPA/NXX in their OSS if needed.  Note: It is the responsibility of both Service Providers, Old and New, to manage the numbers during PDP ensuring that the TN is not reassigned in their systems during permissive dialing.

NPA Split Management Document:

At the May 2013 meeting, the group agreed on the following:

It is the LNPA WG’s recommendation that in order to limit the impacts to customers when the need for area code relief arises, an area code overlay is implemented instead of an area code split.  The Pros and Cons of an Overlay versus a Split can be found in the attached document.

In the case where a split is ordered, service providers shall support the following:

• If the ICP/LSR is sent prior to Permissive dialing beginning but does not complete until after permissive dialing the new and old providers shall support processing the port request under the old NPA.
• If the ICP/LSR is sent after permissive dialing begins the new and old providers shall support processing the port request under the new NPA.
• If the OSP cannot support receiving the ICP/LSR under the old NPA they shall return the ICP/LSR with the appropriate reject code letting the NSP know to cancel and start again under the new NPA.
• The NPA should remain the same throughout the life of the port request. If for any reason the NPA needs to change then the port request should be cancelled and resubmitted under the appropriate NPA.

NOTE 1:  The NANC approved Best Practice 30 and the the attached “Overlays versus NPA Splits” Pro/Con list reference document (developed by the LNPA WG) in the NANC September 2013 meeting.  The NANC chair forwarded the recommendation for approval to the FCC on October 17, 2013.

NOTE 2:  After a Public Comment cycle completed, the FCC issued DA 14-862 (June 20, 2014), commending the Best Practice 30 efforts to improve the number porting process.  However, the FCC did not mandate the cessation of NPA splits.  Instead, the FCC reaffirmed the States’ ability, per 47 C.F.R. § 52.10(a), to determine the best method of implementing area code relief for their citizens.

Back to Top

0031  NSP Sending Create Message to NPAC Prior to Receiving Confirmation from OSP

Submitted By Team: WNPO | Date Logged: 2/2/04

Background:

Documentation Referenced:

• NANC Inter-Service Provider LNP Operations Flows

  0031 Nov03_NANC_Ops_Flow_Narratives_v2.0a-1

Decisions/Recommendations

This Best Practice is intended to reinforce within the industry the requirement that a NSP must receive a positive Firm Order Confirmation (FOC) response from the OSP before the NSP sends their Create message to the NPAC.  All Service Providers must ensure that all personnel are properly trained on the correct, agreed upon industry process.  Please refer to Figure 6 Step 5 in the attached NANC LNP Provisioning Flows, adopted by the FCC as part of FCC Orders 09-41 and 10-85, for this specific step in the industry’s porting process.

Back to Top

0032  Standard industry process for removal of a “preferred carrier freeze,” e.g., port protection, to facilitate porting a telephone number

Submitted By Team: WNPO | Date Logged: 2/3/04

Background:

Decisions/Recommendations

The industry needs to recognize that any carrier who offers a preferred carrier freeze on an account, regardless of what a carrier names that freeze, is subject to the rules regarding removal of the freeze as defined by the FCC (47 CFR Ch. I § 64.1190).

Removal of the preferred carrier freeze should not unnecessarily delay the porting process.

By FCC definition, a “preferred carrier freeze” (or freeze) prevents a change in a subscriber’s preferred carrier selection unless the subscriber gives the carrier from whom the freeze was requested his or her express consent.”  A preferred carrier freeze can be offered in many forms that include, a passcode, pin, local freeze, port protection, etc.; however all such freezes fall under this FCC definition.

The FCC has previously determined requirements for removing a preferred carrier freeze, therefore, it is the intent of the LNPA WG to reinforce the requirements for all service providers with this Best Practice.

It is the position of the LNPA WG that all service providers follow, at a minimum, the processes ordered by the FCC to remove a preferred carrier freeze when a subscriber elects to change its service provider and that change requires porting the customer’s telephone number(s).  The customer (not the NLSP or OLSP) has the option of which process to use to remove the preferred carrier freeze.  The OLSP must, at minimum, be prepared to remove the freeze using the subscriber’s choice of one of the FCC ordered processes.  This does not preclude a service provider from offering additional options for freeze removal as long as the choice of options remains with the customer.

Back to Top

0033 DELETED -- Best Practices

Submitted By Team: WNPO | Date Logged: 2/2/04

Background:

Decisions/Recommendations

Team consensus at the March 2012 LNPA WG meeting was to remove this issue.

Back to Top

0034 SPID Migrations

Submitted By Team: LNPA-WG | Date Logged: 9/8/04

Background:

Documentation Referenced: INC CO Code Reallocation Process: http://www.nationalpooling.com/documents/poolingdocuments/conxx.pdf (broken link)

See the following document for current checklist and process: 

Decisions/Recommendations

A SPID migration should be scheduled on or as soon after  the published Telcordia LERG™ Routing Guide effective date as possible.  An exception to this practice is that a SPID migration is allowed to occur before  the Telcordia LERG™ Routing Guide effective date provided the effective date is no later than the following Wednesday of the SPID migration date.

Additionally, Service Providers are urged to follow the processes listed below for required SPID changes:

INDUSTRY SPID CORRECTION SELECTION PROCESS:

If Ported or Pooled Numbers DO NOT Exist In The Code(s) Affected By The Move:

If no ported or pooled numbers are in the code, the new code holder should contact the current code owner as shown in the NPAC to have the code (and any associated LRNs) deleted in the NPAC.  The new code holder will then add the code in the NPAC under their SPID.

If Ported or Pooled Numbers DO Exist In The Code(s) Affected By The Move:

1. Coordinated Industry Effort:  The new code holder should identify the number of ported and/or pooled TNs within the NXX(s) in question and the number of involved Service Providers to determine if this option is feasible.  Based on the number of involved Service Providers, the new code holder should coordinate a conference call to determine if the delete/recreate process is acceptable among all affected Service Providers.  If this process is deemed acceptable, the affected Service Providers shall coordinate the deletion and recreation of all ported and/or pooled TN records in the code(s).  Note that the delete/recreate process is service affecting for those ported and/or pooled subscribers.  Type of customer should also be considered when determining if this option is feasible.  It is recommended that this process be considered when there are five (5) or fewer Service Providers involved and less than one hundred and fifty (150) working TNs and no pooled blocks.
2. NANC 323 SPID Migration:  If Option 1 above cannot be used to change NPA-NXX code ownership in the NPAC, the industry preferred process is to perform a NANC 323 SPID migration.
3. CO Code Reallocation Process:  The following process should be considered only as a last resort when Options 1 and 2 above cannot be used to change NPA-NXX code ownership in NPAC!   Service Providers may utilize the CO Code Reallocation Process (pooling the blocks within the code at NPAC).

When ported numbers exist, Service Providers are to determine which of the above 3 options best fit their needs based on time constraints, number of carriers involved, number of SVs involved, type of customer(s), etc.

Back to Top

0035  DELETED -- Abandoned Ports

Submitted By Team: LNPA-WG | Date Logged: 2/11/05

Background:

Decisions/Recommendations

Team consensus was to remove this issue at the November 2012 meeting.

Back to Top

0036  Porting Obligations

Submitted By Team: LNPA-WG | Date Logged: 4/7/05

Background:

Documentation Referenced: 

• NANC Inter-Service Provider LNP Operations Flows

• Porting Order_FCC Porting Order (FCC-07-188AI)

Decisions/Recommendations

VoIP Service Providers along with Wireless and Wireline Service Providers, have the obligation to port a telephone number to any other Service Provider when the consumer requests, and the port is within FCC mandates.  Porting of telephone numbers used by VoIP Service Providers should follow the industry porting guidelines and the NANC Inter-Service Provider LNP Operations flows.

Click here for the most current flows: 

Back to Top

0037  Use of Evidence of Authorization

Submitted By Team: LNPA-WG | Date Logged: 5/27/05 | Date Revised: 11/2/05, 6/14/11

Background:

Documentation Referenced:

• CFR 64.1150

• FCC Order 99-223

Decisions/Recommendations

Prior to placing orders on behalf of the end user, the New Local Service Provider is responsible for obtaining and having in its possession evidence of authorization. (CFR Title 47, Section 64.1120 (a) (1)

Evidence of authorization shall consist of verification of the end user’s selection and authorization adequate to document the end user’s selection of the New Local Service Provider. (CFR Title 47, Section 64.1130)

The evidence of authorization needs to be obtained and maintained by the New Local Service provider as required by applicable federal and state regulation, as amended from time to time.

"It is the LNPA WG’s position that Firm Order Confirmation (FOC) of a port request shall not be predicated on the Old Local Service Provider obtaining a physical copy of the evidence of authorization from the New Local Service Provider.  In the event of an end user allegation of an unauthorized change, the New Local Service Provider shall, upon request and in accordance with all applicable laws and rules, provide the evidence of authorization to the Old Local Service Provider."

At its May 2005 meeting, the North American Numbering Council (NANC) endorsed the LNPA-WG’s position as stated above.

Subsequent to NANC’s endorsement of the statement above, a related issue regarding requests for Customer Service Records (CSRs) was brought to the LNPA WG.  The LNPA WG revised and endorsed its stated position as follows:

"It is the LNPA WG’s position that Firm Order Confirmation (FOC) of a port request, or return of requested customer information, e.g., Customer Service Record (CSR), shall not be predicated on the Old Local Service Provider obtaining a physical copy of the evidence of authorization from the New Local Service Provider.  In the event of an end user allegation of an unauthorized change, the New Local Service Provider shall, upon request and in accordance with all applicable laws and rules, provide the evidence of authorization to the Old Local Service Provider."

At the November 30, 2005 NANC meeting, the LNPA WG requested and received NANC’s endorsement of the revised position statement.

NOTE:  Evidence of authorization may consist of a Letter of Authorization (LOA) to review the end user’s account and port his number, which may include a written contract with the end user or electronic signature, Proof of Authorization (POA), 3^rd  party verification, a voice recording verifying the end user’s request to switch local carriers, oral authorization with a unique identifier given by the end user, etc.

Back to Top

0038  Use of End Users Social Security Number and Tax ID on Local Service Requests/Wireless Port Requests

Submitted By Team: LNPA-WG | Date Logged: 5/27/05

Background:

Documentation Referenced:

• OBF Local Service Request (LSR)/Wireless Port Request (WPR)

Decisions/Recommendations

It has been brought to the LNPA WG’s attention that some Service Providers, when acting as the Old Local Service Provider in a port, are requiring the New Local Service Provider involved in the port to provide the Social Security Number (SSN) or Tax Identification Number of the consumer wishing to port their number for identification purposes.

Due to concerns surrounding the use of one’s Social Security Number or Tax Identification Number, which in many cases can be one’s Social Security Number, in the commission of crimes such as identity theft, it is understandable that many consumers are hesitant or refuse to provide that information for identification purposes.

Guidelines for the Wireless Port Request (WPR) state that either of the forms of consumer identification, Social Security Number/Tax Identification Number or Account Number, is mandatory only if the other is not provided on the LSR/WPR.

"It is the position of the LNPA WG that the consumer’s Social Security Number/Tax Identification Number shall not be required on an LSR/WPR to port that consumer’s telephone number if the consumer’s Account Number associated with the Old Local Service Provider is provided on the LSR/WPR for identification."

At its May 2005 meeting, the North American Numbering Council (NANC) endorsed the LNPA-WG’s position as stated above, and agreed to send a letter to the FCC with its endorsement of the LNPA-WG position.

Back to Top

0039 Identification of multiple or generic, reject errors on wireline Local Service Requests (LSRs) and Wireless Port Requests (WPRs)

Submitted By Team: LNPA-WG | Date Logged: 10/3/05 | Date Modified: 11/04/14

Background:

Documentation Referenced:OBF Local Service Request (LSR)/Wireless Port Request (WPR)

Decisions/Recommendations

When a Service Provider receives a port request, they should read as much of the port request as possible to identify and provide as much information on all errors as is possible to report on the response.

Service Providers should avoid a process of only reporting one error on each response to a port request resulting in a prolonged process of submitting multiple, iterative port requests for a single port, each time restarting the response timers.

When a losing Provider issues generic Reject / Response Codes such as 1P=OTHER or 6C=CUSTOMER INFORMATION DOES NOT MATCH, REMARKS relating to which data element(s) caused the reject should be included.

Back to Top

0040  Compliance to LRN Assignment Practices

Submitted By Team: LNPA-WG | Date Logged: 11/2/05

Background:

Documentation Referenced:

• INC LRN Assignment Practices

Decisions/Recommendations

It has been brought to the attention of the LNPA WG that Service Providers are finding instances where an LRN has been entered on a Ported or Pooled telephone number in the NPAC, but the LRN on that record is not shown in the LERG.  This situation is not causing call completion issues, but may cause additional time and work in Trouble resolution and identifying Carrier ownership of the LRN.

The Industry Numbering Committee (INC) has established the "LRN Assignment Practices" to advise Service Providers on how to establish LRNs and notify the industry of their LRNs. The way the Service Providers notify the industry is detailed in the INC Assignment Practices, and it states, "The LRN will be published in the LERG."

The LNPA WG agrees with the INC guidelines and recommends all Service Providers, to the extent possible based on current Business Integrated Routing and Rating Database Systems (BIRRDS) edits, follow these practices and ensure all their LRNs are published in the LERG.

The INC "LRN Assignment Practices" are located on the following website: http://www.atis.org/inc/wkdocs1112.asp

Two examples where LRNs missing in the LERG may cause problems:

1. When the LRN information in the LERG is used to identify the carrier to which to send Access Billing records, without the LRN being populated in the LERG, the records fall out of automated system processing and require manual handling to determine the carrier.
2. Even though the NPA-NXX is shown in the LERG and open in the network so the call should complete, if a trouble is experienced and a Trouble Ticket is opened, not having the LERG entry correct may lead to increased confusion and more investigation time during the resolution process to determine who the LRN belongs to.

Back to Top

0041  Compliance to JIP Standards and Guidelines

Submitted By Team: LNPA-WG | Date Logged: 12/22/05

Background:

Documentation Referenced: 

• ATIS Technical Requirement on Number Portability Switching Systems (T1.TRQ.2-2001)

• ATIS Network Interconnection Interoperability Forum (NIIF) Reference Document, Part III, Installation and Maintenance Responsibilities for SS7 Links and Trunks.

Decisions/Recommendations

The ISUP Jurisdiction Information Parameter (JIP) is a 6-digit parameter in the format of NPA-NXX that is signaled in the Initial Address Message (IAM) by the originating switch.  The JIP is used by carriers downstream in the call path to identify the originating switch for billing settlement purposes.  When carriers signal an incorrect JIP to another carrier, e.g., signaling an NPA-NXX in the JIP that is LERG-assigned to another carrier, this will result in improper identification of the originating switch.

The LNPA WG supports and reiterates the following signaling requirements and guidelines for JIP as documented in ATIS’ (www.atis.org) industry standard for Local Number Portability – Technical Requirement on Number Portability Switching Systems  (T1.TRQ.2-2001) (Number Portability Operator Services Switching Systems (Revision of T1.TRQ.1-1999))  and in ATIS’ Next Generation Interconnection Interoperability Forum’s (NGIIF) (NGIIF Reference Document Part III - Installation and Maintenance Responsibilities for SS7 Links and Trunks - Version 12.0 ) Reference Document, Part III, Installation and Maintenance Responsibilities for SS7 Links and Trunks :

From ATIS' Technical Requirement on Number Portability Switching Systems:

Page 6, Assumption 19:

"An NPA-NXX used as a JIP is a LERG-assigned code on the switch."

And, where technically feasible:

Page 50, cites from REQ-03300:

"The ISUP JIP parameter shall be included in the IAM for all line and private trunk call originations."

"The JIP identifies the switch from which the call originates, and can be recorded to identify that switch."

From ATIS NIIF Reference Document, Part III, Installation and Maintenance Responsibilities for SS7 Links and Trunks:

Rules for Populating JIP

1. JIP should be populated in the IAMs of all wireline and wireless originating calls where technically feasible.
2. JIP should be populated with an NPA-NXX that is assigned in the LERG to the originating switch or MSC.
3. The NIIF does not recommend proposing that the JIP parameter be mandatory since calls missing any mandatory parameter will be aborted. However, the NIIF strongly recommends that the JIP be populated on all calls where technologically possible.
4. Where technically feasible if the originating switch or MSC serves multiple states/LATAs, then the switch should support multiple JIPs such that the JIP used for a given call can be populated with an NPA-NXX that is specific to both the switch as well as the state and LATA of the caller.
5. If the JIP cannot be populated at the state and LATA level, the JIP should be populated with an NPA-NXX specific to the originating switch or MSC where it is technically feasible.
6. Where the originating switch cannot signal JIP it is desirable that the subsequent switch in the call path populate the JIP using a data fill default associated with the incoming route. The value of the data fill item is an NPA-NXX associated with the originating switch or MSC and reflects its location.
7. When call forwarding occurs, the forwarded from DN (Directory Number) field will be populated, the JIP will be changed to a JIP associated with the forwarded from DN and the new called DN will be inserted in the IAM.
8. As per T1.TRQ2, the JIP should be reset when a new billable call leg is created.

Back to Top

0042  Reclamation of ported numbers when no record that FOC was sent 

Submitted By Team: LNPA-WG | Date Logged: 8/31/06 | Date Modified: 12/15/08

Background: Carriers taking back numbers that have been ported out because their systems do not reflect a valid FOC was sent and also addresses inadvertent ports

Documentation Referenced:

• Refer to attached PIM 53

Decisions/Recommendations

There have been instances of carriers taking back numbers that have been ported out several months or even years because their systems do not reflect a valid FOC was sent. In many cases they have not removed the number from their number inventory and they have re-assigned the TN to another customer.

This PIM addresses instances where it was the intent of the end user to port to the New SP.

• Providers should not arbitrarily port back numbers without attempting to contact and work with the New SP to resolve any disputes/issues related to the port.
• For an activated port that is disputed by the Old SP or not recognized in the systems of the Old SP, if it is determined that it was in fact the intent of the end user to port his/her number to the New SP, both providers should work together in resolving any systems true-up issues, e.g. reissuance of any necessary LSRs, when possible, without impacting the end user's service.
• In the case of a double assignment, between the two end users involved, the end user with the longer continuous service with that number shall retain the number, unless otherwise agreed to by the providers involved. In instances where a pooled unavailable TN is assigned to more than one customer served by different SPs (i.e., Block Holder and LERG Assignee) due to an error made by the LERG Assignee in the population of unavailable TNs in the LNP database at the time of donation, the customer of the original SP (i.e., the customer to whom the TN was originally assigned) shall retain assignment of the TN and the Block Holder shall assign its customer a new TN. However, in instances where a pooled unavailable TN is assigned to more than one customer served by different SPs (i.e., Block Holder and LERG Assignee) due to the LERG Assignee's failure to protect the block from further TN assignment after block donation, the customer of the Block Holder shall retain assignment of the TN, and the LERG Assignee that assigned the TN to its customer in error after block donation shall assign its customer a new TN.
• In any case of an inadvertent port, defined here as a port where it was not the intention of the end user to port his/her number to the New SP, both providers will work together to restore the end user's service with the Old SP as quickly as possible, regardless of the time interval between activation of the inadvertent port and discovery of the inadvertent port.

Back to Top

0043  Reseller SPIDs for use in Alternative SPID field introduced in NANC 399

Submitted By Team: LNPA-WG | Date Logged: 11/25/06

Background:

Documentation Referenced:

• NANC-399-Ver_0_3

Decisions/Recommendations

Reseller SPIDs, for use in the alternative SPID data element of an SV, are created in NPAC’s network data only upon an NPAC User’s request.  Consistent with the historical use of an entity’s OCN as the entity’s NPAC SPID, the industry strongly encourages each reseller to obtain an OCN from NECA for use as an NPAC SPID.  This in turn allows the identity of a reseller associated with a ported number to be displayed as that number’s “alternative SPID.”  Notwithstanding this strong industry preference, an NPAC User can request that the NPAC assign a surrogate SPID to a reseller in NPAC’s network data; that surrogate SPID then could be used as the alternative SPID to identify the reseller associated with a ported number.  (Surrogate NPAC SPIDs are values that NECA does not assign as OCNs.  Currently these values are made up of the alphanumeric values X000 through X999.)

Back to Top

0044  DELETED -- Pooled Block record discrepancies between PAS and NPAC

Submitted By Team: LNPA-WG | Date Logged: 12/19/06

Background: Why carriers had discrepancies between PAS and NPAC for pooled blocks.

Documentation Referenced:

• CO41 Final Summary

Decisions/Recommendations

Team consensus was to remove this issue at the March 2011 meeting.

Back to Top

0045  Porting prevented when NPA-NXX not open in NPAC

Submitted By Team: LNPA-WG | Date Logged: 05/07/07

Background: When Subscriber is unable to port their telephone numbers because the NXX code is not opened for portability in the NPAC SMS

Documentation Referenced:

• PIM 58 v3

Decisions/Recommendations

There have been instances where the LERG assignee of an NXX code has not opened a code to portability in NPAC, and either cannot be contacted to do so, or refuses to do so.

Individual circumstances may vary depending on the situation.  In some cases, the NXX may have been opened for portability in the LERG but not in the NPAC SMS.  In other cases, the NXX may not have been opened for portability in the LERG or the NPAC SMS.  It may be that if the NSP or the NPAC Administrator contacts the OSP, the situation will be resolved.  But in those situations where the OSP can't be contacted or refuses to cooperate, the following procedure should be followed:

1. The NSP should document attempts to contact the OSP to request that the NXX be opened in the NPAC SMS.

2. If the NSP attempts to make contact are unsuccessful, the NSP should contact the NPAC Administrator.  The NPAC Administrator should attempt to contact the OSP to request that the code be opened in the NPAC SMS. Attempts should be documented.

3. If neither the NSP nor the NPAC Administrator can make contact with the OSP or if the OSP refuses to cooperate, the NSP should contact the appropriate regulatory authorities for assistance.  The NSP should provide details to the regulatory authority including the Service Provider Identification (SPID) of the OSP who should have opened the code.

4. The regulatory authority may convince the OSP to open the code, or may authorize the NPAC Administrator to open the code to portability in the NPAC SMS.  Any such authorization directed to the NPAC Administrator shall include the NSP-provided SPID of the code holder under which the code shall be opened in the NPAC.  Upon receipt of such regulatory authorization, the NPAC Administrator shall proceed with opening the code in the NPAC SMS.

5. The OSP should have the LERG updated to show the code as portable if it does not already do so.

Back to Top

0046  Intermodal Port delayed due to CSR too large

Submitted By Team: LNPA-WG | Date Logged: 05/07/07

Background:

Documentation Referenced:

• PIM 50

Decisions/Recommendations

There have been instances where wireline to wireless ports fail the automated process because they are from large accounts where the Customer Service Record (CSR) is too large to return on a CSR query.

At the November 2006 NANC meeting, NANC recommended that carriers should be following the OBF guidelines.  The OBF LSOG guidelines have options for providing a CSR for a TN with or without directory, or the entire account with or without directory.  If wireline carriers sent only the information requested in the customer inquiry per the LSOG CSI guidelines, this error would be greatly reduced if not eliminated.

Back to Top

0047  DELETED -- LNPA-WG Position on 24 Hour Firm Order Confirmation

Submitted By Team: LNPA-WG | Date Logged: 05/07/07

Background:

Documentation Referenced:

• LNPA WGPosition on 24 hours FOC v3

• 3rd report wireline wireless integration

• FCC-03-284A1

Decisions/Recommendations

Team consensus was to remove this issue at the November 2012 meeting.

Back to Top

0048  Porting of Wireline Reseller Numbers

Submitted By Team: LNPA-WG | Date Logged: 06-08-07

Background:

Documentation Referenced: 

• PIM 32v4

Decisions/Recommendations

PIM 32 seeks to address issues related to the process of obtaining a Customer Service Record (CSR) for wireline reseller customers.  The CSR contains information necessary to complete a Local Service Request (LSR) for porting a wireline number. In some cases, carriers are not able to obtain an end user's specific CSR information from some wireline network Service Providers when attempting to port telephone numbers (TNs) associated with reseller accounts.  For example, some Service Providers refuse to send the CSR information to the New Local Service Provider (NLSP) because they have been instructed by their resellers not to share the end user's specific information which the resellers consider to be proprietary.

This is a critical problem.  For those reseller errors where there is a workaround, many of the port requests are significantly delayed before completion.  In some cases there are no workaround solutions and end users who want to port their number cannot.  Those customers either give up on porting their number, or cannot keep their number and must change to a new number.  It is not always possible to work with the resellers to obtain the information needed to populate the LSR.  It is often difficult to find someone with the reseller that can support a port and provide the needed information.

The failure to port wireline reseller TNs can be resolved.  Direction by resellers to Old Network Service Providers (ONSPs) to provide the specific customer information where possible would greatly reduce the unsuccessful ports.  Resellers should not be allowed to withhold end user specific customer information necessary for the porting process.

At the April 17, 2007 NANC meeting, the LNPA WG submitted this final Position Paper in order to bring the LNPA WG's consensus position to the attention of the NANC and the FCC.

Back to Top

0049  Unlocking of 911 record on ports to VoIP providers

Submitted By Team: LNPA-WG | Date Logged: 06-08-07

Background:

Documentation Referenced: 

• PIM 59

Decisions/Recommendations

Questions have been raised and Issues have been identified by a number of VoIP providers related to the process of unlocking the 911 database on ports to VoIP providers.

For future inquiries related to 911 issues for VoIP porting, it is recommended that carriers review the materials published and approved by the NENA (www.NENA.org).

Back to Top

0050  Porting in conjunction with Foreign Exchange (FX) Service

Submitted By Team: LNPA-WG | Date Logged: 07-06-07

Background:

Documentation Referenced: 

• PIM 60

Decisions/Recommendations

Regarding the attached PIM 60 and the porting scenario described therein, the LNPA WG reached consensus at their May 2007 meeting that this is a technically feasible porting scenario provided that each of the following conditions are met in providing service to the customer by the New Service Provider.  The following conditions are intended as technical guidelines for porting in conjunction with wireline foreign exchange (FX) service and are not intended to address location (geographic) portability, virtual NXX, transport obligations, or inter-carrier compensation, nor are they intended to be inconsistent with any applicable federal and/or state regulatory requirements.

• The customer would like to receive calls to their number(s) at a location of theirs that is physically outside of the Rate Center associated with their number(s).
• The customer understands that these numbers must continue to be rated in accordance with the Rate Center currently associated with their number(s) and does not want them to take on the rating characteristics of the Rate Center of their new location.
• The New Service Provider offers service coverage or a tariffed or publicly published local exchange service, consistent with applicable federal and state regulatory requirements for providing local/foreign exchange (FX) service, to customers located in the same rate center to which the ported number will be rated.
• The New Service Provider switch that already serves the Rate Center of the customer's number(s) has an existing POI, consistent with applicable federal and state regulatory requirements for service provider interconnection obligations, over which calls to these numbers are routed.  If this customer's number(s) are ported into the New Service Provider switch, they will be routed and transported in a manner consistent with these applicable legal requirements.  The New Service Provider would then be responsible for arranging for the transport and delivery of traffic from that existing POI to the customer's premise that is located outside of the Rate Center associated with the customer's number(s).
• The New Service Provider offers a tariffed and/or publicly published foreign exchange (FX) service in accordance with regulatory requirements that would cover this situation.  Calls to and from customers located in the Rate Center associated with these ported numbers and the customer served by the New Service Provider will be routed exactly the same whether the New Service Provider assigns the customer a phone number from its 1K block of numbers in that Rate Center or whether the New Service Provider ports the numbers.  This customer will be served out of the New Service Provider's tariffed and/or publicly published foreign exchange (FX) service offering in accordance with regulatory requirements.
• The LSR submitted by the New Service Provider reflects the customer's original service location as recorded by the Old Service Provider.

Back to Top

0051  Proper and Timely Updates to LNP Routing Databases

Submitted By Team: LNPA-WG | Date Logged: 07-06-07

Background:

Documentation Referenced:

• PIM 56v2

Decisions/Recommendations

The following high-level process is recommended as a guide to assist in determining the cause of post-port call routing issues.

Process

1. Customer ports number.
2. Ported customer reports problem receiving some phone calls or another customer reports problem with making calls to the ported number.
3. New Network Service Provider (NNSP) checks to ensure that all provider LSMSs' active subscription version (SV) data is correct by launching an audit request.
4. NSP reports the problem to the Telco that is routing calls with incorrect LRN (SCP/STP is discrepant with NPAC).
5. These issues are reported to the Telco's Network Operations Center (NOC).
6. All involved Telco's work together to identify and correct the problem.
7. Discrepant Telco will notify to the reporting Telco when the problem has been found and corrected.
8. NSP may notify the customer that the problem has been corrected.

For an additional guide to troubleshooting in a multiple service provider environment, the following link will access the ATIS Network Interconnection Interoperability Forum's (NIIF's) Guidelines for Reporting Local Number Portability Troubles in a Multiple Service Provider Environment: http://www.atis.org/niif/Docs/atis0300082.pdf

Back to Top

0052  Resellers Discontinuing Business and/or Declaring Bankruptcy

Submitted By Team: LNPA-WG | Date Logged: 11-05-07

Background:

Documentation Referenced: 

• PIM 57v3

Decisions/Recommendations

The attached document reflects the LNPA WG's consensus for a strategy to address porting issues resulting from Resellers claiming bankruptcy and/or going out of business.

Back to Top

0053  Duration of Porting Outages Due to Planned SP Maintenance

Submitted By Team: LNPA-WG | Date Logged: 11-05-07

Background:

Documentation Referenced: 

• PIM 62v2

Decisions/Recommendations

Every attempt should be made to perform planned maintenance during the regularly scheduled Sunday SP maintenance windows.

An Industry Best Practice has been agreed upon to limit the length of time for planned service provider downtime to a maximum of 60 consecutive hours as it relates to Local Number Portability outages.  Additionally, Trading Partners should provide 30 days notice of planned porting outages.  If 30 days is not possible, a minimum of 14 days notice should be provided.

It is recognized that there may be emergency situations that could require outages within the proposed minimum 14 day planned outage notification window.  The Suggested Resolution of PIM 62 is not meant to prevent any required outages under these extreme emergency conditions.

Back to Top

0054  Porting prevented because current service in effect for less than 30 days

Submitted By Team: LNPA-WG | Date Logged: 02-05-08

Background: Some carriers are requiring that the customer have service for 30 days before they will approve a port out request

Documentation Referenced: 

• PIM 63v2

Decisions/Recommendations

In paragraph 18 of the attached FCC Order 03-284, the FCC concluded that ""¦ wireless carriers may not impose "business rules" on their customers that purport to restrict carriers' obligations to port numbers upon receipt of a valid request to do so."  Additionally, the paragraph states, "We confirmed also that, in cases where wireless carriers are unable to reach agreement regarding the terms and conditions of porting, all such carriers must port numbers upon receipt of a valid request from another carrier, with no conditions."

For any valid port request submitted to a carrier, wireline or wireless, it is the position of the LNPA WG that the length of time a customer has service with a carrier should not dictate if they can port out from that carrier.

Back to Top

0055  DELETED -- FCC Order 07-188 impact on LNP provisioning flows; WG proposal for more required LSR fields

Submitted By Team: LNPA-WG | Date Logged: 03-11-08

Background: Revisions to NANC LNP Provisioning Flows to address FCC Order 07-188, LNPA WG recommendation on LSR data fields in addition to the four LNP validation fields addressed in FCC Order 07-188

Documentation Referenced: 

• NANC Ops Flow Narratives V3.0

• Porting Order FCC Porting Order (FCC-07-188AI)

Decisions/Recommendations

Deleted as a result of agreement at July 2011 LNPA WG meeting.

Back to Top

0056  Delayed update of SMS message address after porting

Submitted By Team: LNPA-WG | Date Logged: 12-22-08

Background: Some newly ported wireless customers are unable to receive text messages from customers of the wireless carrier they left due to the data in the Old Service Provider's system(s) not being fully deactivated or cleaned-up.

Documentation Referenced: 

• PIM 67v2

Decisions/Recommendations

Old Service Providers are to ensure that ancillary service databases associated with telephone numbers that are porting out are cleared for the telephone number within 24 hours of the switch/HLR disconnect.

Back to Top

0057  Impact of breaking pooled blocks into individual SVs

Submitted By Team: LNPA-WG | Date Logged: 02-27-09

Background: Several service providers in the industry have encountered indications of imminent LSMS capacity exhaust due to full (over 90%) Pooled Blocks being broken down into individual port records, or due to the creation of individual subscription versions (aka ports of an individual telephone number).

Recommend Change to Requirements: NANC 436 was implemented in order to ensure that a pooled 1K block would contain ALL information that could be carried at a subscription version (telephone number) level. No other requirement changes have been recommended at this time

Decisions/Recommendations

Several Service Providers in the industry have encountered indications of imminent LSMS capacity exhaust due to full (over 90%) Pooled Blocks being broken down into individual port records, or due to the creation of individual subscription versions (aka ports of an individual telephone number).

With the introduction of number pooling in 2003, an entire 1k block can be provisioned to an individual carrier.  All appropriate routing information can be stored in carrier systems at the NPA-NXX-X level, overriding the code holder's routing details for the block.  Porting an individual TN still works within this paradigm to allow for routing at the TN level if it would be needed to differentiate from the block level.  Full pooled 1K blocks have been broken into individual port Subscription Versions (SVs) for various Service Providers' projects.  This has led to a large growth in the size of LSMS instances across the industry in a short period of time (weeks/months vs. years) as it receives these individual SV records.  This resulted in capacity and performance concerns for many LSMS service providers based on these actions.  Based on these concerns, the LNPA-WG deems actions of this type in large volumes can potentially result in adverse impacts to the industry, e.g., accelerated database capacity exhaust, and affect the service of porting customers.

In recognition of the NPAC as a shared industry resource, it is the position of the LNPA-WG that service providers, or others working on their behalf, should limit to the extent possible breaking pooled thousands blocks apart and creating individual Subscription Versions (SVs) in order to facilitate projects or for other purposes.

The LNPA-WG further recognizes that exceptions to this Best Practice may exist, but should not be common practice, that may result in the creation of individual SVs from within a pooled 1K block.  An example of a possible exception that has been identified is outside plant considerations during customer re-homes.

Back to Top

0058  Handling of Disputed Ports

Submitted By Team: LNPA-WG | Date Logged: 05/06/09

Background:

Decisions/Recommendations

Agreement was reached in the LNPA WG that "Disputed Ports" were not addressed within PIM 53 or the corresponding Best Practice 42.  As such, they should not be expected to fall under the Inadvertent Port process.

A disputed port is a port that occurs when a New Service Provider receives a valid request to port a telephone number, submits a port request to the Old Service Provider, receives confirmation for and completes the port.  Subsequently the Old Service Provider receives notification from another authorized user that the number was ported without their authorization and should be ported back.  The Old Service Provider then contacts the New Service Provider identifying the issue.  Disputed ports are to be addressed on a case by case basis by the parties involved.

Back to Top

0059  Use of certain SV Optional Data Fields and SV Optional Data Parameters

Submitted By Team: LNPA-WG | Date Logged: 05/04/09

Background:

Recommend Change to Requirements: NANC 436 was introduced in order to ensure that pooling a block would contain ALL Optional Data parameters that could be carried at a Subscription Version (telephone number) level. No other requirement changes have been recommended at this time.

Decisions/Recommendations

NANC 436 was introduced in order to ensure that pooling a block would contain ALL Optional Data parameters that could be carried at a Subscription Version (telephone number) level.

A number of service providers have used in the past, and continue to use, certain Subscription Version (SV) record data fields and Optional Data parameters (added in NANC Change Order 436) for which until this point the LNPA WG has not defined a use.  These data fields and Optional Data parameters, listed below, are being used by some providers to facilitate internal projects such as network migrations and customer rehomes.

• SV data field Billing ID(supported for LNP Type 0 and 1 SVs)
• SV data field End User Location Value(supported for LNP Type 0 and 1 SVs)
• SV data field End User Location Type(supported for LNP Type 0 and 1 SVs)
• SV Optional Data parameter altBilling ID(supported for LNP Type 0 and 1 SVs and 1K Pooled Blocks)
• SV Optional Data parameter altEnd User Location Value(supported for LNP Type 0 and 1 SVs and 1K Pooled Blocks)
• SV Optional Data parameter altEnd User Location Type(supported for LNP Type 0 and 1 SVs and 1K Pooled Blocks)

The LNPA WG understands that the use of these fields and parameters can assist in daily business activities such as network migrations, customer rehomes, etc.  Nevertheless, due to concerns related to potential LSMS database capacity exhaust, the LNPA WG feels it necessary to define a Best Practice around the use of these data fields and parameters.

It is the position of the LNPA WG that service providers, or others working on their behalf, should not create a new SV or pooled block record solely for the purpose of populating one or more of these fields or Optional Data parameters.

The LNPA WG will not attempt to define strict usages or definitions for these fields and Optional Data parameters at this time.

While adherence to this Best Practice is voluntary, all service providers should recognize that the NPAC is a shared industry resource, used by service providers and others primarily in support of Local Number Portability and Number Pooling.

Back to Top

0060  Impact to the porting process of SP-assigned pass codes/PINs to End User accounts

Submitted By Team: LNPA-WG | Date Logged: 09/16/09

Background:

Decisions/Recommendations

FCC Order 07-188 requires that LNP validation for Simple Ports be based on no more than the following 4 data fields on an incoming port request:

1. 10-digit telephone number;
2. customer account number;
3. 5-digit zip code; and
4. pass code (if applicable).

It has been brought to the attention of the LNPA WG that some providers have instituted a practice of assigning pass codes or PINs to their End Users' accounts without the request, or in some cases, the knowledge, of the End User. This practice can severely delay and impede the porting process. These provider-assigned pass codes differ from the practice of many providers that enable their End Users to request that a pass code or PIN be assigned to their account to ensure privacy and to prevent activity without the End User's permission.

It is the position of the LNPA WG that only pass codes/PINs requested and assigned by the End User for the purposes of limiting or preventing activity and changes to their account (and not, for example, a password or PIN the End user uses to access their account information on-line [Customer Proprietary Network Information (CPNI)] may be utilized as an End User validation field on an incoming port request by the Old Network Service Provider/Old Local Service Provider. In addition, any service provider assigned pass code/PIN may not be utilized as a requirement in order to obtain a Customer Service Record (CSR). This Best Practice applies to all ports (not just Simple Ports.)

NOTE:  A clarifying revision to this Best Practice was approved by the LNPA WG at its January 12-13, 2010 meeting. Subsequent to its approval by the LNPA WG, revised Best Practice 60 was reviewed by the North American Numbering Council (NANC) at its February 18, 2010 meeting and endorsed at the request of the LNPA WG.

The original Best Practice 60 was approved by the LNPA WG and included in the recommended Implementation Plan for FCC Order 09-41, which was endorsed by NANC at its October 15, 2009 meeting and forwarded to the FCC.

Back to Top

0061  Additional permitted use of Conflict Cause Value 51

Submitted By Team: LNPA-WG | Date Logged: 12/22/09

Background:

Decisions/Recommendations

It is the position of the LNPA WG that the Old SP may place a port in Conflict with a Cause Value of 51 (Initial Confirming FOC/WPRR Not Issued) in instances where the New SP has not complied with the Firm Order Confirmation (FOC) returned by the Old SP and the following applies:

• The Object Create Notification contains a Medium Timer Indicator set to True and contains a Due Date that differs from the Due Date on the Firm Order Confirmation.

Note that this does not apply for mutually agreed upon Due Date Changes.

NOTE:  This Best Practice was approved by the LNPA WG at its January 12-13, 2010 meeting.  Subsequent to its approval by the LNPA WG, Best Practice 61 was reviewed by the North American Numbering Council (NANC) at its February 18, 2010 meeting and endorsed at the request of the LNPA WG.

Back to Top

0062  DELETED -- Start of the 4-hour FOC response interval when LSR is for Simple Port

Submitted By Team: LNPA-WG | Date Logged: 02/01/10

Background:

Problem: Start of 4 hour Firm Order Confirmation (FOC)/Response interval in response to a Simple Port Local Service Request (LSR)

Decisions/Recommendations

Deleted upon agreement at the July 2011 LNPA WG meeting.

Back to Top

0063  Sending of the LSR Response to the New Network Service Provider (NNSP)

Submitted By Team: LNPA-WG | Date Logged: 02/09/10

Background:

Decisions/Recommendations

It is the position of the LNPA WG that the word "Sends" in the porting flows means a valid response to the LSR (FOC, Reject, Jeopardy or other appropriate response) is delivered by the ONSP to the NNSP.  To "send" in this context does not mean to just post or transmit the response to the ONSP's GUI as this can cause delay and confusion as the NNSP struggles to know when or if the response is available and to know if subsequent responses have been issued.  This delay and confusion is especially impactful during a reduced Simple Port interval.  By actually sending the response directly to the NNSP, it gives the NNSP an immediate and positive notice of the response.

The LNPA-WG continues to support and encourage the use of automated methods for sending LSRs and FOCs where possible, to reduce the amount of manual interaction necessary for all parties involved.  Sending the response to the LSR (FOC, Reject, Jeopardy or other appropriate response to the NNSP) in one of the following methods, notifies the NNSP of its presence and allows for the maximum processing time possible so the port can complete on time for the end user.  This Best Practice is not  meant to imply that the ONSP would need to accept LSRs via a method that they do not support.

Therefore, the LNPA Working Group Best Practice is for an ONSP to do one of the following:

• If XML/EDI/API is used to send the LSR to the ONSP, then the response to the LSR (FOC, Reject, Jeopardy or other appropriate response to the NNSP) should be sent back to the NNSP via XML/EDI/API.
• If a GUI is used to submit the LSR to the ONSP, then the response to the LSR (FOC, Reject, Jeopardy or other appropriate response to the NNSP) should be sent back to either: the NNSP's e-mail address or fax number indicated on the LSR or to a default email address for the NNSP agreed to by the NNSP and ONSP.
• A less desirable but acceptable alternative method would be for the ONSP to send a notification that a response has been produced and is now available for review in the GUI by the NNSP.  This notification should be sent back to either: the NNSP's e-mail address or fax number indicated on the LSR or to a default email address for the NNSP agreed to by the NNSP and ONSP.  This email notification should clearly indicate the PON or Order number involved.
• If email is used to send the LSR to the ONSP, then the response to the LSR (FOC, Reject, Jeopardy or other appropriate response to the NNSP) should be sent to either: the NNSP's e-mail address or fax number indicated on the LSR, or to a default email address for the NNSP agreed to by the NNSP and ONSP.
• If fax is used to deliver the LSR to the ONSP, then the response to the LSR (FOC, Reject, Jeopardy or other appropriate response to the NNSP) should be sent to either: the NNSP's e-mail address or fax number indicated on the LSR or to a default fax number/email address for the NNSP agreed to by the NNSP and ONSP.

NOTE 1:  At its January 12-13, 2010 meeting, the LNPA WG agreed that compliance to this Best Practice should be no later than February 2, 2011.

NOTE 2:  This Best Practice was approved by the LNPA WG at its February 9, 2010 meeting.  Subsequent to its approval by the LNPA WG, Best Practice 63 was reviewed by the North American Numbering Council (NANC) at its February 18, 2010 meeting and endorsed at the request of the LNPA WG.

Back to Top

0064  Industry Notification of Service Provider LNP System and Process Changes

Submitted By Team: LNPA-WG | Date Logged: 02/09/10

Background:

Decisions/Recommendations

It is the position of the LNPA WG that when a Service Provider implements changes to LNP systems or processes that require other Service Providers to change the way they interface with them, adequate notice should be given.  Such changes will require other Service Providers to implement changes as well.  These changes may involve educating employees or may involve reprogramming of systems.

The LNPA Working Group recommends as a Best Practice that Service Providers planning to implement changes to their Local Number Portability interface systems or processes give as much lead time as possible with a minimum of 60 calendar days notice to the industry before implementing those changes.  This will allow time for other Service Providers to make necessary adjustments.

The Service Provider making changes to their LSR interface systems or processes should make reasonable effort to notify other service providers who port with them.

NOTE:  This Best Practice was approved by the LNPA WG at its February 9, 2010 meeting.  Subsequent to its approval by the LNPA WG, Best Practice 64 was reviewed by the North American Numbering Council (NANC) at its February 18, 2010 meeting and endorsed at the request of the LNPA WG.

Back to Top

0065  LSR SUPPs, Expedites, Due Date Changes

Submitted By Team: LNPA-WG | Date Logged: 05/04/10

Background:

Decisions/Recommendations

Agreement was reached in the LNPA WG that service providers should continue to follow the ATIS OBF (Alliance for Telecommunications Industry Solutions, Ordering and Billing Forum) LSR guidelines when submitting a supplement to cancel, change the due date or change data values on a previous order for any port to or from a wireline carrier.  Per the current (Jan. 2010) LSR Guidelines, Expedites are not allowed on a simple port request.

If a New Network Service Provider (NNSP) finds for some reason that they will not be able to complete a port request on the original Due Date, they must submit a supplement changing the Due Date to the Old Network Service Provider (ONSP) to prevent the customer being put out of service.  When the port is a simple, next business day port request submitted before 1:00PM in the predominant time zone of the NPAC region in which the number is being ported (Due Date the next business day) and it is necessary to change the Due Date, it is critical that the New Service Provider (NSP) send the Old Service Provider (OSP) a supplement changing the Due Date before the OSP's porting center's closing business hour.  For those carriers that disconnect on the due date, they must accept SUPPs up until 9:00PM on Day 1.

Following are the three options for the ONSP to disconnect the number per the NANC Flow Narratives [(1.) will not be done until the old Service Provider has evidence that the port has occurred, or (2.) will not be scheduled earlier than 11:59 PM one day after the due date, or (3.) will be scheduled for 11:59 PM on the due date, but can be changed by an LSR supplement received no later than 9:00 PM local time on the due date.]

The response to the supplement should follow the industry standard response times, i.e., a non-simple port request should receive a response to a request/supplement within a maximum of 24 hours and a simple, next business day port request/supplement should receive a response within a maximum of 4 hours of having received the request/supplement.  (A request/supplement received before 1:00PM in the predominant time zone of the NPAC region in which the number is being ported, must receive a response within 4 hours that day in that time zone.  A request/supplement received after 1:00PM in that time zone, must receive a response before Noon of the next business day.)

The timing of the request/supplement should be considered when populating the Due Date to prevent the request/supplement being rejected by the OSP for an invalid Due Date further delaying the port.

NOTE 1:  This Best Practice was approved by the LNPA WG at its March 2010 meeting.  Subsequent to its approval by the LNPA WG, Best Practice 65 was reviewed by the North American Numbering Council (NANC) at its May 21, 2010 meeting and endorsed by the NANC at the request of the LNPA WG.

NOTE 2:  The following redlines were approved by LNPA WG at the March 6, 2013 meeting, and will be presented for approval to the NANC in their May 2013 meeting.  If approved at the NANC, it will be sent to the FCC for approval.

NOTE 3:  The NANC approved Best Practice 65 and the associated NANC LNP Process Flows in their September 2013 meeting.  The NANC forwarded their recommendation for approval to the FCC on October 17, 2013.

NOTE 4:  After a Public Comment cycle was completed, Best Practice 65 was approved and mandated by the FCC in DA 14-842 dated June 20, 2014.

Back to Top

0066  Master billing accounts and the impact to the End User's ability to port in one day

Submitted By Team: LNPA-WG | Date Logged: 05/25/10

Background:

Documentation Referenced: FCC Order 09-41

Decisions/Recommendations

Some Service Providers currently bundle single-line, single number End User accounts under a master billing account.  This could have impacts on the End User's ability to port their telephone number on a next-day basis if the Old Service Provider defines this port to be a Non-Simple Port by considering it to be a port of a single telephone number from a multi-telephone number account.  In this scenario, the End User has no idea that their account with the Service Provider is part of a master billing account and would expect to be able to port their number on a next-day basis as a Simple Port.

With the implementation of one business day porting for Simple Ports starting on August 2, 2010, it is the position of the LNPA WG that a Service Provider's retail End User with a single-line, single-telephone number or the Service Provider's wholesale Class 2 or Class 3 Interconnected VoIP Provider's retail End User with a single-line, single-telephone number must be able to port their telephone number on a next-day basis upon request.  This port would be done following the rules for a one-day Simple Port, provided that the other criteria defining a Simple Port would otherwise lead to classifying the port as Simple, regardless of whether or not the Service Provider has bundled this End User's single-line, single-telephone number account with other End Users under a master billing account.

NOTE 1:  This Best Practice is not intended to propose changes to the current FCC Simple Port definition related to resellers, unless changed by the FCC.

NOTE 2:  This Best Practice was approved by the LNPA WG at its May 2010 meeting.  Subsequent to its approval by the LNPA WG, Best Practice 66 was reviewed by the North American Numbering Council (NANC) at its May 21, 2010 meeting and endorsed by the NANC at the request of the LNPA WG.

Back to Top

0067  Processing Interval for Simple, Non-Simple, Porting Project and Customer Service Records (CSR)

Submitted By Team: LNPA-WG | Date Logged:10/21/10 | Date Modified: 5/10/11

Background:

Simple Port: Per FCC Order 09-41 Service Providers are required to support a 1 business day order to port interval for simple LNP ports. By definition, simple port allows for a minimum requested due date of 1 business day (4 hour Firm Order Confirmation [FOC] plus 1 or 2 day due date).

Non Simple Port: Service Providers have different definitions and thresholds associated to non simple LNP ports which requires the Old Service Provider to process within a minimum requested due date of 4 business days (1 day Firm Order Confirmation [FOC] plus 3 day due date).

Project Port: Typically Old Service Providers define an LNP project as a LNP request that is above the maximum non simple port LNP order threshold. LNP orders that are defined as a project order result in longer FOC and due date intervals. Due dates and processing timelines lack definition and are often negotiated with the Old Service Provider. In addition to the lack of interval standardization, FCC Order 09-41 did not establish standard minimum thresholds in terms of the quantity of TNs that could be considered a LNP project. The result is that a number of Service Providers have established minimum thresholds of TNs, some as low as 2, that are not candidates for the 4 day non-simple porting interval.

This proposed Best Practice seeks to reach consensus at the LNPA Working Group on an acceptable least common denominator in order to do the following:

1. Remind Service Providers of their obligation to return a Firm Order Confirmation (FOC) or an appropriate error message for all simple wireline and intermodal ports within 24 hours (excluding weekends and holidays) as directed in FCC 03-284A1 and as previously set forth in Best Practice 47 now superseded by Best Practice 67.

2. Re-affirm earlier consensus of the LNPA WG that the 4 hour Firm Order Confirmation (FOC) response to simple wireline and intermodal ports with shortened intervals as mandated by FCC 09-41 starts when a complete and accurate LSR is received by the Old Service Provider or is received by the agent/service bureau/clearing house of the Old Service Provider as previously set forth in Best Practice 62 now superseded by Best Practice 67. Also see Chart 1 & 2.

3. Establish the minimum quantity of TNs on a port request that can be considered a “project” by the Old Service Provider for which the due date can be negotiated between the Old and New Service Providers and not necessarily a candidate for the 4 business day non-simple porting interval.

4. Establish the minimum quantity of TNs on a port request that can be considered a “project” by the Old Service Provider for which the response to the Local Service Request (LSR) (either the Firm Order Confirmation [FOC] or Reject, whichever is applicable) can exceed 24 clock hours.

5. Establish the minimum quantity of TNs on a requested Customer Service Record (CSR), if applicable, for which the return of the CSR to the requesting New Service Provider can exceed 24 clock hours and be negotiated between the Old and New Service Providers.

Decisions/Recommendations

For simple wireline and intermodal ports as described in Best Practices 47 and 62 respectively, it is the intent of the LNPA WG to consolidate the information and present it as follows in its condensed form.  Further, for non-simple ports, it is the position of the LNPA WG that the following minimum thresholds and processing timelines shall apply.  NOTE: The following are subject to applicable state guidelines and unless otherwise negotiated between the involved Service Providers.

The following minimum thresholds shall apply for requested Customer Service Records (CSRs), when applicable.  These are also subject to applicable state guidelines and unless otherwise negotiated between the involved Service Providers.

NOTE 1:  This Best Practice is not intended to imply or encourage Service Providers to lower their minimum thresholds if they currently support higher quantities of TNs that can be ported within the 4 business day non-simple porting interval, nor is it meant to encourage Service Providers to withhold issuing the FOC or CSR if they currently respond in a timeframe quicker than is outlined above.  It is only intended to require Service Providers to support a higher threshold of TNs if they currently only support less than the established thresholds described above.  Service Providers that currently support higher thresholds of TNs for non-simple ports are encouraged NOT to initiate changes to their systems and processes in order to lower them.

NOTE 2:  Excluding weekends and Old Service Provider Company Holidays

NOTE 3:  One TN in this context would be an LSR for a Non-Simple port of a single TN, e.g., a port of a single TN from a multi-TN account.

NOTE 4:  These CSR return times are subject to the New Service Provider selecting a delivery method that can meet these intervals, if the New Service Provider is given such options.

NOTE 5:  The intervals for TN counts of 1-50 above apply for multiple TN accounts when the entire account of TNs is being ported.  When partial accounts of complex services are being ported, e.g., MLHG, ISDN, DID, PRI, Centrex, etc., and the remaining block of TNs must be rebuilt by the porting out Service Provider, this will be considered a “project” subject to negotiation by the involved Service Providers per the intervals in Note 5.

NOTE 6:  Upon request by the New Service Provider in the port, the Old Service Provider will supply the Project ID and completion date (port Due Date) of the entire project within 72 clock hours (see Note 1).  This information will be included on the LSR submitted by the New Service Provider.  Once the LSR is received by the Old Service Provider, the FOC must be returned to the New Service Provider within 72 clock hours (see Note 1).  The project completion date interval (port Due Date) will be no longer than 15 business days from receipt of the LSR unless otherwise requested by the New Service Provider or negotiated by the Old Service Provider. 

• Chart 1 Simple Port: LSR to FOC Interval Chart

• Chart 2 One Business Day: FCC09-41 LSR Submit/FOC Receipt and Prospective Due Date/Time Chart for Normal Business Week (no Holidays)

This Best Practice was endorsed by the North American Numbering Council (NANC) at its May 17, 2011 meeting.  At that meeting, the NANC also endorsed and agreed to forward this Best Practice to the FCC’s Wireline Competition Bureau with a request that it and its accompanying revisions to the NANC LNP Provisioning Flows be formally adopted.

Back to Top

0068  Stolen Telephone Numbers

Submitted By Team: LNPA-WG | Date Logged: 05/01/11

Background:

Decisions/Recommendations

This Best Practice addresses Stolen Numbers which are telephone numbers that are ported away from subscriber(s) to whom the telephone number was legitimately assigned, where the party that ported the telephone number is unknown to the legitimate subscriber and where the porting party did so to facilitate the sale or acquisition of the telephone number.  A Stolen Number differs from a Disputed Port in that a Disputed Port involves two parties who have a relationship, e.g., spouses, partners, employer and employee, whereas in a Stolen Number, no such relationship exists. 

Due to the recent increase in challenges associated with attempts to steal telephone numbers and such telephone numbers being ported, the LNPA WG developed the following Best Practice. 

The Service Provider requesting the return of a telephone number due to its theft or fraudulent acquisition is responsible for verifying the rightful subscriber.  Upon request, the Service Provider requesting return of the telephone number must provide sufficient documentation to prove that its subscriber is the rightful subscriber and assignee of the telephone number.

Once the Service Providers have verified that a subscriber’s telephone number has been “stolen,” the telephone number should be returned to the original subscriber/Service Provider within the same business day but not to exceed 24 hours.

Back to Top

0069 Large Port Notifications

Submitted By Team:  LNPA-WG | Date Logged: 05/10/11

Background:

See the "Large Port" M&P on the NPAC secure web site under Help Desk & Training, Help Desk Services, and Select Help Desk M&Ps.

Decisions/Recommendations

A Service Provider should notify the industry of planned porting activity (activate, modify, delete) whenever 25,000 or more TNs in a region in one hour are affected.  The SP does this by notifying NPAC by e-mail at large.ports@neustar.biz  of the anticipated activity.  The NPAC Help Desk compiles the SP notices and sends them to the U.S. Cross Regional Distribution List on an as needed basis.

Back to Top

0070 Required information for Customer Service Record (CSR) requests

Submitted By Team: LNPA-WG | Date Logged: 05/01/11

Background:

With the implementation of one-day porting for Simple Ports in accordance with FCC Orders 09-41 and 10-85, the FCC adopted the following requirements pertaining to Customer Service Records (CSRs) by virtue of adopting the attached NANC LNP Provisioning Flows:

0070_PIM_NANC_Ops_Flow_Narrative_2011-04-16

• The Old SP shall not require the New SP to have previously obtained a CSR before they will accept an LSR from the New SP.  For those New SPs that choose not to obtain a CSR, they understand that there is heightened risk that their LSR may not be complete and accurate.  This is not intended to preclude those providers who provide an ordering GUI from including a step involving a real-time CSR pull within that process, as long as an alternate ordering process is available that does not require a CSR being pulled.
• CSRs, if requested and available, must be returned within 24 clock hours, unless otherwise negotiated between service providers, excluding weekends and Old Service Provider holidays.
• Any of the end user validation fields required by the Old SP on an incoming LSR must be available on the CSR, excluding end user requested and assigned password/PIN.
• Only passwords/PINs requested and assigned by the end user may be utilized as an end user validation field on an incoming LSR by the Old Network Service Provider/Old Local Service Provider.  Any service provider assigned password/PIN may not be utilized as a requirement in order to obtain a CSR.
• NLSP obtains verifiable authority (e.g., Letter of Authorization – [LOA], third-party verification – [TPV], etc.) from end user to act as the official agent on behalf of the end user.  The OLSP cannot require a physical copy of the end user authorization to be provided before processing the Customer Service Request (CSR) or the port request.  The NLSP is responsible for demonstrating verifiable authority in the case of a dispute.

Decisions/Recommendations

One of the primary reasons that the New Local Service Provider (NLSP) in a port requests a CSR from the Old Local Service Provider (OLSP) in the port is to obtain the customer’s Account Number, which is one of the required fields on a Simple Port request.

It has come to the attention of the LNPA WG that some providers are requiring information such as the customer’s Account Number (AN), before they will honor a CSR request.  This is serving to add delay in obtaining the necessary CSR and therefore, is adding delay to the customer’s ability to port their telephone number.

It is the position of the LNPA WG that for all Customer Service Record (CSR) requests, only the following information may be required by the Old Local Service Provider (OLSP) when the New Local Service Provider (NLSP) makes a request for a CSR:

1. Any Working Telephone Number (WTN) associated with the customer’s account,
2. A positive indication that the proper authority has been obtained from the customer,
3. The date that authority was obtained from the customer.

Providing this information will result, at a minimum, in the return of the CSR for the specified Working Telephone Number (WTN), but that CSR must contain all necessary account information, e.g., Account Number (AN), Billing Telephone Number (BTN), Customer Name, Customer Address, etc., in order to complete a Local Service Request (LSR) for any telephone number(s) associated with the customer’s account.

(Note: If the BTN or AN is not used to pull the initial CSR, to insure a complete CSR, including all WTN’s on the account can be returned for the entire account, it may be necessary for the New Provider to submit a second CSR request, using the AN or BTN provided in the first CSR retrieval, to get the full CSR for the account.)

The NLSP must obtain verifiable authority (e.g., Letter of Authorization – [LOA], third-party verification – [TPV], etc.) from the end user to act as the official agent on behalf of the end user prior to requesting the CSR from the OLSP.  The NLSP is responsible for indicating positively on the CSR request that they have obtained the necessary verifiable authority from the end user and the date that authority was obtained.  The NLSP is responsible for demonstrating verifiable authority in the case of a dispute.

This Best Practice was endorsed by the North American Numbering Council (NANC) at its September 15, 2011 meeting.  At that meeting, the NANC also endorsed and agreed to forward this Best Practice to the FCC’s Wireline Competition Bureau with a request that it and its accompanying revisions to the NANC LNP Provisioning Flows be formally adopted.

Back to Top

0071 Wireless Reseller Port Out Validation Requirements

Submitted By Team:  LNPA-WG | Date Logged: 11/04/15

Background:

Consumers are experiencing negative porting experiences as a result of the lack of uniformity and clarity in processes that drive port completion timeframes.

Having no industry standards for reseller validations on port out requests lead to confusion from the port in carriers and at times makes it difficult on the end user to port a TN to a different service provider.

Though every reseller is under contract with a Network Service Provider (NSP) and is obligated to port, lack of specific regulations provide resellers the ability to validate on any field on a port request.  Standardization of wireless reseller validation requirements will allow for more consistent port completion timeframes and a better customer experience.

Decisions/Recommendations

Wireless reseller port out validations are not consistent across the industry ranging from zero validations to obscure validations such as a customer’s birthdate.  The lack of port out validation uniformity by wireless resellers confuse service providers, as well as end users, when the port out request is not completed in a timely manner.

It is the position of the LNPA WG that wireless reseller end user validations must be reasonable and should adhere to the wireless simple port validation fields allowed by the FCC.  Those four fields are:

• Ported Telephone Number
• Active Account Number
• Zip Code
•  End User Provided Password/PIN (if applicable)

Use of other validations on port out fields delay the port request unnecessarily and causes confusion for end users.

Back to Top

0072 Service Provider E-Mail Guidelines

Submitted By Team:  LNPA-WG | Date Logged: 09/13/16

Background:

Create a best practice for managing e-mail responses, escalation paths and related timeframes.  This includes accurate e-mail addresses (accurate as in destined for personnel who can assist with LNP order issues) and toll free TNs in TPPs and on websites.

Decisions/Recommendations

There are some service providers (including resellers) who choose to respond to port out requests and/or communicate via e-mail.  These providers (including resellers) can be small to mid-size carriers and either wireless or wireline providers.

This best practice is intended to provide guidelines for those service providers (including resellers) who respond and/or communicate via e-mail. 

An e-mail response to port out or supplemental requests must be sent by the Old Service Provider (OSP) (including resellers) within four (4) business hours of receipt. 

The e-mail must include the following:

1. A thorough response to allow the New Service Provider (NSP) to correct any and all information on the next iteration of the port out request. (Best Practice 39)
2. An escalation point of contact name and number.

E-mail responses to NSP communications must be sent within four business hours of receipt.

**This Best Practice should also apply to carriers who utilize fax for responding to port out requests.

Back to Top

0073 Unauthorized Port Flow

Submitted By Team:  LNPA-WG | Date Logged: 07/07/15

Background:

As porting becomes increasingly more complex with varying service types, and with varied levels of automation being introduced into the environment, these variable (non-standardized) porting processes may result in a higher volume of unauthorized porting activity. It has become increasingly more difficult to determine how to approach a resolution without consistent guidelines about which information can be examined and/or exchanged between providers/carriers. When determining how to address an out of service or unauthorized port, the flow should provide a detailed outline for carriers to follow to resolve customer complaints.

Decisions/Recommendations

Service providers should follow the outlined flow to resolve any ports believed to be Unauthorized, Disputed, Fraudulent or Inadvertent. Recommend using this Best Practice (BP) as the master BP over the other associated PIMs/BPs dealing with Unauthorized, Disputed, Fraudulent or Inadvertent ports.

0073_PIM_Disputed Port Flow - 2017-05-02

Back to Top