NYCAC\
Number Portability Administration Center and Service Management System\
Request For Proposal

(NYCAC NPAC/SMS RFP)

TABLE OF CONTENTS

1\. GENERAL INFORMATION

1.1 Introduction

1.2 Description of LNP Environment

1.3 Eligibility to Submit Proposals

1.4 Preparation of Responses

1.5 Additional Contractual Terms and Conditions

1.6 Evaluation of Proposals

2\. BUSINESS PROCESS FLOWS

2.1 Provision Service Process

2.2 Disconnect Process

2.3 Repair Service

2.4 Conflict Resolution Process

2.5 Disaster Recovery and Backup Process

3\. NPAC DATA ADMINISTRATION

3.1 Overview

3.2 NPAC Personnel Functionality

3.3 System Functionality

4\. SERVICE PROVIDER DATA ADMINISTRATION

4.1 Service Provider Data Administration and Management

5\. SUBSCRIPTION ADMINISTRATION

5.1 Subscription Administration and Management

6\. NPAC SMS Interfaces

6.1 SOA to NPAC SMS Interface

6.2 NPAC SMS to Local SMS Interface

6.3 Interface Transactions

6.4 Interface and Protocol Requirements

7\. SECURITY REQUIREMENTS

7.1 Identification

7.2 Authentication

7.3 Access Control

7.4 Data and System Integrity

7.5 Audit

7.6 Continuity of Service

7.7 Software Vendor

7.8 OSI Security Environment

8\. AUDIT ADMINISTRATION

8.1 Service Provider Verify of Data in NPAC SMS

8.2 Periodic Audits

8.3 NPAC SMS Verify of Data in Local SMS

9\. REPORT MANAGEMENT

9.1 Overview

9.2 User Functionality

9.3 System Functionality

10\. NPAC SMS Reliability, Availability, performance and capacity

10.1 Availability and Reliability

10.2 Capacity and Performance

11\. BILLING / RESOURCE ACCOUNTING

11.1 Overview

11.2 Assumptions

11.3 User Functionality

11.4 System Functionality

12\. NUMBER PORTABILITY ADMINISTRATION CENTER

12.1 Number Portability Administration Center (NPAC)

12.2 Logon Administration

12.3 Customer Record Security

12.4 Scheduled System Unavailability Notification

12.5 Software Release Acceptance Testing

12.6 Service Administration

12.7 Mass Change Administration

12.8 User Support Group

12.9 System Support Group

12.10 NPAC Organizational Interface Requirements

12.11 NPAC SMS Data Center

12.12 Administration

12.13 Facilities Requirements

12.14 Telecommunications Requirements

12.15 Staffing

12.16 Service Objectives

13\. FUTURE CONSIDERATIONS

14\. GLOSSARY

15\. ACRONYMS

16\. ATTACHMENTS

Section 1: General Information

1.1. Introduction

1.1.1. Purpose of This Request For Proposal (RFP)

> The purpose of this Request For Proposal (RFP) is for the New York
> Carrier Acquisition Company LLC (NYCAC) to invite Primary Vendor
> participation in submitting a complete "turnkey" database solution,
> related firm pricing proposal and commitment to provide a Number
> Portability Administration Center (NPAC) and Service Management System
> (SMS). The NYCAC was formed by the participating carrier members of
> the NY Commission's Local Number Portability Consortium in order to
> manage the database Local Number Portability procurement in accordance
> with this RFP. The NPAC/SMS will support the statewide implementation
> of Local Number Portability in New York.
>
> ***SIGNIFICANTLY, NYCAC's DECISION IN ISSUING THIS RFP DOES NOT MEAN
> THAT NEW YORK IS OPTING OUT OF ITS NANC-DESIGNATED REGIONAL DATABASE.
> THIS \"OPT-OUT\" DECISION RESTS WITH THE NY PUBLIC SERVICE COMMISSION
> AND FCC (SEE FCC ORDER AT PARAGRAPH 96). NYCAC BELIEVES THAT THE
> IMPORTANT PRE-QUALIFICATION ROUND CAN BEGIN NOW. OUR PROGRESS IN
> RESOLVING \"STATE VERSUS REGION\" ISSUES, AND OTHER ISSUES AS THEY
> ARISE WILL BE PERIODICALLY COMMUNICATED TO YOU AS SUPPLEMENTS TO THIS
> RFP.***
>
> Primary Vendor responses must be based upon the specifications
> provided in this RFP and should contain detailed information on degree
> of compliance with requirements, pricing and availability, as
> specified herein.
>
> The Evaluation/Procurement Team, is made up of one voting
> representative from each of the following telecommunications carriers,
> electing to participate as members in good standing in the NYCAC
> ([i.e]{.underline}., RTC, NYNEX, TW, TCG, AT&T, MCI, MFS, and
> Cablevision). The NYCAC's Evaluation/Procurement Team will also
> solicit the counsel of the New York Staff, and any other
> industry/company experts to facilitate this Evaluation and procurement
> (including but not limited to risk management expertise, legal,
> procurement, and/or relevant matters of a technical nature). NYCAC's
> Evaluation/ Procurement Team will evaluate all proposals from a total
> network and operations perspective to verify integration with existing
> network and operating procedures. Proposals will also be assessed on
> their ability to evolve, as necessary, from serving a limited
> geographic area into a regional and/or nationwide service, with
> minimal obsolescence of existing investment (See, Section 1.6.
> Evaluation of Proposals).
>
> 1.1.2. Primary Vendor's Information
>
> Do not submit any proprietary or confidential information or mark any
> as such. Information furnished by you to the Evaluation/Procurement
> Team pursuant to this RFP shall not be considered by you to be
> confidential or proprietary. In no event will the
> Evaluation/Procurement Team consider or hold any information contained
> in your proposal proprietary or confidential, except for the pricing
> information specified in Section 1.4.3.1.

1.1.3. Impact of State and Federal Regulation and/or Legislation on this
Procurement

> This RFP is being issued by a Limited Liability Company (the NYCAC), a
> group of service providers who currently provide or intend to provide
> facilities-based local exchange services in the state of New York
> through the porting of local telephone numbers. LNP implementation is
> subject to direct regulatory oversight by the State of New York Public
> Service Commission.
>
> Moreover, it is the express and stated intent of the NYCAC to: (1)
> comply with any order or other directive concerning local number
> portability issued by the New York Commission or the Federal
> Communications Commission, including, but not limited to, any
> directive to expand, reduce, merge, consolidate, dissolve and
> terminate, or otherwise modify this RFP; and/or (2) supervise and
> oversee the Primary Vendor and any Sub-contractor or vendor to ensure
> compliance with any such order or other legal/regulatory directive.

**1.2. Description of LNP Environment**

> 1.2.1. Functions of the Service Management System/SMS
>
> The Service Management System is a hardware and software platform
> which contains the database of information required to effect the
> porting of telephone numbers in New York. In general, the SMS receives
> information from both the old (confirmation) and new service providers
> (customer information, including the new Location Routing Number),
> validates the information received, and downloads the new routing
> information when an "activate" message is received indicating that the
> customer has been physically connected to the new service provider's
> network. The SMS also contains a record of all ported numbers and a
> history file of all transactions relating to the porting of a number.
> The SMS shall also provide audit functionality and the ability to
> retransmit LNP information to service providers under certain
> conditions. The SMS is not involved in real time call processing,
> because this function resides solely in the respective networks of the
> underlying carriers.
>
> 1.2.2. Management and Integration Role of Primary Vendor's Number
> Portability Administration Center/NPAC Function
>
> The NPAC shall provide management, administration, oversight for, and
> integration of, the data center operations, hardware and software
> development, and all maintenance related functions. It shall have
> responsibility for achieving the highest performance standards
> established by the industry and for providing user and technical
> support services and training for industry participants on an ongoing
> day-to-day basis.

**1.3. Eligibility to Submit Proposals**

> 1.3.1. Pre-Qualification of Primary Vendor Bidders
>
> A. Upon release of the RFP, the NYCAC's Evaluation/Procurement Team
> requests that Primary Vendors that plan to bid on the RFP present
> information to the NYCAC concerning: 1) Financial responsibility and
> stability (capability to perform the contract); 2) Experience relevant
> to performance of the contract; 3) Neutrality (address the vendor's
> compliance with the requirement that the system administrator (Primary
> Vendor) be a neutral third party, and disclose the identity and
> corporate affiliation of software and hardware Sub-Contractor(s), if
> any; disclose any contractual relationships, arrangements or other
> factors that would enhance or impair its ability to perform the
> administrative (Primary Vendor) function as a neutral third party, 4)
> indicate Primary Vendor's acceptance and compliance with the key
> business terms and conditions specified below in Section 1.3.2., and
> (5) indicate its commitment and ability to adopt and comply with the
> RFP's delivery schedule included in cover letter to this RFP.
>
> 1.3.1.1. Financial Responsibility (capability to perform the contract)
>
> RFP Pre-Qualification Applications must include a concise description
> of the financial condition of the Primary Vendor and Sub-Contractors,
> if any. Submissions must include the most recent audited financial
> statements and annual report for the previous three years of the
> Primary Vendor and Sub-Contractors, if any. Submissions must include
> all characteristics of Primary Vendors financial strength to
> demonstrate support that it can perform under a multi-year business
> contract expected to be awarded under this RFP.
>
> 1.3.1.2. Experience Relevant to Performance of the Contract
>
> RFP Pre-Qualification Applications must include a concise description
> of the telecommunications experience of the Primary Vendor and
> Sub-Contractors, if any, including such items as products and services
> offered, customers served, successful performance of the
> functional/technical skills required by this RFP on activities
> performed for other customers, and customer benefits that resulted
> from such successful performance.
>
> 1.3.1.3. Neutrality
>
> RFP Pre-Qualification Applications must include a concise description
> of the principal business of the Primary Vendor and Sub-Contractors,
> if any, including such items as company background, characteristics of
> business strength, accomplishments and capabilities which demonstrate
> a strong foundation for managing and operating the NPAC. The Primary
> Vendor must also demonstrate an understanding and willingness to
> implement policies and procedures that will ensure evenhanded
> treatment of all carriers, and certification that the Primary Vendor
> and Sub-Contractor(s), if any, shall comply with the neutrality
> provisions of Section 1.3.4. of this RFP, ***AT ALL TIMES***.
>
> 1.3.2. Primary Vendor's Acceptance Of Key Business Terms And
> Conditions
>
> Each Primary Vendor submitting a Pre-Qualification application to
> NYCAC must list the following key business terms and conditions and
> indicate its acceptance of these key business terms and conditions, as
> a pre-condition to being considered for a contract award as a Primary
> Vendor, by placing an "X" in the space next to each item listed. These
> terms and conditions are expected to form a part of the Master and
> Service Agreements to be executed with the Primary Vendor selected
> under this RFP, if any, and may not represent a full and complete
> listing of all contractual terms and conditions incorporated into
> those agreements.

**A. KEY BUSINESS TERMS AND CONDITIONS ACCEPTED BY PRIMARY VENDORS**

> 1\. \_\_\_\_\_ The NYCAC shall have the right to terminate the Master
> Agreement entered into through this RFP with the Primary Vendor for
> reasons of default (including, but not limited to, unauthorized
> assignment of Agreement and failure to provide adequate service), upon
> 30 days notice. Also, the Primary Vendor is forbidden from making any
> unilateral changes to the Master or Service Contracts entered into
> upon award of this RFP.
>
> 2\. \_\_\_\_\_ The NYCAC shall be granted appropriate license rights
> in and to any technology or other intellectual property that is
> developed for and at the request of the NYCAC for the purposes of
> providing the Services; and Primary Vendor and Sub-Contractor(s), if
> any, shall agree to appropriate limitations on their use of any such
> technology or other intellectual property for purposes other than the
> express provision of the Services specified in this RFP.
>
> 3\. \_\_\_\_\_ The Primary Vendor and Sub-Contractor(s), if any, shall
> deposit all technology and other intellectual property and related
> documentation under its control, that is necessary to the provision of
> these Services, with a mutually agreeable escrow agent for the use of
> the NYCAC, or to allow another vendor the ability to provide Services,
> in the event of Supplier default (e.g., bankruptcy, failure to
> perform, etc.).
>
> 4\. \_\_\_\_\_ The Primary Vendor and Sub-Contractor(s), if any,
> agrees to indemnify and hold harmless the NYCAC, its Members and their
> parents, subsidiaries, other affiliates, their direct and indirect
> customers, and the officers, directors, employees, successors, agents,
> representatives, successors and assigns of any and all of them (all
> hereinafter referred to in this clause as the \"NYCAC\") from and
> against any and all claims, losses, damages, expenses, liabilities,
> suits, demands, causes of action, including costs and reasonable
> attorney\'s fees, or liens that arise out of or result from:
>
> \(i\) Injury or death to persons, or loss or damage to any and all
> property, including theft, in any way arising directly or indirectly
> out of, or occasioned by, caused or alleged to have been caused by, or
> on account of, the performance of the Work or Services performed by
> Primary Vendor, or Sub-contractor(s), if any, or its agents, or any
> director, officer, employee, agent or representative under this
> Agreement,
>
> \(ii\) Assertions under Workers\' Compensation or similar acts made by
> persons furnished by Primary Vendor, or Sub-Contractor(s), if any, or
> by reason of any injuries to such persons for which the NYCAC would be
> responsible under Workers\' Compensation or similar acts if the
> persons were employed by the NYCAC,
>
> \(iii\) Any failure on the part of Primary Vendor, or
> Sub-Contractor(s), if any, to satisfy all claims for labor, equipment,
> materials and other obligations relating to the performance of the
> Work hereunder, and;
>
> \(iv\) Any failure by Primary Vendor, or Sub-Contractor(s), if any, to
> perform its obligations under this clause, the Insurance clause, or
> any clause in the Agreement.
>
> Each party shall defend or settle, at its own expense, any action or
> suit against the other for which it is responsible hereunder and shall
> reimburse the other for reasonable attorneys\' fees, interest, costs
> of suit and all other expenses incurred by the other in connection
> therewith. Each party shall notify the other promptly of any claim for
> which the other is responsible hereunder, and shall cooperate with the
> other in every reasonable way to facilitate the defense of any such
> claim.
>
> 5\. \_\_\_\_\_ The Primary Vendor and Sub-Contractor(s), if any, shall
> at the NYCAC's request, to obtain a bid and/or performance bond in an
> amount sufficient to guarantee performance of its obligation under
> this RFP.
>
> 6\. \_\_\_\_\_ The Primary Vendor and Sub-Contractor(s), if any, shall
> treat all information obtained from the NYCAC or its Members as
> confidential and proprietary unless they can demonstrate that such
> information was previously known by the Supplier(s) without an
> obligation of confidentiality.
>
> 7\. \_\_\_\_\_ No information furnished by the Primary Vendor or
> Sub-Contractor(s), if any, in response to this RFP or under any
> Contractual Agreement arising out of this RFP shall be considered
> confidential or proprietary, except the Tab 3, Cost and Price
> information described in Section 1.4.3.1.
>
> 8\. \_\_\_\_\_ The Primary Vendor and Sub-Contractor(s), if any, shall
> indemnify the NYCAC and its members against any infringement claims
> arising from the provision of Services under this RFP.
>
> 9\. \_\_\_\_\_ During the term of this Agreement, the Primary Vendor
> and Sub-Contractor(s), if any, shall obtain and maintain, with
> financially reputable insurers ([i.e.]{.underline}, carriers with an
> A.M. Best rating of B+:VII, or better) which are licensed to do
> business in all jurisdictions where any work is performed and which
> are reasonably acceptable to NYCAC, not less than the following levels
> of insurance coverage:
>
> a.) [Worker's Compensation]{.underline} as provided for under any
> worker's compensation or similar law in any jurisdiction where any
> work is performed, with an Employer's liability limit of not less than
> \$500,000 per accident or disease;.
>
> b.) [Commercial General Liability]{.underline}, including coverage for
> Contractual Liability and Products/Completed Operations Liability,
> with a limit of not less than \$1,000,000 combined single limit per
> occurrence for bodily injury, property damage and personal injury
> liability (with contractual exclusion deleted), naming NYCAC, its
> members, their directors, officers, employees, agents and/or
> representatives as additional insureds;
>
> c.) [Business Auto]{.underline} insurance covering the ownership,
> maintenance or use of any owned, non-owned or hired automobiles with a
> limit of not less than \$1,000,000 combined single limit per accident
> for bodily injury and property damage liability, naming NYCAC, its
> members, their directors, officers, employees, agents and/or
> representatives as additional insureds;
>
> d.) [Umbrella/Excess]{.underline} liability with limits of not less
> than \$9,000,000 combined single limit in excess of the
> above-referenced Employer's Liability, Commercial General Liability
> and Business Auto liability coverage naming NYCAC, its members, their
> directors, officers, employees, agents and/or representatives as
> additional insureds;
>
> e.) ["All Risk" Property]{.underline} insurance covering not less than
> the full replacement cost of Primary Vendor's and any
> Sub-Contractor(s), if any, personal property at risk due to this
> Agreement; and,
>
> f.) Errors and Omissions Insurance in the amount of at least
> \$1,000,000 per claim with an annual aggregate of at least \$3,000,000
> inclusive of legal defense costs.
>
> [Waiver of Subrogation]{.underline}: Primary Vendor shall look first
> to any insurance in its favor before making any claim against NYCAC,
> its members, their directors, officers, employees, agents and/or
> representatives for recovery resulting from injury to any person
> (including Primary Vendor's or Sub-Contractor's employees, if any) or
> damage to any property arising from any cause, regardless of
> negligence, and does hereby release and waive to the fullest extent
> permitted by law, and shall cause its insurers to waive, all rights of
> recovery against NYCAC, its members, their directors, officers,
> employees, agents and/or representatives.
>
> [Certificates of Insurance]{.underline}: Primary Vendor and
> Sub-Contractors, if any, must, as a material condition of this
> Agreement, prior to the commencement of any work and prior to the
> renewal thereof, deliver to NYCAC a certificate of Insurance,
> satisfactory in form and content to NYCAC, evidencing that the above
> insurance is in force and contains a provision that it will not be
> canceled or materially altered without first giving NYCAC thirty (30)
> days prior written notice and that all coverage is primary to any
> insurance carried by NYCAC or its members.
>
> Nothing contained in this section shall limit Primary Vendor or
> Sub-Contractor's, if any, liability to NYCAC or its members to the
> limits of insurance coverage certified or actually carried.
>
> 10.) \_\_\_\_\_ The Primary Vendor shall submit a list of
> Sub-Contractor(s), if any, to the NYCAC with its Pre-Qualification
> submission, for review and approval. Any subsequent change in the use
> of any Sub-Contractor(s) shall require the review and approval of the
> NYCAC.
>
> 11.) \_\_\_\_\_ The Primary Vendor and Sub-Contractor(s), if any,
> shall not have the right to assignment of the Contractual Agreement
> entered into through this RFP without the prior approval of the NYCAC.
>
> 12.) \_\_\_\_\_ The governing law and forum under this RFP and any
> Contractual Agreement entered into through this RFP shall be that of
> the state of New York, exclusive of conflict of laws provisions.
>
> 13.) \_\_\_\_\_ In the event that the Service does not pass a mutually
> agreed upon Acceptance Plan, designed to determine the Primary
> Vendor's system compliance with the functional and technical
> requirements of this RFP, the NYCAC shall have the option to terminate
> the arrangement without any penalties whatsoever to it or its member
> carriers.
>
> B. The NYCAC's Evaluation/Procurement Team will evaluate the
> Pre-Qualification submissions and vote to consider or reject each
> submission based upon financial responsibility, relevant experience,
> neutrality, acceptance of key business terms and conditions, and
> acceptance/compliance with the delivery schedule (See, Section 1.6,
> Evaluation/Procurement of Proposals).
>
> C. The NYCAC will notify Primary Vendors concerning whether their
> submission was considered or rejected, and identify why a submission
> was rejected, if the reason is neutrality. Unsuccessful proposals (on
> the basis of neutrality as defined in Section 1.3.4. following) may be
> revised and submitted again, within a period of time as specified by
> the NYCAC, in its notice to the Primary Vendor. This method will allow
> the NYCAC to address potentially problematic neutrality issues, and
> allow vendors to correct them, before the time and expense of a full
> response to the RFP is undertaken. Further, it will allow members of
> the NYCAC to be assured that any of the actual bidders of the RFP will
> be neutral, financially responsible, qualified, and experienced.
>
> 1.3.3. Primary Vendor
>
> The NPAC/SMS Master Contract and Service Agreements expected to be
> awarded under this RFP will be awarded to a single Primary Vendor who
> shall be completely and totally responsible for providing a total
> "turnkey" solution encompassing the NPAC functionality and the SMS
> platform (both hardware and software). The Primary Vendor shall be
> responsible for all NPAC administration duties and system
> performance/adherence in accordance with the requirements of this RFP
> and the expectations of the NYCAC. The Primary Vendor shall be the
> single point of contact between the NYCAC and the NPAC/SMS Vendor(s).
> The Primary Vendor shall be required to submit a comprehensive bid
> response to provide all elements of the solution. At its option, the
> Primary Vendor may use its own resources exclusively or engage the
> services of Sub-Contractors to provide one or more elements of the SMS
> platform ([i.e.]{.underline}, hardware, software, etc.), or other
> elements of the total "turnkey" solution. However, all such
> arrangements and/or affiliations entered into by the Primary Vendor to
> provide the total NPAC/SMS solution must be clearly described in the
> Primary Vendor's Pre-Qualification Application Submission (Section
> 1.4.1.), and subsequently, in the Pre-Qualified Primary Vendor's bid
> response.
>
> 1.3.4. Eligibility to bid on the RFP (Neutrality)
>
> A. In order to prevent a conflict of interest, the Primary
> Vendor/System Administrator must be a neutral third party that has no
> financial or market interest in providing local exchange services
> within the United States.
>
> B. To prevent such a conflict of interest, the Primary Vendor/ System
> Administrator \"NPAC\" function ***[will not]{.underline}*** be
> awarded to:
>
> 1.) any entity with a ***direct material financial interest*** in the
> ***United States portion*** of the North American Numbering Plan
> (NANP), and number assignments pursuant to the Plan, including (but
> not limited to) telecommunications carriers;
>
> 2.) any entity with a ***direct material financial interest*** in
> manufacturing telecommunications network switching equipment or
> transmission equipment;
>
> 3.) any entity affiliated in other than a deminimus way in any entity
> described in 1.) or 2.) above, and;
>
> 4.) any entity involved in a contractual relationship or other
> arrangement that would impair the entity's ability to administer
> numbers fairly under the NANP and in accordance with the procedural
> delivery schedule established by the NYCAC (refer to the cover
> letter).
>
> C. The technical requirements for SMS hardware and software will be
> defined in this RFP. It is less likely that the fulfillment of these
> technical design criteria could result in an unfair advantage for
> carriers that use the number portability system. Therefore, it is
> possible for a company that is precluded from being a Primary
> Vendor/Systems Administrator to act as an SMS Sub-Contractor
> (hardware/software provider) to a neutral third party Primary Vendor,
> in responding to this RFP.
>
> D. A Primary Vendor's response to this RFP must fully disclose the
> corporate identity or affiliation of its vendor Sub-Contractor(s), if
> any. ***Failure to adequately do so will be a basis on which to
> disqualify the Primary Vendor's response.***
>
> 1.3.5. Sub-Contractors
>
> Responses to this RFP shall clearly state the roles and
> responsibilities of any and all Sub-Contractors which are providing
> parts of the total "turnkey" solution under the direction of the
> Primary Vendor.

