2015 LNPA Technical Requirements Document
1. TRD OVERVIEW, INTRODUCTION, and FRS Section 1
1.1 STATEMENT:
TRD Introduction and Purpose
Pursuant to the Telecommunications Act of 1996, the Federal Communications Commission (FCC) has adopted a succession of orders implementing Local Number Portability (LNP), whichallows consumers to change service providers for telecommunications services at the same location without changing their telephone numbers.Currently, LNP is enabled in the seven United States former Regional Bell Operating Company (RBOC) service areas or regions, including their related Territories (each a "Region" and collectively, the "Regions") throughseven databases, one in each Region, collectively referred to as the Number Portability Administration Center/Service Management System (NPAC/SMS). Each Regional database is operated and administered by a Local Number Portability Administrator (LNPA), neutral and independent from Telecommunications Carriers. A separate Master Agreement governs the operation and administration of the NPAC/SMS by the LNPAin each of theseven Regions and specifies the terms and conditions for providing NPAC/SMS services (referred to as the "Services").
All Master Agreements in all Regions are managed by the North American Portability Management LLC (NAPM LLC), and all Master Agreements in all Regions expire on June 30, 2015. The FCC has delegated authority to its advisory committee, the North American Numbering Council (NANC), working in consultation with the NAPM LLC, to implement a vendor selection process, for the next-generation NPAC/SMS in all Regions, to commence at the expiration of the current Master Agreements. This vendor selection process includes issuance of a Request For Information (RFI) and a subsequent Request For Proposal (RFP) and will culminate in the selection of the LNPA in each of the seven Regions. The purpose of the NANC is toadvise the Commission and to make recommendations, reached through consensus, that foster efficient and impartial number administration. The NANC, a diverse body with consumer, stategovernment, and industry representatives, has established an LNPA Selection Working Group (SWG) to oversee the selection process of the LNPA. See Order, WC Docket No. 09-109 and CC Docket No. 95-116, DA 11-883, (adopted May 16, 2011) for process information and the respective roles of the FCC, NANC, and NAPM LLC. During this process, options for replacement and/or enhancement of the current NPAC/SMS in all Regions may be considered.
The purpose of the RFP is to provide each prospective RFP vendor (referred to as a Respondent or a Bidder) with an opportunity to demonstrate how its proposal satisfies the requirements of the RFP and will benefit TelecommunicationsCarriers and other qualified parties who will be Users of the NPAC/SMS and who rely upon the NPAC/SMS for the rating, routing, and billing of calls, law enforcement and other parties who may be granted certain limited and special access to NPAC/SMS data for other permissible purposes, and ultimately consumers. Each Respondent is instructed to answer all questions in as concise and complete a manner as possible, and in many instances, the Respondent is provided with an opportunity to elaborate on its answers.
The RFP includesthis Technical Requirements Document (TRD) survey that identifies both the technical requirements describing the requisite technical capability of any proposal and the required obligations of an LNPA to administer the NPAC/SMS(s).Although great care has been taken to ensure the accuracy of the TRD and other reference documents, it is the Respondent's responsibility to ensure that any response to a specific NPAC/SMS technical requirement contained herein is based on the latest NPAC/SMS Functional Requirements Specification (FRS) and other reference documents as currently published and made available to the industry.FRS Rel 3.4.1 (a) was used in creating the TRD FRS sections. Each technical document (FRS, IIS, GDMO, ASN 1.0) has its own glossary, abbreviations, figures and tables.
The Local Number Portability Administration Working Group (LNPA WG) is a public industry forum that determines what technical capabilities are to be implemented in the NPAC/SMS. Information about this subcommittee of the NANC is found at http://www.npac.com. All respondents to the TRD survey are encouraged to attend the LNPA WG, during and after their submission(s).
The NAPM LLC hasauthorized one of its Advisory Committees, the Future of NPAC Subcommittee (hereafter referred to as the FoNPAC), to project manage the RFP process, including the solicitation and evaluation of responses to this TRD surveyand to utilize the Iasta® SmartSource SRM® Tool to gather, evaluate, and weigh all responses to thisTRD surveyas part of the LNPA selection process.The LNPA selection process is expected to conclude on or about March 2013.
Thank you in advance for your participation in the RFP process.
1.2 STATEMENT:
Vendor TRD Response Instructions
As part of responding to this TRD survey, Respondents will be required to respond to each requirement as indicated, as well as answer a series of questions in more detail. The detailed question section is at the end of this TRDsurvey called, "TRD Detailed Response."
· If theRespondentwould like to explain any answers,please do so in the "TRD Detailed Response" section.
· If the Respondent would like tosuggest improvements or additional enhancements,pleasedo so in the "TRD Detailed Response" section.
RFP survey Section 9 on Service Level Requirements supersedes any and all corresponding Service Level Requirementsdocumentedin this TRD survey or in the FRS.
1.3* QUESTION:
Backwards Compatibility Requirement
In responding to the requirements in this TRD, all Respondents submitting bids MUST indicate and highlight any and all areas of functionality in their proposal that will not remain Interface and Functional Backwards Compatible.
Backward Compatibility Definitions
There are three areas of Backwards Compatibility. These are defined below:
· Pure Backwards Compatibility -means that interface specification has NOT been modified and therefore, no recompile is necessary. Also, no behavior on the NPAC/SMS has been modified to provide any change to the previously existing functionality accessible over the interface.
· Interface and Functional Backwards Compatibility -means that the interface may have been modified, however the changes are such that no action is required for the Service Provider to remain backward compatible. However, any new functionality is optionally implemented, and would require a recompile and possibly functional software changes by the Service Provider to access the newly defined features over the interface. Also, no changes may be made to any existing interface functionality that will require modifications to SOA and/or LSMS platforms.
· Re-Compile Only Backwards Compatibility -means that the interface has been modified, however the changes are such that only a recompile is necessary to remain backward compatible. Any new functionality is optionally implemented by accessing the newly defined features over the interface. Also, no NPAC/SMS software changes may be made to any existing interface functionality that will require source code modifications to SOA and/or LSMS platforms.
The objective is that all implementations resulting from this bidding process remain Interface and Functional Backwards Compatible, to the extent possible.
Has the Respondent agreed to this requirement to indicate any and all areas of their responses that WILL NOT remain at least "Interface and Functional Backwards Compatible"? Please answer "YES" or "NO".
(Note: The FoNPAC will assume that all responses include backwards compatibility unless indicated otherwise.)
(no answer)
Yes
No
1.4* QUESTION:
Treatment of SubsequentNANC Change Orders
By submitting a bid to this RFP, Respondent understands and agrees that any NANC Change Orders implemented in the NPAC/SMS subsequent to the submission of their bid, or scheduled for implementation prior to the turn-up of the next-generation NPAC/SMS, MUST be incorporated into their proposed NPAC/SMS platform and ready for implementation at turn-up.
(no answer)
Agree
Disagree
1.5* QUESTION:
TRD FRS Section 1: Introduction
The FRS defines the functional requirements of the NPAC/SMS enabling LNP.
This introductiongivesanoverview of NPAC/SMS functionality. It is intended to preparethe Respondentfor the detailed TRD FRS sections that follow.Consult the applicable detailed sections in the FRSor the NPAC/SMS Interoperable Interface Specification (IIS),Guidelines for the Definition of Managed Objects (GDMO),and Abstract Syntax NotationOne(ASN.1)for more detailed information. www.napmllc.org/pages/NPACRFP/NPACRFP_refdocs.aspx
Has the Respondentread, understood, and incorporated the FRS Section 1 concepts intoRespondent's proposal?
(no answer)
Yes
No
2. TRD FRS Section 2: BUSINESS PROCESS FLOWS
2.1*QUESTION:
TRD FRS Section 2: Business Process Flows
Theprocess flows in Section 2 of the FRS indicate how the NPAC/SMS is used by the Service Providers in business processes associated with LNP. Specific requirements generated by the process flows are included in the appropriate FRS sections.
The process flows supported by the NPAC/SMS are:
1.Service Provisioning
2.Service Disconnection
3.Service Repair
4.Conflict and Conflict Resolution
5.Disaster Recovery and Backup
6.Service Order Cancellation
7.Audit Requests
8.Report Requests
9.Data Administration Requests
Please note the followingare the specific requirements listed in Section 2 of the FRS and are currently outside the scope of the NPAC/SMS:
1.Interactions between Service Providers (CN2-1.1.1)
2.Service Provider network change activities (CN2-1.3.1)
3. ServiceProvider's network change validationactivities (CN2-1.5.1)
4.Service Provider's repairactivities (CN2-3.3.1)
5. Service Provider's conflict resolution activities (CN2.4.2.1)
Has the Respondentread, understood, and incorporated these concepts intoRespondent's proposal?
(no answer)
Yes
No
3. TRD FRS Section 3: NPAC DATA ADMINISTRATION
3.1*QUESTION:
TRD FRS Section 3: NPAC Data Administration
The NPAC/SMS manages the ported TN information associated with Service Provider portability for the LNP service. This section describes the high level requirements associated with managing ported telephone numbers from an operations perspective.
TRD FRS Section 3: Sub Section 3.1:
The required Data Models are described in detail in the FRS document Section 3.1:
3.1.1: Data Type Legend
3.1.2: NPAC Customer Data Model
3.1.3: Subscription Version Data Model
3.1.4: Network Data Model
Does the Respondent's proposal adhere to these exact Data Models and hasRespondentread, understood, and incorporated these concepts intoRespondent's proposal?
(no answer)
Yes
No
3.2*QUESTION:
TRD FRS Section 3: Sub Section 3.2: NPAC Personnel Functionality
The FRS Section 3.2 requirements describe the functionality required by the NPAC/SMS to support the daily operation of the Regional LNP SMS support staff. These requirements define the high level functionality required by the system with the specifics of each requirement defined in more detail in FRS Sections 4 and 5.
Doesthe Respondent'sproposal fully comply with the requirements below in time to meet the published implementation date?
R3-3: Create NPA-NXX data for a Service Provider
R3-6.2: Mass Update Filter Usage
R3-7.2: Administer Mass update on one or more selected Subscription Versions
R3-7.3: Mass Update Selection Criteria
R3-7.4: Mass Update Service Provider Id
R3-7.7: Mass Update Error Processing
R3-7.8: Mass Update Exception Report
RR3-254: Validation of LATA ID Errors on Mass Updates
R3-7.9: Mass Update Required Entry of Service Provider ID
R3-13: NPAC/SMS mass change update capability to the Local SMS
RR3-254: Validation of LATA ID Errors on Mass Updates
RR3-550: Mass Update Pending and Active Subscription Versions – DPC-SSN Field-level Data Validation
RR3-551: Mass Update Pending and Active Subscription Versions – Validation of DPC-SSNs for Mass Update
RR3-552: Mass Update Pending and Active Number Pool Blocks – DPC-SSN Field-level Data Validation
RR3-552.5: Mass Update Pending and Active Number Pool Blocks – Validation of DPC-SSNs for Mass Update
RR3-708: Mass Update - Notifications for Pseudo-LRN Updates
(no answer)
Yes
No
3.2.1*QUESTION:
TRD FRS Section 3: Sub Section 3.2.1: Block Holder, Mass Update
TheFRS Section 3.2.1 requirementsdescribe the functionality required by the NPAC/SMS to support Block Holder Mass Updates.
Doesthe Respondent'sproposal fully comply with the requirements below in time to meet the published implementation date?
RR3-210: Block Holder Information Mass Update – Update Fields
RR3-211: Block Holder Information Mass Update – Block Intersection Rejection
RR3-212: Block Holder Information Mass Update – Block Status Validation
RR3-213: Block Holder Information Mass Update – Download to EDR Local SMS
RR3-214: Block Holder Information Mass Update – Download to non-EDR Local SMS
RR3-215: Block Holder Information Mass Update – Download of SVs of Type POOL to non-EDR Local SMS
(no answer)
Yes
No
3.2.2 STATEMENT:
TRD FRS Section 3: Sub Section 3.2.2: Service Provider ID (SPID) Migration Update
This FRS section defines how the NPAC/SMS supports modification of Service Provider ID on Local Number Portability information. Two options are available, 1.) an on-line self-service feature is available using the LTI that can be used by Service Provider Personnel optionally in lieu of spreadsheets submitted via e-mail to NPAC Personnel, and 2.) an interface message enhancement allows NPA-NXX ownership changes to be sent via a CMIP message. NPAC Personnel generate Selection Input Criteria SPID Migration Update Request Files (SIC-SMURF) to all Service Providers (as a primary means of update by those that do not support the interface message to update their databases, and as a backup means of update for those that do support the interface message). Additionally, SIC-SMURFs are used even by Service Providers that support the interface message when the migration involves NPA-NXX-Xs and/or LRNs. SIC-SMURFs are placed in all Service Providers' Secure FTP sites at the beginning of a maintenance window; updates are performed independently off-line during the maintenance window by each Service Provider to its own databases.
3.2.2.1* QUESTION:
TRD FRS Section 3: Sub Section 3.2.2.1: SPID Migration Updates and Processing
With functionality in NANC 323, SIC-SMURFs are generated by NPAC Personnel and distributed (via Secure FTP) to all Service Providers. SPID Migrations may be performed as defined in sections 3.2.2.2 and 3.2.2.3.
Doesthe Respondent'sproposal fully comply with the requirements below in time to meet the published implementation date?
RR3-255: SPID Migration Update - OpGUI Entry
RR3-256: SPID Migration Update - Generation of SIC-SMURF Files
RR3-257: SPID Migration Update - NPAC/SMS Processing of Requested Data
RR3-258: SPID Migration Update - Suppression of Notifications
RR3-259: SPID Migration Update - NPAC/SMS Processing of Requested Data Based on Status
RR3-260: SPID Migration Update - SIC-SMURF File Names
RR3-261: SPID Migration Update - SIC-SMURF File Formats
RR3-262: SPID Migration Update - SIC-SMURF NPA-NXX File Processing - Update NPA-NXX Network Data
RR3-709: SPID Migration Update - SIC-SMURF NPA-NXX File Processing - Update SV Data for Pseudo-LRN Records
RR3-710: SPID Migration Update - SIC-SMURF NPA-NXX File Processing - Update Block Data for Pseudo-LRN Records
RR3-264: SPID Migration Update - SIC-SMURF LRN File Processing - Update LRN Data
RR3-265: SPID Migration Update - SIC-SMURF LRN File Processing - Update Block Data
RR3-266: SPID Migration Update - SIC-SMURF-LRN File Processing - Update SV Data
RR3-267: SPID Migration Update - SIC-SMURF NPA-NXX-X File Processing - Update NPA-NXX-X
RR3-268: SPID Migration Update - Maximum Level of Granularity
RR3-269: SPID Migration Update - Minimum Level of Granularity
RR3-274: SPID Migration Update - Exclusion of Data During Recovery
RR3-275: SPID Migration Update - Rejection for 'pending-like' Number Pool Blocks or Subscription Versions
RR3-276: Update SPID on Messages Queued for Recovery
RR3-277: SPID Migration Update - Consistency Check Across Network Data and LRN