Print
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Notice:
Effective August 1, 2017 the role of Change Management Administrator (CMA) of the Local Number Portability Administration Working Group (LNPAWG) for all US Regions was transferred to Telcordia Technologies, Inc., d/b/a iconectiv.
To contact the iconectiv CMA or to be added/removed from the LNPAWG distribution list please email cma@iconectiv.numberportability.com.
Please note that on or about September 30, 2017 the collection and history of industry documents will be transferred to https://numberportability.com/. Stay tuned for further updates at upcoming LNPAWG meetings and conference calls.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Problems and Issues Management
In late 1999, the LNPA WG established a "problem identification and management process" (PIM) for LNP issues. The LNPA WG is not responsible for resolving all LNP problems. The LNPA WG does an initial evaluation of each LNP problem submitted, then either develops a resolution for the issue or refers the issue to the appropriate forum for resolution. The status of each LNP issue submitted is reported to the NANC on a regular basis.
The LNPA WG has developed issue submittal guidelines, an issue submittal form, process flows, and a tracking mechanism. Issues should be submitted to the LNPA WG, using the issue submittal form, at least two weeks before the LNPA WG meeting at which LNP issue's discussion is desired.
-
PIM 92
During iconectiv LNPA transition testing of a local system, issues were discovered that impacts the execution and/or verification of an Industry Test Case (ITC) required for certification. These issues relate to a nonconformance to Industry Specification(s), an undocumented capability or feature, or a difference of interpretation (between LNPAs) of an Industry Specification. The specific issue herein needing resolution concerns the Optional Data XML string not in certain messages. The XML string does not conform to the XSD specification.
Download the document PIM 92
-
PIM 91
During iconectiv LNPA transition testing of a local system, issues were discovered that impacts the execution and/or verification of an Industry Test Case (ITC) required for certification. These issues relate to a nonconformance to Industry Specification(s), an undocumented capability or feature, or a difference of interpretation (between LNPAs) of an Industry Specification. The specific issue herein needing resolution concerns the Completion Timestamp in the SWIM Processing Results notification. The Completion Timestamp field does not conform to the industry specification.
Download the document PIM 91
-
PIM 90
During iconectiv LNPA transition testing of a local system, issues were discovered that impacts the execution and/or verification of an Industry Test Case (ITC) required for certification. These issues relate to a nonconformance to Industry Specification(s), an undocumented capability or feature, or a difference of interpretation (between LNPAs) of an Industry Specification. The specific issue herein needing resolution the Synchronous field in messages. The Synchronous field does not conform to the industry specification.
Download the document PIM 90
-
PIM 89
During iconectiv LNPA transition testing of a local system, issues were discovered that impacts the execution and/or verification of an Industry Test Case (ITC) required for certification. These issues relate to a nonconformance to Industry Specification(s), an undocumented capability or feature, or a difference of interpretation (between LNPAs) of an Industry Specification. The specific issue herein needing resolution concerns the user ID field in the access control structure of messages. The user ID field does not conform to the industry specification.
Download the document PIM 89
-
PIM 88
Some Service Providers do not have a contact number to assist with porting fallout questions. Instead, the carriers rely on e-mail. There are not any documented guidelines around using email for porting fallout such as timing of the response and an escalation path if a response is not received via e-mail.
Download the document PIM 88
-
PIM 87
LNPA WG Best Practices reflect the consensus of the working group regarding the preferred processes for porting. Best Practice 0004, N-1 Carrier Methodology Clarification, was originally submitted by the working group in December 2001. The most current version 5.0 was a result of revisiting the practice in January 2005.
The best practice states that the N-1 carrier is responsible for performing the dip and describes the role of a “donor carrier” in certain situations. To clarify the meaning of this term, the LNPA WG confirms the donor carrier is the A-Block Code Holder designated in the LERG for the NPA-NXX of the called number (default carrier for routing calls based on the NPA-NXX of the called number).
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.
Bright House believes BP4 requires additional detail and edits as it relates to donor carrier.
Download the document PIM 87
-
PIM 86
Originally submitted as per below, seeking consensus to amend the scope of this PIM to address overall challenges related to claims of an unauthorized port in order to develop one cohesive PIM and resulting Best Practice (“BP”).
Currently there are a variety of PIMs and BPs covering such things as, (including but not limited to) “Inadvertent Ports”, “Disputed Ports”, “Fraudulent Vanity Number Ports”, “Unauthorized Ports”, etc. All of which are in part or whole addressed in a variety of PIMs and/or BPs, (including but not limited to, PIM 53, BP 42, and BP 58) which have been developed over a broad time frame. Some of these areas, definitions, practices, etc., overlap, have opportunities for refinement especially in light of newer technologies and systems, and/or are scattered across the various resources. Because of this there is a need to bring together all the information related to this overall topic/issue in order to replace the existing various PIMs/BP with one all inclusive updated cohesive PIM/BP.
Original Submission:
In the event of a claim of a disputed port, for any reason, there are:
1. No existing clear guidelines around how providers will work together to research and resolve the claim of a disputed port.
2. Based on the outcome of the research, there is an opportunity for clearer broad recommendations around the circumstances under which a number will be released back to the then losing provider (or “OSP”).For the purposes of this PIM, the term “disputed” shall mean any port which for whatever reason resulted in the OSP receiving a report from their customer and/or end user and/or another service provider that the port-out was in error; this is regardless if the OSP provided FOC or otherwise was not aware of an issue with the port prior to its completion.
In the end, although the losing carrier may not necessarily agree with the veracity of a given port, they should feel confident they verified to the fullest extent possible and can defend the position of the winning provider (or “NSP”) to their claiming customer and/or end user.
It should be noted that while pre-FOC validations afford a level of prevention, there are multiple factors which negate the full utility (including, but not limited, to an increasing amount of identity theft, and CSR validation which provides an avenue chance for an individual to learn the account information required to port).
Many providers may not view these instances as immediately impacting to their customers’ continuity of service at present. However, the FCC’s movement toward opening numbering authority to non-CLEC/LEC entities creates a forward-looking reality of an increase in LNP participants that could quickly make the disputed port landscape more complicated if a best practice does not already exist.
Download the document PIM 86
-
PIM 85
Consumers are experiencing negative porting experiences as a result of the lack of uniformity and clarity in processes that drives port completion timeframes. We are allowing resellers to validate on any field at whim and this is causing significant impacts to the porting process. We need uniformity in the resellers porting requirements, we need set guidelines surrounding wireless reseller port out validation requirements and we feel a best practice is the place to start.
Download the document PIM 85
-
PIM 84
There is not an industry defined process interval for Wireless to Wireline and Wireless to Wireless reseller ports. Reseller ports are not considered simple ports, they are complex. There is not any documentation to date around expectations of the timing of a port out response when the losing service provider is a reseller. In other words, how long does a reseller have to respond to a wireless port out or an intermodal port out request?
Download the document PIM 84
-
PIM 83
Initially, a request was made by a number of Service Providers in the LNPA Working Group for Neustar to create a report that reflects all wireless Service Providers that have Long T1 and T2 Timers set in their NPAC SP Profiles.
At the November 2014 LNPA WG meeting, this PIM 0083 was accepted for further discussion. During the discussion, Service Providers requested that the report be expanded to include additional information as outlined below in Section 2.
Download the document PIM 83