**1.4. Preparation of Primary Vendor's Response to this RFP**

> 1.4.1. Pre-Qualification Application Submission
>
> All Primary Vendor's wishing to submit proposals in response to this
> RFP, complete in every respect, must first submit their
> Pre-Qualification Application to the members of the NYCAC's RFP
> Evaluation/Procurement Team listed on the cover letter.
>
> A cover letter should be provided which includes both the name, phone
> number, and FAX number of the individual within the Primary Vendor's
> organization who can be contacted in case any questions arise during
> the Evaluation/Procurement phase of its submissions. A Primary
> Vendor's Pre-Qualification Application should include i) audited
> financial statements for the last three years, ii) a short summary of
> experience in this area of service and technology, iii) an affirmation
> of your neutrality (as defined in this RFP) and of your
> Sub-Contractors, if any, iv) your acceptance of the key business terms
> and conditions summarized in Section 1.3.2., and v) an indication of
> the Primary Vendor's willingness, ability, intention, and commitment
> to comply with the delivery schedule set forth in the cover letter.
> Any notice required under this RFP may be given via FAX, provided that
> the notice is also sent via regular US mail on the same date, and in
> addition to the FAX, to the members of the NYCAC's
> Evaluation/Procurement Team listed on the cover letter.
>
> Please provide written notice of your interest in responding to this
> RFP as soon as possible to the above addresses but no later than the
> due date specified in the cover letter***.*** This will be your
> company's only opportunity to validate itself as a Pre-Qualified
> Primary Vendor in accordance with Section 1.3. You will be notified as
> to your status with respect to eligibility to bid on this RFP in
> accordance with the Pre-Qualification criteria (Section 1.3.), in the
> timeframe noted on the cover letter. This Pre-Qualification
> Application submission is separate and apart from your response to
> this RFP. Also, upon establishing your qualification to bid as a
> Primary Vendor, you will be invited by NYCAC to participate fully in
> the NYCAC\'s RFP process.
>
> Failure to direct your Pre-Qualification Application response to the
> addresses given above by the closing date contained in this section
> will result in the ***absolute disqualification*** of your proposal
> from further consideration under this RFP.
>
> 1.4.2. RFP Proposal Submission
>
> The package containing a Pre-Qualified Primary Vendor's RFP Proposal
> Response submission shall be marked "Sealed RFP Proposal" with this
> RFP title and your organization's name prominently affixed to it.
>
> 1.4.2.1. Submission Date

Refer to the cover letter for the due date.

> 1.4.3. Composition of Pre-Qualified Primary Vendor's RFP Proposal
> Response
>
> All Primary Vendors must submit nine (9) sets (hard copy and diskette
> copy in IBM DOS format, Microsoft Word 6.0) of two-sided copies of
> your RFP response (one copy each to the Evaluation/Procurement Team
> Members listed in the cover letter). Please mark one (1) paper copy of
> your response as "Master Copy." If discrepancies between copies and/or
> the diskette are found to exist, the "Master Copy" will govern and be
> relied upon as the "official" response for all submissions. Please
> send the "Master Copy" of your RFP Response submission to the New York
> Public Service Commission\'s member of the NYCAC
> Evaluation/Procurement Team listed on the cover letter.
>
> All RFP Response proposals shall be typed, double spaced, using 8 1/2"
> x 11" three-hole punched paper, three-ring bound, with each volume
> beginning on a new page and separately tabbed.
>
> Primary Vendor's are requested not to make their proposals elaborate
> with respect to three-ring binding or presentation. A simple,
> straightforward, efficient and economically reproduced proposal is
> strongly recommended. Our proposal Evaluation/Procurement procedure
> places a higher premium on thoroughness and substance of presentation,
> [i.e.,]{.underline} responsiveness, instead of on packaging or
> quantity of material provided.
>
> 1.4.3.1. Content Structure
>
> A Primary Vendor is responsible for any and all costs incurred in the
> preparation of its response to this RFP. All proposals should consist
> of the following separate Tabs:
>
> Tab 1 - Proposal Executive Summary
>
> Tab 2 - Functional and Technical Requirements
>
> Tab 3 - Cost and Price - "SHORT-LIST" Primary Vendors only
>
> ***DO NOT INCLUDE COST OR PRICE FIGURES ANYWHERE EXCEPT IN YOUR TAB 3
> RESPONSE, THE COST AND PRICE SECTION OF THE RFP PROPOSAL, only for
> "short list" Primary Vendor.***
>
> All proposals meeting the stated requirements and specifications
> except for minor exceptions and deviations, shall be considered by
> NYCAC\'s Evaluation/Procurement Team. Failure to meet requirements
> however, could result in a proposal being disqualified from further
> consideration in the selection process. However, proposals having
> minor exceptions and/or deviations shall be considered only if the
> following conditions are satisfied:
>
> \(A\) All exceptions and deviations from the specifications are to be
> explicitly and clearly stated in the Proposal\'s Executive Summary
> (Tab 1), and;
>
> \(B\) All exceptions and deviations are appropriately justified on the
> basis of performance, delivery schedule and/or relative price, based
> upon factual considerations.
>
> 1.4.3.2. Tab Content
>
> The required content of each Tab of your RFP Proposal Response
> follows:
>
> Proposal Executive Summary (Tab 1)
>
> This Tab should summarize all key features of your proposal response.
> All deviations and exceptions from the RFP should be stated, and a
> brief factual justification must be given. A more detailed
> justification can be included in the Tab that covers the subject.
>
> Functional and Technical Requirements (Tab 2)
>
> This section should discuss the major aspects of the functional
> design. You should address;
>
> \(1\) all areas which result in a potentially high degree of risk,
>
> \(2\) all areas which impose an unusually high degree of
> responsiveness,
>
> \(3\) all areas that are deficient and that could be improved, and;
>
> \(4\) each section of the RFP and every functional and technical
> requirement must be addressed in your response. The same article,
> section or paragraph number and title used in the RFP shall be used
> for the Primary Vendor's detailed RFP response submission. Every
> requirement in the RFP will be evaluated to determine the Primary
> Vendor\'s compliance/non-compliance, partial compliance, or full
> compliance.
>
> Cost and Price (Tab 3)
>
> This Tab will be required only for those Primary Vendors which make
> the NYCAC\'s Evaluation/Procurement Team's "Short list". Tab 3 shall
> include a description of the proposed costs and prices under this RFP
> for a minimum of a three year and five year term. All pricing
> information shall be limited solely to this Tab of your proposal. For
> purposes of your response you ***must*** provide both a three year and
> a five year view. ([See]{.underline}, Section 10, R10-17 and 18). This
> Tab should address all requirements set forth in this RFP as well as
> any other items pertinent to your pricing proposal such as additional
> discounts for increased volume, prompt payment, transportation charges
> (FOB destination), etc.. Pricing shall also be firm for all orders
> placed through December 31, 2001, and shall be based on the
> engineered, furnished, and installed cost of all applicable goods,
> software, and services of the most recent vintage and/or technology
> available in the telecommunications industry. Firm pricing proposals
> must be guaranteed by each Primary Vendor as being good and available
> to NYCAC and its members for a period of at least one-hundred-eighty
> (180) days after the initial submission of your RFP.
>
> 1.4.4. Clarification, Questions and/or Requests for Additional
> Information
>
> All clarification, questions or requests for information will be
> submitted in writing to the address and by the date specified in the
> cover letter.
>
> All questions and responses will be promptly distributed to all
> Pre-Qualified Primary Vendors under this RFP. Please note that the
> identity of the requesting company shall be withheld from disclosure.
> Telephone inquiries will not be accommodated. Requests made by FAX are
> expected and appreciated, however, please follow up all Faxed
> submissions with same day delivery via regular US Mail to NYCAC\'s
> Evaluation/Procurement Team member listed above.
>
> 1.4.5. Acceptance Period
>
> All Primary Vendor RFP Proposals shall indicate that they are valid
> for a period of not less than one hundred eighty (180) days from the
> closing date for submission under this RFP.
>
> 1.4.6. Contract Award
>
> The NYCAC reserves the right;
>
> a\) to reject any and all responses,
>
> b\) to conduct negotiations with more than one Primary Vendor
> simultaneously,
>
> c\) to add, delete and/or change the terms of this RFP and to issue
> corrections and/or amendments, or supplements to the RFP, at any time
> without further notice, for any reason whatsoever,
>
> d\) to accept or reject, in whole or in part, any response without
> giving any reason for its decision,
>
> e\) to enter into a contractual arrangement with any Primary Vendor
> and it is not obligated or limited to do so because of any event
> associated with issuance of this RFP,
>
> f\) to have any documents submitted by a Primary Vendor reviewed and
> evaluated by any individuals, including, independent consultants, and;
>
> g\) to cancel the RFP process for any reason without penalty or
> liability at any time before a written contract is executed.
>
> 1.4.6.1. Factors Relevant to Contract Award
>
> The Master Contract will be awarded to the responsible Primary Vendor
> whose offer conforms to this RFP solicitation and which will be most
> advantageous to the NYCAC, in the NYCAC's sole discretion. Therefore,
> price and other factors will be considered. A final contract award may
> not necessarily be awarded to the Vendor offering the lowest price.
>
> 1.4.6.2. NYCAC not Responsible or Obligated Under this RFP
>
> The NYCAC or any individual carrier shall not be obligated in any way
> to make a contractual award as a result of this RFP. In no event shall
> the NYCAC or any individual carrier be responsible for the costs of
> preparing the Primary Vendors' response to this RFP; nor shall the
> NYCAC or any individual carrier indemnify or incur any liability
> whatsoever to Primary Vendors and/or their Sub-Contractors, if any,
> electing to participate in this RFP process.
>
> 1.4.7. No contractual obligations are assumed by NYCAC or its members
> by issuing this RFP, receiving, accepting, and evaluating the Primary
> Vendors\' responses, and/or making a preliminary Primary Vendor
> selection.
>
> 1.4.8. The NYCAC reserves the right to cancel any agreement if the
> services or facilities do not pass mutually agreeable acceptance
> tests. This will be done at no cost or obligation to the NYCAC's RFP
> Evaluation/Procurement Team, NYCAC, or NYCAC Members and individual
> carriers. The Acceptance Testing Plan will form a part of the Master
> Contract with the Primary Vendor and will be evaluated after initial
> database deployment.
>
> 1.4.9. The NYCA reserve sthe right to negotiate all terms and
> conditions in order to enter into a formal agreement with the
> successful Primary Vendor. This document, the Primary Vendor's
> response, and full system documentation will form a part of the Master
> Agreement, if applicable.
>
> 1.4.10. No publicity or news releases pertaining to this RFP,
> responses to this RFP, discussions of any kind regarding the RFP, or
> the award of any agreement related to the RFP document may be released
> without the prior express written consent and approval of NYCAC's RFP
> Evaluation/Procurement Team and NYCAC's Managers.
>
> 1.4.11. All work and materials must comply with all federal, state,
> and local law, municipal ordinances, regulations, and directions of
> appropriately appointed members of proper authorities having
> jurisdiction.
>
> 1.4.12. The Primary Vendor, by stating compliance to a requirement in
> this RFP, agrees that the Primary Vendor has read and understood the
> requirement and that its compliance is complete and deliverable at no
> additional cost unless otherwise noted.
>
> 1.4.13. This RFP may include unintended errors, omissions, and/or
> deficiencies. Therefore, the accuracy and completeness of this
> document and related documents are not guaranteed. In the event that
> such errors, omissions, and/or deficiencies are discovered by the
> Primary Vendor, the Primary Vendor shall notify the RFP
> Evaluation/Procurement Team in writing within 48 hours of their
> discovery.
>
> The Primary Vendor is expected to examine the specifications and
> instructions carefully. Calculation errors shall be the Primary
> Vendor's risk. In the event of a Primary Vendor's error in price, time
> or calculations, the quoted terms shall prevail, and the Primary
> Vendor will bear all risk of loss, without opportunity for recovery
> from NYCAC or its members or individual carriers.

**1.5. Additional Contractual Terms and Conditions**

> This section identifies contractual terms and conditions that the
> NYCAC intends to incorporate into the Master Agreement. The following
> list is in addition to the key business terms and conditions specified
> in the RFP (Section 1.3.2.), but is not necessarily a complete list of
> all the items, terms and conditions that may be included in the final
> Master Agreement.
>
> 1\. Conformity with applicable law:
>
> Primary Vendors shall comply with all applicable New York PSC and FCC
> rules and federal, state, and local statutes, regulations and case
> law.
>
> 2\. Indemnification:
>
> Primary Vendors shall provide indemnification with regard to damage,
> death, or personal injury due to Primary Vendors\', subcontractors, or
> agents if any acts or omissions.
>
> 3\. Trademarks and Publicity:
>
> Except as specifically provided in the Master Agreement, Primary
> Vendors shall have no rights to use names or trademarks developed of
> NYCAC or any of its
>
> members.
>
> 4\. Confidentiality:
>
> Primary Vendors shall not disclose NYCAC or NTCAC member confidential
>
> information.
>
> 5\. Termination:
>
> The Agreement shall establish NYCAC's right to terminate the Agreement
> with or without cause.
>
> 6\. Limitation of Liability:
>
> Except as specifically provided in the Agreement, NYCAC shall not
> assume any liability for Primary Vendors\' damages.
>
> 7\. Taxes:
>
> Primary Vendors shall file all tax returns required by law to be filed
> by Primary Vendor. Also, Primary Vendors shall provide access to all
> relevant documents for tax compliance audits.
>
> 8\. Insurance:
>
> Primary Vendors shall maintain worker's compensation insurance,
> employer's liability insurance, comprehensive general liability
> insurance and appropriate motor vehicle insurance.
>
> 9\. Authority:
>
> Primary Vendors shall represent and warrant that they have approval
> and authority to execute the Agreements on behalf of the Primary
> Vendor and its Sub-Contractors, if any.
>
> 10\. Mechanic's Lien:
>
> Primary Vendors shall perform services free of mechanic's lien or
> other liens.
>
> 11\. Method of Payment:
>
> The compensation to be awarded to the Primary Vendor, under the LNP
> Service Agreements to be signed by the Primary Vendor and the
> individual Carrier Members of NYCAC, pursuant to the LNP Master
> Agreement between the Primary Vendor and NYCAC, under this RFP, will
> flow between the NPAC/SMS users (as defined in Section 3.1.2) and the
> Primary Vendor.

1.6 Evaluation of Proposals

> The criteria to be used for the proposal evaluation include:
>
> \(a\) technical merit
>
> \(b\) schedule
>
> \(c\) price and cost
>
> \(d\) quality considerations
>
> \(e\) responsiveness to contract provisions
>
> \(f\) Prime Vendor's financial stability, history, including program
> management

No weighting or relative importance of criteria is intended or implied
by this list.

You shall furnish all information as requested per the applicable
instructions providing sufficient data to enable us to evaluate the
proposal. Any deviations or exceptions to the RFP should be noted. Any
supplier who does not completely reply to the proposal as requested may
be eliminated at the sole discretion of NYCAC.

The same article, section or paragraph number and title used in the RFP
shall be used for your comments.

In the cases where your reply is \"will not be complied with\" or \"not
agreed to\", you shall indicate your reasons for such disagreement and
provide an alternative with which you will comply or agree.

Compliance with a requirement means your response indicates the
requirement will be met by the turn-up date and clearly explains how the
requirement will be met.

Partial compliance with a requirement indicates the response is
deficient one of two ways; the requirement will be met but not by the
date or there is an alternative to the requirement. Please provide the
date the requirement will be met or a detailed explanation of the
alternative method.

Non-Compliance indicates the response will not satisfy the requirement
and/or did not state how it will satisfy the requirement.

Section 2: Business Process Flows

The following process flows indicate how the NPAC and NPAC/SMS are used
in the various business processes associated with number portability.
This information is intended to provide an overview of the role of the
SMS in number portability. Details of steps in the processes that do not
involve the NPAC or NPAC SMS, such as interactions between service
providers, will be determined by the service providers and are beyond
the scope of this document. Specific requirements generated by the
process flows are included in the appropriate sections later in the
document.

2.1 Provision Service Process

This process flow defines the provisioning flow in which a customer
ports a telephone number to a new service provider.

The new service provider will obtain authorization to port the customer
and notify the old service provider according to processes internal to
the service providers. Both the old and new service providers will send
a notification to the NPAC SMS from their Service Order Administration
Systems. When the NPAC SMS receives the notification(s), it will perform
certain validation checks, including that both the old and new service
provider has sent a notification. If errors are found or both service
providers did not send notifications, the SMS will enter into a
coordination process described in the next paragraph. Assuming the
notifications are valid, the two service providers will complete any
physical changes required. At the time new service provider is ready to
provide service, it will send an activation notice to the NPAC SMS. The
NPAC SMS will place an activation time stamp on the update and broadcast
the update out in real time to all local service providers\' networks.
Upon receiving the update from the NPAC SMS, all service providers will
update their networks. The NPAC SMS will record any transmission
failures and take the appropriate action.

