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 Time Stamp on SV Create
Submitted By Team: | Date Logged: 10/9/01
Background:
Recommend Change to Requirements: Yes
Decisions/Recommendations
The WNPO decided that for an inter-species port (between wireless and wireline) the time stamp on an SV create sent to the NPAC must be set to zero. For wireless-to-wireless SV creates, specific times can be set. There are still some operational problems associated with the time stamps today, and they may be exacerbated with the introduction of wireless porting.
0002 Type 1 Trunk Conversion
Submitted By Team: | Date Logged: 10/9/01
Background:
Recommend Change to Requirements: Yes
Decisions/Recommendations
Recommend that project management processes be put in place for Type 1 trunk conversions.
0003 BFR Contact Information
Submitted By Team: | Date Logged: 12/10/01
Background:
Recommend Change to Requirements: Yes
Decisions/Recommendations
Sending the BFR form to the recipient contact information in the WNPO BFR Matrix or the LERG contact information guarantees that you have made the request for another service provider to support long-term Local Number Portability (LNP) and open ALLcodes 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 the necessary codes for porting. It is the recipient's responsibility for ensuring that the contact information in the WNPO BFR Matrix and/or the LERG is correct.
0004 N-1 Carrier Methodology Clarification
Submitted By Team: | Date Logged: 12/10/01
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. If there is a locally terminated call then the originating carrier needs to perform the dip, because they cannot be sure whether the tandem switch belongs to the N-1 carrier or the N carrier (terminating carrier). For all local terminations the originating carrier needs to perform the dip, however, for any calls going through an IXC the IXC must perform the dip. Following are examples that were discussed:
- Wireless to a ported local wireless—the originating wireless carrier should perform the dip (unless they intend to default route and pay the terminating carrier to perform the dip for them).
- Wireless to a ported local wireline—the originating wireless carrier should perform the dip, since they cannot be sure whether a tandem switch belongs to a different carrier than the terminating switch (unless they intend to default route and pay the terminating carrier to perform the dip for them).
0005 FCC 3rdReport 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
BFR Requirements
The NRO 3rdReport & Order, released on 12/28/01, clarified that BFRs (Bonafide Requests) are not needed within top 100 MSAs—all codes within the top 100 MSAs must be open for porting by 11/24/02. This applies to both wireline and wireless SPs.
0006 Sufficient Testing Prior to Turn-Up
Submitted By Team: | Date Logged:1/9/02
Background:
Recommend Change to Requirements: Yes
Decisions/Recommendations
Service providers must sufficiently test all equipment prior to turning it up in production. If service providers are unable to complete sufficient testing they should not turn up equipment that is not ready for production use.
0007 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 HLR queries for call originations on a wireless MSC.
0008 DELETED
Team consensus was to remove this issue.
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.
0010 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
NPAC porting activities should not be carried out during the service provider maintenance window timeframes AND service providers should start maintenance at the start of the window.
0011 Neustar 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 SPs start the application process with Neustar no later than July 1, 2002 to secure the necessary Neustar resources in order to comply with the mandated dates. A carrier cannot begin participation in intercarrier testing until the application process is completed.
0012 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
The WNPO took a vote on 4/8/02 and decided that Option B(as described in a contribution from Sprint), an alternative wireless reseller flow, would be used instead of those documented in the Technical, Operational and Implementation Requirements document (Option A). The flows and narratives for Option B will be documented in upcoming WNPO meetings.
0013 FCC 3rdOrder on Reconsideration and NPRM (FF 02-73)
Submitted By Team: | Date Logged:4/9/02
Background:
Recommend Change to Requirements: Yes
Documentation Referenced:
- FCC 3rdOrder on Reconsideration and NPRM (FCC 02-73)
- FCC 3rdReport and Order (FCC 01-362)
Decisions/Recommendations
The issuance of the FCC 3rdOrder on Reconsideration and NPRM (FCC 02-73) in March 2002 has caused uncertainty within the wireless industry. The WNPO has agreed upon the assumptions below in an effort to minimize the uncertainty and effectively manage the implementation of WLNP and pooling.
1) Wireless service providers participating at the WNPO are agreeing to open all their codes within the Top 100 MSAs prior to 11/24/02 (without receiving a BFR), regardless of whether BFRs are required in the future. The original mandate specifies that BFRs must be submitted no less than nine months prior to implementation.
2) Wireless service providers participating at the WNPO will assume the Top 100 MSAs are those defined in the 3rdNRO Report and Order "" FCC 01-362 issued in December 2001 (including CMSAs).
Note:Participating service providers are defined as those in attendance at the 4/8/02 WNPO meeting.
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.)
0015 Deleted
Submitted By Team: | Date Logged:5/14/02
Team consensus was to remove this issue.
0016 LRN Assignments
Submitted By Team: | Date Logged:5/14/02
Background:
Recommend Change to Requirements: Yes
Decisions/Recommendations
Wireless carriers should define their LRNs per switch, per LATA, per wireless point of interconnect (in the case of multiple points of interconnect to multiple LECs in the same LATA).
0017 Troubleshooting Contacts
Submitted By Team: | Date Logged:5/14/02
Background:
Recommend Change to Requirements: Yes
Decisions/Recommendations
Carriers should update their troubleshooting contact information on the NIIF (Network Interconnection & Interoperability Forum) website under http://www.atis.org/niif/cscdlnp.asp
0018 LSOG Version
Submitted By Team: | Date Logged:5/14/02
Background:
Decisions/Recommendations
Wireless and wireline carriers should support at least LSOG 5.0.
Note: This item is for historical reference.
0019 Clearinghouse Maintenance Windows
Submitted By Team: | Date Logged:6/10/02
Background:
Recommend Change to Requirements: Yes
Decisions/Recommendations
Maintenance on all systems used exclusively for LNP should be scheduled to occur during the regular Service Provider Maintenance Window that occurs each Sunday morning.
0020 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
In a wireline to wireless port, the applicable entry for the NPDI field on the LSR is a value of "C''. On an SPSR, the NPDI field is not applicable.
0021 Permissive Dialing Periods
Submitted By Team: | Date Logged:11/25/02
Background:
Recommend Change to Requirements: Yes
Decisions/Recommendations
Due to the fact that wireless and wireline service providers will be sharing codes in the pooling/porting environment, extended Permissive Dialing Periods for wireless service providers can no longer be supported.
0022 Porting/Pooling and Telemarketing
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
In a pooling or porting environment, there will be a potential impact from telemarketers after November 24, 2002 on the wireless customer. 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.
0023 Vertical Services Database Updates
Submitted By Team: | Date Logged: 2/25/03
Background:
Recommend Change to Requirements: No
Decisions/Recommendations
The recommendation is that all Service Providers analyze their internal processes by which the various databases are updated with their individual database provider to assess timing requirements and determine potential issues. This will be placed on the decision recommendation matrix.
0024 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
Carriers will use ICP systems that are OBF WICIS 2.0 compliant for production on 11/24/2003. Letter from OBF dated 2/14/03 to industry.
Note: This item is for historical reference.
0025 In-Vehicle Services
Submitted By Team: | Date Logged: 4/07/03
Background:
Recommend Change to Requirements: No
Decisions/Recommendations
The process of porting a vehicle MDN is based on a formal arrangement between any and all impacted partners.
0026 10-Digit Trigger
Submitted By Team: | Date Logged: 7/10/03
Background:
Documentation Referenced: OBF Local Service Request (LSR)
Decisions/Recommendations
As a reminder to wireless carriers: In your agreements with wireline trading partners make the 10-digit trigger functionality a default and to the extent that you are issuing an LSR for a third party provider, ensure the 10-digit trigger box on the LSR is checked.
0027 Retail Holiday Hours
Submitted By Team: | Date Logged: 7/10/03
Background:
Decisions/Recommendations
If Service Providers [mutually] agree to does the Intercarrier Communication Process on holidays then by default the Service Providers agree to follow normal intervals for concurrence in order to complete the port?
0028 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
See the following Document for current process
Team consensus was to remove this issue.
0029 ICP Hours of Operation
Submitted By Team: FORT | Date Logged: 12/8/03
Background:
Decisions/Recommendations
ICP process should be able to support porting 24 X7 and it is up to the trading partners to add additional restrictions.
0030 NPA Splits
Submitted By Team: WNPO | Date Logged: 2/2/04 | Date Modified: 4/5/04
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 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:
0031 NPAC Port Prior to Confirmation
Submitted By Team: WNPO | Date Logged: 2/2/04
Background:
Documentation Referenced:
- NANC Inter-Service Provider LNP Operations Flows
Decisions/Recommendations
Raise awareness within the industry that a NSP must receive a positive responsebefore a "create" is sent to the SOA. Ensure that all personnel are properly trained on the correct, agreed upon industry process. Please refer to the official NANC flows for the exact process to be followed.
0032 Port Protection
Submitted By Team: WNPO | Date Logged: 2/3/04
Background:
Decisions/Recommendations
WNPO agreed to recommend (non-binding) that service providers utilize the following method to remove port protection from customer accounts that had port protect in place:
"Provide the customer with a password/pin number they can use to remove the port protection service from their account. The new service provider would then send the password/pin number in the WPR to the old service provider authorizing the removal of the port protection service and the port to the new service provider."
0033 Best Practices
Submitted By Team: WNPO | Date Logged: 2/2/04
Background:
Documentation Referenced:
- WNPO NP Best Practices Document
Decisions/Recommendations
This contribution documents specific industry guidelines agreed upon among trading partners since Nov. 24, 2003.
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)
Decisions/Recommendations
See the following document for current checklist and process:
A SPID migration is allowed to occur before the Telcordia LERGTM Routing Guide effective date provided, however, that the effective date is no later than the following Wednesday. In general, however, SPID migrations should be scheduled on or as soon after the published Telcordia LERGTM Routing Guide as possible.
Additionally, service providers are urged to follow the processes listed below for required SPID changes:
INDUSTRY SPID CORRECTION SELECTION PROCESS
If No Ported or Pooled Numbers 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 deleted in the NPAC. The new code holder will then add the code in the NPAC under their SPID.
If Ported or Pooled Numbers Exist In The Code(S) Affected By The Move:
- 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.
- NANC 323 SPID Migration: If Option 1 above cannot be used to change NXX code ownership in NPAC, the industry preferred process is to perform a NANC 323 SPID migration.
- 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 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, etc.
0035 Abandoned Ports
Submitted By Team: LNPA-WG | Date Logged: 2/11/05
Background:
Documentation Referenced: NANC Inter-Service Provider LNP Operations Flows: http://www.fcc.gov/wcb/tapd/Nanc/gnflw14.ppt (broken link)
Decisions/Recommendations
This is the solution only when a carrier has not or is unable to use the recommended cancel process as documented in the NANC Process Flows.
Most wireless carriers have agreed to follow the following two scenarios. Other carriers can have different intervals and processes for determining when a port is abandoned. Those carrier's business rules for identifying an abandoned port and when and how they will purge the abandoned port from their records will be posted on their LNP web sites.
- Scenario 1—This scenario applies to the service providers that use the NPAC activation notice before disconnecting the porting end using customer. When the Old Service Provider (OSP) has confirmed the port request but does not receive an activation notice from NPAC, they can consider the port request abandoned 30 calendar days after the due date. In a similar process, the NPAC purges pending Subscription Versions (SVs) 30 days after their due dates have passed.
- Scenario 2—The OSP has responded to a port request with a Resolution Required requiring subsequent activity from the NSP. If no subsequent activity has been received within 30 calendar days, then the port may be considered abandoned.
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:
0037 Use of Evidence of Authorization
Submitted By Team: LNPA-WG | Date Logged: 5/27/05 | Date Revised: 11/2/05
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.
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.
The evidence of authorization needs to be obtained and maintained as required by applicable federal and state regulation, e.g., CFR 64.1150, FCC Order 99-223, 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), 3rdparty 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.
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.
0039 Identification of multiple errors on wireline Local Service Requests (LSRs) and Wireless Port Requests (WPRs)
Submitted By Team: LNPA-WG | Date Logged: 10/3/05
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.
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 LRN's 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 insure 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:
- 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.
- 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.
0041 Compliance to JIP Standards and Guidelines
Submitted By Team: LNPA-WG | Date Logged: 12/22/05
Background:
Documentation Referenced:
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) and in ATIS' Network Interconnection Interoperability Forum's (NIIF) (www.atis.org/niif/index.asp) 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
- JIP should be populated in the IAMs of all wireline and wireless originating calls where technically feasible.
- JIP should be populated with an NPA-NXX that is assigned in the LERG to the originating switch or MSC.
- 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.
- 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.
- 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.
- 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.
- 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.
- As per T1.TRQ2, the JIP should be reset when a new billable call leg is created.
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
Note: Disputed ports are not covered by the inadvertent port process. Refer to Best Practice 58 for disputed ports.
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.
The attached file contains contact numbers/sites to be used by other providers to contact the applicable service provider to address PIM 53-related issues.
0043 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).
0044 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
Change Order 41 directed the Pooling Administrator (PA) to perform a one-time scrub of the entire PAS Database to reduce the likelihood that carriers will receive over-contaminated blocks or incorrectly identified contaminated blocks in lieu of pristine blocks. The PA provided a list of blocks to the NPAC in order to determine the contamination level of each block. The NPAC then provided the PA with the results; the PA compared the NPAC data against the block contamination status in PAS. Out of the 189,552 available blocks, 10,758 resulted in a discrepancy, which meant that the information entered by the Service Provider into PAS or the NPAC was incorrect, and in addition, out of the 10,758 discrepant blocks, 506 blocks appeared to be over 10% contaminated. The carriers involved in these discrepancies were notified to correct these discrepancies. Following is a list of explanations from the carriers as to why they had discrepancies:
- Lack of communication between the carriers departments;
- The SPs did not realize they needed to do intra-SP ports prior to donating blocks;
- The SPs did not have a process in place to notify the PA when the contamination status of a previously donated block goes from contaminated to non-contaminated;
- Some SPs mistakenly believed that updating NRUF automatically updated the NPAC; and
- Some SPs thought they could donate the block even though it was over 10% contaminated, if the numbers were ported to another carrier.
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.
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.
0047 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
It has been brought to the attention of the Local Number Portability Administration Working Group (LNPA WG) that a number of Service Providers participating in local number portability are failing to comply with the requirement that all simple wireline and intermodal port requests shall be confirmed by the Old Service Provider (OSP) within 24 hours, excluding weekends and holidays.
The Firm Order Confirmation (FOC) process is defined by the Alliance for Telecommunications Industry Solutions (ATIS) Ordering and Billing Forum (OBF). The timing requirements for return of the FOC are cited in a number of industry and regulatory documents, including the North American Numbering Council Local Number Portability Administration Working Group's 3rdReport on Wireless Wireline Integration, dated September 30, 2000, which states, "An LSR is submitted by the NSP (New Service Provider) to the OSP (Old Service Provider). When an LSR is submitted to the OSP, the OSP will return either an error message or a LSC (FOC). SPs are required to provide a LSC/FOC within 24 hours of receiving a LSR." In addition, in Paragraph 49 of its Memorandum Opinion and Order and Further Notice of Proposed Rulemaking (FCC 03-284A1), adopted November 7, 2003, the FCC stated, "the wireline NANC LNP Process Flows establish that the FOC must be finalized within 24 hours of receiving the port request."
It is the LNPA WG's position that the return of either the Firm Order Confirmation (FOC) in response to a valid Local Service Request (LSR), or an appropriate error message in response to an invalid LSR, by the Old Service Provider for a simple port request shall not exceed 24 hours, excluding weekends and holidays.
At the April 17, 2007 NANC meeting, the LNPA WG submitted this Position Paper in order to bring this issue and the LNPA WG's position to the attention of the NANC and the FCC.
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, two of four RBOCs 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.
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 at www.NENA.org.
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.
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
- Customer ports number.
- Ported customer reports problem receiving some phone calls or another customer reports problem with making calls to the ported number.
- New Network Service Provider (NNSP) checks to ensure that all provider LSMSs' active subscription version (SV) data is correct by launching an audit request.
- NSP reports the problem to the Telco that is routing calls with incorrect LRN (SCP/STP is discrepant with NPAC).
- These issues are reported to the Telco's Network Operations Center (NOC).
- All involved Telco's work together to identify and correct the problem.
- Discrepant Telco will notify to the reporting Telco when the problem has been found and corrected.
- 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
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.
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.
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.
0055 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
Attached are the NANC Inter-Service Provider LNP Operations Flows and Narratives that have been revised to address the implementation of FCC Order 07-188, also attached, released on November 8, 2007. These revised flows were presented to the NANC on February 22, 2008.
During the process of revising the documentation to address FCC Order 07-188, the LNPA WG discussed the continued need for two data fields that are common to both the current Local Service Request (LSR) and Wireless Port Request (WPR) forms and the message that both the Old and New Service Providers send to the Number Portability Administration Center (NPAC) to process a port. These two data fields within the purview of the LNPA WG are the New Service Provider Identification (SPID) and the Desired Due Date. The New Provider SPID is a 4-digit field that identifies the New Service Provider in a port request. All providers with connectivity to the NPAC are required to establish a SPID. The Desired Due Date is the date upon which the New Service Provider wishes the port to take place in order to gain the customer.
The service providers that participated in the revision of these LNPA WG documents unanimously agreed that these two data fields are necessary for established NPAC functionality to be maintained, for the continued efficiency of the porting process, and to ensure the end user's service is not interrupted during the porting process.
Reasons for the continued need for the New Provider SPID and the Desired Due Date on an LSR are as follows:
1. Retain the ability of the old SP to avoid service outages: The Old Service Provider "create" message to the NPAC, used by the Old Service Provider (Old SP) in a port to provide confirmation of the pending port to the NPAC, is an optional message if the Old SP agrees with the port request, however, if the Old SP needs to place the pending port into conflict in the NPAC because, for example, the wrong number is about to be inadvertently ported, their only vehicle for doing so is to send the Old SP create message to the NPAC with the confirmation "flag" unchecked. The Old SP create message is required in this case in order for the Old SP to retain the ability to maintain customer service. An inadvertent port impacts the terminating service of two customers, the one who wants to port their number and the one who does not. It presents costs for trouble report handling and may involve extended periods of service impairment or outage. The New Provider SPID and the Desired Due Date are necessary NPAC system and local system fields that must be populated on the Old SP create message and must match the same fields in the New SP create message in the NPAC.
2. Additional reasons cited for the need for the Old SP create message, and therefore the New Provider SPID and Desired Due Date, include:
- Addressing potential port delay should the Old SP fail to return the Firm Order Confirmation (FOC) in a timely manner: The Old SP create message enables the Old SP to stop the NPAC timers which were designed to prevent premature activation of the port until they expire? Cancellation of these timers could potentially allow the New SP to still activate the port on the desired due date in this scenario.
- Enabling a reduced wireless-to-wireless porting interval: Although the standard wireless-to-wireless porting interval is currently 2½ hours, approximately 80% of these ports take place within 30 minutes. If the Old SP did not send the Old SP create message to the NPAC to cancel the NPAC timers described above, the New SP could not activate the port until 2 hours have elapsed.
3. Proper identification of New Provider on a port request: Specific to the New Provider SPID, this LSR field is used by the Old SP to properly identify and verify the submitting provider in order to send the FOC, especially in the case of a faxed LSR.
4. Accurate scheduling of customer disconnect in Old SP switch to avoid service outages: Specific to the Desired Due Date, while the Old SP in a port could assume a Desired Due Date based on the current standard porting interval if the New SP does not include the Desired Due Date on an LSR, introducing such an assumption into the porting process has service-affecting consequences should an incorrect assumption be made by the Old SP. The Desired Due Date is used by porting-out providers that schedule the customer disconnect to take place on or after the due date of the port activation. If the New SP failed to provide the Desired Due Date on an LSR, and the Old SP assumed the standard porting interval, however, the New SP had not scheduled the port to take place until some time after that which would be dictated by the standard porting interval, the customer would be taken out of service on the date assumed by the Old SP. A significant percentage of port requests currently have Desired Due Dates beyond the standard porting interval.
5. Allowing sufficient time to ship necessary Customer Premise Equipment: Again specific to the Desired Due Date, service providers participating in the discussion whose service offerings include Customer Premise Equipment (CPE) stated that as the New SP in a port, they intend to continue to populate the Desired Due Date on port requests. It is critical that they communicate a Desired Due Date that allows them sufficient time to ship the necessary Customer Premise Equipment (CPE) in order to maintain end user service.
Based on the reasons cited above, all providers participating in the discussion unanimously agreed that the New Provider SPID and Desired Due Date should continue to be necessary data fields on a Local Service Request (LSR). Those providers participating in this discussion at the LNPA WG included:
- Alltel -- AT&T -- AT&T Mobility
- Comcast -- Cox Communications
- Delta 3 -- Embarq -- Level 3
- One Communications -- Qwest
- Sprint Nextel -- T-Mobile
- US Cellular -- Verizon
- Verizon Wireless -- Vonage
The two additional data fields referenced above, the New Service Provider Identification (SPID) and the Desired Due Date, are addressed in this Best Practices document because as NPAC data fields, they are within the purview of the LNPA WG. Should the industry reach consensus on the need for the continued requirement of additional LSR/WPR administrative data fields to affect the porting process, they will be reviewed by the LNPA WG and incorporated into this Best Practice as appropriate.
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 MDNs that are porting out are cleared for the MDN within 24 hours of the switch/HLR disconnect.
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
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 rehomes.
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.
0059 Use of SV 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
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.
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:
- 10-digit telephone number;
- customer account number;
- 5-digit zip code; and
- 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.
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.
0062 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
It is the position of the LNPA WG that the 4 hour Firm Order Confirmation (FOC)/Response interval in response to a Simple Port Local Service Request (LSR) starts when a complete and accurate LSR is received by the Old Network Service Provider or is received by the agent/service bureau/clearing house of the Old Network Service Provider. See Chart 1 and Chart 2 in Section 3.1 of the NANC/LNPA WG's FCC 09-41 Implementation Plan (attached here).
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 62 was reviewed by the North American Numbering Council (NANC) at its February 18, 2010 meeting and endorsed at the request of the LNPA WG.
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 notmeant 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: 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: 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.
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.
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 dayport 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: 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.
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: 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: 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.
0067 Processing Interval for Simple, Non-Simple, Porting Project and Customer Service Records (CSR)
Submitted By Team: LNPA-WG
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). The due date of the first TN ported in an NPA-NXX is no earlier than five (5) Business Days after FOC receipt 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.
| TN QTY on Request |
FOC Return (hrs) |
Port Interval (Bus Days) |
Total port Interval (Bus Days) |
|
|---|---|---|---|---|
| Simple (Chart 1 & 2) | 1 | 4 |
1 or 2 (When requested by New Service Provider) |
2 |
| Simple extended due date | 1 | 24 |
3 (When requested by New Service Provider) |
4 |
| Non simple port |
1-50 (Notes 2,4) |
24 | 3 | 4 |
| Project | 51+ | Negotiated by Involved Service Providers (Note 5) |
Negotiated by Involved Service Providers (Note 5) |
Negotiated by Involved Service Providers (Note 5) |
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.
| QTY OF TNs ON CSR |
CSR RETURN INTERVAL (CLOCK HOURS – Note 1) |
|---|---|
| 1-50 | 24 (Note 3) |
| 51-200 | 48 (Note 3) |
| >200 | 72 (Note 3) |
NOTE: 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 1: Excluding weekends and Old Service Provider Company Holidays
Note 2: 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 3: 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 4: 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 5: 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)
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.
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 15,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.
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:
- Any Working Telephone Number (WTN) associated with the customer’s account,
- A positive indication that the proper authority has been obtained from the customer,
- 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.