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 121

    During transition, it became apparent to iconectiv that there were a number of SPIDs in the NPAC database that were no longer in use. iconectiv has carefully planned a clean-up process for obsolete SPIDs. One way that a SPID is designated as obsolete is that the owner of that SPID definitively indicated to iconectiv that it should not be Onboarded to the iconectiv NPAC. The clean-up process has now begun. A user noticed that two of the deleted SPIDs were still indicated in the Last Alt SPID field. One SPID was in 14 records; one SPID was in 1 record.

    Download the document PIM 121

  • PIM 120

    The Alternate SPID attribute was introduced in NANC 399 in Release 3.3.
    The Last Alternate SPID attribute was then added in NANC 438 in Release 3.3.4.
    During transition, iconectiv noticed that a number of altSPIDs were not or never used in the NPAC database, not in the altSPID or last altSPID fields on Subscription Versions or NPBs.
    iconectiv had solicited Users for their altSPIDs during onboarding. This was done via a separate form to be filled out with their Transition User Agreement (TUA). Because the incumbent did not provide copies of registration forms when service providers requested altSPIDs, iconectiv relied on Users providing feedback. The result was very little feedback from service providers on what altSPIDs they use or requested to be created in the past. After further research, iconectiv noticed that a significant portion of altSPIDs in the regional database are not used/were never used and therefore are candidates to be removed.

    Download the document PIM 120

  • PIM 119

    The NPA-NXX Create will be rejected if the ownership information is not present in the NPAC SMS industry reference data. Service Providers sometimes experience NPA-NXX Create rejections when they attempt to open up the NPA-NXX for portability in the NPAC within industry defined guidelines, but ownership information is not present in the NPAC SMS industry reference data. This causes calls to the help desk and workarounds to get the proper NPA-NXX ownership reference data loaded so the NPA-NXX Create (opens an NPA-NXX for portability) will not fail.

    Download the document PIM 119

  • PIM 118

    During transition, iconectiv was required to outreach to every SPID defined in the NPAC database or assigned to an NPAC user. One discovery was that some SPIDs were either choosing to not onboard or Out of Business. In most cases this was benign with no impact. However, further investigation led iconectiv to see that some of these SPIDs had Active or Pending SVs, LRNS, NPA-NXXs, or NPA-NXX-Xs in the NPAC regional database.

    Download the document PIM 118

  • PIM 117

    One function of the LNPA is to assign SPIDs (NPAC Customer ID) and Names for approved applicants to NPAC. During the transition, iconectiv presented its SPID Naming methodology. No such defined methodology has existed in the past. For future clarification, LNPA TOSC members suggested to have certain specifications regarding the assignment of Names put in place.

    Download the document PIM 117

  • PIM 116

    Over time the Typing of SPIDs was inconsistent manifesting in X SPIDs that were created for use for Associations to receive LSMS downloads. Previously some of these SPIDs were typed as Wireless or Wireline because the Service Provider requesting the SPID was Wireless and Wireline. As time went on, newer SPIDs were Typed correctly utilizing the Non-Carrier Type with a /3 suffix in their Name. It would be beneficial to reset the type on Non-Carrier SPIDs to match the other SPIDs that exist with a /3 suffix (type) to allow for proper alignment and consistency going forward.

    Download the document PIM 116

  • PIM 115

    iconectiv has observed that Audits created with an Activation Time Range are not executing as expected.

    Download the document PIM 115

  • PIM 114

    Based on feedback from SV BDD users in regions where the LNPA has transitioned, there appears to be implementation differences between the Neustar and iconectiv NPAC’s implementation of full SV BDD files.

    Download the document PIM 114

  • PIM 113

    SV modify requests on pending SVs that contain a due date that is identical to and does not modify the due date on the SV in the NPAC DB does not send Attribute Value Change (AVC) notifications to the submitting SP SOA. A Service Provider indicated that the Neustar NPAC does generate AVC notifications in these situations.

    Download the document PIM 113

  • PIM 112

    Based on discussions at the April 4, 2018 NANC (LNPA) Transition Oversite Sub-Committee (TOSC) conference call, there is differences in implementation between the Nuestar and iconeciv NPAC concerning rolling-up SV/Block Broadcasts while LSMSs are in recovery.

    Download the document PIM 112

  • PIM 111

    During SPID Migration processing, a local system had issues in processing the SPID Migration files produced by the iconectiv NPAC. The SPID Migration only involved NPA-NXXs being migrated and the iconectiv NPAC only produced NPA-NXX SIC-SMURF files for the SPID Migration. Local System expected all SPID Migration Files to be produced, even those that were empty.

    Download the document PIM 111

  • PIM 110

    In a typical Software Development process, requirements are explicitly defined and numbered so that such requirements can be developed and fully tested and the traceability to verify that every requirement has been appropriately developed and tested can be tracked. Some NPAC SMS requirements are implicit in that the explicit behavior of the NPAC SMS needs to be inferred from narratives defined in non-FRS NPAC SMS documents, such as in error code descriptions in interface specifications. This can lead to requirement needs not fully being understood and implementation having differences.

    Download the document PIM 110

  • PIM 109

    Based on feedback from current users of the Neustar NPAC, there appears to be a need to utilize Hold – Replay functionality for CMIP mechanized users that is not related to those users transitioning from a CMIP implementation to an XML implementation.

    Download the document PIM 109

  • PIM 108

    Based on feedback from a current user of the Neustar NPAC, there appears to be implementation differences between the Neustar and iconectiv NPAC’s implementation of the XML Hold/Replay functionality. This functionality can be used when a SOA or LSMS SPID transitions from using a CMIP implementation to using an XML implementation or is initially onboarding to an XML interfacing system.

    Download the document PIM 108

  • PIM 107

    An issue was raised in the industry concerning documenting and maintaining the MUMP File spreadsheets. The understanding was that the implementation was vendor specific, and the implementations may be different between the NPAC vendors. The FRS requirements identified a high-level view of the MUMP files and only identified a subset of the fields that can appear in a MUMP File.

    Download the document PIM 107

  • PIM 106

    iconectiv implemented the BDD files based on the NPAC SMS FRS BDD requirements and examples in Appendix E. During certification and regression testing of the iconectiv NPAC vendors and mechanized service providers, no one identified any issues with iconectiv’s BDD implementation. While onboarding non-mechanized BDD file only users, a small set of users identified issues with the content and format of some fields in the SV BDD file as compared to the incumbent NPAC implementation. This particular issue concerns the content of the SSN field in SV and Number Pool Block BDD files. iconectiv would like clarification on the correct behavior for producing BDD files that contain the SSN fields.

    Download the document PIM 106

  • PIM 105

    During iconectiv LNPA transition testing of a local system, issues were discovered that impact the execution and/or verification of an Industry Group Test Case. 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 SIC-SMURF (Selection Input Criteria – SPID Migration Update Request Files) naming convention.

    Download the document PIM 105

  • PIM 104

    Based on feedback from current users of the Neustar NPAC and based on iconectiv’s own experience with BDD files from Neustar, it appears as though full BDD files – though not delta BDD files – may be compressed using gzip. It is not clear whether full BDD files are compressed for all Users. iconectiv requests consensus as to whether all full BDD files produced by the iconectiv NPAC for all Users should be in gzip format.

    Download the document PIM 104

  • PIM 103

    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 extraneous SPIDs in XML messages.

    Download the document PIM 103

  • PIM 102

    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 recovery Active SVs that were modified. The modified SV data recovered was different than the local system was expecting.

    Download the document PIM 102

  • PIM 101

    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 SV Query Response for an Audit. The local system SV Query Response did not match the specifications.

    Download the document PIM 101

  • PIM 100

    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 recovery of Service Provider Relative Distinguished Name (RDN). The RDN did not match specifications.

    Download the document PIM 100

  • PIM 99

    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 an SV Query Response Relative Distinguished Name (RDN). The RDN did not match specifications.

    Download the document PIM 99

  • PIM 98

    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 recovery of Network Data delete transactions. The local system expected optional attributes to be present in the recovered data.

    Download the document PIM 98

  • PIM 97

    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 Modifying the Old SP Authorization by the Old SP. The local system expected different results than were exhibited.

    Download the document PIM 97

  • PIM 96

    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 recovery of Network Data objects. The Local System expected optional attributes in recovery messages.

    Download the document PIM 96

  • PIM 95

    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 Disconnect Requests with Effective Release Date in the Past. Local System expected behavior does not match specifications.

    Download the document PIM 95

  • PIM 94

    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 scoped and filtered queries for SVs including a NOT filter. NOT filters are not required to be supported in the specifications.

    Download the document PIM 94

  • PIM 93

    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 creation of port-to-original (PTO) SVs. The PTO SV create message did not conform to the specifications.

    Download the document PIM 93

  • 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

  • PIM 82

    Due to the automated processing of large quantities of ports, there are occasions (rare, but can happen) that an Old Provider may have auto-issued a FOC and then their downstream systems may discover a legitimate reason the port should stop.  The Old Provider then is allowed by ATIS LSOG order processes, to send a Reject and/or JEP to the New Provider.  It has been determined that some New Providers are not reacting to these subsequent JEP/Reject’s, even though it can be proven those messages did indeed reach the New Provider.  When a New Provider ignores those subsequent messages, this in-effect means the new provider has “taken” a number without a valid LSR still in play.

    Download the document PIM 82

  • PIM 81

    It has come to the attention of Providers that a New Provider is using an NPAC modify message to unilaterally move up the port due date once the T1/T2 timers have been stopped due to both matching SV Creates arriving at NPAC.  This unilateral acceleration of the Due Date (DD) by the New Provider, when not agreed to via a concurred LSR Supplement, is service affecting to the end user and goes against industry practice and the intent of the FCC mandated NANC’s LNP Process Flows, Figure 9, Flow A, Step 3 and Figure 10, Flow AA Step 4, which both state, “No NPAC SV may activate before the SV due date/time.”

    Download the document PIM 81

  • PIM 80

    A significant quantity of ported/pooled NPAC database records currently contain LRNs that are in a different LATA than their associated ported/pooled telephone numbers (TNs).  This is resulting in customer complaints that they are not receiving all of their telephone calls.

    Download the document PIM 80

  • PIM 79

    Item 1.) Url link inside BP36 which says,

            ““NANC Inter-Service Provider LNP Operational Flows” is broken.

    Item 2.) Change title of BP to be “VoIP Porting Obligations.

    Item 3.) Add some helpful VoIP cites to the BP.

    Download the document PIM 79