In the case where either the old or new service providers did not send a
notification to the NPAC SMS, the NPAC SMS will notify the service
provider from which it did not receive a notification that it is
expecting a notification. If it then receives the missing notification
and the notifications indicate agreement among the service providers,
the process proceeds as normal. If it still does not receive a
notification and if it is the old service provider that failed to
respond, the NPAC SMS will log the failure to respond and then the
process proceeds as normal. If it was the new service provider that
failed to respond, the NPAC will log the failure to respond, cancel the
notification, and notify the old service provider of the cancellation.
If there is disagreement among the service providers as to who will be
providing service for the telephone number, the conflict resolution
procedures will be implemented. Processes for obtaining authorization
from the customer to port a number are defined by the service providers.
The NPAC is not involved in obtaining or verifying authorization.

From the time the new service provider sends a notification to the time
it sends the activation notice, the new service provider may send a
message to the NPAC SMS to cancel the notification. If this occurs, the
NPAC SMS will remove the notification from its database and notify the
old service provider that the notification has been canceled.

(refer to Figure 1 in Attachments)

2.2 Disconnect Process

When a ported number is being disconnected, the customer and service
provider will agree on a date. After an intercept period, if any, the
service provider will send an update indicating the disconnect to the
NPAC SMS. A carrier can send an effective date indicating when the NPAC
SMS is to broadcast the update. If the effective date is blank, it
defaults to the current date and the update is sent out immediately. The
NPAC SMS will broadcast the update to all service providers and remove
the telephone number from its database of ported numbers. Upon receiving
the update, all service providers will remove the telephone number from
their LNP databases. The NPAC SMS will log the update in history. Calls
to the telephone number will be routed as a non-ported number.

In both the service provisioning process and disconnect process, when
the NPAC SMS is performing validity checks (such as confirming that
required data fields are filled in), if an error is found, the NPAC SMS
will notify the service provider\'s with an appropriate error message.
The service provider will have to resend the notification to have it
processed.

(refer to the Attachmented process flows)

2.3 Conflict Resolution Process

If service providers disagree on who will serve a particular line number
or due date of the order, the NPAC will place the request in
\"conflict\" and notify both service providers. The service providers
will determine who will serve the customer via internal processes. When
a resolution is reached, the NPAC will be notified and will remove the
request from \"conflict\" or cancel it.

2.4 Disaster Recovery and Backup Process

If there is planned downtime for the NPAC SMS, the NPAC SMS will send an
electronic notification to the service provider\'s SOAs that includes
information on when the downtime will start, how long it will be and if
they will be required to switch to the backup or disaster recovery
machine. Downtime is considered planned when the NPAC can provide
notification to the service providers at least 24 hours in advance. If
the downtime will be less than 60 minutes, the service providers will
remain connected to the primary machine and not send any updates during
the downtime. If the downtime will be longer than 60 minutes, the NPAC
service providers will switch to the backup or disaster recovery machine
as indicated in the notification. There will be a quiet period (minutes)
when no updates can be sent in order to allow the NPAC to connect the
service providers to the proper machine. At the end of the quiet period,
processes will proceed as normal. When the primary machine is brought
back up, the backup or disaster recovery machine will send an electronic
notification to the service providers\' SOAs indicating the time the
NPAC will switch them back to the primary machine. At the end of the
quiet period, processes will continue as normal and the NPAC will synch
up the database in its primary SMS with any updates sent to the backup
or disaster recovery machine during the downtime.

If there is unplanned downtime, the NPAC will assess how long the
primary machine will be down. The NPAC will notify all of the service
providers by telephone calls to the service providers\' contact numbers
of the situation and planned action. If the downtime is expected to be
less than 60 minutes, the service providers will remain connected to the
primary machine and not send any updates during the downtime. If the
downtime will be longer than 60 minutes, the service providers will
switch to the backup or disaster recovery machine and later back to the
primary using the same process as described for planned downtime. In
addition, once the service providers have been switched off of the
primary machine, each service provider will check to see if any updates
of newly ported numbers sent to the primary machine during the time it
went down were not broadcast out. If a service provider finds such
updates, the service provider may use internal inter-carrier processes
to update its own SCPs and have other carriers update their SCPs with
the information in order to ensure service to the affected customers.
This will not be needed for disconnect orders. Even if it finds such
updates, a service provider may choose to wait until it can begin
sending updates to the backup or disaster recovery machine and then just
resend the updates that had died in the primary machine. If a service
provider does use internal processes to request updates to SCPs while
waiting to be able to send them to the backup or disaster recovery
machine, the service provider will still resend the updates when backup
or disaster recovery machine can begin processing them in order to
ensure every service provider and the NPAC SMS receive the update.

(refer to Figure 4 in Attachments)

Section 3: NPAC Data Administration

3.1 Overview

The NPAC/SMS manages the ported TN information associated with the
service provider portability for the LNP service.

3.1.1 Service Data

The Service Data contains global parameters specific to the LNP service.

Examples of some of these parameters are described below. The
description presents a logical representation of the data, not an
implementation view.

Time interval for concurrence from both service providers (Section 5,
R5-21)

Number of retries for download to Local SMS (Section 5, R5-59)

Time interval a subscription version stays in conflict (Section 5,
R5-44)

3.1.2 Service Provider Data

Service Provider Data contains information about authorized NPAC/SMS
users. There are two categories of NPAC/SMS users. SOA Users are those
with service order activation (SOA) access; the ability to add, change,
and delete service data. SMS Users are those that can only receive
broadcasts of service data.

The data items that need to be administered by NPAC/SMS User Data
Administration include (but are not limited to):

A.  NPAC/SMS User Name

B.  Facility-based NPAC/SMS User Identification

C.  NPAC/SMS User Address

D.  NPAC/SMS User Phone

E.  NPAC/SMS User Contact

F.  NPAC/SMS User Repair Center Information

G.  NPAC/SMS User System Data Link Information

3.1.3 Subscription Data

Subscription Data consists of information about the ported TNs.

The data items that need to be administered by Subscription Data
Administration functions are described below. The description presents a
logical representation of the data, not an implementation view.

Table 3-1 describes the data items associated with each ported TN that
are maintained by the NPAC SMS. Size of the data items is in bytes.

+---+---------+----+-----+---+-------+-----+-------------------------+
|   | **Data  | ** | **  | * | *     | **I | **Comments**            |
|   | Item**  | Si | Typ | * | *Defa | npu |                         |
|   |         | ze | e** | S | ult** | t** |                         |
|   |         | ** |     | r |       |     |                         |
|   |         |    |     | c |       |     |                         |
|   |         |    |     | * |       |     |                         |
|   |         |    |     | * |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 1 | TN      | 10 | N   | S |       | Re  | Telephone Number        |
| . |         |    |     | P |       | qd. |                         |
|   |         |    |     |   |       |     |                         |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 2 | DD      | 8  | N   | S |       | R   | Expected Due Date of    |
| . |         |    |     | P |       | eqd | activation              |
|   |         |    |     |   |       |     |                         |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 3 | LRN     | 10 | N   | S |       | Re  | Routing information     |
| . |         |    |     | P |       | qd. |                         |
|   |         |    |     |   |       |     |                         |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 4 | F       | 4  | A-N | S |       | Re  | Facilities-based        |
| . | acility |    |     | P |       | qd. | service providers. This |
|   | -based  |    |     |   |       |     | field can be used for   |
|   | Service |    |     |   |       |     | repair, maintenance     |
|   | P       |    |     |   |       |     | purposes.               |
|   | rovider |    |     |   |       |     |                         |
|   | ID      |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 5 | Act     | 10 | N   | S |       |     | Date/Time of activation |
| . | ivation |    |     | M |       |     | request from local      |
|   | Time    |    |     | S |       |     | service provider, e.g., |
|   | Stamp   |    |     |   |       |     | xx-xx-xxxx/xxxx         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 6 | Dis     | 8  | N   | S |       | Re  | Date e.g., xx-xx-xxxx   |
| . | connect |    |     | P |       | qd. | of TN (end user)        |
|   | Date    |    |     |   |       |     | disconnect.             |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 7 | Dis     | 8  | N   | S |       | Re  | Date e.g., xx-xx-xxxx   |
| . | connect |    |     | P |       | qd. | of TN (end user)        |
|   | Br      |    |     |   |       |     | disconnect broadcast,   |
|   | oadcast |    |     |   |       |     | if broadcast is         |
|   | Date    |    |     |   |       |     | deferred.               |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 8 | Status  | \* | \*  | S |       | Re  | E.g., active, old,      |
| . |         |    |     | M |       | qd. | invalid, conflict.      |
|   |         |    |     | S |       |     |                         |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 9 | DPC for | 9  | N   | S |       | Re  | DPC for 10-digit GTT    |
| . | CL      |    |     | P |       | qd. | for CLASS features      |
|   | ASS[^1] |    |     |   |       |     |                         |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 1 | SSN for | 3  | N   | S |       | Re  | Required if type for    |
| 0 | C       |    |     | P |       | qd. | CLASS DPC is EO         |
| . | LASS^1^ |    |     |   |       |     |                         |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 1 | DPC for | 9  | N   | S |       | Re  | DPC for 10-digit GTT    |
| 1 | LIDB    |    |     | P |       | qd. | for LIDB access         |
| . |         |    |     |   |       |     |                         |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 1 | DPC for | 9  | N   | S |       |     | DPC for interswitch     |
| 2 | ISVM    |    |     | P |       |     | voice message waiting   |
| . |         |    |     |   |       |     | indicator               |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 1 | SSN for | 3  | N   | S |       |     | Subsystem number for    |
| 3 | ISVM    |    |     | P |       |     | ISVM = 0, if gateway.   |
| . |         |    |     |   |       |     |                         |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 1 | DPC for | 9  | N   | S |       |     | DPC for caller ID with  |
| 4 | CNAM    |    |     | P |       |     | name                    |
| . |         |    |     |   |       |     |                         |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 1 | SSN for |    |     |   |       |     | Subsystem number for    |
| 5 | CNAM    |    |     |   |       |     | CNAM = 0, if gateway.   |
| . |         |    |     |   |       |     |                         |
|   |         |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 1 | E       | 12 | N   | S |       |     | Value: Zip code, V&H,   |
| 6 | nd-user |    |     | P |       |     | Longitude and Latitude, |
| . | L       |    |     |   |       |     | rate center (Value not  |
|   | ocation |    |     |   |       |     | determined yrt. Future  |
|   | Value   |    |     |   |       |     | Use.                    |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 1 | E       | 2  | N   | S |       |     | Indicates which         |
| 7 | nd-user |    |     | P |       |     | location value. Future  |
| . | L       |    |     |   |       |     | Use.                    |
|   | ocation |    |     |   |       |     |                         |
|   | Value   |    |     |   |       |     |                         |
|   | Type    |    |     |   |       |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+
| 1 | Billing | 4  | A-N | S | Faci  |     | Billing ID.             |
| 8 | ID      |    |     | P | lity- |     |                         |
| . |         |    |     |   | based |     | Probably NECA's company |
|   |         |    |     |   | Se    |     | number.                 |
|   |         |    |     |   | rvice |     |                         |
|   |         |    |     |   | Pro   |     | Future Use.             |
|   |         |    |     |   | vider |     |                         |
|   |         |    |     |   | ID    |     |                         |
+---+---------+----+-----+---+-------+-----+-------------------------+

**Table 3-1 Subscription Data**

3.1.4 Data Used for Validation

The data items that need to be administered by Network Data
Administration functions are described below. The description presents a
logical representation of the data, not an implementation view.

A.  Participating facilities-based service providers and their IDs

B.  NPA-NXXs that are portable

C.  LRNs associated with each facilities-based service provider

D.  Service Provider valid Location Values

E.  Valid Billing IDs

Certain types of updates made to network data, such as NPA splits, may
cause mass changes to data managed by the NPAC. The NPAC will need to
support such mass changes, which typically involve an investigation of
all service, service provider, and subscription data in order to
determine if such data will be affected by the change, as well as the
potential modifications and activation of the data records affected by
the change.

An NPA split is supported by maintaining two sets of records or an
equivalent mapping to reduce memory costs and administrative care (old
NPA and new NPA) in the NPAC SMS, Local SMSs, and SCPs for the duration
of the permissible dialing period, during which dialing of both NPAs are
allowed. After the expiration of the transition period, all records for
the old NPA are removed from the systems. These old NPA-NXX combinations
may be used in the future.

3.2 NPAC Personnel Functionality

R3-1 Authorized NPAC personnel shall be able to initialize the network
data when the NPAC SMS is initially deployed.

R3-2 Authorized NPAC personnel shall be able to administer NPAC network
data.

R3-3 Authorized NPAC personnel shall be able to open up a new NPA-NXX
for LNP.

R3-4 Authorized NPAC personnel shall be able to add/delete a service
provider.

R3-5 Authorized NPAC personnel shall be able to administer information
related to a service provider.

R3-6 Authorized NPAC personnel shall be able to perform mass changes
that affect several records. NPA splits, LRN changes, LIDB changes and
other similar network data changes affect multiple subscription records
in the NPAC SMS.

R3-7 Authorized NPAC personnel shall be able to select a subset of data
which matches a user defined selection criteria, and specify a mass
update action to be applied against all key data elements found in the
selected records.

3.3 System Functionality

R3-8 The NPAC SMS shall support an off-line batch download (e.g., FTP)
mechanism to mass update Local SMSs (e.g., for new service providers, or
in case of disaster recovery for a Local SMS).

R3-9 The NPAC SMS shall be able to download network data (e.g. portable
NPA-NXX data), to the Local SMSs.

R3-10 The NPAC SMS shall notify ( electronic bulletin) all service
providers about the availability of the NPA-NXXs for porting. NOTE: This
is a temporary solution.

R3-11 The NPAC shall notify (broadcast / electronic bulletin) all
service providers about a new service provider and the associated LRNs.
NOTE: This is a temporary solution.

R3-12 The NPAC shall validate the service, service provider, and
subscription data against the current network data.

R3-13 The NPAC SMS shall have the capability to identify all records
affected by mass changes, (such as NPA splits), and automatically carry
out the required updates and download the modified data to the Local
SMSs.

R3-14 The NPAC will provide a "heads-up" notice when it has the first
pending subscription for a portable NPA-NXX. This notice is broadcast
immediately not held for activation.

Section 4: NPAC/SMS User Data Administration

4.1 NPAC/SMS User Data Administration and Management

NPAC/SMS User Data Administration functions allow NPAC personnel to
receive and record data needed to identify authorized NPAC/SMS users.
The NPAC/SMS User data indicates who the NPAC/SMS Users are and includes
location, contact name, security, routing, and network interface
information. These functions will be accessible to authorized NPAC
personnel.

NPAC/SMS User Administration Requirements

4.1.1 User Functionality

Authorized NPAC personnel can invoke the following functionality in the
SMS to administer NPAC/SMS User data:

R4-1 Create a new NPAC/SMS User - creates, validates, and updates new
NPAC/SMS User data.

R4-2 Modify NPAC/SMS User data - modifies, validates, and updates
existing NPAC/SMS User data.

R4-3 Delete NPAC/SMS User data - deletes the NPAC/SMS User data and
stores it in a history file.

R4-4 View NPAC/SMS User data.

R4-5 View a list of subscriptions associated with the NPAC/SMS User
(i.e., see all ported TNs associated with a specific NPAC/SMS User).

Additionally, authorized NPAC/SMS User personnel can view their own
NPAC/SMS User data.

4.1.2 System Functionality

This section describes SMS functionality required to support the NPAC
user requests described in the above section. The following specifies
user requests and lists the SMS functionality needed to support those
requests:

4.1.2.1 NPAC/SMS User Data Creation

An NPAC user requests that NPAC/SMS User data be created in SMS by
associating an action of \"create\" with the data. This functionality
enables a new instance of NPAC/SMS User data for a NPAC/SMS User be
created, provided that no other NPAC/SMS User data exists for the
NPAC/SMS User.

R4-6 When the NPAC user is creating a new NPAC/SMS User, SMS shall
receive the following to identify the NPAC/SMS User:

Service Provider ID - identifier of the NPAC/SMS User.

R4-7 SMS shall check to see if there is an existing NPAC/SMS User with
the same service provider ID. If there is, the SMS shall notify the user
that the NPAC/SMS User data already exists for the NPAC/SMS User and
that the new NPAC/SMS User data cannot be created.

R4-8 If there is no existing NPAC/SMS User data, the SMS shall receive
the following data:

NPAC/SMS User name, address, phone number, and contact\
organization \<\-- required data.

NPAC/SMS User billing name, address, phone number, and billing contact
for NPAC billing \<\-- optional data. If left blank this shall default
to NPAC/SMS User name, address, phone number, and contact.

NPAC/SMS User to NPAC/SMS User Repair contact name and phone number
\<\-- optional data. If left blank this shall default to NPAC/SMS User
contact and phone number.

Location Routing Numbers (LRN) - the identifier of the switches having
portable NXXs and used by the NPAC/SMS Users \<- at least one LRN is
required.

Assigned NPA-NXXs open for LNP \<\-- at least one required.

Network Address of NPAC to Local SMS interface

Network Address of NPAC to SOA interface

Security data

R4-9 After the NPAC/SMS User data has been collected, SMS shall validate
that all required data has been received as defined in R4-8.

R4-10 If all validations are passed, SMS shall notify the user that the
request to create the NPAC/SMS User data was successful.

R4-11 If the NPAC/SMS User data fails validation, SMS shall issue an
appropriate error message to the request originator. The NPAC/SMS User
data shall not be created.

4.1.2.2 NPAC/SMS User Data Modification

An NPAC user requests that NPAC/SMS User data be modified in SMS by
associating an action of \"modify\" with the NPAC/SMS User data. This
functionality enables a user to add or change data for the NPAC/SMS
User.

R4-12 SMS shall receive a request to modify NPAC/SMS User data.

R4-13 SMS shall receive the following data from the user to identify the
NPAC/SMS User data to be modified: the Service Provider ID.

R4-14 If the NPAC/SMS User data does not exist, SMS shall issue an
appropriate error message to the request originator. SMS shall not
proceed further with the modification request.

R4-15 SMS shall allow all data to be modified or added to the NPAC/SMS
User data with the exception of the Service Provider ID which is the key
to the NPAC/SMS User data.

R4-16 When a user attempts to submit modified NPAC/SMS User data, SMS
shall revalidate the NPAC/SMS User data. This revalidation process shall
include the validations defined in R4-9.

R4-17 If the NPAC/SMS User data fails validation, SMS shall issue an
appropriate error message to the request originator.

R4-18 If the validations defined in R4-9 are passed, SMS shall determine
if there are any subscriptions associated with the Service Provider ID.

\(A\) If there are no subscriptions, SMS shall notify the user that the
request to modify the NPAC/SMS User data was successful, or

\(B\) If there are subscriptions that contain data that is dependent on
the NPAC/SMS User data proposed for change, SMS shall notify the user
that the request to modify the NPAC/SMS User data cannot be completed
until the individual subscriptions are modified via subscription
administration functions.

4.1.2.3 Delete NPAC/SMS User Data

When an NPAC user requests that NPAC/SMS User data be deleted in SMS a
network action of \"delete\" will be associated with the subscription
data and it will be written to a history file.

R4-19 SMS shall receive a request to delete NPAC/SMS User data.

R4-20 SMS shall receive the following data from the user to identify the
NPAC/SMS User data to be deleted: the Service Provider ID.

R4-21 If the NPAC/SMS User data does not exist, or if it has already
been deleted and exists only in a history file, SMS shall generate an
error message and send it to the request originator. SMS shall not
proceed further with the deletion request.

R4-22 If the NPAC/SMS User data does exist, SMS shall do the following:

SMS determine if there are any subscriptions (i.e., ported TNs)
associated with the NPAC/SMS User:

\(A\) If there are no subscriptions, SMS shall notify the user that the
request to delete the NPAC/SMS User data was successful and shall write
the NPAC/SMS User data to a history file which includes the date and
time of deletion and the login of the NPAC personnel.

\(B\) If there are subscriptions, SMS shall notify the user that the
request to delete the NPAC/SMS User data cannot be completed until the
subscriptions are deleted or are associated with a different NPAC/SMS
User.

4.1.3 NPAC/SMS User Queries

The query functionality discussed in this section will give users the
ability to view NPAC/SMS User data without being able to update that
data. A user may not be able to modify a particular data item because
that user does not have the proper security permissions and the data is
made available via SMS for read-only purposes.

Assumptions

Users will need to be able to retrieve NPAC/SMS User data that they
cannot modify.

User Functionality

R4-23 An authorized SMS user shall be able to invoke the following
functionality in the SMS to query NPAC/SMS User data:

a NPAC/SMS User may view only its own NPAC/SMS User data.

R4-24 Authorized NPAC personnel shall be able to view:

all subscriptions associated with a NPAC/SMS User, or

all subscriptions associated with a LRN.

System Functionality

The following specifies SMS functionality needed to support the user
requests described above.

NPAC/SMS User Query

R4-25 For queries regarding NPAC/SMS User data, SMS shall receive the
NPAC/SMS User ID.

R4-26 If SMS does not have NPAC/SMS User data as specified by the
request originator, SMS shall provide the request originator with a
message indicating that there was no data in SMS that matched the search
keys. Otherwise SMS shall return all NPAC/SMS User data associated with
the Service Provider ID.

R4-27 For queries regarding subscription data for a specific NPAC/SMS
User, SMS shall receive the NPAC/SMS User ID, a request to view
subscription data, and optionally the subscription data status types to
be returned (e.g., active only, active or pending).

R4-28 If SMS does not have subscription data as specified by the request
originator, SMS shall provide the request originator with a message
indicating that there was no data in SMS that matched the search keys.
Otherwise SMS shall return all subscription data associated with the
Service Provider ID and any optional status requests.

Subscription List Query

R4-29 For queries regarding subscriptions, SMS shall receive the
attributes to be searched on. Allowable attributes are all data elements
in Table 3-1 or subsets thereof.

R4-30 If SMS does not have subscriptions as specified by the request
originator, SMS shall provide the request originator with a message
indicating that there was no data in SMS that matched the search keys.
If SMS does have subscriptions as specified by the request originator,
SMS shall return all subscriptions (active versions only) which satisfy
the selection criteria. If more than a pre-specified number of
subscriptions are found (this shall be a parameter which is tuneable by
the SMS System Administrator the default value shall be 50) the
subscription data shall be returned to a previously designated
(off-line) output device/medium.

Section 5: Subscription Administration

5.1 Subscription Administration and Management

Subscription Administration functions allow users to specify data needed
for ported numbers. The subscription data indicates how local number
portability should operate to meet subscribers\' needs. These functions
will be accessible to authorized NPAC/SMS Users via an interface (e.g.,
the SOA interface) from their operations systems to the NPAC SMS and
will also be accessible to (and performed by) NPAC personnel.

Subscription Administration supports functionality to manage multiple
versions of subscription data. A subscription record can be associated
with the following statuses: invalid, pending, sending, active,
conflict, failed, canceled, or old (history). See Record Management for
more details on different states of a record. There can be only one
invalid, pending, sending, conflict, partially failed, or failed record
per subscription. There can also be one active subscription record at
any time and multiple old and/or canceled subscription records.

5.1.1 Record Management

Record management provides functionality to manage multiple
time-sensitive views of subscription data. This sections addresses
record management for LNP and the user and system functionality needed
for subscription administration. In this context a record may be defined
as time-sensitive subscription data.

At any given time, a subscription record in the SMS can have one of
several statuses (e.g., active, invalid) and may change status depending
on results of different SMS processes (e.g., modification, activation).
This section describes different statuses that a record can have and the
SMS processes that can change the status.

This section on Record Management discusses functionality and data that
is needed for Subscription Administration.

Requirements

Record Status

R5-1 At any given time, a record in the SMS will have one of the
following statuses:

Pending - passed initial validations and edits and will be submitted to
the network (i.e., Local LNP SMSs) when activation is requested.

Invalid - failed validations.

\[**Note:** SMS will not create subscriptions or accept updates to
subscriptions which result in an invalid condition. However, pending
subscriptions will be revalidated prior to sending updates to the local
SMSs. Subscriptions that fail this revalidation will have a status of
invalid. It will be necessary to notify the porting NPAC/SMS User of
this change in status.\]

Conflict - non-concurrence from old facilities-based NPAC/SMS User, lack
of *create* from new facilities-based NPAC/SMS User.

Sending - being sent to the network.

Active - currently active in the network.

Failed - failed activation in the network (at one or more Local SMSs).

Old - previously active in the network.

Canceled - previously pending, invalid, or in conflict.

R5-2 The length of time that old subscription records will be retained
(before deletion) and will be accessible through a query request will be
a tuneable parameter that is tuneable by the SMS Administrator (with the
appropriate security permission). The default value for this parameter
will be eighteen (18) months.

R5-3 The length of time that canceled subscription records will be
retained (before deletion) and will be accessible through a query
request will be a tuneable parameter that is tuneable by the SMS
Administrator (with the appropriate security permission). For canceled
records, this parameter shall be tuneable based on the last status of
the record. The default values for these parameters shall be as follows:

[Last status before cancellation]{.underline} [Parameter
value]{.underline}

pending 90 Days

invalid 90 Days

conflict 30 Days

R5-4 The LNP SMS will maintain only a single pending record of a
subscription.

R5-5 Subscriptions for individual ported TNs that are created through a
\"TN range-level\" request shall be treated as individual subscription
records after activation has occurred.

R5-6 SMS shall log all subscription administration transactions. The log
entries shall include:

Activity Type: create, modify, active, activate, conflict \"on,\"
conflict \"off,\" disconnect, cancel, or query

Initial Record Status

New Record Status

User ID and/or Login

Local Number Portability Type (SP, Loc., Serv)

Date and Time Stamp

Ported Telephone Number

Status Flag - successful or failed

5.1.2 Subscription Administration Requirements

5.1.2.1 User Functionality

Authorized users[^2] can invoke the following functionality in the SMS
to administer subscription data:

R5-7 Create a subscription record - creates, validates, and pends (if
valid) a new subscription record for activation in the network.

R5-8 Modify a subscription record - modifies, validates, and pends (if
valid) a pending, invalid, or active subscription record for activation
in the network. Old, canceled, conflict, and failed records cannot be
modified.

R5-9 Activate a subscription record - activates a pending subscription
record in the network.

R5-10 Conflict \"On\"/Conflict \"Off\" - places a subscription record in
conflict or removes it from conflict. A subscription record in conflict
cannot be activated.

R5-11 Disconnect a subscription record (from the network) - deletes the
active subscription record in the network and stores it as an old
subscription record.

R5-12 Cancel a subscription record - removes an invalid, conflict or
pending subscription record and stores it as a canceled subscription
record.

R5-13 Query: displays a subscription record and its associated
parameters.

5.1.2.2 System Functionality

This section describes SMS functionality required to support user
requests defined in the above section. Subscription records can be
created or viewed by the old facilities-based NPAC/SMS User.
Subscription records can be created, modified, activated, disconnected,
canceled, or viewed by the new facilities-based NPAC/SMS User. In
addition to being able to create, modify, activate, disconnect, cancel,
and view subscriptions, only authorized NPAC personnel can place
subscriptions in conflict and remove them from conflict. Additionally,
any authorized NPAC/SMS User can view any subscription record for any
ported TN. (Note: Tuneable security permission matrix may be required.)

Additionally, SMS functionality is required to perform operations which
are not invoked by a direct user request. This functionality shall
monitor a subscription record to determine whether the old and the new
facilities-based NPAC/SMS Users have authorized the transfer of service
for a ported number, shall issue appropriate notifiers to NPAC/SMS
Users, and shall change the status of a subscription record based on
tuneable parameters, e.g. pending record will be automatically canceled
after an \"X\" number of days (\"X\" = tuneable parameter)

The following specifies user requests and lists the SMS functionality
needed to support those requests:

5.1.2.2.1 Subscription Record Creation

A user requests a subscription to be created in SMS by associating an
action of \"create\" with a record. This functionality, which can be
invoked by the old or the new facilities-based NPAC/SMS User, enables a
new instance of a subscription record for the ported telephone number to
be created, provided that there exists at most one active subscription
record. Multiple old and/or canceled subscription records may exist. If
a create is initiated by the old facilities-based NPAC/SMS User, they
shall identify the ported telephone number, the new facilities NPAC/SMS
User, the due date and indicate that they are authorizing the transfer
of service. If the create is initiated by the new facilities-based
NPAC/SMS User, all information pertaining to the ported TN may be
provided, with the exception of the old facilities-based NPAC/SMS
User\'s authorization.

R5-14 When the user is the old (ported-from) NPAC/SMS User SMS shall
receive the following to identify the subscription record to be created:

Local Number Portability Type ID - identifier of the Number Portability
types. (NOTE: While Local Service Provider Portability will be the first
type supported by the NPAC SMS, the system needs to be extensible so as
to support multiple types at a future date.)

Ported Telephone Number(s) - this entry can be a single TN or a
continuous range of TNs that identifies a subscription or a group of
subscriptions that share the same attributes.

Due Date - date on which transfer of service from old facilities-based
SOA User to new SOA User is planned to occur. This is used by the NPAC
only to help match corresponding create orders from the service
providers and for certain internal timers.

New facilities-based service provider ID - the identifier of the new
facilities-based NPAC/SMS User.

Old facilities-based service provider ID - the identifier of the old
facilities-based NPAC/SMS User.

Authorization from old facilities-based NPAC/SMS User - indication that
the transfer of service is authorized by the ported-from NPAC/SMS User.

R5-15 When the user is the new facilities-based service provider SMS
shall receive the following to identify the subscription record to be
created:

Local Number Portability Type ID - identifier of the Number Portability
type.

Ported Telephone Number (TN) - this entry can be a single TN or a
continuous range of TNs that identifies subscription (i.e., the
telephone number assigned to the customer) or a group of subscriptions
that share the same attributes.

Due Date - date on which transfer of service from old facilities-based
service provider to new facilities-based service provider is planned to
occur. This is used by the NPAC only to help match corresponding create
orders from the service providers and for certain internal timers.

New Facilities-based Service Provider ID - the identifier of the new
facilities-based service provider.

Old Facilities-based Service Provider ID - the identifier of the old
facilities-based service provider.

Location Routing Number (LRN) - the identifier of the ported-to switch.

Global Title Translation (GTT) and Destination Point Code (DPC)
information as per Table 3-1.

R5-16 The following fields are for future use. The new facilities-based
service provider may not be required to treat these fields as mandatory.

Billing Service Provider ID

End-User Location - Value

End-User Location - Type

SMS shall invoke the following Record Creation functionality:

R5-17 When a user attempts to submit a new record, SMS shall determine
whether a pending record already exist for the entity in question.

If a pending record exists and if the authorized user is associated with
the old or new facilities-based SOA User (who has not yet authorized the
transfer of service), SMS shall:

Allow the old facilities-based SOA User to perform the functions defined
in R5-14 or

Allow the new facilities-based SOA User to perform the functions defined
in R5-15 and R5-16.

Otherwise, the SMS will send an error message to the request originator.

R5-18 If there is no pending record of the subscription (or if the
conditions in R5-17 have been met) and no active record, SMS shall
proceed as follows:

SMS shall perform the following validations for the record:

All data has been received as defined in R5-14 or R5-15 and R5-16.

The old and the new facilities-based SOA User must agree as to the Due
Date.

The Due Date is the current date or a future date.

The NPA-NXX of the ported Telephone Number must be in the Portable
NPA-NXX table.

The old and new facilities-based SOA User IDs must match existing SOA
User data (due dates can later be modified by either provider and no
longer match).

The new LRN must be associated with the new facilities-based SOA User.

R5-19 If there is no pending record of the subscription but there is an
active record, SMS shall, in addition to the validations defined in
R5-16, verify that the old SOA User on the record being created is equal
to the SOA User on the active subscription record.

R5-20 If the subscription record fails validation, SMS shall issue an
appropriate error message to the request originator. If a valid
subscription record already exists (e.g., the current create is being
done by the old facilities-based SOA User, but the new facilities-based
SOA User has already done a create for the ported TN), the pending
subscription record shall be retained. Otherwise, the subscription
record shall not be created.

R5-21 If the subscription record passes validations, SMS shall:

Verify if both the old and the new facilities-based SOA Users have
authorized the transfer of service for the ported TN.

If not, SMS shall compute the date by which authorization data from both
SOA Users must be received and shall store this with the subscription
record. The date by which concurrence from both SOA Users must be
received shall be computed as being a predetermined number of days prior
to the Due Date. This will be a parameter that is tuneable by the SMS
Administrator. The default value for this parameter shall be three (3)
days. If either provider subsequently modifies due date NPAC shall use
later date.

Mark the record with a status of pending in the SMS and issue an
appropriate message to the request originator indicating successful
completion of the pending process.

R5-22 When the date for concurrence for a pending subscription record
has been reached, SMS will send a notifier to the SOA User (old or new)
who has not yet authorized the transfer of service.

R5-23 If a create meassage for the transfer of service has not been
received from the new facilities-based SOA User within the allotted
period of time (tuneable parameter) after SMS sent the notifier, the
subscription record shall be canceled as defined in R5-70. The user ID
for this transaction shall be the \"SMS System ID.\"

5.1.2.2.2 Subscription Record Modification

A user requests a pending, invalid or conflict subscription record to be
modified in SMS by associating an action of \"modify\" with a record.
This functionality, which can be invoked only by the new
facilities-based SOA User, enables a user to add or change data in a
subscription record.

5.1.2.2.2.1 Modification of a Pending, Invalid, or Conflict Subscription
Record

R5-24 SMS shall receive data in support of modification of a
subscription record:

\(1\) to change the data associated with a pending, conflict, or invalid
subscription record or (2) to add additional data to a pending or
conflict subscription record.

R5-25 If the record status is sending, failed, canceled, or old, SMS
shall generate an error message and send it to the request originator.
SMS shall not proceed further with the modification request.

R5-26 SMS shall receive the following data from the user to identify the
subscription record to be modified: the Ported Telephone Number
Subscription ID.

R5-27 SMS shall allow the following data to be modified in the
subscription record:

> Location Routing Number (LRN) - the identifier of the switches having
> portable NXXs and used by the service providers \<- at least one LRN
> is required.
>
> Due Date - date on which transfer of service from old facilities-based
> SOA User to new SOA User is planned to occur.
>
> Global Title Translation (GTT) and Destination Point Code (DPC)
> information as per Table 3-1.

R5-28 The following fields are for future use. The new facilities-based
SOA User may not be required to treat these fields as mandatory.

Billing Service Provider ID

End-User Location - Value

End User Location - Type

R5-29 SMS shall revalidate the modified subscription record. This
revalidation process shall include the validations defined in R5-18.

R5-30 If the record fails validation, SMS shall issue an appropriate
error message to the request originator. The pending subscription
record, which the user was attempting to modify, shall be retained with
no changes.

R5-31 If the record passes validations, SMS shall mark the record with a
status of pending in the SMS and shall issue an appropriate message to
both old and new SOA Users indicating successful completion of the
pending process.

~~R5-32~~ Deleted requirement. Do not respond.

5.1.2.2.2.2 Modification of an Active Subscription Record

R5-33 SMS shall receive data in support of modification of an active
subscription record to change only specific data associated with an
active subscription record.

R5-34 SMS shall invoke record creation functionality to create a new
(pending) subscription record based on the active subscription record.

R5-35 SMS shall receive the following data from the user to identify the
active subscription record is to be modified: the Ported Telephone
Number Subscription ID.

R5-36 SMS shall allow the following data to be modified in the newly
created subscription record:

Location Routing Number (LRN) - the identifier of the switches having
portable NXXs and used by the service providers \<- at least one LRN is
required.

LIDB GTT data - network addressing information for routing to serving
LIDB.

DPC Type for LIDB features GTT - indicates whether Destination Point
Code identifies the subsystem or a gateway.

GTT data for CLASS features - network addressing information for routing
TCAP messages to the ported-to switch.

DPC type for CLASS features GTT - indicates whether Destination Point
Code identifies the end office or a gateway STP.

R5-37 The following fields are for future use. The new facilities-based
service provider may not be required to treat these fields as mandatory.

Billing Service Provider ID

End-User Location - Value

End-User Location - Type

R5-38 SMS shall validate the modified subscription record. This
validation process shall include the applicable validations defined in
R5-18.

R5-39 If the record fails validation, SMS shall issue an appropriate
error message to the request originator. A new subscription record shall
not be created and no changes shall be made to the current active
subscription record.

R5-40 If the record passes validation, SMS shall record the current date
and time (i.e., system date and time) as the Activation Date and Time
Stamp, shall mark the record with a status of sending in the SMS, and
shall issue an appropriate message to the request originator indicating
successful completion of the modify process.

R5-41 SMS shall activate the record in the network as defined in R5-51
through R5-61.

5.1.2.2.3 Conflict Subscription Record

An authorized NPAC user requests a subscription be placed in conflict or
removed from conflict by associating an action of \"conflict on\" or
\"conflict off\" with a record. This functionality is invoked when an
authorized user requests that the record be placed in or removed from
conflict.

5.1.2.2.3.1 Placing a Subscription Record in Conflict

R5-42 SMS shall receive the following data from the user to identify the
subscription record is to be placed in conflict: the Ported Telephone
Number Subscription ID.

R5-43 If the record status is not pending, SMS shall generate an error
message and send it to the request originator. SMS shall not proceed
further with the request to place the subscription record in conflict.

R5-44 If the record status is pending, SMS shall mark the record with a
status of conflict, shall record the current date and time (i.e., system
date and time) as the **Conflict** Date and Time Stamp and shall issue
an appropriate message to the request originator indicating successful
completion of the process to place a subscription in conflict.

R5-45 If a subscription record remains in conflict for thirty days, SMS
shall invoke cancellation processing as defined in R5-71 (tuneable
parameter). The user ID for this transaction shall be the \"SMS System
ID.\"

5.1.2.2.3.2 Removing a Subscription Record from Conflict

R5-46 SMS shall receive the following data from the user to identify the
subscription record is to be removed from conflict: the Local Number
Portability Service ID and the Ported Telephone Number Subscription ID.

R5-47 If the record status is not in conflict, SMS shall generate an
error message and send it to the request originator. SMS shall not
proceed further with the request to remove the subscription record from
conflict.

R5-48 If the record status is conflict, SMS shall validate the
subscription record. This validation process shall include the
applicable validations defined in R5-18.

R5-49 If the record fails validation, SMS shall issue an appropriate
error message to the request originator. A new subscription record shall
not be created and SMS shall not proceed further with the request to
remove the subscription record from conflict.

R5-50 If the record passes validations, SMS shall mark the record with a
status of pending in the SMS and shall issue an appropriate message to
the request originator indicating successful completion of the process
to remove a subscription from conflict.

5.1.2.2.4 Subscription Record Activation

A user requests a subscription be activated in the network by
associating a network action of \"activate\" with a record. This
functionality, which can be invoked only by the new facilities-based
service provider enables an authorized user to request that a
subscription record be activated.

R5-51 SMS shall receive the following data from the user to identify the
subscription record is to be activated: the Ported Telephone Number
Subscription ID. SMS shall record the current date and time (i.e.,
system date and time) as the Activation Date and Time Stamp.

R5-52 If the record status is not pending, SMS shall generate an error
message and send it to the request originator.

R5-53 SMS shall re-validate the subscription record as per the
validations defined in R5-18.

R5-54 If the record fails re-validation, SMS shall log the error
message(s) and make them available to authorized users, and mark the
record status as invalid in the SMS.

R5-55 If the record is valid, SMS shall determine the Local SMS
configuration data of all the Local SMSs.

R5-56 SMS shall translate the subscription record data to create
interface messages containing the information to be updated to the Local
SMSs.

R5-57 SMS shall send the interface messages to the Local SMSs. The
subscription record shall be marked with a status of sending in the SMS.
SMS shall record the current date and time (i.e., system date and time)
as the Broadcast Date and Time Stamp in the subscription record.

R5-58 SMS shall log the activation responses resulting from the
activation requests sent to the Local SMSs. SMS shall allow users (with
the appropriate security permissions) to view this information. The
length of time that data will remain in this log shall be a parameter
that is tuneable by the SMS Administrator.

R5-59 If a positive acknowledgment is received from all involved Local
SMSs, then the subscription record shall be marked with a status of
active in the SMS and the previously active record (if one exists) for
the same subscription (i.e., ported TN) shall be marked as old.

R5-60 If the record fails activation in some of the Local SMSs to which
it was sent (e.g., the link between SMS and a specific network node is
down), the update shall remain in queue and shall be resent to the Local
SMSs where activation failed. The number of automatic resends and the
interval between resends shall be parameters that can be modified by the
SMS Administrator. There shall be a default of three (3) for the number
of retries and a default of two (2) minutes for the interval between
resends. During this period, the status of the record shall remain
\"sending.\" Once the maximum queue time is exceeded, SMS shall consider
the record to have failed activation at specific Local SMSs. SMS shall
mark the status of the previously active record (if one exists) for the
subscription (i.e., ported TN) as old. SMS shall send a notification to
the NPAC System Administrator. This notification shall include the list
of the Local SMS(s) where activation failed. Special processing must be
invoked by the NPAC System Administrator to resend the subscription
record to the Local SMS(s) where it failed activation. The subscription
record shall be marked with a status of failed and an indication that
the failure was partial.

R5-61 If the record fails activation in all the Local SMSs to which it
was sent, SMS shall mark the status of the record as failed. If there is
a current active subscription record, it shall remain active. SMS shall
send a notification to the NPAC System Administrator indicating that the
subscription failed activation at all Local SMSs. Special processing
must be invoked by the NPAC System Administrator to resend the
subscription. The subscription record shall be marked with a status of
failed.

5.1.2.2.5 Disconnect Subscription Record

When a user requests that an active subscription be disconnected, it
will be deleted from the network. This functionality, which can be
invoked only by the new facilities-based service provider, enables the
user to remove an active record from the network. The user-supplied
Disconnect Date indicates when the customer\'s service was disconnected.
The user supplied Broadcast Disconnect Date indicates when the update
should be broadcast.

R5-62 SMS shall receive the following data from the user to identify the
subscription record is to be deleted: the Local Number Portability
Service ID and the Ported Telephone Number Subscription ID.

R5-63 If there is no subscription record with a status of active, SMS
shall notify the request originator that the record is not active in the
network and cannot be disconnected

R5-64 If there is a subscription record with a status of pending,
invalid, failed, or conflict and there is also a subscription record
with a status of active, SMS shall notify the request originator that
the active record cannot be disconnected until the pending, invalid,
failed, or conflict record is canceled. SMS shall not proceed with the
request.

R5-65 If the status of the current record for the subscription is
active, SMS shall do the following:

determine from the disconnect broadcast date when the update needs to be
broadcast:

 If the disconnect broadcast date is prior to the current date, equal
to the current date or blank it will broadcast the update immediately,

 If the disconnect broadcast date is beyond the current date then the
system will broadcast the update on that date,

once the broadcast date is determined the system shall translate the
pending disconnect request to create an interface message identifying
the subscription to be deleted by the Local SMSs,

send the disconnect message to the Local SMSs, and

mark the disconnect request with the status sending. SMS shall record
the current date and time (i.e., system date and time) as the Broadcast
Date and Time Stamp in the disconnect request.

R5-66 If the disconnect request succeeds in all the Local SMSs, SMS
shall mark the current active subscription record with a status of old,
shall update the Disconnect Date to the old subscription record, and
shall mark the disconnect request as old.

R5-67 If the disconnect request fails in all of the Local SMSs, the
status of the disconnect request shall be changed to failed. The current
active subscription record shall remain active. SMS shall send a
notification to the NPAC System Administrator that the disconnect
request failed. Special processing must be invoked by the NPAC System
Administrator to resend the disconnect request to the Local SMS(s).

R5-68 If the disconnect request fails in some of the Local SMSs to which
it was sent (e.g., the link between SMS and a specific network node is
down), the disconnect request shall remain in queue and shall be resent
to the Local SMSs where the disconnect failed. The number of automatic
resends and the interval between resends shall be parameters that can be
modified by the SMS Administrator. There shall be a default of three (3)
for the number of retries and a default of two (2) minutes for the
interval between resends. During this period, the status of the
disconnect request shall remain \"sending.\" Once the maximum queue time
is exceeded, SMS shall consider the disconnect request to have failed at
specific Local SMSs. SMS shall send a notification to the NPAC System
Administrator. This notification shall include the list of the Local
SMS(s) where the disconnect request failed. Special processing must be
invoked by the NPAC System Administrator to resend the disconnect
request to the Local SMS(s) where it failed. The disconnect request
shall be marked with a status of failed and an indication that the
failure was partial.

5.1.2.2.6 Subscription Record Cancellation

Only subscription records with a status of pending, invalid, or conflict
can be canceled. A user requests that a pending, invalid or conflict
subscription be canceled in SMS by associating an action of \"cancel\"
with a record. This functionality enables a user to cancel a
subscription record that has not yet been activated in the network.
Additionally, only NPAC personnel can cancel a subscription record with
a status of conflict.

R5-69 SMS shall receive the following data from the user to identify the
subscription record to be canceled: the Ported Telephone Number
Subscription ID.

R5-70 If there is no subscription record with a status of pending,
invalid, or conflict, SMS shall issue an appropriate error to the
request originator and shall not proceed with the request.

R5-71 If there is a subscription record with a status of pending,
invalid, or conflict, SMS shall mark the subscription record with a
status of canceled and record the current date and time (i.e., system
date and time) as the **Cancellation** Date and Time Stamp.

5.1.3 Subscription Queries

The query functionality discussed in this section will give users the
ability to view subscription data without being able to update that
data. A user may not be able to modify a particular data item because
that user does not have the proper security permissions and the data is
made available via SMS for read-only purposes.

Assumptions

Users will need to be able to retrieve subscription data that they
cannot modify.

Users shall submit query requests for subscription data based on a
single ported TN only.

Any authorized SOA User personnel shall be able to view any subscription
record for any ported TN.

User Functionality

R5-72 An authorized SMS user shall be able to invoke the following
functionality in the SMS to query subscription data:

Query data stewarded by SMS for a subscription and all its records.

System Functionality

The following specifies SMS functionality needed to support the user
requests defined above.

R5-73 For queries regarding subscription data, SMS shall receive the
Ported Telephone Number Subscription ID, and optionally, the status of
the subscription record (e.g., active, pending).

R5-74 If multiple subscription records are found, and the user has
provided the status of the subscription record desired, SMS shall
retrieve only the data associated with that status of the subscription
record only. Otherwise SMS shall return all subscription record data
associated with the ported TN. The parameters to be returned, as
appropriate for the subscription record status, are as follows:

Ported Telephone Number(s)

Due Date

New facilities-based service provider ID

Old facilities-based service provider ID

Authorization from old facilities-based SOA User

Location Routing Number (LRN)

Global Title Translation (GTT) and Destination Point Code (DPC)
information as per Table 3-1.

Billing Service Provider ID

End-User Location Value

End User Location Type

Disconnect Date

Conflict Date and Time Stamp

Activation Date and Time Stamp

Broadcast Date and Time Stamp

Cancellation Date and Time Stamp

R5-75 If SMS does not have a subscription record as specified by the
request originator, SMS shall provide the request originator with a
message indicating that there was no data in SMS that matched the search
keys.

Section 6: NPAC SMS Interfaces

Two interfaces to the NPAC SMS shall be supported. The first interface
shall be between the NPAC SMS and the SOA User\'s Service Order
Activation platform and the second shall be between the NPAC SMS and the
Local SMSs. Both of the interfaces shall support two-way communications.

6.1 SOA to NPAC SMS Interface

The SOA to NPAC SMS Interface could be used by a variety of local
service provider systems for retrieving and updating subscription data
in an NPAC SMS. The types of systems that are expected to use this
interface are Service Provisioning OSs and/or Gateway Systems.

![](media/image1.emf){width="4.177083333333333in"
height="2.6770833333333335in"}

6.1.1 Request Administration

The SOA to NPAC Interface will support three types of transactions:
subscription request and view request transactions from the front end
system (e.g., the SOA) interface users, and response and notification
transactions from the NPAC SMS. The Interface will require security
features to ensure that data is not corrupted by unauthorized access.
Security management is outside the scope of the interface, however, the
Interface user will be required to provide parameters to support
security management at the NPAC SMS.

R6-1 Associations on these application to application interfaces must
use strong authentication.

R6-2 Each subscription administration request sent over the Interface
shall be capable of supporting multiple independent transactions. One
failed item in a request will not cause other items in the request to
fail. See ANSI standard T1.246, Operations, Administration, Maintenance
and Provisioning (OAM&P) - Information Model and Services for Interfaces
between Operations Systems across Jurisdictional Boundaries to Support
Configuration Management - Customer Account Record Exchange (CARE) for
an example of a GDMO (ISO 10165-4) description of an interface that can
deal with bunched transactions.

R6-3 Each subscription administration request shall be acknowledged with
at least one response transaction from the NPAC SMS. Some requests may
be acknowledged more than once. For example, after validation processing
is completed a response transaction would be sent back to the user with
either a positive acknowledgment or a negative acknowledgment with an
error message indicating the results of the validation.

R6- The SOA interface shall support the update of service provider data.

6.1.2 Subscription Administration

Subscription Administration provides functionality in creating or
modifying subscriptions and activating or deleting them from the
networks. Based on security parameters, users of the interface shall be
able to do the following:

R6-4 Add new records of subscription data, as well as cancel or modify a
specific record of subscription data.

R6-5 View subscription data, including either specific records of a
subscription or all records.

R6-6 Request the activation or deletion of subscription data.

6.1.3 Notifications

NPAC SMS shall have functionality to send notifications to NPAC/SMS
Users based on parameters which are tuneable by the NPAC SMS
Administrator. NPAC SMS shall be able to do the following via the
interface:

R6-7 Notify a new or an old NPAC/SMS User that they haven\'t provided
authorization for a transfer of service for a TN.

R6-8 Notify an old NPAC/SMS User that the Due Date for a subscription
has been modified.

6.2 NPAC SMS to Local SMS Interface

The NPAC SMS to Local SMS Interface could be used to send subscription
data and audit requests to a variety of NPAC/SMS User systems. The types
of systems that are expected to use this interface are Local SMSs (or
SMS-like functionality at LNP SCPs) and/or Gateway Systems. The
interface will require security features to ensure that data is not
corrupted by unauthorized access. Security management is covered in
Section 7, however, the interface user will be required to provide
parameters to support security management at the NPAC SMS.

![](media/image2.emf){width="4.177083333333333in"
height="2.6770833333333335in"}

6.2.1 Transaction Administration

The NPAC SMS to Local SMS Interface will support five types of
transactions: subscription download transactions from the NPAC SMS, view
requests from the NPAC SMS, network data download transactions from the
NPAC SMS, response transactions from the Local SMS, and requests from
the Local SMS that specific transactions be resent.

R6-9 Interface users shall specify their user-identification, system
identification, and password to be able to use the Interface.

R6-10 Each subscription download request sent over the interface shall
be capable of supporting multiple independent transactions. One failed
item in a request will not cause other items in the request to fail.

R6-11 Each subscription download request shall be acknowledged with at
least one response transaction from the Local SMS. A response
transaction shall be sent back to the NPAC SMS with either a positive
acknowledgment or a negative acknowledgment which may include a request
that the transaction be sent again.

R6-12 Each view request sent over the interface shall be for a single
transaction or for a range of transactions.

R6-13 Each view request shall be acknowledged with a response from the
NPAC SMS with the requested data.

R6-14 A local SMS shall be able to request the NPAC SMS to resend a
subscription based on its TN or a block of subscriptions based on a time
window specified in the request. This function might be provided by
allowing for an audit request from the local SMS.

R6-15 Each network data download request shall be acknowledged with one
response transaction from the Local SMS. A response transaction shall be
sent back to the NPAC SMS with either a positive acknowledgment or a
negative acknowledgment which may include a request that the transaction
be sent again.

6.2.2 Network Subscription Administration

Network Subscription Administration provides functionality in
activating, modifying, or deleting subscription data from the network
and in requesting views. The NPAC SMS, via its interface to Local SMSs
shall be able to do the following:

R6-16 Add new subscription data, as well as delete or modify specific
subscription data.

R6-17 Request audits of subscription data, including either a specific
subscription or a range of subscriptions.

6.3 Interface Transactions

The CMIP protocol provides for six types of transactions over the
interface (Reference: ISO 9595 and 9596). They are Create, Delete, Set,
Get, Cancel-Get, and Notification. The first five transactions are
originated by the manager, and affect objects contained in the agent.
The Notification transaction is created by the agent and is used to give
notice to the manager that something of interest to the manager has
happened to an object in the agent system.

R6-18 The object model shall be designed in terms of using these
transactions in a manager-agent relationship.

6.4. Interface and Protocol Requirements

While it is expected that dedicated links will be used for the
interfaces, switched connections should also be supported. Reliability
and availability of the links will be essential and high capacity
performance will be needed.

R6-19 The SOA to NPAC SMS Interface and the NPAC SMS to Local SMS
Interface shall be an open, non-proprietary interface.

6.4.1 Protocol Requirements

Both of the NPAC SMS interfaces, as defined above, shall be implemented
via the following protocol stack:

R6-20:

Application: ASCE, CMISE/ROSE (ANSI T1.224)

Presentation: as described in ANSI T1.224

Session: as described in ANSI T1.224

Transport: OSI Transport Class 0, RFC 1006, and TCP

Network: Internet (IETF) IP

Link: ethernet routing, or frame relay, or ATM\
(or more than one of these)

Physical: as appropriate

R6-21 Multiple associations per NPAC/SMS User may be required.

6.4.2 Interface Performance Requirements

R6-22 Both the SOA to NPAC SMS and the NPAC SMS to Local SMS shall be
available on a 24 by 7 basis.

R6-23 A 99.9 % availability rate shall be maintained for both
interfaces.

R6-24 A transaction rate of about 1 transaction per second shall be
supported by each SOA to NPAC SMS interface association (See Section 10
for number of associations).

R6-25 A transaction rate of about 1 transaction per second shall be
supported by each NPAC SMS to Local SMS interface association (See
Section 10 for number of associations).

6.4.3 Interface Specification

The primary vendor will be asked to build to an existing interface
specification that is being/will be used for other NPAC SMSs. The
interoperable interface model is specified in terms of ISO 10165-4+
Generalized Definition of Managed Objects (GDMO). A copy of the
interoperable interface specification should be available for
distribution to all vendors that prequalify.

R6-26 Any additions/modifications to the interface specification will be
documented and become the property of the NYCAC, which may make them
public at any time.

R6-27 LSMS users must be able to choose which NPA-NXXs they will receive
broadcasts for.

Section 7: Security Requirements

Introduction

In addition to the general security requirements based on the user
interface paradigm in Section 7.1 through 7.7, there are requirements
for the security on an OSI application to application interface (such as
the one specified in Section 6 for the NPAC SMS to LSMS and NPAC SMS to
SOA interfaces). Section 7.8 describes such a security environment.

7.1 Identification

A user identification is a unique, auditable representation of the
user\'s identity within the system. The SMS requires all system users,
both individuals and remote machines, to be uniquely identified to
support individual accountability.

R7-1 Unique user identification codes (userids) must be utilized to
identify individuals and remote machines.

R7-2 SMS must require users, i.e., individuals and remote machines, to
identify themselves with their assigned userid before performing any
actions. There will be different userids for the LSMS function and the
SOA function for users that are both LSMS users and SOA users.

R7-3 SMS must maintain internally the identity of all currently active
users.

R7-4 Every process running on SMS must have associated with it the
userid of the invoking user (or the userid associated with the invoking
process).

R7-5 SMS must disable userids after a period of time during which the
userid has not been used. The time must be NPAC-specifiable with a
system delivered default of 60 days.

R7-6 SMS must provide a complementary mechanism or procedure for the
re-instatement or deletion of disabled userids.

R7-7 SMS must support the temporary disabling of userids.

R7-8 The mechanism that disables userids should provide an option for
automatic reactivation.

R7-9 SMS must control and limit simultaneous active usage of the same
userids by allowing only one active login. When the second login is
entered, the system will ask if the first login can be disconnected. If
the user replies yes, the second login can continue; however, if the
user replies no, the second login is terminated.

7.2 Authentication

The identity of all system users, both individuals and remote machines,
must be verified or authenticated to enter the system, and to access
restricted data or transactions.

R7-10 SMS must authenticate the identity of all system users, both
individuals and remote machines, prior to their initially gaining access
to SMS.

R7-11 SMS must not support ways to bypass the identity authentication
mechanisms.

R7-12 SMS must protect all internal storage of authentication data so
that it cannot be accessed by any unauthorized user.

7.2.1 Password Requirements

R7-13 SMS shall not provide a mechanism whereby a single password entry
can be shared by multiple userids.

R7-14 SMS must not prevent a user from choosing a password that is
already associated with another userid.

R7-15 SMS must store passwords in a one-way encrypted form.

R7-16 Encrypted passwords must not be accessible to non-privileged
users.

R7-17 Unencrypted passwords must not be accessible to any users,
including NPAC personnel.

R7-18 SMS must automatically suppress or fully blot out the clear-text
representation of the password on the data entry device, e.g., terminal.

R7-19 Passwords should not be sent over public or shared data networks
in clear text.

R7-20 SMS must not allow for any password to be null.

R7-21 SMS must provide a mechanism to allow passwords to be
user-changeable. This mechanism must require re-authentication of the
user identity.

R7-22 The NPAC must have a mechanism to reset passwords.

R7-23 SMS must enforce password aging, i.e., passwords must be required
to be changed after a NPAC-specifiable time. The system supplied default
shall be 90 days.

R7-24 SMS must provide a mechanism to notify users in advance of
requiring them to change their passwords. This can be done by one of the
following methods:

\(1\) SMS will notify users a NPAC-specifiable period of time prior to
their password expiring. The system supplied default shall be seven
days.

\(2\) Upon password expiration, SMS will notify the user, but allow an
NPAC-specifiable subsequent number of additional logons prior to
requiring a new password. The system supplied default shall be two
additional logins.

R7-25 Password must not be reusable by the same individual for an
NPAC-specifiable period of time. The system supplied default shall be
six months.

R7-26 SMS must provide a method of ensuring the complexity of
user-entered passwords that meets the following requirements:

\(1\) Passwords must contain a combination of at least six alphanumeric
characters including at least one alphabetic and one numeric or
punctuation character. If the system does not distinguish between upper
and lower case alphabetic characters, the minimum acceptable length is
eight characters.

\(2\) Passwords must not contain the associated userid.

R7-27 SMS-supplied password generation algorithms must meet the
following requirements:

\(1\) Passwords must be \"reasonably\" resistant to brute-force password
guessing attacks, i.e., the total number of system generated passwords
must be on the same order of magnitude as what a user could generate
using the rules specified in requirement 7-26 (1) above.

\(2\) The generated sequence of passwords must have the property of
randomness, i.e., consecutive instances must be uncorrelated and the
sequences must not display periodicity.

7.3 Access Control

Access to the SMS and other resources must be limited to those users
that have been authorized for that specific access right.

7.3.1 System Access

R7-28 SMS must allow access to authorized users and authorized remote
systems.

R7-29 SMS must provide a procedure for the initial entry or modification
of authorized users and authentication information.

R7-30 SMS must not provide any default userids that can permit
unauthenticated SMS access.

R7-31 SMS\'s login procedure should be able to be reliably initiated by
the user, i.e., a trusted communications path should exist between SMS
and the user during the login procedure.

R7-32 SMS must disconnect or re-authenticate users after an
NPAC-specifiable period of non-use. The system supplied default shall be
60 minutes.

R7-33 The SMS login procedure must exit and end the session if the user
authentication procedure is incorrectly performed an NPAC-specifiable
number of times. The system supplied default shall be three times.

R7-34 SMS must provide a mechanism to immediately notify the NPAC when
the above threshold is exceeded.

R7-35 When the above threshold has been exceeded, an NPAC-specifiable
interval of time, not to exceed 60 seconds, must elapse before the login
process can be restarted on that I/O port.

R7-36 SMS must not suspend the userid upon exceeding the above
threshold.

R7-37 SMS must perform the entire user authentication procedure even if
the userid that was entered was not valid.

R7-38 Error feedback must provide no other information except
\"invalid,\" i.e., it must not reveal which part of the authentication
information is incorrect.

R7-39 SMS should provide a mechanism to exclude or include users based
on time-of-day, day-of-week, calendar date, etc.

R7-40 SMS should provide a mechanism to exclude or include users based
on method or location of entry.

R7-41 SMS must provide a mechanism to limit the users authorized to
access the system via dial-up facilities.

R7-42 SMS must provide a mechanism to limit system entry for privileged
NPAC users on an NPAC-specifiable network access or per-port basis.

R7-43 Since some form of network access, e.g., dial-in, Wide Area
Network, or Internet, is provided by SMS, SMS must provide a strong
authentication mechanism. For example, the authentication mechanism
could be a private or public key encryption-based mechanism, an
additional password, and/or smart card to validate the user or remote
system. For remote machines, public key encryption may be required in
conjunction with dedicated private lines. For dial-in users (NPAC
administrative and NPAC operations), smart cards are required.

R7-44 A mechanism must exist to end the session through secure logoff
procedures.

R7-45 SMS must provide an advisory warning message upon system entry
regarding unauthorized use, and the possible consequences of failure to
meet those requirements.

R7-46 The message must be NPAC-specifiable to meet their own
requirements, and any applicable laws.

R7-47 SMS must be able to display a message of up to 20 lines in length.
This message should be displayed at the first point of entry. If
possible, the message should appear before the logon process. As part of
the delivered software, the following is an example of the default
message that must be included:

**NOTICE: This is a private computer system.**

**Unauthorized access or use may lead to prosecution.**

R7-48 Upon successful access to the system, the following must be
displayed:

\(1\) Date and time of the user\'s last successful system access.

\(2\) The number of unsuccessful attempts by that userid to access the
system, since the last successful access by that userid.

R7-49 SMS must allow only the NPAC well-defined privileged users
responsible for security administration to authorize or revoke users.

R7-50 Procedures for adding and deleting users must be well defined and
described in the NPAC security documentation.

7.3.2 Resource Access

R7-51 Only authorized users shall be able to access the data that is
part of or controlled by the SMS system.

R7-52 Each service provider\'s data must be protected from access by
unauthorized users.

R7-53 Only authorized users shall be able to access the transactions,
data, and software that constitute the SMS.

R7-54 The executable and loadable software must be access controlled for
overwrite and update, as well as execution rights.

R7-55 Control of access to resources must be based on authenticated user
identification.

R7-56 Encryption may be used to augment the access control mechanisms,
but must not be used as a primary access control mechanism for sensitive
data.

R7-57 For every resource controlled by SMS, it must be possible to grant
access rights to a single user or a group of users.

R7-58 For every resource controlled by SMS, it must be possible to deny
access rights to a single user or a group of users.

R7-59 It will be necessary to restrict user access to information based
on the data content of a specific field, attribute, tuple, record, etc.

R7-60 Modification of the access rights to a resource must only be
allowed by the NPAC.

R7-61 SMS must provide a mechanism to remove access rights to all
resources for a user or a group of users.

R7-62 The access control mechanism\'s data files and tables must be
protected from unauthorized access.

7.4 Data and System Integrity

R7-63 SMS must be able to identify the originator of any accessible
system resources.

R7-64 SMS must be able to identify the originator of any information
received across communication channels.

R7-65 SMS must provide mechanisms or procedures that can be used to
periodically validate the correct operation of the system. These
mechanisms or procedures should address:

\(1\) Monitoring of system resources

\(2\) Detection of error conditions that could propagate through the
system

\(3\) Detection of communication errors above/below an NPAC-specifiable
threshold

\(4\) Detection of Link Outages.

R7-66 SMS must be designed and developed to protect data integrity. This
should include some or all of the following:

\(1\) Proper rule checking on data update

\(2\) Proper handling of duplicate/multiple inputs

\(3\) Checking of return status

\(4\) Checking of inputs for reasonable values

\(5\) Proper serialization of update transactions.

R7-67 NPAC documentation must contain recommendations for running
database integrity checking utilities on a regular basis.

7.5 Transaction Audit Log Generation

7.5.1 Audit Log Generation

R7-68 SMS must generate an audit log that contains information
sufficient for after-the-fact investigation of loss or impropriety and
for appropriate response, including pursuit of legal remedies. The audit
data shall be available on-line for a minimum of 90 days, and archived
off-line for a minimum of two years.

R7-69 The user-identification associated with any SMS request or
activity must be maintained, so that the initiating user can be
traceable.

R7-70 SMS must protect the audit log from unauthorized access.

R7-71 Only well-defined privileged NPAC personnel can modify or delete
any or all of the audit log.

R7-72 The audit control mechanisms must be protected from unauthorized
access.

R7-73 SMS must cause a record to be written to the security audit log
for at least each of the following events:

\(1\) Invalid user authentication attempts

\(2\) Logins and activities of NPAC users

\(3\) Unauthorized data or transaction access attempts.

R7-74 Auditing of NPAC actions must not be able to be disabled.

R7-75 For each recorded event, the audit record must contain, at a
minimum:

\(1\) Date and time of the event

\(2\) User identification including associated terminal, port, network
address, or communication device

\(3\) Type of event

\(4\) Name of resources accessed

\(5\) Success or failure of the event.

R7-76 Actual or attempted passwords must not be recorded in audit logs
until after an NPAC-specifiable threshold of consecutive login failures.
The SMS supplied default shall be three failures.

7.5.2 Reporting and Intrusion Detection

R7-77 SMS must provide post-collection audit analysis tools that can
produce exception reports, summary reports, and detailed reports on
specific data items, users, or communication failures.

R7-78 The NPAC must be able to independently and selectively review the
actions of any one or more users, including other NPAC users, based on
individual user identity.

R7-79 SMS must provide tools for the NPAC to monitor the activities of a
specific network address or terminal in real time.

R7-80 SMS should contain a real-time mechanism that is able to monitor
the occurrence or accumulation of security auditable events that may
indicate an imminent security violation. This mechanism shall be able to
notify the NPAC immediately when thresholds are exceeded, and if the
occurrence or accumulation of these security relevant events continues,
SMS shall take the least disruptive action to terminate the event.

7.6 Continuity of Service

R7-81 No service provider action, either deliberate or accidental,
should cause the system to be unavailable to other users.

R7-82 SMS should detect and report conditions that would degrade service
below a pre-specified minimum.

R7-83 Procedures or mechanisms must be provided to allow recovery after
a system failure or other discontinuity without a protection compromise.

R7-84 Procedures shall be documented for software and data backup and
restoration.

R7-85 The system must contain a database containing the exact revision
number of the latest software installed.

7.7 Software Vendor

R7-86 The SMS software vendor must have a corporate policy governing its
internal development of software. This policy must contain specific
guidelines and requirements that are aimed at the security of its
products, and are applicable throughout the software life cycle.

R7-87 The SMS software vendor shall not design any mode of entry into
the SMS for maintenance, support, or operations that would violate or
bypass any security procedures.

R7-88 The SMS software vendor shall not design any mode of entry into
the SMS for maintenance, support, or operations that is not a documented
feature of the SMS.

7.8 OSI Security Environment

This section examines potential threats to the NPAC SMS interfaces and
proposes a set of security requirements to thwart such threats.

The security mechanisms described in the OSI Security segment are meant
to illustrate the level of security and flexibility that is required for
the OSI interfaces specified. The response to the RFP may propose
different security mechanisms than the ones described. However, such
security mechanisms should provide at least the same level of security
and at least the same level of flexibility as the mechanisms described.
The proposed mechanisms shall not be more difficult to manage, and
should not require more processing or transmission capacity than the
mechanisms described below.

7.8.1 Threats

Attacks against the NPAC SMS may be perpetrated in order to achieve any
of the following:

Denial of service to a customer by placing wrong translation information
in the SMS

Denial of service to a customer by preventing a valid message from
reaching the SMS

Disrupting a carrier\'s operations by having numerous spurious calls (to
users who are not clients of that carrier) directed to that carrier

Switching customers to various carriers without their consent

Disrupting the functioning of the NPAC SMS by swamping it with spurious
messages.

7.8.2 Security Services

The threats enumerated above can be thwarted by using the following
security services:

R7-89 Authentication (at association setup)

R7-90 Data origin authentication for each incoming message

R7-91 Integrity - detection of replay, deletion or modification to a
message

R7-92 Non-repudiation of origin

R7-93 Access control - allowing only authorized parties (i.e., carriers
serving a given customer) to cause changes in the NPAC SMS database.

7.8.3 Security Mechanisms

This section outlines the requirements for specific security mechanisms
to support the security services enumerated above. For simplicity of
presentation and without loss of generality, it assumes that information
in the NPAC SMS is modified only in response to CMIP notifications from
authorized entities.

7.8.3.1 Encryption

R7-94 Since non-repudiation must be supported a Public Key Crypto System
(PKCS) must be used to provide digital signatures. Since there is no
requirement for confidentiality service there is no need for any
additional encryption algorithms. The NPAC SMS shall support one of the
digital signature algorithms listed in the OIW Stable Implementation
Agreement, Part 12, 1995.

R7-95 If a digital signature based on RSA encryption is chosen then the
size of the modules of each key shall be at least 600 bits. If another
algorithm is chosen then the size of the key(s) shall be chosen to
provide a level of security commensurate with RSA encryption with a
600-bits modules.

R7-96 The digital signature algorithm shall be applied to ASCII
representation of the signed data fields, without any separators between
those fields or any other additional characters.

7.8.3.2 Authentication

R7-97 Strong, two-way peer authentication at association setup time
shall be provided by using an authenticator (based on the authenticator
used for the Trouble Administration application of Electronic Bonding as
described in Committee T1 Technical Report No. 40 \"Security
Requirements for Electronic Bonding Between Two TMNs\") consisting of:

1.  The unique identity of the sender

```{=html}
<!-- -->
```
1.  The Generalized Time corresponding to the issuance of the message,
    each party is responsible to assure that its system clock is
    accurate to within two minutes of GMT

```{=html}
<!-- -->
```
1.  A sequence number (equal to zero for association request and
    association response messages)

```{=html}
<!-- -->
```
1.  A key identifier

```{=html}
<!-- -->
```
1.  Any additional parameters required by the chosen digital signature
    algorithm, as specified in OIW Stable Implementation Agreement, Part
    12, 1995

```{=html}
<!-- -->
```
1.  The digital signature of the sender\'s identity, Generalized Time
    and sequence number listed above.

R7-98 The authenticator shall be conveyed in the CMIP access control
field. (An appropriate syntax for this EXTERNAL field shall be
provided.)

7.8.3.3 Data Origin Authentication

R7-99 Every subsequent CMIP message that contains the access control
field shall carry the authenticator described above in that field. Each
party maintains a separate counter for the sequence number it uses.
Every time the authenticator is used the value of the sequence number
shall be incremented by one.

7.8.3.4 Integrity and Non-repudiation

R7-100 Because CMIP notifications do not have an access control field,
all the notifications defined for the number portability application
shall contain a security field. The syntax of the security field shall
correspond to the authenticator defined above.

R7-101 The values of the components of the authenticator shall also be
as specified for the authenticator above, except that the digital
signature shall apply to all the fields in the notification, except the
security field, in the order in which they appear, followed by the
Generalized Time and the sequence number. This ensures data origin
authentication, integrity and non-repudiation of origin for each
notification. In particular, the Generalized Time and the sequence
number allow detection of deletion, replay and delay.

R7-102 All the notifications shall be sent in the confirmed mode.

7.8.3.5 Access Control

R7-104 The NPAC SMS shall be responsible for access control. In
particular, it will assure that only authorized parties (current and
future service providers for a given customer) can change information
related to the number associated with that customer.

R7-105 The only initiator-provided access control information that shall
be used to this effect is the authenticated identity of the sender of
the message that would result in a modification to the NPAC SMS
database, and the value of the Generalized Time in that message (it
should be within five minutes of the NPAC SMS system clock).

7.8.3.6 Audit Trail

R7-106 The NPAC SMS shall keep a log (as defined in ISO/IEC 10164 parts
6 and 8, 1992) of all incoming messages that result in the setup or
termination of associations, all invalid messages (invalid signature,
sequence number out of order, Generalized Time out of scope, sender not
authorized for the implied request) as well as all incoming messages
that may cause changes to the NPAC SMS database.

7.8.3.7 Key Exchange

R7-107 There shall be an exchange of keys between the NPAC and each
carrier it serves. During this exchange each party shall provide the
other with a list of keys. The list shall be provided in electronic
form. The originator of list of keys shall also provide the receiver
with signed (in ink) paper copy of the MD5 hashes of the keys in the
list. The lists can be exchanged in person or remotely. If the lists are
exchanged remotely, they shall be conveyed via at least two different
channels (e.g., a diskette sent via certified mail and file sent via
e-mail).

R7-108 Upon remote reception of a list of keys the recipient shall send
an acknowledgment to the sender of the list. The acknowledgment shall
consist of the MD5 hash of each one of the keys in the list. The
acknowledgment shall be provided in electronic form via at least two
different channels. In addition, the recipient shall call the sender by
phone for further confirmation, and provide the sender with the MD5 hash
of the whole list.

R7-109 The NPAC shall issue periodically (e.g., once a month) a paper
list of the MD5 hashes of all the public keys it uses and those of its
clients. The list shall be sent to each client. Upon reception of the
list and verification of its own the NPAC\'s public keys hashes, the
client shall return an acknowledgment (by phone or mail) to the NPAC.

R7-110 Each list shall consist of 1000 encryption keys, numbered from 1
to 1000, and 10 Key Encryption Keys (KEK), numbered from 1001 to 1010.
Only encryption keys shall be used for digital signatures for normal
number portability operations. They shall range in size (if RSA
encryption is used) from 600 bits to 900 bits. (Larger keys shall be
used in future years.) KEKs shall be used only to transmit a new list of
keys, if necessary. The whole new list will be signed using a KEK. KEK
sizes shall range from 1000 bits to 1200 bits (if RSA encryption is
used). Keys in subsequent list shall be numbered from 2000 to 3010, 3000
to 4010, etc.

R7-111 A new encryption key can be chosen with every message that
contains a key identifier. After the usage of a key has stopped, that
key shall not be used again. The key shall be changed every time there
is a suspicion that the key has been compromised. The key shall be
changed at least once a year. The keys used during a year shall be
larger than the keys used the previous year by at least 20 bits.

Section 8: Audits

Overview

The NPAC SMS will provide three types of functionality to insure
database integrity between service providers\' SOA/SMS and the NPAC SMS.
A service provider can verify what is in the NPAC SMS, the NPAC SMS can
verify what is in a local SMS, and the NPAC SMS can initiate periodic
audits against local SMSs.

8.1 Service Provider Verify of Data in NPAC SMS

R8-1 A local SMS or SOA will be able to request data from the NPAC SMS
for a given TN or a range of TNs. The local SMS or SOA may request all
data for a TN or specific fields.

R8-2 For audit requests from a local SMS or SOA to the NPAC SMS, the
size of the range of TNs will be limited by a tuneable parameter.

R8-3 Only the old and new service providers can request data for records
in a pending or conflict state.

8.2 Periodic Audits

R8-4 The NPAC SMS will perform bulk periodic audits against local SMS\'s
data. The request may specify individual or ranges of TNs and specific
data fields to be returned or that the local SMS return all data
associated with the TNs. This type of audit will be performed via FTP as
opposed to over the CMISE interface.

R8-5 NPAC personnel will be able to specify that an audit be initiated
either immediately or at a future time.

R8-6 NPAC personnel will be able to monitor the status of periodic
audits.

8.3 NPAC SMS Verify of Data in Local SMS

R8-7 The NPAC SMS will be able to request data from the local SMS\'s for
a given TN or a range of TNs. The request may be for all data for a TN
or for specific fields.

R8-8 For audit requests from the NPAC SMS to a local SMS, the size of
the range of TNs will be limited by a tuneable parameter.

Section 9: Report Management

9.1 Overview

The NPAC SMS must support scheduled and ad hoc report generation for
selectable reports. The report generation service shall create output
report files according to specified format definitions, and distribute
reports to output devices as requested.

A report distribution service is used to distribute report files to
selected output devices.

Authorized NPAC personnel can request reports from active database,
History Logs, Error Logs, traffic measurements, usage measurements, and
performance reports.

Examples of the items available from active database are:

1.  List of ported TNs for a service provider

```{=html}
<!-- -->
```
1.  List of pending subscription orders for a service provider

```{=html}
<!-- -->
```
1.  Subscriptions without concurrence

```{=html}
<!-- -->
```
1.  Status of pending subscription order for a TN being ported

```{=html}
<!-- -->
```
1.  Date/Time Stamp of Subscription Port (Activation)

```{=html}
<!-- -->
```
1.  Date/Time Stamp of Subscription Disconnect (Activation)

```{=html}
<!-- -->
```
1.  Records that required conflict resolution

```{=html}
<!-- -->
```
1.  Previous service providers and dates of service for ported TNs

```{=html}
<!-- -->
```
1.  Date/Time Stamp of Broadcast time for transactions

```{=html}
<!-- -->
```
1.  Subscription order records in error

```{=html}
<!-- -->
```
1.  Download requests in error

```{=html}
<!-- -->
```
1.  Log of Missing Response from SOA for order matching

```{=html}
<!-- -->
```
1.  Log of Missing Response from Local SMS for downloads

```{=html}
<!-- -->
```
1.  Log of Unauthorized Access Attempts

```{=html}
<!-- -->
```
1.  Counts of events and usage as described in resource accounting.

Performance Reports

1.  CPU usage.

```{=html}
<!-- -->
```
1.  Number of transactions handled and transactions per second.

```{=html}
<!-- -->
```
1.  Measure of time starting from the receipt of subscription order
    activation to the broadcast of transaction to Local SMSs.

```{=html}
<!-- -->
```
1.  Measure of time starting from the receipt of subscription order
    activation to the receipt of response from Local SMSs.

```{=html}
<!-- -->
```
1.  NPAC SMS to Local SMS link utilization.

```{=html}
<!-- -->
```
1.  NPAC SMS to SOA link utilization.

9.2 User Functionality

R9-1 The NPAC personnel must be able to select the type of report
required.

R9-2 The NPAC personnel must be able to select the output device
destination (printer or other destination) for the report.

R9-3 The NPAC personnel must be able to save/reprint reports from backed
up output files.

R9-4 The NPAC personnel must be able to create customized reports
through an ad-hoc facility.

R9-5 The NPAC personnel must be able to define scope and filtering for
items to be included in the customized reports.

R9-6 The service provider users must be able to receive reports on
information related to their activities.

R9-7 Vendors must provide examples of report outputs.

9.3 System Functionality

R9-8 The NPAC SMS must provide easy to read on-line and hard copy
reports of the requested information.

R9-9 The NPAC SMS must verify whether the user requesting the report has
the proper viewing privileges for the selected data.

R9-10 The NPAC SMS must support on-line file transfer capabilities
(e.g., FTP or FTAM) to transfer report files.

R9-11 The NPAC SMS must maintain a History Log to keep track of
transaction processed.

R9-12 The NPAC SMS must maintain an Error Log to keep track of
transaction errors, transmission errors, unauthorized access attempts.

R9-13 Vendors must specify a list of available output device options.

Section 10: NPAC SMS Reliability, Availability, Performance and Capacity

This section defines the reliability, availability, performance and
capacity requirements for the NPAC SMS.

10.1 Availability and Reliability

The NPAC SMS will be designed for high reliability, including and data
integrity features, symmetrical multi-processing capability, and allow
for economical and efficient system expansion. The system will adhere to
the following availability and reliability requirements:

R10-1 It will be available 24 hours a day, 7 days a week.

R10-2 It's reliability will be 99.9%. This applies to all functionality
and data integrity.

R10-3 The amount of unscheduled downtime per year will be \<= 9 hours.

R10-4 For unscheduled downtime, the mean time to repair will be \<= 1
hour.

R10-5 The amount of scheduled downtime per year will be \<= 24 hours.

R10-6 It will be capable of monitoring the status of all of its
communication links and be capable of detecting and reporting link
failures.

R10-7 It will be capable of detecting and correcting single bit errors
during data transmission between hardware components (both internal and
external).

R10-8 If a failure occurs resulting in downtime of any functionality,
affected transactions received immediately prior to the failure must be
queued and processed when functionality resumes.

R10-9 The design will provide:

1.  Functional components with on board automatic self checking logic
    for immediate fault locating.

```{=html}
<!-- -->
```
1.  Continuous hardware checking without any performance penalty or
    service degradation.

```{=html}
<!-- -->
```
1.  Duplexing of all major hardware components for continuous operation
    in the event of a system hardware failure.

```{=html}
<!-- -->
```
1.  Hardware that is transparent to the service providers.

R10-10 If the system becomes unavailable for normal operations due to
any reason, including both scheduled and unscheduled maintenance,
service providers must be notified of the system unavailability.

1.  When possible, the notification will be made via an electronic
    broadcast message to the service providers. When this is not
    possible, the NPAC will notify the service providers via their
    contact numbers.

```{=html}
<!-- -->
```
1.  The notification will include, at a minimum, the functionality that
    is unavailable, the reason for the downtime, estimated length of the
    downtime and a NPAC contact number.

R10-11 During any maintenance, if resources allow only partial
functionality, the capability of receiving, processing and broadcasting
updates will be given the highest priority.

R10-12 It must provide system tolerance to communication link outages
and offer alternate routing during such outages. Communication link
outages would include both vendor system hardware and/or facilities
provided by service providers. Vendors should anticipate these Sps will
be required to provide some form of communication link redunadancy with
automatic fail over handling.

R10-13 For any downtime, either schedule or unscheduled, lasting more
than 1 hour, the NPAC SMS will switch service providers to a backup or
disaster recovery machine as described in section 2. In most cases, the
time to switch the service providers to another machine and provide full
functionality must not exceed the mean time to repair . However, in the
event of a disaster that limits both the NPAC and NPAC SMS ability to
function:

1.  The capability of receiving, processing and broadcasting updates
    must be restored within 24 hours.

```{=html}
<!-- -->
```
1.  Full functionality must be restored within 48 hours.

The vendor is requested to describe the architecture used to satisfy the
reliability and availability requirements, including the use, if any, of
a backup and/or disaster recovery machine and the use of any disaster
recovery location. Alternatives to the backup and disaster recovery
process flow in section 2 should be included here.

R10-14 Reports documenting the performance of the NPAC SMS in regards to
the above requirements will be provided periodically to the service
providers.

10.2 Capacity and Performance

The following requirements define the capacity and performance of the
NPAC SMS. While the initial transaction rates and data storage
requirements are not high, the NPAC SMS is expected to provide high
performance and allow for future expansion. Refer to section 13 for
future expansion possibilities.

R10-15 The system will be engineered to allow for 50 service providers
having SOA and/or SMS interfaces. On initial turnup, it is expected
there will be 10 service providers having SOA and/or SMS interfaces.

R10-16 Describe any capacity requirements related to the NPAC personnel
who will be users of the NPAC SMS.

R10-17 It will be capable of handling the transaction rates noted in the
table below.

Assumptions used for estimating the quantity of transactions are:

1.  8 million possible TNs in an NPA

```{=html}
<!-- -->
```
1.  3% annual growth rate

```{=html}
<!-- -->
```
1.  Annual \"churn\" Rate (ported TNs which port again) is 30%

```{=html}
<!-- -->
```
1.  Market penetration increases by 4% annually

```{=html}
<!-- -->
```
1.  Market penetration stabilizes at 20% in 2003

```{=html}
<!-- -->
```
1.  Nominal porting occurs 4Q97 and is treated as 0 here

```{=html}
<!-- -->
```
1.  Both old and new service provide send up \"create\" messages

```{=html}
<!-- -->
```
1.  There are 30 local service providers

```{=html}
<!-- -->
```
1.  There are 20 interexchange carriers

```{=html}
<!-- -->
```
1.  Each new port represents 53 transactions: 2 uploads, 1 activate, and
    50 broadcasts

```{=html}
<!-- -->
```
1.  Combined local/toll carriers ignored, treated as separate

```{=html}
<!-- -->
```
1.  14.8 million estimated assigned numbers at end of year 1997

```{=html}
<!-- -->
```
1.  30.8 million estimated assigned numbers at end of year 1998

Ports Due

[Year Transactions To Churn]{.underline}

1997 nominal

1998 70 million 15%

1999 100 million 30%

2000 130 million 40%

2001 140 million 40%

2002 180 million 60%

20% Market Penetration Level Reached

2003 120 million 90%

2004 130 million 90%

Considering the accuracy of the data used to develop these transaction
volumes, they should be viewed as having, at best, one significant
digit. That is, each of these annual estimates is good within a range of
plus or minus 50,000,000.

R10-18 Data storage of the History file must keep track of all
transactions made for one year (churn and new records.) It is assumed
that there will be thirty percent churn of accumulated records.

R10-19 From the time an activation notice is received from the new
service provider to broadcast out an update until the time the update is
broadcasted to all service providers will be \< 60 seconds.

R10-20 The response time from when a request or transaction is received
in the system to the time an acknowledgment is sent to will be \< 3
seconds. This does not include the transmission time across the
interface to the service provider\'s SOA or SMS.

R10-21 The NPAC SMS must be expandable to handle any future growth due
to circumstances described in section 13.

Section 11: Billing / Resource Accounting

11.1 Overview

Resource Accounting allows the tracking of NPAC resource usage data,
which may be used as a basis for billing the service providers for their
use of NPAC functionality. Resource Accounting is responsible for
gathering the information into usage measurement categories, aggregating
the measurements, and formatting and outputting the measurements to the
appropriate entities (e.g., Billing Operations Applications, service
providers). Other potential applications for usage information include
cost allocation, marketing, and usage studies.

The NPAC system costing methods should be designed to recover initial
system costs, as well as the on-going
operations/maintenance/administration costs. The vendors shall describe
the cost drivers for NPAC HW/SW platform, including a breakdown of cost
for the major features. The vendors may propose additional/alternate
measurements that are based on their specific implementation, and
provide measure of usage of the relevant cost causing elements in the
NPAC system. The vendors shall describe their proposals for costing and
billing to the participating service providers.

The following are some examples of items measured for each service
provider:

A.  Duration of login session, date/time, service provider ID, user
    login ID, of login session

B.  Number of transactions (port/disconnect/cancel) processed

C.  Counts of types of updates made (e.g., \# of port, \# of disconnect)

D.  Number of errors encountered in transactions

E.  Number of errors encountered during transmission

F.  Number of current records maintained

G.  Number of pending records maintained

H.  Number of history records maintained

I.  Number of records downloaded as normal action

J.  Number of records sent in response to a resend request

K.  Number of records re-sent due to transmission problems

L.  Number of records in conflict

M.  Number of missing responses (e.g., during order matching)

N.  Number of records audited on request

O.  Number of records corrected (e.g., as result of audit)

P.  Number of records queried/viewed

Q.  Amount of data transported to Local SMS as bulk load update

R.  CPU usage

S.  Failures and maintenance problems in the NPAC SMS

T.  Quantity and type of links per service provider

U.  Usage of NPAC resources beyond standard day-to-day operations and
    maintenance by service providers.

Please indicate what other measurements may be made.

11.2 Assumptions

The resource accounting measurements will not cause degradation in the
performance of the basic functions of the NPAC.

11.3 User Functionality

R11-1 The NPAC personnel shall be able to turn on or off the generation
of usage measurements for each of the usage types.

11.4 System Functionality

R11-2 The NPAC SMS shall measure and record the usage of NPAC resources
on a per service provider basis to cost allocation / billing.

R11-3 The NPAC SMS shall generate usage measurements for login sessions,
for each service provider.

R11-4 The NPAC SMS shall generate usage measurements for the allocated
mass storage (number of records stored), for each service provider.

R11-5 The NPAC SMS shall measure the number of transactions processed,
for each service provider.

R11-6 The NPAC SMS shall measure the number of transactions downloaded
to each service provider.

R11-7 The NPAC SMS shall measure the number of records sent in response
to a request for resend of data from the service provider.

R11-8 NPAC should be able to render detailed periodic bills to the
contracting entity.

Section 12: Number Portability Administration Center

12.1 Number Portability Administration Center (NPAC)

NPAC Role

The NPAC will be staffed by a neutral third party contractor who will be
responsible for the administration and operational support services
required by service providers in their use of the NPAC SMS. The NPAC
must be run in support of consortium of local service providers. As a
result of agreed-to guidelines, the NPAC will be involved in local
ported number administration monitoring. Mechanized enforcement
capabilities may or may not exist in the NPAC SMS to assist the NPAC in
the monitoring and control functions.

Operational Functions

The primary roles of the NPAC are to assist users in obtaining reliable
access to the NPAC SMS and to support all users encountering local
ported number service provisioning problems resulting from NPAC SMS
operation. To meet this need, the NPAC must support the following
functional areas: System Administration, User Support, and System
Support.

Administrative Functions

Administrative functions include all management tasks required to run
the NPAC. The NPAC Contractor must be accountable for all personnel,
legal, and financial management associated with the NPAC. These include,
but are not limited to billing management, staffing, equipment and site
procurement, facilities, and the contractor\'s own accounts payable
obligations, which are part of day to day management. The NPAC
contractor must provide for the administration of its staffing,
contractual, financial, and operational needs. Proposals must specify
how this will be accomplished.

The NPAC will be responsible for working with Local service providers to
update data tables required to route calls for ported local numbers. The
NPAC is also responsible for distributing the most current version of
ported local number administration guidelines.

NPAC staff performing these activities need to combine strong project
planning skills, organizational management experience, interpersonal
communication and negotiation skills, and a clear understanding of the
day-to-day business issues associated with running a successful NPAC.
The NPAC manager and administrative staff ideally would come from a data
processing environment requiring these attributes.

System Administration

System administration is the NPAC operational group responsible for NPAC
SMS logon administration, user access and customer data security, user
notification of scheduled system downtime, and management and
administration of the NPAC SMS information tables required to link
customer records with the correct ported number service functions,
features, and network routing information.

12.2 Logon Administration

Key Responsibilities

R12-1 Assist with new logon requests

R12-2 Verify logon signature approval

R12-3 Initialize logon ID, password, and security level

R12-4 Update data base and add new users

R12-5 Notify user of logon activation

R12-6 Resolve problems with existing logon IDs or passwords.

Procedure Description

Logon Administration provides an individual requiring access to the NPAC
SMS system with a unique logon ID and password upon receipt of an
approved request form.

Access is initiated upon receipt of a completed NPAC SMS logon ID
request form having the proper signature approvals from the requesting
organization and the NPAC manager. After access approval, the logon
administrator will assign the logon ID and appropriate security level
corresponding to the type of NPAC SMS user. The user\'s security
clearance sets the correct level of customer record access and NPAC SMS
functional capabilities. After the logon is initialized and entered into
the NPAC SMS, the users are informed of the logon activation, and a
completed NPAC SMS logon ID request form is mailed back to them for
their records.

Logon administration is responsible for resolution of any of the user\'s
NPAC SMS access problems that the User Support group cannot solve. All
problems should be recorded as NPAC consultation reports and entered as
trouble reports into a mutually agreed upon trouble reporting system.
The NPAC must attempt to resolve all problems in real-time. Those
requiring additional assistance will be assigned a priority level in the
trouble report system and the appropriate NPAC SMS support group will be
contacted directly. The NPAC is required to report issue resolution
status back to the reporting party on a timely basis.

12.3 Customer Record Security

Key Responsibilities

R12-7 Establish user boundaries through user access permission classes

R12-8 Assign new users to the correct security permission class

R12-9 Exercise absolute control of access to customer information

R12-10 Monitor and report unauthorized system access attempts and
security violations

Procedure Description

Closely linked with logon administration is the procedure that provides
the correct level of system access and customer data record access. The
permitted level of access depends on the classification of NPAC SMS
user. Before any logons are assigned, a security group will be
associated with a specific classification of NPAC SMS user. The NPAC
will establish boundaries for the appropriate level of customer record
access and feature set functionality.

When the security groups are configured, any logon request that is
received must be assigned to the correct user class. The logon
Administrator is responsible for determining the correct group based on
the organization that originates the request.

12.4 Scheduled System Unavailability Notification

Key Responsibilities

R12-11 Notify users in advance of planned or known system unavailability

Procedure Description

In concert with the System Support group, System Administration is
responsible for notifying NPAC SMS users of scheduled periods of system
shutdown. These periods may be due to routine maintenance of the system
or the result of non-critical system failures that require a brief and
immediate shutdown of the system for repairs. Users are given sufficient
warning to complete their current transactions and exit the system
without loss of information. Users will usually be made aware of periods
of system shutdown via electronic mail capabilities of the NPAC SMS or
other methods as agreed to with individual users.

12.5 Software Release Acceptance Testing

Key Responsibilities

R12-12 Update software test plans

R12-13 Allocate staff for performing tests

R12-14 Execute test plans

R12-15 Generate and resolve testing trouble reports

R12-16 Document test results

R12-17 Certify NPAC SMS software and release for operation

Procedure Description

The NPAC is required to perform acceptance tests on every release of the
NPAC SMS system software before certifying it for operational release.
The NPAC SMS release test plan must be reviewed and updated by the NPAC
contractor for each NPAC SMS release, including testing of new features
or existing features that have been modified and any major fixes that
have been implemented. It is the responsibility of the NPAC contractor,
as part of an acceptance test plan to fully regression test major
releases.

The System Administration group is responsible for testing those
functions associated with its specific procedural duties included in the
NPAC release test plan. These include, but are not limited to the
following:

System Logon and Security Features

NPAC SMS administrative data table update features

Customer record features

Electronic mailbox features

Completion of acceptance tests will result in a release certification
report summarizing all the test results, including those errors
encountered and the resolutions required to successfully pass the tests.

12.6 Service Administration

Key Responsibilities

R12-18 Create and maintain NPAC SMS data table

R12-19 Map table information to appropriate codes (e.g., NPA, LRN, GTT)

R12-20 Create and maintain descriptive data table labels

Procedure Description

The Tables Administration function within the System Administration
group is responsible for creating and maintaining internal NPAC SMS data
tables used to validate data entries and minimize user input errors
through the use of appropriate quality assurance and quality control
methods. There are several different types of tables which can be
grouped into mapping, validation, and NPA splits/mass changes tables,
which include, but are not limited to the following:

1.  Location Routing Number (LRN) tables

```{=html}
<!-- -->
```
1.  Service Provider GTT information tables

The procedures associated with table administration vary depending on
the table involved.

12.7 Mass Change Administration

Examples of mass changes may include but are not limited to; LRN,
service provider ID, DPC info., location values and type, billing ID,
code split, and new DPC information due to new services.

Key Responsibilities

R12-21 Maintain a close working relationship with organizations
responsible for NPA mass changes scheduling.

R12-22 Analyze mass change impact on NPAC SMS administrative tables

R12-23 Analyze mass change impact on NPAC SMS customer records

R12-24 Notify mass change to appropriate service provider service
administration centers.

R12-25 Coordinate with data center vendor to execute NPAC SMS programs
required to perform table and record modifications.

Procedure Description

Mass changes required to NPAC SMS records are elements of an infrequent
and complex process beginning more than one year before the cutover
date. The NPAC becomes involved after receiving notification from the
company responsible for the mass change. The goal of the NPAC is to
transparently transition affected records in the NPAC SMS data base to
reflect the new information.

The first step in the process is to analyze the impact of the mass
change on the NPAC SMS table and record information. After impact
analysis and record sorting have been completed the NPAC will work
closely with the NPAC SMS data center support group to include the
modifications as part of the data base.

Specific tasks performed by the group are routine and procedural. Staff
members will need to have clerical data processing skills and training
in on-line computer processing. Types of problems resolved by the System
Administration Staff will primarily concern user access and system
security issues.

12.8 User Support Group

The User Support Group is the primary NPAC contact for NPAC SMS users
encountering problems with system features, or with inputting or
accessing of their customer record data. The group would also be
responsible for the dissemination of NPAC SMS status information, such
as scheduled downtime, new software releases, documentation updates, and
training registration information.

This group provides the NPAC SMS user a central point of contact for
resolution of NPAC SMS problems and trouble reporting. Resolution of
user problems will be handled primarily through the efforts of the User
Support Group itself. Those issues requiring the efforts of another NPAC
group will be promptly referred to the appropriate group. Issues
requiring Vendor or NPAC SMS Data Center operations support must always
be researched first by the responsible NPAC staff member. The key point
of contact for users will always reside within the NPAC for NPAC SMS
service issues.

The User Support Group requires staff who are well versed in all NPAC
SMS capabilities. The ability to learn from many different user problems
and to quickly relate a given problem to a previous experience will
ensure successful user support. The User Support staff must also speak
English clearly, have excellent communication skills to effectively
interact with NPAC SMS users and take prompt action to resolve problems.

12.8.1 User Problem Resolution

Key Responsibilities

R12-26 Resolve customer record access problems

R12-27 Clarify feature capabilities for users

R12-28 Resolve customer record input and modification problems

R12-29 Perform acceptance testing for new software releases

R12-30 Support link problem resolution with datalink protocol analysis
capabilities

Procedure Description

The primary function of the User Support Group is solving the problems
of the NPAC SMS user. Phone calls to the User Support Group must be
dealt with as they are received, with the goal of real-time problem
resolution (i.e., within one hour). If this requires the assistance of
another group within the NPAC, the call should be transferred to a staff
member who can better aid in resolving the issue. This requires the User
Support staff to be knowledgeable in all NPAC responsibilities and aware
of specific expertise. The NPAC is responsible for responding to the
user with either an answer or a date by which an answer will be
available. If the problem is determined to be critical it will be given
priority within the NPAC.

12.8.2 Software Release Acceptance Testing

Key Responsibilities

R12-30 Update software test plans

R12-31 Allocate staff for performing tests

R12-32 Execute test plans

R12-33 Generate and resolve testing trouble reports

R12-34 Document test results

R12-35 Certify NPAC SMS software and release for operation

Procedure Description

The NPAC is required to perform acceptance test on every release of the
NPAC SMS system software before certifying it for operational release.
The NPAC SMS release test plan must be reviewed and updated by the NPAC
contractor for each NPAC SMS release including testing of new features
or existing features that have been modified. It is the responsibility
of the NPAC contractor to fully regression test major releases.

The User Support group must work with the administrative organization to
test those functions associated with its specific procedural duties
included in the NPAC release test plan which include but are not limited
to:

1.  Customer record features

```{=html}
<!-- -->
```
1.  Electronic mailbox features

```{=html}
<!-- -->
```
1.  Help messages

Resolution of testing problems must occur to complete testing and gain
approval of the software release. Completion of the acceptance tests
will result in a release certification report summarizing all the test
results, including those errors encountered and the resolutions required
to successfully pass the tests.

12.8.3 Software Update Notification

Key Responsibilities

R12-36 Notify users of upcoming NPAC SMS software releases

Procedure Description

In an administrative capacity, the User Support Group is responsible for
keeping the NPAC SMS user community abreast of system software update
activity. The notifications must include the specific reasons for the
new release and summaries of what is being added, deleted, or modified
with respect to system features and capabilities. If the release was
unscheduled and is the result of resolution of several critical system
problems, the notifications must summarize all problems being corrected.
Updated documentation should be included as part of the software update.

12.8.4 Training Administration

Key Responsibilities

R12-37 Serve as primary contact for course schedules/registration
information

R12-38 Ensure availability of all NPAC SMS training

Procedure Description

The User Support Group is responsible for managing the availability of
NPAC SMS training courses and the handling of user registration
requests. The NPAC may develop and administer all NPAC SMS training
independently, or procure from another qualified training vendor, the
facilities and instructors necessary to teach the courses. The training
materials must be procured

from a qualified vendor. The NPAC will also perform training
registration. Course schedules will be negotiated between the User
Support Group and the training vendor, based on course demand forecast
by the User Support Group. The training vendor will be responsible for
billing attendees directly.

12.8.5 Document Order Administration

Key Responsibilities

R12-39 Process documentation requests

R12-40 Provide billing documentation

R12-41 Initiate documentation update distribution

R12-42 Provide documentation description, ordering information and price
list literature

Procedure Description

In an administrative capacity, the User Support Group is responsible for
handling user requests for NPAC SMS documentation. The NPAC will
maintain an inventory of available NPAC SMS documentation for quick
processing of orders, as available. The NPAC will handle all customer
billing for documentation. Phone in documentation inquiries should be
handled immediately. If documentation description, pricing, or ordering
information literature is requested, it must be mailed to requester
within 24 hours. Orders should be accepted only from companies with
active system logons and must be accompanied by a documentation request
form. Facsimiles should be accepted in emergency situations.
Documentation billing will be added to the NPAC SMS user\'s service
bill.

12.8.6 Training and Documentation User Feedback

Key Responsibilities

R12-43 Getting appropriate user recommendations reflected in NPAC SMS
system documentation and training material

Procedure Description

User feedback for NPAC SMS training and documentation is just as
important as feedback receiver for the operational system itself. The
User Support Group is responsible for recording the feedback received
during phone in conversations. Those comments pertaining to training and
documentation must be recorded and entered into the trouble reporting
system just as a service problem would be entered. Analysis of the
impact of a problem on training or documentation material should be
included as part of the impact analysis done for every trouble report
entered into the trouble system.

12.8.7 LSMS Download Problem Resolution

Key Responsibilities

R12-44 Analyze and resolve exception report issues resulting from
unsuccessful updates

Procedure Description

Failures in the download of customer records to the service providers
served by NPAC SMS are reported to the NPAC User Support Group. User
Support staff must resolve all download failures.

Failures will primarily be the result of unsuccessful sending of
customer records and/or NPAC SMS administrative instructions to the
receiving service provider. Resolution of customer record download
failures to an service providers must have the highest priority.
Resolution efforts must continue until the problem is solved, with the
service provider receiving notification when the updates are
successfully completed.

12.9 System Support Group

The System Support group is responsible for resolving or coordinating
resolution of all user or NPAC SMS problems relating to system
availability or technical communication problems. This group will be
responsible for maintaining reliable system communication linkages
between NPAC SMS and all other local number systems that rely on NPAC
SMS for information updates. The NPAC SMS will generate a multitude of
system performance, customer record, and problem exception reports. The
System Support group must be able to interpret, generate, and distribute
reports requested by an NPAC SMS user.

12.9.1 NPAC SMS Report Administration

Key Responsibilities

R12-45 Generate and distribute NPAC SMS reports to all requesting users
who are entitled to receive reports

R12-46 Validate the accuracy of report contents

R12-47 Generate and distribute reports to NPAC SMS users who are
entitled to receive reports and do not have local print facilities

R12-48 Resolve report interpretation problems

Procedure Description

The System Support group is the key point of contact for resolution of
problems pertaining to NPAC SMS reports. The System Support group must
ensure that the system is able to produce requested reports and assist
in the validation and interpretation of any report. As with other NPAC
SMS problems the System Support staff will file a trouble report in the
system for evaluation and record keeping. Any NPAC SMS user with an
active NPAC SMS logon can view or obtain copies of those reports allowed
by the security associated with their logon ID.

12.9.2 Failure Recovery Administration and User Notification

Key Responsibilities

R12-49 Notify all NPAC SMS user groups of an unscheduled system shutdown
or failure

R12-50 Serve as the key point of contact for system recovery status

Procedure Description

In the event of an unscheduled, instantaneous system shutdown or
failure, the NPAC SMS Data Center operations staff will notify the NPAC
System Support group within five minutes of failure. Within 15 minutes
of failure, the NPAC will notify the NPAC SMS user community.
Notification will be through an NPAC SMS broadcast message. If the
system is not available the NPAC must provide a system status hotline
number that users can call to obtain the latest system information. The
NPAC will receive updated system status from the NPAC SMS data center at
agreed upon intervals, and convey that information to the users via the
NPAC SMS system or hotline. The NPAC will inform the NPAC SMS users of
the data base status after the problem is fixed. Users will need to know
the time period during which transactions were lost and affect
restoration to the best of their abilities, while the NPAC will help in
reconciliation.

12.9.4 NPAC SMS Interface Monitoring

Key Responsibilities

R12-51 Assist in the resolution of data communication problems with
other NPAC SMS service systems (service providers, Operator Service
Systems, RAOs, etc.)

R12-52 Provide technical assistance to NPAC SMS users experiencing
problems accessing the system

R12-53 Generate automatic audit reports

Procedure Description

The objective of this System Support function is to provide reliable
NPAC SMS user access and system communication with other ported number
service system components through the performance of routing functional
audits. These audits must be organized into a suite of tests that are
run periodically, and at least every week. The results of these audits
will be used by more technically trained staff to detect potential
system performance or availability problems. In all cases the System
Support group must be responsible for coordinating the resolution of
issues involving user access to the NPAC SMS. NPAC SMS problems will
typically be referred to System Support through phone calls received by
the NPAC User Support group. All issues must be documented in the form
of a NPAC consultation report, and, if due to a system failure, must be
recorded as a trouble report in the trouble reporting system.

12.9.4 Software Release Acceptance Training

Key Responsibilities

R12-54 Update software test plans

R12-55 Allocate staff for performing tests

R12-56 Execute test plans

R12-57 Generate and resolve testing trouble reports

R12-58 Document test results

R12-59 Certify NPAC SMS software and release for operation

Procedure Description

The System Support group is responsible for testing those functions
associated with its specific procedural duties included in the NPAC
release test plan. These include, but are not limited to:

1.  NPAC SMS report availability verification

```{=html}
<!-- -->
```
1.  NPAC SMS service maintenance and diagnostic procedures

```{=html}
<!-- -->
```
1.  NPAC SMS-Service Provider administrative functions

Resolution of testing problems must occur to complete testing and gain
approval of the software release. The NPAC will work with the platform
provider to resolve NPAC SMS system related problems. All problems will
be recorded in the trouble reporting system.

Key attributes staff members of the System Support group must possess
the ability to diagnose a problem using a strong set of technical system
skills, and quickly disseminate that information to the appropriate NPAC
or Vendor Support groups to rectify the situation. Personnel staffing
these positions need to have strong data processing, problem diagnosis
and system communication skills and previous experience supporting a
data processing operation. Specific skills include knowledge of the NPAC
SMS System Vendor\'s Information Management System for data base
systems, operating system, and their wide area data communications
protocols.

12.10 NPAC Organizational Interface Requirements

In meeting contractual requirements the NPAC contractor will be required
to interact with a diverse set of organizations, especially the full
range of NPAC users. The most common user will be companies using the
NPAC SMS as the centralized data base for their provisioning of ported
local numbers for their customers. The NPAC will also work with the
service providers' support and service administration organizations
which use ported local number routing instructions. The NPAC must be
able to work with service providers utilizing multiple software vendors.
All users will identity their primary contacts to the NPAC for each
area.

12.11 NPAC SMS Data Center

The NPAC contractor will also manage the data center operation and as
such, they shall be required to provide hardware, operational support
for NPAC SMS application(s) including systems engineering to integrate
computer system and communications components. (Reliability requirements
are outlined in Section 10.)

The NPAC contractor will have direct contact with the data center
operations staff to assist in resolution of NPAC SMS access and
communication problems. Coordination of scheduling and execution of
special NPAC SMS table administration, NPA splits, and mass change
programs will be handled by the NPAC with the data center operation. The
NPAC and the data center will share information necessary to plan for
growth or reconfiguration of the hardware platform and communications.

12.12 Administration

The administrative staff must provide support and direction for the
operational NPAC groups and manage the business and technical issues
affecting the performance of NPAC services.

Key Responsibilities

R12-60 Plan NPAC staff for software acceptance testing, report
acceptance results, and ensure problem resolution of discrepancies.

R12-61 Schedule staff training for new software features and updates

R12-62 Analyze documentation and training impact

R12-63 Coordinate testing and cutover with NPAC SMS data center
operations

R12-64 Coordinate critical software release cutover

R12-65 Provide billing for service providers\' usage

R12-66 Manage NPAC accounts receivable collection

R12-67 Manage NPAC accounts payable responsibilities

R12-68 Resolve any NPAC billing disputes

R12-69 Process bills to NPAC from data center operations and system
vendor for support services

R12-70 Adjust Staffing Level Based on Forecast System Usage Demands

R12-71 Plan capital equipment based on required staffing levels and NPAC
performance standards

R12-72 Manage NPAC facilities

R12-73 Monthly status reports on total billing, summary of customer
service activities, transactions, and trouble reports, summary of
administrative and other support activities

R12-74 List of trouble reports, with a breakdown between NPAC SMS and
NPAC user complaints

R12-75 List of cleared trouble reports

12.13 Facilities Requirements

The NPAC must provide an actual or virtual point of presence in the New
York LATA 132 in New York by which service providers can connect to the
NPAC SMS. Service providers will be able to connect to the NPAC SMS by
connecting to either the NPAC SMS facility location or to the New York
LATA 132 point of presence

The physical location of the NPAC facility is at the discretion of the
NPAC contractor. The only limitation is that the facility must be within
the continental United States. Identification of the proposed NPAC
location must be included as part of the bidder\'s response.

The facility may be a separate building or be part of a larger facility
owned or leased by the NPAC contractor. If the NPAC is located within a
larger facility, space allocated to the NPAC must have the following
characteristics:

R12-76 Be dedicated entirely for NPAC use

R12-77 Be a distinguishable area, separate from other parts of the
facility by use of secure access points

R12-78 Be contiguous space so that all NPAC staff members are physically
located within the same secure area

R12-79 Serve as the primary (and, if applicable, secondary) work areas
for all NPAC functions to be performed

R12-80 Have sufficient and suitable telecommunications links available
with diverse routing disaster protection

R12-81 Provide sufficient backup power to maintain operation through
electrical outages of at least eight hours

The amount of space allocated by the NPAC contractor must be specified
in proposals. The specification must include square footage and work
space layouts for each of the NPAC staff members. It is recommended that
each functional area specified have its own distinct work area. Any
equipment required by the different groups should be located within the
individual functional group work area, except for equipment deemed to be
common to multiple NPAC groups (e.g., high-speed printers, data
communication controllers) which may be located in a common area.

12.14 Telecommunications Requirements

Key Requirements

R12-82 Individual phone lines for staff members

R12-83 24 hour hotline

R12-84 Voice messaging system

R12-85 Data communication facilities

R12-86 FAX Machine

R12-87 Each NPAC staff member must have an individual phone line to
their desk. All phone lines must provide the capability of transferring
a call to any other phone line within the NPAC.

R12-88 The NPAC must have a primary phone number (hotline) with direct
inward dialing functionality. Staff members must be able to answer the
hotline directly from their desks. This number will be the primary means
of contact for the NPAC SMS users who have questions.

R12-89 The phone system must provide the capability to allow a caller to
leave a message easily. This can be accomplished by an electronic
messaging system that allows the caller to leave a message for the
person called. In any case, a visual indication that a message has been
left is required. The caller must be able to reach a \"live\" NPAC staff
member at all times.

R12-90 The NPAC must provide a 24-hour hotline that will give the NPAC
SMS user:

1.  Guaranteed Access to an Actual NPAC Staff Member 24 Hours a Day

```{=html}
<!-- -->
```
1.  The latest NPAC SMS status available at times when the system may be
    unavailable during scheduled or unscheduled downtime.

R12-92 The choice of voice communication architecture, vendors,
equipment, and services is totally at the discretion of the NPAC
contractor. The goal of these choices should be to best meet the
functionality and service requirements described above. The NPAC
contractor will be responsible for the cost and services management of
its voice communication facilities. The NPAC contractor will also be
responsible for meeting or exceeding the required qualitative and
quantitative performance levels that will be part of the regular service
monitoring audits. Bidder response to this RFP must include a
description of the proposed NPAC voice communication facilities to be
implemented.

R12-93 Procurement and management of the data communication facilities
required between the NPAC contractor, the data center, and the system
vendor are the responsibility of the NPAC contractor. The contractor
must provide redundant data communication facilities to provide for
disaster recovery due to facility outages. It will be the responsibility
of NPAC contractor to meet the data communication specifications of the
NPAC SMS system vendor. Data Communication must also include the ability
to input into the appropriate trouble reporting systems.

12.15 Staffing

Key Requirements

R12-94 Please provide proposed staffing profiles and staffing levels.
This must be part of the bidder\'s initial response.

R12-95 Please indicate whether you are using part and full-time
employees and also the screening process for determining employment.

12.16 Service Objectives

NPAC Availability

R12-96 NPAC hours of operation will be 24 hours a day, seven days a
week. Staffing at the facility will be at appropriate levels to ensure
quick response to user needs at any time of the day or week.

Quality of Service

The goal of the NPAC is to provide high quality NPAC SMS support and
user support. NPAC will play a key role in the achievement of error
free, ubiquitous ported local number service provisioning on the part of
service providers. In this role, the NPAC contractor must, at all times,
be mindful of the revenue and time sensitive nature of the support
services provided to users.

Performance Standards

The NPAC contractor performance will be monitored in accordance with the
standards proposed as part of the bidder\'s response and then negotiated
following the contractor selection. These NPAC service standards must
tie together the following three quality-of-service components:

Performance standards for NPAC procedural tasks (illustrative task
standards available upon request)

Bidder\'s quality assurance and control guidelines upon which NPAC staff
members base their individual performance objectives

NPAC contractor-defined performance evaluation process that, through
self- monitoring, provides ongoing measurements of how well NPAC service
objectives are being met.

The bidder\'s response must address standards addressing each of the
following criteria:

R12-97 Service consistency

R12-98 Service reliability

R12-99 Service response time

The NPAC contractor\'s performance will be evaluated by the Contracting
Party. The process will consist of both quantitative and qualitative
assessments.

Section 13: Future Considerations

The future of number portability, such as the number of service
providers and possible expansion to geographic and service portability,
and number administration are not known at this time. The SMS platform
should not preclude future expansion to adapt to additional needs as
they arise. The above are not intended as requirements on the SMS, but
only as information on possible future needs. Vendors are requested to
describe how the NPAC and SMS can be adapted to accommodate the above
situations. This information does not imply future obligation on the
group to contract with the selected vendor for any future needs.

Specific impacts that may occur are as follows:

1\. Expansion to allow additional service providers. This will increase
the number of ports needed for the links and the number of service
providers sending updates and receiving broadcasts.

2\. Expansion to other states: This will require an increase in the size
of the database, and an increase in both the number of updates and the
number of broadcasts. The number of service providers using the SMS may
also increase. It will be necessary to screen broadcasts for each SMS
association to determine whether data is desired on an NPA-NXX basis.

3\. Geographic number portability: This will require an increase in the
size of the database, and an increase in both the number of updates and
the number of broadcasts. There may also be interfaces between regional
SMSs. Geographic portability may be done in stages, such as initially
being geographic portability beyond current rate centers but within a
specific region.

4\. Overlays of NPA-NXXs: The NPAC SMS will be required to adapt to
changes, if any, resulting from overlays.

5\. Expansion for use by wireless service providers: This may require
new data fields and an increase in the number of service providers using
the SMS.

6\. Expansion to include data related to resellers. This may require
data indicating the reseller, if any for telephone numbers and will
increase the size of the database. Resellers may also need to access the
database.

Section 14: Glossary

+----------------+-----------------------------------------------------+
| **Activation   | Date/Time Stamp of when the TN porting activation   |
| Time Stamp**   | command was received by the NPAC SMS from the new   |
|                | Service Provider. This time stamp is also stored in |
|                | the Local SMSs and SCPs to assist auditing.         |
+----------------+-----------------------------------------------------+
| **Destination  | The DPC is a 9 digit SS7 address which identifies a |
| Point Code     | node in the signaling network.                      |
| (DPC)**        |                                                     |
+----------------+-----------------------------------------------------+
| **Due Date**   | The Due Date is a date/time stamp on a subscription |
|                | order that indicates the approximate date/time of   |
|                | activation. The actual activation of the            |
|                | subscription order is triggered by the Activation   |
|                | Request from the new SP. The Due Date will be used  |
|                | to determine when both new and old SPs should have  |
|                | sent their matching subscription orders, as well as |
|                | for aging old unprocessed orders from the system.   |
|                | Subsequent changes to due date will not be required |
|                | to match and will not trigger notification to other |
|                | service providers.                                  |
+----------------+-----------------------------------------------------+
| **Global Title | Global Title Translation - performed for feature    |
| Translation    | call processing and LIDB access. A 10-digit GTT is  |
| (GTT)**        | now required for LNP (instead of the current        |
|                | 6-digit). This requires that the NPAC maintain:     |
|                |                                                     |
|                | a\) the DPC and DPC-type (End-office or Gateway)    |
|                | information for the CLASS feature, and              |
|                |                                                     |
|                | b\) the DPC information for LIDB Gateway for LIDB   |
|                | access.                                             |
+----------------+-----------------------------------------------------+
| **NPAC**       | Number Portability Administration Center is         |
|                | operated by a neutral third party, and performs     |
|                | administration functions for LNP.                   |
+----------------+-----------------------------------------------------+
| **NPAC SMS**   | The regional SMS is the HW/SW platform for an       |
|                | Operations Support System that performs             |
|                | administration functions for the Local Number       |
|                | Portability Service. It is the master database for  |
|                | ported TNs.                                         |
+----------------+-----------------------------------------------------+
| **LNP**        | Local Number Portability is the ability to port     |
|                | TNs. There are two types initially:\                |
|                | - Service Provider Portability, internetwork\       |
|                | - Service Provider Portability, intranetwork        |
+----------------+-----------------------------------------------------+
| **Local SMS**  | The SMS used by the Service Provider, that receives |
|                | LNP data from the NPAC SMS and distributes it to    |
|                | the SPs network elements (e.g., SCPs). This is a    |
|                | logical function and may be implemented as a        |
|                | separate system or as part of a network element.    |
+----------------+-----------------------------------------------------+
| **Longitude &  | Coordinates to define geographic location for       |
| Latitude**     | billing and rating purposes.                        |
+----------------+-----------------------------------------------------+
| **LRN**        | Location Routing Number is a 10-digit number used   |
|                | to uniquely identify a switch that supports         |
|                | porting.                                            |
+----------------+-----------------------------------------------------+
| **Ported TN**  | A TN ported to a switch that is not the             |
|                | NANP-assigned switch.                               |
+----------------+-----------------------------------------------------+
| **Rate         | Geographic locations assigned V & H coordinates     |
| Center**       | between which distances are determined for billing  |
|                | and rating purposes.                                |
+----------------+-----------------------------------------------------+
| **Service      | The ability to port TNs when changing services,     |
| Portability**  | e.g., from POTS to ISDN.                            |
+----------------+-----------------------------------------------------+
| **Service      | A Service Provider that provides telecommunication  |
| Provider**     | services. Some examples of service providers are:\  |
|                | - Local Service Provider\                           |
|                | - Long Distance Service Provider\                   |
|                | - SCP/SMS Service Provider\                         |
|                | - Directory Services/Operator Service Provider\     |
|                | - Non-facilities-based Service Provider (e.g.,      |
|                | Reseller)                                           |
+----------------+-----------------------------------------------------+
| **Service      | The ability to port TNs when changing service among |
| Provider       | Local Service Providers.                            |
| Portability**  |                                                     |
+----------------+-----------------------------------------------------+
| **             | Information record for a TN.                        |
| Subscription** |                                                     |
+----------------+-----------------------------------------------------+
| **TN**         | Telephone Number                                    |
+----------------+-----------------------------------------------------+
| **V&H          | Vertical and Horizontal Coordinates to define       |
| Coordinates**  | geographic location for billing and rating          |
|                | purposes.                                           |
+----------------+-----------------------------------------------------+
| **Version**    | Time-sensitive (or status-sensitive) instance of    |
|                | subscription data.                                  |
+----------------+-----------------------------------------------------+

Section 15: Acronyms and Other Abbreviations

**AIN** Advanced Intelligent Network

**AMA** Automatic Message Accounting (Billing)

**BAF** Bellcore AMA Format

**CLASS** Custom Local Area Signaling System

**CNAM** Caller ID with name

**DPC** Destination Point Code

**'GDMO** Generalized Definitions of Managed Objects

**GTT** Global Title Translation

**IN** Intelligent Network

**ISVM** Interswitch voice message

**LATA** Local Access Transport Area

**LIDB** Line Information Database

**LNP** Local Number Portability

**LRN** Location Routing Number

**NANP** North American Numbering Plan

**NECA** National Exchange Carrier Association

**NPAC** Number Portability Administration Center

**OCN** Operating Company Number

**RAO** Revenue Accounting Office (Billing)

**SOA** Service Order Administration

**SMS** Service Management System

**SP** Service Provider

**SSN** Subsystem Number

**TN** Telephone Number

**TT** Translation Type

Section 16: Attachments

[^1]: CLASS is a Service Mark of Bellcore®.

    \*These data fields will be determined by SMS.

[^2]: An "authorized user" shall be able to access the data that is part
    of or controlled by the SMS. A user, either an individual or
    machine, shall be identified by a unique user identification code
    (user id).