Exhibit 10.1

Pursuant to 17 CFR 230.406, confidential information has been omitted in places marked “[* * *]” and has been filed separately with the Securities and Exchange Commission pursuant to a Confidential Treatment Application filed with the Commission.

Pursuant to Instruction 2 to Item 601 of Regulation S-K, NeuStar, Inc., as assignee of Lockheed Martin IMS, has filed an agreement with the Northeast Carrier Acquisition Company, LLC, which is one of seven agreements that are substantially identical in all material respects other than the parties to the agreements.  North American Portability Management, LLC succeeded to the interests of Northeast Carrier Acquisition Company, LLC and each of the other entities listed below.  The following list identifies the other parties to the six agreements that have been omitted pursuant to Instruction 2 to Item 601:

•LNP, LLC (Midwest)

•Southwest Region Portability Company, LLC

•Western Region Telephone Number Portability, LLC

•Southeast Number Portability Administration Company, LLC

•Mid-Atlantic Carrier Acquisition Company, LLC

•West Coast Portability Services, LLC

AGREEMENT

FOR

NUMBER PORTABILITY ADMINISTRATION CENTER/
SERVICE MANAGEMENT SYSTEM

BETWEEN

LOCKHEED MARTIN IMS

AND

NORTHEAST CARRIER ACQUISITION COMPANY , L.L.C.

ARTICLE 1 - DEFINITIONS

ARTICLE 2 - SCOPE OF WORK

ARTICLE 3 - TERM

ARTICLE 4 - COMPENSATION AND NPAC/SMS USER AGREEMENTS

4.1 COMPENSATION

4.2 NPAC/SMS USER AGREEMENTS

ARTICLE 5 - RELATIONSHIP

ARTICLE 6 - PRICING AND ADJUSTMENT

6.1 GENERAL

6.2 SERVICE ELEMENT CHARGES

(a) Monthly Charges

(b) Per User/Per Request Charges

(c) Non-Recurring Charges

6.3 USER TRAINING

6.4 INTEROPERABILITY TESTING

6.5 EXPENSES

6.6 TARGET AMOUNTS; SHORTFALL AND CREDITS; BILLING

(a) Target Amounts, Optional Target Schedule

(b) Determining Allocable Target Shortfalls and Credits

(c) Invoicing of Monthly Charges for Users; Monthly Summary of Charges

(d) Certain Charges Incurred Prior to Acceptance

6.7 MOST FAVORED CUSTOMER

6.8 ADOPTION OF NANC FLOWS

ARTICLE 7 - BENCHMARKING

7.1 BENCHMARK OVERVIEW

7.2 BENCHMARKER

7.3 BENCHMARK

7.4 BENCHMARK INFORMATION

7.5 BENCHMARKING RESULTS

ARTICLE 8 - OBLIGATIONS OF CONTRACTOR

8.1 TESTING OF NPAC/SMS

(a) Testing; Readiness of Users

(b) Network Testing

(c) Delays

8.2 ACCEPTANCE; EFFECT OF DELAYS ON PAYMENTS

8.3 PROVISION OF NPAC/SMS; SERVICE LEVEL ADJUSTMENTS

8.4 COMPLIANCE WITH SERVICE LEVEL REQUIREMENTS; MONITORING AND REPORTING

8.5 SECURITY; UNAUTHORIZED ACCESS; INSPECTION

8.6 PROCUREMENT; STAFFING RESPONSIBILITIES; LOCATION CHANGES

8.7 TRAINING

8.8 TAXES

8.9 LICENSES AND PERMITS

8.10 LAWS AND REGULATIONS

8.11 IMMIGRATION LAW COMPLIANCE

8.12 QUALITY

8.13 NOTIFICATION OF ADDITIONAL SERVICES, ENHANCEMENTS AND MODIFICATIONS

i

ARTICLE 9 - OWNERSHIP OF INTELLECTUAL PROPERTY; SOURCE CODE ESCROW

9.1 OWNERSHIP OF INTELLECTUAL PROPERTY

9.2 GRANT OF LICENSE ON CONDITION OF TERMINATION BY CUSTOMER

9.3 GRANT OF LICENSE ON CONDITION OF FORCE MAJEURE OR CONTRACT EXPIRATION

9.4SOFTWARE ESCROW

ARTICLE 10 - PROBLEM RESOLUTION

10.1 HOTLINE SERVICE

10.2 PROBLEM CORRECTION

ARTICLE 11 - PROJECT STAFF

11.1 PROJECT EXECUTIVES AND OVERSIGHT

11.2 PROJECT MANAGERS

11.3 CONDUCT OF PERSONNEL

ARTICLE 12 - DISASTER RECOVERY

12.1 CONTRACTOR’S RESPONSIBILITY FOR DISASTER RECOVERY

12.2 DISASTER RECOVERY PLANS

12.3 DISASTER RECOVERY EXERCISES FOR THE NPAC/SMS

12.4 IMPLEMENTING SWITCH TO DISASTER RECOVERY SITE; RESTORATION

12.5 DATA LOSS DURING A DISASTER RECOVERY

12.6 OCCURRENCE OF FORCE MAJEURE

12.7 ALLOCATION OF RESOURCES FOR DISASTER RECOVERY OR FORCE MAJEURE

12.8 PERMANENT LOSS OF CONTRACTOR’S NPAC/SMS DATA CENTERS

(a) Loss of NPAC/SMS Production Computer System site

(b) Loss of NPAC/SMS Disaster Recovery Computer System site

(c) Customer’s Right to Terminate for Cause

ARTICLE 13 - ADDITIONAL SERVICES

13.1 REQUESTED BY CUSTOMER

13.2 PROPOSED BY CONTRACTOR

13.3 CHANGES PURSUANT TO BENCHMARKING AND AGREED-UPON CHANGES IN SERVICE LEVELS

13.4 STATEMENT OF WORK

13.5 STAFFING

13.6 ENHANCEMENTS TO NPAC/SMS SOFTWARE

ARTICLE 14 - BUSINESS RECORDS AND AUDITS

14.1 CONTRACTOR’S REGULAR AUDITS; CUSTOMER’S RIGHT TO AUDIT

14.2 ACCESS FOR AUDITS

14.3 PROVISION OF FACILITIES FOR AUDITS

14.4 AUDIT OF FEES

14.5 RECORD RETENTION

14.6 COMPLIANCE WITH AUDIT RECOMMENDATIONS

ARTICLE 15 - CONFIDENTIAL INFORMATION

15.1 CONFIDENTIAL INFORMATION DEFINED; OBLIGATIONS

15.2 EXCLUSIONS

15.3 RETURN OR DESTRUCTION

15.4 INJUNCTIVE RELIEF

15.5 LOSS OF CONFIDENTIAL INFORMATION

ARTICLE 16 - DELAYS; PERFORMANCE CREDITS AND CORRECTIVE REPORTING; DEFAULTS; FORCE MAJEURE

16.1 NOTICE OF DELAYS

ii

16.2 DELAYS IN IMPLEMENTATION OF INITIAL SERVICES

16.3 PERFORMANCE CREDITS

16.4 ALLOCATION OF DAMAGES AMONG USERS

16.5 CONTRACTOR DEFAULTS

16.6 FORCE MAJEURE

ARTICLE 17 - INDEMNIFICATION

17.1 MUTUAL INDEMNIFICATION

17.2 CONTRACTOR INDEMNIFICATION

17.3 PROCEDURES

ARTICLE 18 - INFRINGEMENTS

18.1 CONTRACTOR’S OBLIGATION TO INDEMNIFY FOR INFRINGEMENT

18.2 CONTRACTOR’S OBLIGATIONS IF USE IS THREATENED

ARTICLE 19 - LIABILITY; LIMITATION OF LIABILITY

19.1 DIRECT DAMAGES

19.2 CONSEQUENTIAL DAMAGES

19.3 EXCLUSIONS

ARTICLE 20 - INSURANCE

20.1 CONTRACTOR’S INSURANCE REQUIREMENTS

20.2 CONTRACTOR’S FAILURE TO MAINTAIN INSURANCE

20.3 SELF INSURANCE

20.4 CUSTOMER’S INSURANCE REQUIREMENTS

20.5 CUSTOMER’S FAILURE TO MAINTAIN INSURANCE

20.6 ADDITIONAL INSURANCE

ARTICLE 21 - WARRANTIES

21.1 HARMFUL CODE OR DATA

21.2 NO LIENS OR VIOLATIONS OF THIRD PARTY RIGHTS

21.3 CONFORMANCE WITH SPECIFICATIONS AND OTHER STANDARDS

21.4 AUTHORITY

21.5 EXCLUSIVE WARRANTIES

ARTICLE 22 - ASSIGNMENT, OTHER TRANSFER, AND SUBCONTRACTING

22.1 CONSENT REQUIRED

22.2 ASSIGNMENT OF MONIES DUE

ARTICLE 23 - TERMINATION

23.1 TERMINATION BY CUSTOMER

23.2 NONWAIVER

23.3 USERS’ LIABILITY FOR PAYMENTS

23.4 RETURN OF PROPERTY UPON TERMINATION

ARTICLE 24 - TRANSITION AT EXPIRATION OR TERMINATION OF THIS AGREEMENT

24.1 CONTRACTOR’S OBLIGATION TO ASSIST WITH TRANSITION

24.2 OPTIONAL EXTENSION UPON TERMINATION OR NON-RENEWAL WITHOUT LICENSE

24.3 OPTIONAL EXTENSION UPON TERMINATION OR NON-RENEWAL WITH LICENSE, LOSS OF NEUTRALITY ORREGULATORY TERMINATION

24.4 TRANSITION SERVICES

ARTICLE 25 - REGULATORY AND LEGISLATIVE CONSIDERATIONS

25.1 USERS ARE COMMUNICATIONS COMMON CARRIERS

25.2 CHANGES IN LAW AND REGULATIONS

iii

ARTICLE 26 - INTERNAL DISPUTE RESOLUTION AND ARBITRATION

26.1 INTERNAL DISPUTE RESOLUTION

26.2 ARBITRATION

26.3 CONTINUATION OF SERVICES

26.4 DISPUTES REGARDING CUSTOMER’S APPLICATION OF ALLOCATION

ARTICLE 27 - GENERAL

27.1 SUCCESSORS AND ASSIGNS

27.2 ATTORNEYS’ FEES

27.3 SERVICE PARITY

27.4 ADVERTISING OR PUBLICITY

27.5 NON-WAIVER

27.6 NOTICES

27.7 GOVERNING LAW

27.8 SEVERABILITY

27.9 REMEDIES

27.10 SURVIVAL

27.11 JOINT WORK PRODUCT

27.12 HEADINGS

27.13 COUNTERPARTS

ARTICLE 28 - NONEXCLUSIVE MARKET RIGHTS

ARTICLE 29 - CENTRALIZATION

ARTICLE 30 - ENTIRE AGREEMENT

EXHIBITS:

Exhibit A	Request for Proposal (Customer RFP dated September 20, 1996)
Exhibit B	NANC NPAC/SMS Functional Requirements Specification
Exhibit C	NANC NPAC/SMS Interoperable Interface Specification
Exhibit D	Contractor Response to RFP
Exhibit E	Pricing Schedules
Exhibit F	Project Plan and Test Schedule
Exhibit G	Service Level Requirements
Exhibit H	Reporting and Monitoring Requirements
Exhibit I	Key Personnel
Exhibit J	Form of NPAC/SMS User Agreement
Exhibit K	External Design
Exhibit L	Additional Terms and Conditions of Software License
Exhibit M	Software Escrow Agreement

iv

CONTRACTOR SERVICES AGREEMENT

THIS CONTRACTOR SERVICES AGREEMENT (“Agreement”) is made and entered into this 7th day of November, 1997 (“Effective Date”) by and between the Northeast Carrier Acquisition Company, L.L.C. (the “Customer”), a New York limited liability company, having offices at c/o Carville B. Collins, Piper & Marbury L.L.P., 36 South Charles Street, Baltimore, Maryland 21201 and Lockheed Martin IMS (“Contractor”), a New York corporation, having offices at 1200 K Street NW, 11th Floor, Washington, DC 20005.

WITNESSETH:

WHEREAS, Customer is the limited liability company created by its Members under and pursuant to the Limited Liability Company Operating Agreement made as of the 5th of September, 1996 (the “Operating Agreement”) for the purposes of engaging in business activities related to implementing number portability; and,

WHEREAS, 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 telephone numbers formed Customer on September 4, 1996, pursuant to the State of New York Public Service Commission’s (“PSC”) Order in Case No. 94-C-0095, entitled “Proceeding on Motion of the Commission to Examine Issues Related to the Continuing Provision of Universal Service and to Develop a Framework for the Transition to Competition in the Local Exchange Market. Number Portability Trial - Progress Report,” issued on January 23, 1996 , to develop, evaluate, recommend and implement, if possible, a permanent service provider portability solution, and such formation was endorsed by the PSC in its further Order in Case No. 94-C-0095, entitled, “Number Portability - Final Report of Number Portability Trial,” issued on November 25, 1996 (“PSC Orders”); and,

WHEREAS, the Federal Communications Commission (“FCC”) has issued its First Report and Order adopted June 27, 1996 and released July 2, 1996 in its Docket 95-116 regarding telephone number portability specifying proposed rules applicable to NPAC/SMS, as defined below; and its First Memorandum Opinion and Order on Reconsideration adopted March 6, 1997 and released March 11, 1997, in its Docket 95-116, recognizing the formation of Customer (“FCC Orders”); and,

WHEREAS, the North American Numbering Council (“NANC”) issued the Local Number Portability Administration (“LNPA”) Selection Working Group report, dated April 25, 1997, to address all issues delegated to NANC by the FCC Orders regarding LNPA selection, and, in Section 4 thereof, “LNPA Vendor Selection,” has endorsed the LLCs actions and role in vendor selection; and,

WHEREAS, Customer issued a Request for Proposal (“RFP”) on September 20, 1996, attached hereto as Exhibit A, in order to obtain a Number Portability Administration Center/Service Management System (“NPAC/SMS”) service vendor to provide a turnkey database solution to

5

local number portability in the State of New York and other States in the Northeastern region; and,

WHEREAS, Contractor has reviewed and analyzed the RFP and has developed and submitted to Customer its Proposal dated October 25, 1996 and revisions thereto (hereinafter collectively the “Proposal”), and said Proposal sets forth Contractor’s offer and representations including, without limitation, conclusions, recommendations, and benefits incident to the appropriate facilities, hardware, system, software, and services, required to provide Users, as defined below, with the functional and operational performance capabilities and capacities specified in the RFP; and,

WHEREAS, Contractor represents that it is fully qualified to furnish NPAC/SMS to Customer; and,

WHEREAS, based on the representations contained in Contractor’s Proposal, presentations, other printed material, correspondence, discussions, and in reliance upon the expertise of Contractor in developing, designing and delivering systems, Customer wishes to retain the professional services of Contractor as the provider of NPAC/SMS in the Service Area, as defined below, and desires to have Contractor furnish such services to Users from the Contractor’s NPAC/SMS Data Centers, as defined below, utilizing the same computer systems, software and disaster recovery computer system and facility as provided to the Centralized NPAC LLCs, as defined below; and,

WHEREAS, Contractor desires to provide NPAC/SMS in the Service Areas, as defined below, and provide Services to Users from its NPAC/SMS Data Centers in accordance with the terms and conditions as set forth herein.

NOW, THEREFORE, for and in consideration of the premises and the mutual promises and covenants contained herein, it is hereby agreed as follows:

ARTICLE 1 - DEFINITIONS

As used throughout this Agreement, the following terms shall have the meanings set forth below unless otherwise indicated:

1.1The term “Acceptance Date” shall have the meaning set forth in Section 8.2.

1.2The term “Additional Services” shall have the meaning set forth in Section 13.1.

1.3The term “Ad Hoc Report” means any report of any aspect of Per User/Per Request Charges or activity other than a Standard Report prepared by Contractor at the request of a User.

1.4The term “Agreement” includes all the terms and conditions contained herein, including any Statement of Work and any Exhibit, appendix, attachment or documents referenced herein or incorporated herein by reference, including any and all amendments to this Agreement and each of the foregoing instruments.  In the event of a conflict between or among the terms and

6

conditions contained herein, in any Statement of Work or any such Exhibit, appendix or attachment, the following shall control in descending order of precedence:  (a) Exhibit M - Software Escrow Agreement, (b) any Statement of Work (but only with respect to the subject matter thereof), (c) the terms and conditions contained herein, (d) Exhibit E - Pricing Schedule, (e) Exhibit F - Project Plan and Test Schedule, (f) Exhibit G - Service Level Requirements, (g) Exhibit H - Reporting and Monitoring Requirements,  (h) Exhibit B -  NANC Functional Requirements Specification, (i) Exhibit C - NANC NPAC/SMS Interoperable Interface Specification, (j) Exhibit K - External Design, (k) any other documents identified as Exhibits, (l) any other appendices or attachments referenced in this Agreement, (m) Exhibit D - Response to RFP, and (n) Exhibit A - Request for Proposal.

1.5The term “Allocation Model” means the initial price allocation algorithm which shall be provided to Contractor by Customer and which, upon issuance by the FCC and/or state regulatory agency having competent jurisidiction over the NPAC/SMS, shall be superseded by the FCC-determined and/or state regulatory agency-determined price allocation algorithm provided to Contractor by Customer from time to time, which shall specify (i) which Service Element Charges shall be allocated among Users; and (ii) the method of allocation to be used for such Service Element Charges and any other amounts which may appropriately be billed to Users hereunder or under the NPAC/SMS User Agreements and with respect to which Contractor requests billing or allocation instructions from Customer. Contractor acknowledges that the Allocation Model may require different allocations among Users for different states within the Service Area.  Customer may amend the Allocation Model by delivery of an amended Allocation Model to Contractor at least thirty (30) days prior to the Billing Cycle with respect to which such Allocation Model is to be effective.

1.6The term “Billing Cycle” means any calendar month, or portion thereof, during which Services are rendered hereunder.

1.7The term “Business Day” means Monday through Friday of each week, excluding New Year’s Day, Memorial Day, July 4th, Labor Day, Thanksgiving Day, and December 24th and the 25th.

1.8The term “Centralized NPAC LLCs” shall have the meaning given to such term in Article 29 hereof.

1.9The term “Confidential Information” has the meaning defined in Section 15.1.

1.10The term “Contractor” refers to Lockheed Martin IMS, a New York corporation, having offices at 1200 K Street NW, 11th Floor, Washington, DC 20005 and shall include its permitted successors or assigns pursuant to Article 22 of this Agreement.

1.11The term “Contractor Delays” shall mean any delays directly or indirectly the result of Contractor having failed to meet or perform any of its obligations hereunder.

7

1.12The term “CPI” means the Consumer Price Index for the City of Chicago, Illinois, for all items, as published by the Bureau of Labor Statistics of the United States Department of Labor, or if such Consumer Price Index shall be discontinued, any comparable statistics on the cost of living for the City of Chicago as may be mutually agreed upon by the Parties.

1.13The term “Custom Enhancement” means any Enhancement made by Contractor at the request of Customer in order to adapt the NPAC/SMS Software to Customer’s specific requirements, which Enhancements will have no utility or limited utility to other customers, service providers or other users in other service areas in which Contractor provides similar services in accordance with procedures set forth in Article 13 - “Additional Services “.

1.14The term “Customer” means the Northeast Carrier Acquisition Company, L.L.C. and its permitted successors or assigns pursuant to Article 22 of this Agreement.

1.15The term “Defects” shall mean, collectively or individually, a failure of the NPAC/SMS to meet the Specifications or a demonstrable mistake in any Documentation, and shall include Minor Defects and Material Defects.

1.16The term “Delay Extensions” shall have the meaning given to such term in Section 8.1(c).

1.17The term “Deliverables” means Documentation, other than escrowed proprietary technical manuals and documentation, and other materials developed for or delivered to Customer by Contractor under this Agreement or under any Statement of Work issued hereunder.

1.18The term “Documentation” means technical or user manuals and other similar written reference or instructional materials that relate to the Users’ use or operation of NPAC/SMS.

1.19The term “Effective Date” means the date set forth in the preamble to this Agreement.

1.20The term “Enhancements” means changes or additions, other than Maintenance Modifications, to the NPAC/SMS Software and related Documentation, including all new releases, Custom Enhancements, and User Enhancements that improve existing functions, add new functions, or significantly improve performance by changes in system design or coding.

1.21The term “Final Delivery Date” shall mean November 3, 1997, as such date may be extended by Delay Extensions.

1.22The term “Intellectual Property” means rights under patents, copyrights, trade secret law, and any other statutory provision or common law doctrine, relating to rights in and to Software, designs, formulas, procedures, methods, ideas, inventions and improvements, works of authorship and other material, recordings, graphs, drawings, reports, analyses, other writings, any information in any form and other property of any type not specifically listed herein, whether or not the foregoing are protected or protectable under Intellectual Property rights now or in the future

8

1.23The term “LSMS” means a User’s Local Service Management System or its equivalent , including all software, minicomputers, front-end processors, workstations, computers, terminals, local area network (“LAN”) servers and associated peripheral equipment, lines and cabling used to connect and transmit data to and from the NPAC/SMS and other Users.

1.25The term “Maintenance Modifications” means any modifications or revisions, other than Enhancements, to the NPAC/SMS Software or Documentation that correct Defects, support new releases of the operating systems with which the NPAC/SMS Software is designed to operate, support new input/output (“I/O”) devices or provide other incidental updates and corrections.

1.26The term “Material Defect” shall mean a Defect that adversely affects the ability of the NPAC/SMS to port telephone numbers successfully in accordance with the Specifications

1.27The term “Member” shall mean a company which has joined the LLC pursuant to the Operating Agreement.

1.28The term “Minor Defect” shall mean a Defect other than a Material Defect.

1.29The term “Network Testing Readiness Date” shall mean the day following the Turnup Testing Completion Date.

1.30The term “Neutral Third Party” means an entity which (i) is not a telecommunications carrier,  as defined in the Communications Act of 1934 as amended; (ii) is not owned by, or does not own, any telecommunications carrier; provided that ownership interests of five percent (5%) or less shall not be considered ownership for purposes of this Article; or (iii) is not affiliated, by common ownership or otherwise, with a telecommunications carrier.

1.31The term “Normal Business Hours” means 7:00 a.m. to 7:00 p.m. Central Time during Business Days.

1.32The term “NPAC/SMS” means the total solution provided by Contractor as described in this Agreement for providing, maintaining, administering, and operating a number portability administration center and service management system for the Service Area, including, but not limited to, the data processing system used to provide NPAC/SMS, the NPAC/SMS Software (including Enhancements or Maintenance Modifications), Additional Services performed pursuant to Statements of Work, Contractor utilities, hardware, Third Party software, peripherals, communications equipment and services, and other facilities used by Contractor at its NPAC/SMS Data Centers to provide Services under this Agreement, including, without limitation, the points of presence required to be provided by Contractor in the Service Area pursuant to Section 12.13 of Exhibit A - Request for Proposal, to which Users can connect to the NPAC/SMS, and other points of presence that may be provided pursuant to a Statement of Work if the “Service Area” is expanded as contemplated in the definition thereof in Section 1.46.

9

1.33The term “NPAC/SMS Data Centers” means the two (2) geographically distinct locations where Contractor provides the facilities, equipment and personnel to operate the NPAC/SMS Production Computer System and the NPAC/SMS Disaster Recovery Computer System.

1.34The term “NPAC/SMS Disaster Recovery Computer System” means the dedicated computer system that provides a software and hardware test capability for ongoing NPAC/SMS development and provides a dedicated NPAC/SMS disaster recovery arrangement, which, as of the Effective Date, is located at 777 Old Saw Mill River Road, Tarrytown, New York, and which is the same disaster recovery computer system utilized to provide NPAC/SMS for the Centralized NPAC LLCs.

1.35The term “NPAC/SMS Production Computer System” means the dedicated computer system that provides NPAC/SMS to Users, which, as of the Effective Date, is located at 200 South Wacker Drive, Chicago, Illinois, and which is the same primary computer system utilized to provide NPAC/SMS for the Centralized NPAC LLCs.

1.36The term “NPAC/SMS Software” means all computer programming code created, written and developed for or in anticipation of the NPAC/SMS application in any form.  If not otherwise specified, the NPAC/SMS Software shall include both Object Code and Source Code.  The NPAC/SMS Software shall include any Maintenance Modifications created by Contractor from time to time, and shall include Enhancements thereto when added to the NPAC/SMS Software in connection with a Statement of Work issued hereunder.

1.37The term “NPAC/SMS User Agreement” means the agreement between Contractor and a User for NPAC/SMS in the form attached to this Agreement as Exhibit J - NPAC/SMS User Agreement Form.

1.38The term “Object Code” means the machine-readable form of any computer programming code.

1.39The terms “Party” or “Parties” meanContractor and/or Customer

1.40The term “Project” means the work being performed under this Agreement to enable Contractor to offer the Services, including work performed under any Statement of Work relating to Additional Services.

1.41The term “Project Executive” means the individual designated by each of the Parties to act as its primary contact between the Parties for the resolution of issues and problems concerning operation of the NPAC/SMS, as provided for under Section 11.1.

1.42The term “Project Manager” means the individuals designated by each of the Parties to act as its primary interface between the Parties with respect to the furnishing of Additional Services, as provided for under Section 11.2.

10

1.43The term “Project Plan” means the timetable for accomplishing a Project, as set out in Exhibit F - Project Plan and Test Schedule, or in the applicable Statement of Work for any Additional Services.

1.44The term “Services” means the delivery of NPAC/SMS services in the manner provided under this Agreement and shall include Additional Services.

1.45The term “Service Area” means New York, and any other jurisdictions or market service areas to which NPAC/SMS is provided under this Agreement, which may include the states of Maine, Vermont, New Hamshire, Massacheusetts, Rhode Island and Connecticut.

1.46The term “Service Element” means any of the individual service items identified and priced in Exhibit E - Pricing Schedules.

1.47The term “Service Element Charges” means (i) all Service Element fees and charges for Service Elements allocable to a User pursuant to the Allocation Model, and (ii) all other Service Element fees and charges for Services incurred by a User.

1.48The term “Service Levels” means the service levels for NPAC/SMS specified in Exhibit G, as amended from time to time as provided for in this Agreement.

1.49The term “Service Provider” means an entity which (i) is a facilities-based carrier intending to provide telecommunications services within the Service Area and (ii) has entered into an NPAC/SMS User Agreement with Contractor to receive Services under this Agreement.

1.50The term “Software” means computer programs and related Documentation and includes application programs, operating system programs, utilities, templates, parameter tables and settings, interfaces to external programs, tools, program related data, and local area network management software.

1.51The term “Source Code” means the human-readable form of any computer programming code and related Documentation, including all comments and any procedural code such as job control language.

1.52The term “Specifications” means the functional, technical and designspecifications for Services set forth in any Statement of Work, Exhibit B - NANC NPAC/SMS Functional Requirements Specification, Exhibit C - NANC NPAC/SMS Interoperable Interface Specification, Exhibit K - External Design, Exhibit D - Response to RFP, Exhibit A - Request for Proposal, any other documents identified as Exhibits, and any other appendices or attachments referenced in this Agreement, with any conflict between or among such documents controlled pursuant to the precedence order described in the definition of “Agreement” in Section 1.4.

1.53The term “Standard Report” means a report designated in Section 9 of Exhibit B - NANC NPAC/SMS Functional Requirements Specifications.

11

1.54The term “Statement of Work” means any Statements of Work entered into under Article 13.

1.55The term “Termination Event” shall have the meaning given to such term in Section 24.1 hereof.

1.56The term “Test Window” shall be the period of time, defined by a start date and completion date, assigned to each User which will be participating in Turnup Testing, as set forth in the Turnup Test Plan.

1.57The term “Third Party” means any individual, corporation, partnership, association or other entity, other than the Parties hereto.

1.58The term “Turnup Testing Completion Date” shall mean the date upon which the incumbent Local Exchange Carrier (“LEC”) and a minimum of two (2) competitive LECs of the Service Providers covered by the Turnup Test Plan are scheduled to have completed Turnup Testing under said plan.

1.59The term “Turnup Testing Start Date” shall mean the date established in the Turnup Test Plan for the commencement of Turnup Testing for the first User under said plan.

1.60The term “Turn-up Test Plan” shall mean the final version of the NPAC/SMS Turnup Test Plan for the Service Area agreed to by the Parties, the schedule of which may be amended from time to time by the Parties for Delay Extensions and Contractor Delays.

1.61The term “Unauthorized Access” includes (i) a breach of security on a system, LAN or telecommunications network which contains, processes or transmits a User’s proprietary or Confidential Information, or (ii) unauthorized or illegal activities by Contractor, its employees, subcontractors or agents to obtain money or information from or through any Customer or Users, or in any way damage Customer, the Users using User Data, an LSMS or the NPAC/SMS.

1.62The terms “User” or “Users” means, individually or collectively, (i) any and all Service Providers and/or (ii)(a) any and all providers of telecommunications related services in the Service Area, having a need to access any part of the NPAC/SMS, such as to route, bill or rate calls, and (b)  which has or have entered into an NPAC/SMS User Agreement(s) with Contractor in the form of Exhibit J hereto to access and use Services under this Agreement.

1.63The term “User Charges” means, as to any User, the sum of (i) such User’s Service Element Charges, (ii) to the extent not reflected in Service Element Charges, such User’s fees and charges incurred in connection with any Statement of Work hereunder, determined in the manner specified by said Statement of Work and (iii) all other amounts which may appropriately be billed to Users hereunder or under the NPAC/SMS User Agreements.

12

1.64The term “User Data” means all data and information, however recorded, provided to Contractor by Users to enable Contractor to provide NPAC/SMS to Users under this Agreement.

1.65The term “User Enhancement” means any Enhancement made by Contractor in order to adapt the NPAC/SMS Software to special requirements of a specific User, which Enhancement will have no utility or limited utility to other Users in the Service Area and, if applicable, other users in service areas of any Centralized NPAC LLCs.

ARTICLE 2 - SCOPE OF WORK

Contractor shall (i) adapt the NPAC/SMS Software to meet Customer’s requirements and test the NPAC/SMS Software according to the terms and conditions of this Agreement, for implementation under the schedule in Exhibit F - Project Plan and Test Schedule; (ii) provide all facilities, equipment, Software, personnel and materials necessary to manage, maintain and operate the NPAC/SMS Data Centers; and (iii) provide Services to Users according to the terms and conditions of this Agreement and the NPAC/SMS User Agreement, including from time to time, providing Additional Services upon the execution of Statements of Work by both Parties under Article 13.

ARTICLE 3 - TERM

This Agreement shall be effective as of the Effective Date of this Agreement and shall continue for a period of five (5) years after the Acceptance Date, or, if Customer elects Target Option B pursuant to Section 6.6 (a), through March 31, 2003 (in either case, the “Initial Term”), unless terminated earlier under the terms and conditions of this Agreement. After the Initial Term, this Agreement shall automatically renew for consecutive one (1) year terms unless an election not to renew is made by (i) Customer by providing at least ninety (90) days written notice to Contractor prior to the end of the Initial Term or any subsequent renewal term or (ii) by Contractor by providing at least one hundred and eighty (180) days written notice to Customer prior to the end of the Initial Term or any subsequent renewal term.

ARTICLE 4 - COMPENSATION AND NPAC/SMS USER AGREEMENTS

4.1Compensation

In consideration for the fulfillment by Contractor of its obligation to provide NPAC/SMS as detailed hereunder, Customer hereby grants to Contractor the right to provide Services to Users in the Service Area for the term of this Agreement.  Contractor acknowledges that the opportunity to provide the Services is a substantial business opportunity to it.

Contractor shall be compensated for Services by the fees paid by Users pursuant to their respective NPAC/SMS User Agreements and under Exhibit E - Pricing Schedules, as provided in Article 6 - Pricing and Adjustment.  Customer shall have no obligation to pay Contractor any compensation for any Services or other work provided under this Agreement, unless expressly

13

authorized by a Statement of Work issued in accordance with Article 13 - Additional Services or a written modification to this Agreement.

4.2NPAC/SMS User Agreements

Contractor shall enter into NPAC/SMS User Agreements with Users for the provision of Services.  The NPAC/SMS User Agreement shall be in exactly the form attached to this Agreement as Exhibit J - NPAC/SMS User Agreement Form.  Contractor shall provide a monthly report to Customer of the name and address of all Users currently under contract with Contractor for Services,which report shall set forth in a separate section all new Users added since the last such report.  Contractor shall also provide a copy of this report to any requesting User at no additional charge.

Contractor shall not provide Services within the Service Area to any Third Party except upon execution of an NPAC/SMS User Agreement.  Any Third Party requesting services from Contractor similar to NPAC/SMS in the Service Area shall be required to complete an application for such Services, the form of which is an attachment to Exhibit J - NPAC/SMS User Agreement Form and may only be amended or modified by the Parties.  Contractor shall determine whether any Third Party qualifies for Services as a User, based upon a good-faith, reasonable interpretation of the information provided by such Third Party pursuant to its application and the definitions of “Service Provider” and “User “ in this Agreement, before entering into an NPAC/SMS User Agreement with such Third Party.  If Contractor is unsure whether a Third Party requesting such access falls within clause (i) of the definition of “Service Provider” or clause (ii)(a) of the definition of “User,” Contractor shall refer such application to Customer for its decision on whether the Third Party qualifies as a “Service Provider” or “User “ under either of the above-referenced applicable clauses of the definitions of “Service Provider” or “User” before entering into an NPAC/SMS User Agreement with such Third Party.  Contractor shall have no obligation to investigate the accuracy of any information provided by a Third Party applying for access to the NPAC/SMS as a User.  However, notwithstanding the preceding sentence, if Contractor’s Project Executive knows that a User is not or ceases to qualify as a “User” under this Agreement, such Project Executive shall notify Customer and take appropriate action under such User’s NPAC/SMS User Agreement, including, without limitation and, if appropriate, terminating such agreement.

Both Parties agree that membership in Customer is not a requirement or qualification for access.

ARTICLE 5 -  RELATIONSHIP

Contractor’s relationship to Customer in the performance of this Contract is that of an independent contractor.  Personnel furnished by Contractor (hereinafter “Contractor’s Employee(s)”) to perform Services hereunder shall at all times remain under Contractor’s exclusive control and direction and shall be employees of Contractor and not employees of Customer.  Contractor shall pay all wages, salaries and other amounts due Contractor’s Employee(s) relative to this Contract and shall be responsible for all obligations respecting them

14

relating to FICA, income tax withholdings, unemployment compensation and other similar responsibilities and, as such, Contractor is filing all required forms and necessary payments appropriate to the Contractor’s tax status. In the event the Contractor’s Employee(s)’ independent status is denied or changed and the Contractor or Contractor’s Employee(s) are declared to have “common law” status with respect to work performed for Customer,Contractor agrees to indemnify and hold Customer,  Members and their parents, affiliates and subsidiaries harmless from all fines, penalties, liabilities, claims, obligations and costs, including legal fees, which may be incurred as a result of such changes in status.

Nothing contained in this Agreement shall be deemed or construed as creating a joint venture or partnership between Contractor and Customer.  Neither Party is, by virtue of this Agreement, authorized as an agent, employee or legal representative of the other.  Except as specifically set forth herein, neither Party shall have power to control the activities and operations of the other and their status is, and at all times will continue to be, that of independent contractors.  Neither Party shall have any power or authority to bind or commit the other.

ARTICLE 6 - PRICING AND ADJUSTMENT

6.1General

Contractor shall be compensated for rendering the Services hereunder by charging Users at the prices set forth in Exhibit E - Pricing Schedules (the “Pricing Schedules”) for such Services in accordance with the Allocation Model.  Customer will deliver an Allocation Model to Contractor on or before September 30, 1997; provided, however, that if Customer fails to provide an Allocation Model by such date and until thirty (30) days after such Allocation Model is so provided, Contractor shall be entitled to allocate all allocable charges hereunder pro rata to the Users, and shall invoice such Users accordingly.

Except as provided in a Statement of Work or as otherwise specifically provided hereunder, Contractor will not increase the prices set forth in the Pricing Schedules during the Initial Term of this Agreement.  Thereafter, the prices for Services may be increased upon not less than ninety (90) days prior written notice to Customer; provided, however, that (i) any such price increase will not exceed the total percentage increase, if any, in the CPIfor the twelve (12) month period immediately preceding Contractor’s proposed price increase, or eight percent (8%), whichever is less, and (ii) prices may not be increased more than once in any twelve (12) month period.

6.2Service Element Charges

(a)Monthly Charges.

Monthly Charges will be assessed to Users for each Service Element requested by Users from those listed under Category 1 in Schedule 1 of the Pricing Schedules.  The applicable monthly rate charges appearing in Schedule 1 of the Pricing Schedules shall be assessed for each month for which the Services are provided.  For the purpose of pro-rating charges for partial months, each month will be deemed to have thirty (30) days.  Contractor may take requests for these Services directly from any User, and will report

15

the respective User charges to Customer in the Monthly Summary of Charges.  Contractor will invoice such charges to the respective Users which requested and received said Service Elements.

(b)Per User/Per Request Charges.

Per User/Per Request charges apply only when a specific Service Element listed under Category 2 in Schedule 1 of the Pricing Schedules has been requested or used by a User, and will be accumulated and billed on a monthly basis as described in more detail below.  The following shall apply to specific Per User/Per Request Service Elements:

(i)NPAC User Support Contacts: NPAC/SMS Hotline Calls.

A flat per-contact charge set forth in Category 2 of Schedule 1 to the Pricing Schedules will be assessed by Contractor for contacts received by Contractor from a User for “Billable NPAC User Support Manual Requests”, as defined in Footnote 3 to Schedule 1 of the Pricing Schedules, in excess of five (5) per day, commencing three (3) months after the date such User completes Turnup Testing.  An initial phone call, e-mail message, facsimile transmission, or any other form of written or oral communication from a User, and all follow-up contacts relating directly to the subject matter of the initial call, shall constitute a single “contact” hereunder.  Contractor may take requests for these Services directly from any User, and will report the respective User charges to Customer in the Monthly Summary of Charges.  Contractor will invoice such charges to the respective Users which requested and received said NPAC User Support Contacts.

(ii)Ported Telephone Numbers.

Promptly after the end of each calendar month, Contractor shall aggregate the total number of telephone numbers ported (as defined in footnote 4 to Schedule 1 of the Pricing Schedules) during the month and multiply such total by the applicable price per “TN Porting Event” set forth in Category 2 of Schedule 1 of the Pricing Schedules (the product of such multiplication being referred to herein as the “Aggregate Porting Charge”).  Each User in the Service Area shall be charged for a portion of the Aggregate Porting Charge for the subject month in the manner specified by the Allocation Model.  In the event Contractor’s charges to Users are based on an initial Allocation Model, or are invoiced to Users in the absence of an Allocation Model as set forth in Section 6.1, such charges shall be “trued-up” to charges that would have applied had an FCC or state regulatory agency Allocation Model been available.

(iii)Reports.

All Standard Reports will be prepared for a fixed fee as set forth in Schedule 1 of the Pricing Schedules.  All Ad Hoc Reports will be prepared by Contractor and charged at an hourly rate for the time required to define and develop the Ad Hoc Report format.  Contractor may take requests for these Services directly from any User, and will report the respective User charges to Customer in the Monthly Summary of Charges.  Contractor will invoice such charges to the respective Users which requested and received said reports

16

(c)Non-Recurring Charges.

Non-Recurring Charges will be assessed to Users for each Service Element listed under Category 3 in Schedule 1 of the Pricing Schedules.  Contractor may take requests for these Services directly from any User, and will report the respective User charges to Customer in the Monthly Summary of Charges.  Contractor will invoice such charges to the respective Users which requested and received said Service Elements.

6.3User Training

Training Charges will be assessed to Users for each of their respective personnel who attend training courses on the use of the NPAC/SMS during the term of this Agreement at the fees per person set forth in Schedule 2 of the Pricing Schedules.  The prices set forth in said Schedule 2 of the Pricing Schedules are based on a three (3) day training course.  The introduction of future Enhancements or other changes to the NPAC/SMS may increase course length and pricing, with any such changes to be described in a Statement of Work relating to the implementation of any such Enhancement or change.  Contractor will provide classroom space and hands-on training plus a copy of the training materials for each participant.  Other costs such as travel and expenses of participants are not included and will be the responsibility of the course participants or the Users they represent, as determined between them.  If more than three participants from the same User attend the same class, each participant’s training fee will be reduced by ten percent (10%).  Contractor will also travel and conduct training courses at a User’s site, provided that a minimum of three participants will take the on-site course.  The price for such training arrangements is ninety percent (90%) of standard training prices set forth in Schedule 2 of the Pricing Schedules, plus reasonable expenses of the person or persons presenting the course (e.g., travel, hotel, meals, etc.).  Contractor may take requests for these Services directly from any User, and will report the respective User charges to Customer in the Monthly Summary of Charges.  Contractor will invoice such charges to the respective Users which requested and received said training.

6.4Interoperability Testing

Interoperability Testing will be performed in accordance with an Interoperability Test Plan to be prepared by Contractor, and will be charged to Users (or, if applicable, a Third Party supplier of LSMS or Service Order Administration (“SOA”) services designated by a User as its provider of LSMS or SOA services, referred to herein as an “LSMS/SOA Supplier”) in accordance with Schedule 3 of the Pricing Schedules.  The Initial Test charges shown in Schedule 3 of the Pricing Schedules will be required to be paid in connection with initial testing of a User’s or LSMS/SOA Supplier’s LSMS or SOA software.  A certain amount of re-testing of a User’s or LSMS/SOA Supplier’s LSMS or SOA software will be required in connection with any new release of the LSMS or SOA software by the User or LSMS/SOA Supplier.  The extent of any such re-testing, and the related fees and charges therefor, will be addressed in a Statement of Work relating to such re-testing.  Re-testing of LSMS or SOA software required in connection with a new release of NPAC/SMS Software initiated by Contractor will not be charged to Users or LSMS/SOA Suppliers.  Additional testing beyond the scope of testing or time frame specified in the

17

Interoperability Test Plan (due, for example, to the need or desire of a User to perform material amounts of re-testing following remediation of defects or other alterations to LSMS or SOA software made during the course of Interoperability Testing) shall be charged at a flat rate per day (or portion thereof) as set forth in said Schedule 3.  Contractor may take requests for these Services directly from any User, and will report the respective User charges to Customer in the Monthly Summary of Charges.  Contractor will invoice such charges to the respective Users which requested and received such Interoperability Testing.

6.5Expenses

Except as otherwise provided in this Agreement and any Statement of Work, all expenses (including travel and travel-related expenses) incurred by Contractor in connection with the provision of Services are included in the fees and shall not be reimbursed by Customer, or Users, unless agreed upon by Customer in writing.

6.6Target Amounts; Shortfall and Credits; Billing

(a)Target Amounts, Optional Target Schedule.

Contractor and Customer have established monthly target amounts for specific periods during the Initial Term hereof as set forth on Schedule 5 of the Pricing Schedules (the “Monthly Target Amounts”). The Monthly Target Amounts will serve as revenue targets for Contractor during such periods and will be used to determine the Allocable Target Shortfalls and Allocable Target Credits as defined and described below. The Parties agree that the Monthly Target Amounts set forth as “Option A” in Schedule 5 of the Pricing Schedules will be the revenue targets under this Agreement unless, on or before September 15, 1997, Customer provides written notice to Contractor that it elects to have the Monthly Target Amounts as set forth as “Option B” in Schedule 5 of the Pricing Schedules serve as the revenue targets under this Agreement.  Any such election by Customer will be irrevocable.

(b)Determining Allocable Target Shortfalls and Credits.

Promptly after the end of each Billing Cycle, Contractor shall compare (i) the sum (the “Target Shortfall/Credit Compare Amount”) of (A) the aggregate amount of User Charges incurred by all Users within the Service Area with respect to Service Elements set forth on Schedule 1 of the Pricing Schedules from the beginning of the calendar year in which such Billing Cycle occurs (the “Subject Year”) to the end of such Billing Cycle and (B) the excess, if any, by which the aggregate Allocable Target Shortfalls (as defined below), if any, for all prior Billing Cycles in the Subject Year exceed the aggregate Allocable Target Credits (as defined below), if any, for the same period (the “Net Shortfall Amount”), to (ii) the aggregate sum of the Monthly Target Amount for such Billing Cycle plus the Monthly Target Amounts for all prior Billing Cycles in the Subject Year (such sum being referred to herein as the “Applicable Aggregate Target Amount”). If at the end of any Billing Cycle, the applicable Target Shortfall/Credit Compare Amount is less than the Applicable Aggregate Target Amount, then the difference (or shortfall amount) shall be an “Allocable Target Shortfall.”  Conversely, if at the end of any Billing Cycle, the applicable Target Shortfall/Credit Compare Amount exceeds the Applicable Aggregate

18

Target Amount, then the excess shall be an “Allocable Target Credit,” but only up to the amount of the Net Shortfall Amount, if any, as of such Billing Cycle.  Allocable Target Shortfalls and Credits are determined on a Subject Year by Subject Year basis, with no carryover to any following year of any prior year’s end of the year Net Shortfall Amount or Schedule 1 User Charges in excess of the aggregate of such prior year’s Monthly Target Amounts.  Each User’s share of any Allocable Target Shortfalls or Credits for any Billing Cycle will be determined in accordance with the Allocation Model and as agreed to in the User Agreement.  A sample calculation of the Allocable Target Shortfalls and Credits applying the foregoing methodology is set forth as part of Schedule 6 of the Pricing Schedules.

(c)Invoicing of Monthly Charges for Users; Monthly Summary of Charges.

Promptly after the end of each Billing Cycle, Contractor shall prepare and send to each User an invoice for the amount of its User Charges, plus such User’s share of the Allocable Target Shortfall, if any, and less the sum of (i) such User’s share of the Allocable Target Credit, if any, and (ii) such User’s allocable share of any liquidated damages, if any, assessed against Contractor pursuant to Article 16 hereof.  Contractor shall also prepare and deliver to Customer a report (the “Monthly Summary of Charges”) setting forth the billing calculation above for each User in the Service Area, and for all Users within the Service Area.  All invoices shall be due and payable within forty-five (45) days of the date of the invoice, as provided in the NPAC/SMS User Agreement.

(d)Certain Charges Incurred Prior to Acceptance.

It is understood by the Parties that certain Services hereunder, including without limitation those described in Sections 6.2(a),6.2(c), 6.3 and 6.4 hereof, may be requested by or provided to Users prior to Acceptance of the NPAC/SMS, and that such Service Element Charges may be invoiced to the appropriate Users in accordance with Section 6.6(c) above, notwithstanding that Acceptance shall not have occurred.

6.7Most Favored Customer

Contractor’s Terms to Users for the Services shall be at least as favorable as the Terms provided by Contractor to any other customer receiving NPAC/SMS-type services.  Subject to the following paragraphs in this Section, if Contractor provides more favorable Terms to another customer for NPAC/SMS services of the type received by Users, Contractor shall extend such Terms to Customer and Users, taking into account any inherent differences resulting from providing such services on a “centralized” versus a “dedicated” basis.  As used in this Article, “Terms” includes, but is not limited to, rates, prices, charges, target amounts, liquidated damages, contractual terms and conditions, or any other contractual element (including, without limitation, service level requirements) affecting the price of NPAC/SMS Services offered or the rights or obligations of the Parties or Users under either this Agreement or the NPAC/SMS Users Agreement or any similar agreement with another customer of Contractor receiving NPAC/SMS-type services (the latter being referred to herein as a “Comparable Agreement”).  Contractor shall promptly advise Customer in writing when it has entered into a Comparable Agreement and

19

inform Customer of any more favorable Terms (and, as provided below, any corresponding less favorable Terms) in such agreement.

Subject to the following paragraph, if Contractor provides more favorable Terms to another customer under a Comparable Agreement, Customer may substitute all or any portion of such more favorable Terms for the Terms of this Agreement or the NPAC/SMS User Agreement, including, if appropriate, the lowest charges included in such Terms, retroactive to the date the more favorable Terms became effective as to such other customer of Contractor.

Notwithstanding the foregoing, if any such more favorable Term of a Comparable Agreement was the product of negotiations which resulted from or resulted in one or more corresponding less favorable Terms elsewhere in such agreement, Customer must also substitute or add, as the case may be, such corresponding less favorable Term or Terms to this Agreement or the NPAC/SMS User Agreements along with the more favorable Term.  The inclusion of such less favorable Terms with the more favorable Terms shall occur only where the more favorable and less favorable Terms are (i) directly related by subject matter and the changes reflecting such Terms are made as part of the same generation of revisions to the Comparable Agreement (prior to the effectiveness thereof) or (ii) are part of the same amendment thereto (after effectiveness).  Contractor shall bear the burden of showing that the changes were so related.

Upon receiving Contractor’s notice of the provision of more favorable Terms in a Comparable Agreement, Customer must respond within ninety (90) days whether or not it wishes to adopt such Term or Terms (except that such period shall be extended, as reasonably necessary, if Customer is in good faith discussions with Contractor regarding the consequence and/or implementation of such Term or Terms within such ninety (90) days), and if Customer does not respond within such period, Customer shall be deemed to have waived the application of this Section 6.7 in such instance.

6.8Adoption of NANC Flows

In addition to all other charges payable in accordance with this Article 6 and the Pricing Schedules, Contractor shall be compensated for additional development of the NPAC/SMS Software relating to the implementation of the process flows adopted as the NANC NPAC/SMS Functional Requirements Specification 1.0 and the NANC NPAC/SMS Interoperable Interface Specification 1.0 (together, the “NANC 1.0 Flows”).  The total charge for the changes arising out of the NANC 1.0 Flows shall be $[* * *], which shall be allocated among the Centralized NPAC LLCs equally (with four Centralized NPAC LLCs, each would be allocated $[* * *]).  The amount allocated to Customer shall be paid by Users in forty-eight (48) equal monthly installments commencing January 1, 1998 and continuing through and including December 31, 2001 (with four (4) Centralized NPAC LLCs, Customer’s allocated monthly share would be $[* * *]).  The amount invoiced to each User in any month shall be determined in accordance with the Allocation Model in effect for such month. The payments provided for in this Section shall not be applied against the Annual Target Amounts.

20

ARTICLE 7 - BENCHMARKING

7.1Benchmark Overview

Within sixty (60) days after the Effective Date, Customer and Contractor shall establish the objective measurement and comparison process (utilizing as the baselines the Service Levels established under Exhibit G - Service Level Requirements, as the same may be amended by this Article 7 - Benchmarking) (the “Benchmarking Process”) in order to ensure that Contractor provides Customer and Users with technology and service level standards equal to or greater than other organizations receiving similar services.

7.2Benchmarker

Each comparison measurement of the Benchmarking Process (the “Benchmark”) shall be conducted by a person (the “Benchmarker”) who is either:

(a)an employee or employees of Contractor; or

(b)at Customer’s option, a Third Party selected by Customer, provided that (i) neither such Third Party nor any of its affiliates competes or intends to compete, directly or indirectly, with Contractor for the provision of NPAC/SMS in the Service Area or in any other service area and (ii) such Third Party signs an appropriate confidentiality agreement with Customer and Contractor regarding the Confidential Information, substantially in accordance with the provisions of Article 15 hereof.

The fees and expenses charged by the Third Party Benchmarker shall be paid by Customer.

7.3Benchmark

The Benchmarker shall conduct the Benchmarking Process annually or at such other frequency as may be mutually agreed upon by the Parties.  Customer and Contractor shall agree upon the period during which the Benchmarking Process shall be conducted.

7.4Benchmark Information

Customer and Contractor shall jointly determine the objective Third Party information that will be required to conduct or support the Benchmark (the “Benchmark Information”).  Customer and Contractor shall:

(a)review the Benchmark Information and

(b)schedule a meeting to address any issues either Party may have with the Benchmark Information.

21

Contractor shall provide the Benchmark Information (including information relating to other customer sites, if available) at no additional cost to Customer.

7.5Benchmarking Results

Within thirty (30) days after the completion of the Benchmarking Process, the Benchmarker shall produce a written report of the results thereof, together with supporting schedules and documentation (such report, the “Benchmarking Results”), and shall deliver the Benchmarking Results to the Project Executives for Customer and Contractor.  If Customer and Contractor agree, after reviewing the Benchmarking Results, that adjustments to the Service Levels are necessary or appropriate, the Parties shall amend the Service Levels accordingly.  If any such adjustment to the Service Levels would also involve or necessitate a change to or modification of the NPAC/SMS, Contractor shall propose a Statement of Work in accordance with Article 13, which shall be agreed to and performed in accordance with the provisions of Section 13.4, and any amendment to the Service Levels agreed to by the Parties shall take effect upon the completion and acceptance of the work subject to any such Statement of Work.  In the event either Party disputes the Benchmarking Results or whether adjustments are necessary or appropriate, the Benchmarking Results or need for adjustments to Service Levels shall be subject to the dispute resolution procedures set forth in Article 26 - Internal Dispute Resolution and Arbitration.

ARTICLE 8 - OBLIGATIONS OF CONTRACTOR

8.1Testing of NPAC/SMS

(a)Testing; Readiness of Users.

Turn-up Testing (as described in footnote 6 to Schedule 1 of the Pricing Schedules) will be completed in accordance with the Turnup Test Plan and the Project Plan, the current version of which and any subsequent versions of which, shall be as set forth in Exhibit F - Project Plan and Test Schedule, which Project Plan and Test Schedule shall conform to any and all requirements of the FCC.  Prior to commencing Turnup Testing, each User must have a Certified System (as defined in Section 7.3(b) of the NPAC/SMS User Agreement, the form of which is attached hereto as Exhibit J) prior to the scheduled commencement date of such User’s Test Window.

(b)Network Testing.

On the Network Test Readiness Date, Contractor shall make the NPAC/SMS available to the Users which have completed Turnup Testing for the purposes of conducting network-to-network testing of the porting of telephone numbers pursuant to the Project Plan and Test Schedule at Exhibit F, which shall conform to any and all requirements of the FCC (“Network Testing”). Customer will determine whether or not the NPAC/SMS is operating in accordance with the Specifications.  Contractor will use reasonable efforts to cooperate with Customer and Customer’s Network Testing coordinator in performing such Network Testing.

22

(c)Delays.

The commencement and successful completion of Turn-up Testing and Network Testing in a timely manner by the three (3) Users referred to in the definition of “Turn-up Testing Completion Date” in Section 1.58 above (the “Acceptance Test Users”) shall be considered a material term of this Agreement.  Subject to Section 16.1, if applicable, the Final Delivery Date shall be extended on a day-for-day basis for any delay in completing such testing which is not directly or indirectly the result of Contractor Delays (such delays, “Delay Extensions”); provided, however, that if Contractor reasonably establishes to Customer’s satisfaction that a longer delay is necessary because personnel, facilities or other resources (including those of subcontractors) could not, through the application of best efforts by Contractor, be made available to allow performance by Contractor in a timely manner based on a day-for-day extension alone, then the Final Delivery Date shall be extended by such additional days as may be considered appropriate under the circumstances.

8.2Acceptance; Effect of Delays on Payments

If not accepted sooner by Customer, the NPAC/SMS shall be deemed to have been accepted (“Acceptance”) upon the day following the Final Delivery Date or, if later, the date upon which the Acceptance Test Users shall have completed Network Testing and Contractor shall have corrected, at its own expense, any Material Defects identified by Contractor, Customer or a User during such testing (such date, the “Acceptance Date”).  Customer with the input of the affected Acceptance Test User(s) will determine whether or not such Material Defects have been corrected so that the NPAC/SMS is operating in accordance with the Specifications.  Minor Defects will not delay Acceptance, but Contractor will use its best efforts to correct such Minor Defects within sixty (60) days following Acceptance.  If the Acceptance Date has not occurred as of October 1, 1997 (as extended, if necessary, day-for-day, for any Contractor Delay days) for any reason other than Contractor Delays or a Force Majeure Event, Contractor may commence including Allocable Target Shortfalls and Allocable Target Credits in its invoices to Users in accordance with Section 6.6 hereof.  Customer’s Acceptance of the NPAC/SMS is not a waiver of the warranty in Section 21.3 that the NPAC/SMS is operating in accordance with the Specifications.

8.3Provision of NPAC/SMS; Service Level Adjustments

Contractor shall provide the NPAC/SMS and the Services at or above the Service Levels, and in a manner such that each Service Provider and each User receives the applicable Services at the same Service Levels.  Customer shall have the applicable remedies set forth herein, for any failure by Contractor to provide the NPAC/SMS and the Services at or above the Service Levels and Users shall have such recourse and remedies as are set forth in the NPAC/SMS User Agreement.

Either Customer or Contractor may, at any time, initiate discussions to review any Service Level.  If Customer and Contractor agree on an adjustment to the Service Levels, the parties shall amend the Service Levels accordingly.  If any such adjustment to the Service Levels would also involve or necessitate a change to or modification of the NPAC/SMS, Contractor shall propose a Statement of Work in accordance with Article 13, which shall be agreed to and performed in accordance with the provisions of Section 13.4, and any amendment to the Service Levels agreed

23

to by the Parties shall take effect upon the completion and acceptance of the work subject to any such Statement of Work.

8.4Compliance with Service Level Requirements; Monitoring and Reporting

Contractor will monitor its compliance with the Service Levels hereunder and certain other aspects of user and system functionality, and issue reports to Customer thereon (“Reports”).  Standard Reports (as defined in Section 9 of Exhibit B) and other Reports to be provided on a periodic basis hereunder, and the fees to be charged therefor, if any, are described in Exhibit H - Reporting and Monitoring Requirements.  Contractor will also prepare Ad Hoc Reports (which include Reports not specifically included on Exhibit H and Reports included on Exhibit H, but requested by Customer or a User at other than the time established for the regular issuance thereof), the preparation of which will be charged in accordance with Exhibit E - Pricing Schedules.  The Project Executives will agree upon the form of Standard Reports within thirty (30) days prior to the Network Testing Readiness Date.  Each Report shall (i) have an executive summary and a glossary of defined terms, (ii) present monthly, quarterly and year-to-date cumulative data (including comparisons with similar data from the immediately prior year, if applicable) where appropriate, (iii) make use of tables, graphs and other similar methods of presenting the information and statistics contained therein, and (iv) also have such narrative analysis and summaries as Contractor feels would aid the understanding of the data presented in statistical, tabular and graphical form.  The Reports, and the systems and procedures for requesting and creating them, shall meet the user and system functionality requirements of Sections 9.1 and 9.2 of Exhibit B - NANC NPAC/SMS Functional Requirements Specifications.

The distribution of Reports shall be controlled by the recipient thereof.  Distribution of Reports within the Contractor’s organization shall be limited to those persons who have a “need to know” and Contractor shall provide to Customer for its approval, and update from time to time as necessary, a list of Contractor personnel who will receive distributions of various Reports.  Contractor’s Project Executive or other appropriate representative of Contractor will be available upon reasonable notice to discuss any Report with Customer’s Project Executive or other appropriate representative of Customer, or in the case of Reports relating to a particular User, with a representative of that User.

Customer reserves the right, at Customer’s expense, to contract with Third Parties to verify the monitoring functions of Contractor referred to above or review reports on Customer’s behalf; provided that (i) neither such Third Party nor any of its affiliates competes or intends to compete, directly or indirectly, with Contractor for the provision of NPAC/SMS in the Service Area or in any other service area and (ii) such Third Party signs an appropriate confidentiality agreement with Customer and Contractor regarding the Confidential Information, substantially in accordance with the provisions of Article 15 hereof.

8.5Security; Unauthorized Access; Inspection

Contractor shall maintain and enforce at the NPAC/SMS Data Centers safety and physical security procedures that conform to Section 7 of Exhibit A - Request for Proposal and the

24

procedures set forth at Sections 2.7 and 2.12.8 (Primary NPAC Physical Access Security) of Exhibit D - Response to RFP (collectively, the “Safety/Security Requirements”).

In the event Contractor becomes aware of an Unauthorized Access to the NPAC/SMS, User Data, or an LSMS, Contractor shall immediately (i) notify Customer and the applicable User(s) in writing; (ii) investigate the Unauthorized Access; and (iii) subject to reasonable access, security, and confidentiality requirements, provide Customer, Users, and their respective designees with reasonable access to all resources and information in Contractor’s possession as may be necessary to investigate the Unauthorized Access.  Customer (together with affected User(s)) shall have the right to conduct and control any investigation relating to the Unauthorized Access as it determines is appropriate.

Subject to Contractor’s reasonable access, security, and confidentiality requirements, Customer, upon twenty-four (24) hours prior written notice to Contractor’s Project Executive, shall have the right to make visits to the Data Center to review Safety/Security Requirements respecting User Data (“Safety/Security Visits”); provided, however, that such Safety/Security Visits may be made no more than four (4) times in any twelve (12) month period (excluding any follow-up visits referred to in the following sentence).  If any of the safety and physical security procedures in effect at the NPAC/SMS Data Centers does not at a minimum comply with those specified in the Safety/Security Requirements, Contractor shall (i) implement corrective measures, and (ii) give notice of such implementation to Customer and permit Customer to make one or more follow-up visits to the affected Data Center, as necessary, to confirm the deficiency has been rectified.  Customer’s rights under this paragraph shall not in any way limit Customer’s right, with reasonable notice, to visit the Data Center for reasons other than a Safety/Security Visit.

8.6Procurement; Staffing Responsibilities; Location Changes

Contractor shall be responsible for and shall pay all expenses and costs of the procurement or provision of all hardware, systems software, telecommunications services, facilities, and supplies required to support the provision of NPAC/SMS, and the operation of the NPAC/SMS Data Centers, by Contractor.  All facilities shall comply with Section 12.13 of Exhibit A - Request for Proposal.Each User shall be responsible for providing and shall pay all expenses and costs of the procurement or provision of all hardware, systems software, telecommunications services, facilities and supplies required by User to access NPAC/SMS from such User’s facilities, to the point of presence, as specified in Section 1.34.

Contractor shall be responsible for staffing the NPAC/SMS Data Centers and providing appropriate personnel to provide the NPAC/SMS.  Contractor must manage its own labor relations with any trade or union represented among its employees and shall negotiate and be responsible for adjusting all disputes between itself, its employees, and any union representing such employees.  If Contractor has knowledge of any actual or potential labor dispute which is delaying or threatens to delay the timely performance of the Project, Contractor shall give prompt notice to Customer.  Contractor shall confirm the notice in writing within twenty-four (24) hours.

25

Any change in the location of an NPAC/SMS Data Center must be approved in advance by Customer, which approval shall not be unreasonably withheld or delayed, and must be accomplished without impairing the level of Services rendered hereunder by Contractor. Any incremental expense incurred by Users as a result of relocation of an NPAC/SMS Data Center shall be reimbursed to Users by Contractor, unless such relocation is done at the request of Customer (alone or on behalf of Users), in which case, Customer shall first enter into a Statement of Work setting forth the manner in which Contractor shall be reimbursed for any expense incurred in connection with such relocation.

8.7Training

Contractor shall develop and provide comprehensive training courses for User personnel consistent with the requirements of Sections 12.8.4 and 12.8.6 of Exhibit A - Request for Proposal.  The pricing for training courses and materials shall be as set forth in Section 6.3 and Exhibit E - Pricing Schedules.All training provided by Contractor shall include written course materials that may be kept, reproduced, and distributed by the Users, provided that any reproductions of such materials shall include any copyright or similar proprietary notices placed on the materials by Contractor. Users shall have the right to make unlimited copies of training materials provided by Contractor, at no additional charge, for internal use.  A User may cancel a training course scheduled by Contractor at any time upon written notice to Contractor; provided, however, that the User shall be liable to Contractor for all reasonable expenses incurred by Contractor in preparation for the course that are not otherwise recoverable by Contractor if such training course is canceled by the User less than two (2) weeks prior to the start of such course.  In order to ensure that only qualified students pass Contractor’s training programs, Contractor shall monitor the progress of Users’ employees as they are trained, shall periodically test students as a course proceeds, and shall provide written certification of satisfactory performance of course requirements for those students that successfully meet such requirements.

There shall be no restrictions on any User having an individual trained in the operation of NPAC/SMS train other employees of the User, except that each User must notify Contractor at the time the training course is scheduled if it desires the individual(s) being enrolled to be trained as trainers.  All individuals trained as trainers must schedule and attend, at the User’s expense, any additional training courses mandated by Contractor to maintain such individual’s expertise as a trainer with respect to any Enhancement or Maintenance Modification to the NPAC/SMS Software.  Contractor shall have no responsibility for certifying any employees trained by such User’s trainers.

Notwithstanding anything to the contrary above, a User may train its personnel internally.  In such event, Contractor shall provide the above-referenced training materials directly to User.  User may then use such materials to train its personnel internally , but, prior to using the NPAC/SMS, such personnel will be required to pass a certification examination of the same or similar nature given to those individuals taking Contractor’s training courses.

26

8.8Taxes

Contractor agrees to pay, and to hold Customer and the Users harmless against, any penalty, interest, additional tax or other charge that may be levied or assessed as a result of the delay or failure of Contractor for any reason to pay any tax or file any return or information required by law, rule or regulation or by this Agreement to be paid or filed by Contractor, unless such delay or failure by Contractor is on account of the delay or failure of a User to remit to or reimburse Contractor for any taxes which a User is obligated to pay by law, rule or regulation or under this Agreement or its respective NPAC/SMS User Agreement.  Customer shall have no liability to Contractor for any taxes.

8.9Licenses and Permits

Contractor shall, at its sole cost and expense, obtain all licenses, authorizations and permits required by applicable legislative enactment and regulatory authorizations in connection with the performance of its obligations under this Agreement.  Contractor shall indemnify and hold Customer, Members, Users and their respective affiliates harmless from and against any and all liabilities, damages (including without limitation punitive or special damages), losses or expenses (including attorney’s fees) arising out of any breach by Contractor of this Section.

8.10Laws and Regulations

Contractor shall comply, at its expense, with all applicable federal, state, county, and local laws, ordinances, regulations, and codes in the performance of its obligations under this Agreement (including procurement of required permits and certificates), including the Fair Labor Standards Act and the Occupational Safety and Health Act. Contractor shall indemnify and hold Customer, Members, Users and their respective affiliates harmless from and against any and all liabilities, damages (including without limitation punitive or special damages), losses or expenses (including attorney’s fees) arising out of any breach by Contractor of this Section.

8.11Immigration Law Compliance

Contractor warrants, represents and agrees that it will not assign any individual to perform work under this Agreement who is an unauthorized alien under the Immigration Reform and Control Act of 1986, as amended or its implementing regulations.

In the event any employee of Contractor working under this Agreement is discovered to be an unauthorized alien, Contractor will immediately remove that individual and replace that individual with one who is not an unauthorized alien.

Contractor shall indemnify and hold Customer, Members, Users and their respective affiliates harmless from and against any and all liabilities, damages (including without limitation punitive or special damages), losses or expenses (including attorney’s fees) arising out of any breach by Contractor of this Section.

27

8.12Quality

Contractor shall provide high-quality service and support to Usersconsistent with the NPAC/SMS Service Level Requirements specified in Exhibit G and as modified through the “Benchmarking” process set forth in Article 7 herein.

The Contractor will measure performance against these Service Level Requirements, report appropriately in accordance with Section 8.4, promote an effective quality assurance process consistent with the provisions of Exhibit D - Response to RFP, and confirm User satisfaction through the survey process.

Contractor shall retain a competent and experienced staff and ensure that each staff member is aware of, committed to, and actively involved in total quality improvement.  Each NPAC/SMS staff member shall be personally responsible to Contractor for the quality of his or her work.  The NPAC/SMS quality manager and functional managers will ensure that sufficient resources are committed to this effort.

Contractor agrees that it will comply with Customer’s reasonable requests for the additional collection and reporting of specific quality data that Customer needs to measure Services and Deliverables against Customer quality objectives.  Any such request for additional collection and reporting will be accomplished through the Statement of Work process.  Customer and Contractor may also agree to apply particular quality standards to specific Statements of Work.

8.13Notification of Additional Services, Enhancements and Modifications

Contractor shall provide written notification to all Users on a monthly basis of any proposed Additional Services, Enhancements, Custom Enhancements, User Enhancements and/or Maintenance Modifications to the NPAC/SMS.  In addition to the above notification requirement, Contractor may also post notice of any proposed Additional Services, Enhancements, Custom Enhancements, User Enhancements and/or Maintenance Modifications to the NPAC/SMS on an Electronic Bulletin Board.

ARTICLE 9 - OWNERSHIP OF INTELLECTUAL PROPERTY; SOURCE CODE ESCROW

9.1Ownership of Intellectual Property

Except as otherwise expressly provided in this Agreement or any applicable Statement of Work, Contractor shall own all Intellectual Property created under this Agreement by or for Contractor, including the NPAC/SMS Software and any Enhancements and Maintenance Modifications.  Contractor shall not own any standard interface connecting the NPAC/SMS to Users, which interface shall be in the public domain.

9.2Grant of License on Condition of Termination by Customer

In the event of termination of this Agreement by Customer under Section 23.1 (a), (b), (c) or (d) and, in the case of Sections 23.1(a) and (b), under circumstances where Customer has not

28

alternatively elected to extend this Agreement pursuant to Section 24.2, Contractor shall grant to Customer a nontransferable (other than to its permitted successors and assigns pursuant to Exhibit L - Additional Terms and Conditions of License), restricted, perpetual, royalty-free, non-exclusive license to use and modify the NPAC/SMS Software and to sublicense the NPAC/SMS Software to any contractor providing services similar to NPAC/SMS to the Users or to any other entity performing a function similar to that of Customer, for use in creating, managing and operating a data center similar to the NPAC/SMS Data Center in the Service Area as it exists at the time of termination.  Other terms and conditions of the above referenced license are set forth in Exhibit L.

9.3Grant of License on Condition of Force Majeure or Contract Expiration

In the event of termination of this Agreement by Customer under Section 12.6 or Section 12.8 or under circumstances where this Agreement has not been renewed pursuant to Article 3 and has not been extended pursuant to Section 24.2, Contractor shall grant to Customer a renewable five (5) year, nontransferable (other than to its permitted successors and assigns pursuant to Exhibit L), restricted, non-exclusive license to use and modify the NPAC/SMS Software and to sublicense the NPAC/SMS Software to any contractor providing services similar to NPAC/SMS to the Users or to any other entity performing a function similar to that of Customer, for use in creating, managing and operating a data center similar to the NPAC/SMS Data Center in the Service Area as it exists at the time of termination or Agreement expiration.  A monthly royalty fee will be required for the duration of the five (5) year license or until the effective date of termination by Customer.  Said monthly royalty fee shall be calculated as set forth in Exhibit L.  Other terms and conditions of the above referenced license are set forth in Exhibit L.

9.4Software Escrow

Contractor shall deposit the Source Code, Object Code and related Documentation for NPAC/SMS Software into an escrow account pursuant to an escrow agreement to be entered into between Contractor, Customer and an escrow agent.  The escrow agreement shall authorize release of the Source Code, Object Code and related Documentation to Customer as a licensee (consistent with Sections 9.2 and 9.3 above) on certain terms and conditions upon the occurrence of a Termination Event or Non-Renewal (as such terms are defined in Section 24.1 below).  The escrow agreement shall be in the form of Exhibit M hereto, subject to any changes to such form of agreement that the parties agree to accept from the escrow agent.

ARTICLE 10 - PROBLEM RESOLUTION

10.1Hotline Service

Contractor shall provide a “Hotline Service” to Users to (i) help Users in answering routine questions and resolving problems with respect to use of the NPAC/SMS and (ii) enable Users to report any defect in the NPAC/SMS or any failure of the NPAC/SMS to perform in accordance with the Specifications, which defects and/or failures shall be responded to by Contractor in accordance with Section 10.2.  In addition to telephone access, the “Hotline Service” shall also

29

include access by means of electronic mail service when made available by Contractor.  The Hotline Service shall be made available seven (7) days a week, twenty-four (24) hours a day.  Contractor will provide personnel to answer the Hotline Service during Normal Business Hours and will have personnel “on call” for calls to the Hotline Service during all other hours.  All common carrier charges incurred by Users and all costs of telephone and terminal equipment incurred by Users shall be the responsibility of the Users using the Hotline Service. Users may contact the Hotline Service at 1-888-NPAC HELP.  Contractor shall make a diligent effort to promptly acknowledge Users’ contacts to the Hotline Service.  Users will be charged for their contacts to the Hotline Service pursuant to Section 6.2(b)(i) hereof.

10.2Problem Correction

When a problem occurs which Contractor or a User determines is caused by a Defect, Contractor will use its best efforts to identify and begin remedial efforts with respect to such problem at no charge within the following timeframes:

(a)With respect to Material Defects, within one hour.

(b)With respect to Minor Defects, within two Business Days.

Additionally, in connection with Material Defects, the Contractor shall prepare updated system status reports from the NPAC/SMS Data Center approximately every thirty (30) minutes following notice of the problem and make that information available to Users via the NPAC/SMS Hotline provided for under Section 10.1.  If Contractor is unable to promptly correct Defects, it shall provide Users with procedures that will enable them to bypass or otherwise work around the problem through efforts that are appropriate in view of (i) the impact of the problem on their operations and (ii) the ability to implement bypass or work-around procedures to minimize such impact during Contractor’s remedial efforts.

As part of the Services rendered under this Agreement, Contractor shall promptly correct any errors or inaccuracies in User Data and any reports provided by Contractor under this Agreement that were caused by Contractor.

ARTICLE 11 - PROJECT STAFF

11.1Project Executives and Oversight

Each Party shall appoint an individual who, from the Effective Date of this Agreement, shall serve as the primary contact for that Party with the other Party (the “Contractor Project Executive” and the “Customer Project Executive,” as applicable).  The initial Contractor Project Executive and Customer Project Executive are identified in Exhibit I - Key Personnel.

The Contractor Project Executive and Customer Project Executive shall be responsible for coordinating the day to day resolution of issues and problems concerning operation of the NPAC/SMS.  Customer agrees that, unless Contractor is otherwise notified by Customer,

30

Customer’s Project Executive has the authority to act on behalf of Customer for all purposes under this Agreement (including without limitation, all consent, approval and delivery requirements), such that Contractor shall (i) require action from, and shall be entitled to rely upon actions taken by, Customer’s Project Executive in all circumstances where action is required of Customer under this Agreement (e.g., consents, approvals, etc.) and (ii) satisfy all its requirements of delivery of items to Customer under this Agreement (including, without limitation, consents, approvals, notices, the NPAC/SMS, Deliverables and other items referred to on Exhibit F - Project Plan and Test Schedule) if Contractor makes delivery of such items to Customer’s Project Executive (leaving open only the determination of whether any such delivery was made to Customer’s Project Executive on or prior to the required delivery date).  Notwithstanding the above, Customer’s Project Executive is not authorized to modify or amend the terms of this Agreement.

Within thirty (30) days after the Effective Date of this Agreement, the Contractor Project Executive and Customer Project Executive shall meet to discuss issues concerning Project execution, including, but not limited to:

(a)determining location and frequency of meetings;

(b)establishing appropriate committees;

(c)resolving contract issues between the Parties;

(d)managing the Project schedule and any changes;

(e)generally overseeing the performance of this Agreement; and

(f)providing strategic direction.

Based upon their review of these issues, Contractor Project Executive and Customer Project Executive shall establish, as they deem necessary, appropriate written policies and procedures for the management of the Project and implementation of the terms of this Agreement.  Such policies and procedures shall be incorporated into an amended Exhibit I - Key Personnel, and shall become a part of this Agreement.

Contractor shall use its best efforts to ensure that its Project Executive (initial and replacement) serves for a minimum of one year, and Customer shall use its best efforts to ensure that there is some level of continuity of service by its Project Executive (initial and replacement).  Contractor’s appointment of any Contractor Project Executive shall be subject to Customer’s consent, which consent shall not be unreasonably withheld or delayed.  The Contractor Project Executive may also serve as Contractor’s Project Manager for Projects calling for the appointment of a Project Manager.

31

11.2Project Managers

For Projects related to Additional Services or any other Project where Project Managers will facilitate completion of the Project, Contractor and Customer shall each designate a Project Manager who shall act as the primary interface between the Parties with respect to the furnishing of such Additional Services in the applicable Statement of Work.  The Parties’ respective Project Managers shall be responsible for insuring the continuity of communications between the Parties as the Project proceeds.  Each Project Manager shall designate an authorized representative to act in his or her absence.

Each month or at such other intervals as may be mutually agreed to, there shall be a meeting to discuss the progress of the Project.  At such meetings the Contractor’s Project Manager shall present a written report to Customer’s Project Manager with respect to Project status and progress.  Contractor’s Project Manager shall also be responsible for (1) producing and verifying the delivery schedule for all new Projects; (2) coordinating logistics and delivery of all Deliverables; and (3) conducting projectquality review meetings as necessary.

11.3Conduct of Personnel

While at the locations of Contractor and Customer, Contractor’s and Customer’s personnel, contractors and subcontractors shall (i) comply with host company’s requests, rules and regulations regarding personal and professional conduct generally applicable to such locations, and safety and physical security procedures applicable to such locations; provided that, such persons are made aware of such requests, rules, regulations and procedures sufficiently in advance in order to have time to comply; and (ii) otherwise conduct themselves in a businesslike and professional manner.

In the event that Customer or Contractor, as the case may be, determines in good faith that a particular employee or subcontractor of the other is not conducting himself or herself properly under this Section 11.3, either Party may provide the other Party with written notice and documentation in respect of such conduct.  Upon receipt of such written notice, the other Party shall promptly investigate the matter and take appropriate action which may include (i) removing the non-compliant person from the Project staff, (ii) providing the other Party with prompt written notice of such removal, and (iii) replacing the non-compliant person with a similarly qualified individual.

Neither Party nor any User shall require waivers or releases of any personal rights from representatives of the other in connection with visits to its premises and both Parties agree that no such releases or waivers shall be pleaded by them or third persons in any action or proceeding.

ARTICLE 12 - DISASTER RECOVERY

12.1Contractor’s Responsibility for Disaster Recovery

As part of the NPAC/SMS, Contractor shall be responsible for providing disaster recovery arrangements consistent with the disaster recovery and back-up processes specified in Exhibit G - Service Level Requirements.

32

In the event of a disaster, Contractor shall not increase its charges under this Agreement or charge Users or Customer usage fees in addition to the fees payable under this Agreement.

12.2Disaster Recovery Plans

Contractor shall provide Customer with separate disaster recovery and back-up plans for the NPAC/SMS Production Computer System site and the NPAC/SMS Disaster Recovery Computer System site, which plans are subject to Customer’s approval.

The disaster recovery and back-up plans shall address both operational and managerial processes and procedures, including back-up and restoration procedures, and shall be a complete, stand-alone document.  The plans shall describe in reasonable detail how Contractor will perform testing, and what will be tested, to validate the managerial processes and procedures implemented by Contractor.

Contractor will, at Customer’s request, review the disaster recovery and back-up plans with Customer.  Such review will address such areas as the disaster recovery and back-up strategy, including procedures, data center facilities, back-up frequency, and disaster recovery processor capacity.  Contractor will make such changes in the plans as may be jointly agreed to by the Parties.  Contractor will also revise the disaster recovery and back-up plans following any significant changes in the NPAC/SMS hardware and software environment, when necessary, in its discretion, after consultation with Customer.

12.3Disaster Recovery Exercises for the NPAC/SMS

Customer may request a complete disaster recovery exercise for the NPAC/SMS Production Computer System once a year (at a time agreed to by Contractor and Customer), unless at any point in time during the twelve (12) months prior to such request Contractor has successfully “cut-over” to the NPAC/SMS Disaster Recovery Computer System and operated thereon during the normal course of operations.  Contractor shall certify to Customer, in a written report, that the disaster recovery plans are fully operational and shall include in such report the detailed results of such exercise.

12.4Implementing Switch to Disaster Recovery Site; Restoration

If a failure of the NPAC/SMS Production Computer System is detected, in accordance with the Methods and Procedures Document (operating procedures as agreed between the Project Executives, as then in effect), and cannot be immediately corrected, the cutover to the NPAC/SMS Disaster Recovery Computer Site must be completed within ten (10) minutes thereafter.  Contractor shall prepare updated system status reports from the NPAC/SMS Data Center approximately every thirty (30) minutes and make that information available to Users via the NPAC/SMS Hotline provided for under Section 10.1.  Whenever it is determined that the NPAC/SMS is to be restored at the NPAC/SMS Production Computer System, such restoration shall be accomplished within the time frame specified in Exhibit G - Service Level

33

Requirements.  Contractor is responsible for executing all phases of the disaster recovery and restoration.

12.5Data Loss During a Disaster Recovery

Contractor shall provide the necessary data communications and computer equipment and develop the necessary procedures to ensure that the NPAC/SMS Production Computer System site databases are recoverable by the NPAC/SMS Disaster Recovery Computer System.

Contractor is responsible for informing Users of the database status after Contractor employs any database recovery procedures.  Contractor will notify the Users of the time period during which transactions were lost so that they may effect restoration to the best of their abilities.  Any User updates required because of a data loss under this Article shall not be considered a billable event.

12.6Occurrence of Force Majeure

Upon the occurrence of a Force Majeure Event, as described in Section 16.6, at the Contractor’s NPAC/SMS Production Computer System site or the NPAC/SMS Disaster Recovery Computer System site, Contractor shall immediately invoke the disaster recovery procedures as set forth in this Article 12.

If any Force Majeure Event results in a failure to deliver the NPAC/SMS from both the NPAC/SMS Production Computer System site and the NPAC/SMS Disaster Recovery Computer System site, Users may, upon written notice to Contractor, cease payment of the charges payable under this Agreement, except for services already rendered, until the recovery from such Force Majeure Event has been completed at either of such NPAC/SMS Data Centers or an alternate location provided by Contractor.

If a Force Majeure Event, as defined in Section 16.6, at both the NPAC/SMS Production Computer System site and the NPAC/SMS Disaster Recovery Computer System site prevents Contractor from reinstating the NPAC/SMS within thirty (30) days of such Force Majeure Event, Customer may terminate this Agreement as of a date specified by Customer (such termination shall not be deemed a termination for cause under Article 23 - Termination).  Contractor shall notify Customer within five (5) Business Days after such Force Majeure Event whether it expects to reinstate the NPAC/SMS within thirty (30) days.  If Contractor will not reinstate within such period, Customer must notify Contractor within five (5) Business Days following its receipt of Contractor’s notice if Customer intends to terminate this Agreement.  If Customer elects not to terminate based on Contractor’s representation that it will reinstate the NPAC/SMS by a certain date, Contractor shall keep Customer informed of its progress toward such reinstatement.  If Contractor informs Customer that Contractor is not able to meet its projected completion date for reinstatement, Customer shall again have the right to terminate this Agreement, within five (5) Business Days following its receipt of such notice from Contractor.  Failure by Contractor to notify Customer that Contractor will not meet the projected completion date does not waive Customer’s right to terminate this Agreement.

34

12.7Allocation of Resources For Disaster Recovery or Force Majeure

Whenever a Force Majeure Event or a disaster causes Contractor to allocate limited resources between or among Customer and Contractor’s other customers, Customer shall receive at least the same priority in respect of such allocation as that received by Contractor’s other customers.

12.8Permanent Loss of Contractor’s NPAC/SMS Data Centers

The following Contractor obligations and Customer rights apply in the event of a permanent loss of Contractor’s NPAC/SMS Data Centers:

(a)Loss of NPAC/SMS Production Computer System site.

If the NPAC/SMS Production Computer System site is physically irreparable and the application cannot be moved back, Contractor shall implement steps to ensure that the NPAC/SMS Disaster Recovery Computer System site is capable of providing all functions of the NPAC/SMS and that any personnel, procedures or other facilities necessary to provide those services on an ongoing basis at the NPAC/SMS Disaster Recovery Computer System site are provided.  At the same time, Contractor shall establish a replacement NPAC/SMS Production Computer System site which must be made operational within six (6) months.  Within thirty (30) days after such loss, Contractor shall establish a contingency plan to provide back-up NPAC/SMS capability at another location pending restoration of the NPAC/SMS Production Computer System, in the event of the loss of or interruption in Services from the NPAC/SMS Disaster Recovery Computer System.

(b)Loss of NPAC/SMS Disaster Recovery Computer System site.

If, at any time, a disaster renders the NPAC/SMS Disaster Recovery Computer System site unusable, then Contractor shall establish a replacement NPAC/SMS Disaster Recovery Computer System site capable of providing all of the NPAC/SMS disaster recovery services, which shall be made operational within six (6) months.  Within thirty (30) days after such loss, Contractor shall establish a contingency plan to provide back-up NPAC/SMS capability at another location pending restoration of the NPAC/SMS Disaster Recovery Computer System, in the event of the loss of or interruption in Services from the NPAC/SMS Production Computer System.

(c)Customer’s Right to Terminate for Cause.

If Customer elects not to exercise its right to terminate for a Force Majeure event under Section 12.6 and Contractor fails to restore the NPAC/SMS after the loss of either or both of the NPAC/SMS Data Centers within the time frames allowed in subsections (a) and (b) above, Customer shall have the right to terminate this Agreement for cause as provided for in Article 23 - Termination.

35

ARTICLE 13 - ADDITIONAL SERVICES

13.1Requested by Customer

During the term of this Agreement, Customer may request that Contractor provide new or additional services under this Agreement or make certain changes in the Services provided under this Agreement, including, without limitation, (i) the addition of new or different functionality to the NPAC/SMS, (ii) a modification, reduction or expansion of existing functionality of the NPAC/SMS,  (iii)  the offering of additional support, training, consulting services or any other addition to or modification or expansion of the Services or alteration of the Specifications, or (iv) an increase or decrease in any new or additional services or changes previously requested pursuant to this Article 13 (collectively (including changes, modifications and reductions) “Additional Services”).  Customer shall initiate its request for Additional Services by delivering a proposal to Contractor detailing the Additional Services being requested and any requirements to be met.  Contractor may request further information or clarification, if needed by Contractor to formulate a response, and within three (3) weeks (or such longer or shorter period agreed to by the Parties) after Contractor’s receipt of Customer’s request (or, if later, Contractor’s receipt of any information or clarification requested by it), Contractor shall respond with a proposed Statement of Work, which shall be prepared and finalized in accordance with the requirements of this Article 13.  Contractor shall not accept any such requests from or enter into Statements of Work with Users without Customer’s written approval.

All requests for User Enhancements by any User must be made through Customer in the form of a request for Additional Services pursuant to Article 13 - Additional Services, and the requesting User shall be responsible for any charges or fees for such User Enhancement as provided in the related Statement of Work.

Customer will not object to the incorporation of User Enhancements.  Furthermore, all User requests for Additional Services will be forwarded by Customer to Contractor under the provisions set forth herein.

As part of its response to any request from Customer for Additional Services that Customer states are intended to benefit more than one User, Contractor shall state (1) the price if paid by Users by a specified date and (2) the price if paid by Users over the remaining term of this Agreement.  Customer may elect the pricing option it prefers.  Customer’s election of either option shall not preclude further negotiations between the Parties as to price.

13.2Proposed by Contractor

During the term of this Agreement, Contractor may propose Additional Services to Customer, including without limitation Enhancements developed by Contractor arising out of its own research and development or in connection with a request for services from another Customer of Contractor.  Contractor will initiate this process by delivering a proposal to Customer detailing the Additional Services being proposed.  If Customer wishes to accept the proposal for Additional Services, it shall so notify the Contractor in writing, and Contractor shall respond

36

within three (3) weeks (or such longer or shorter period agreed to by the Parties) with a proposed Statement of Work, which shall be prepared and finalized in accordance with the requirements of Section 13.4, below.

13.3Changes Pursuant to Benchmarking and Agreed-Upon Changes in Service Levels

During the term of this Agreement, whether pursuant to the Benchmarking Process or pursuant to Section 8.3, Customer and Contractor may agree upon a change in the Services or Service Levels that would necessitate the rendering of Additional Services.  In such cases, Contractor shall prepare a proposed Statement of Work which shall be prepared and finalized in accordance with the provisions of this Article.

13.4Statement of Work

Each proposed Statement of Work submitted by the Contractor pursuant to this Article 13 shall be specifically identified as a Statement of Work relating to this Agreement, and shall set forth at least the following:

(a)Description of the work to be performed by Contractor, with reference to the Specifications for the Additional Services or Enhancements, if any;

(b)Identification of any Enhancements as a Custom Enhancement or an User Enhancement, if applicable;

(c)Delivery schedule for performance and completion of the work and initiation of the Additional Services, including milestones and delivery dates for all Deliverables, where appropriate;

(d)Completion and acceptance criteria (including testing procedures and quality standards);

(e)Designation of the names and addresses of the Project Managers of each Party and resume material concerning other key personnel provided by Contractor;

(f)Any changes to the fees to be charged to Users, and the schedule of effective date(s) for said changes in the fee structure, with the prices set forth in Schedule 4 to Exhibit E - Pricing Schedules forming the basis for any labor charges for the labor categories set forth therein if persons within such categories are engaged providing the Additional Services (with other rates and categories to be agreed to by the Parties as necessary in connection with the Statement of Work); and

(g)Identification of any impact on Service Levels, disaster recovery, and back-up plans, including proposed revisions thereto.

37

Upon receipt of Contractor’s proposal under this Article 13, Customer and, in the case of a User Enhancement, the User which requested the User Enhancement, will review the Statement of Work and may request changes and modifications.  Contractor will then prepare a final Statement of Work containing the provisions agreed upon by both Parties.  Upon Customer’s acceptance of the final Statement of Work submitted by Contractor, the Statement of Work shall be executed by both Parties.  Each Statement of Work shall incorporate and be subject to the terms and conditions of this Agreement.  In the event of any inconsistency between the terms and conditions of a Statement of Work and those in the Agreement, the Statement of Work shall govern.

If a Statement of Work is never finalized between the Parties, the requested or proposed Additional Services (including, without limitation, any Enhancement) will not become a part of the NPAC/SMS or the NPAC/SMS Software.

13.5Staffing

Contractor shall use its best efforts to ensure that the key individuals assigned to perform such Additional Services under any Statement of Work will continue to be assigned to and perform services for the engagement during the entire Project related thereto.

If Customer, within thirty (30) days after commencement of work on a Project by a key individual designated by Contractor, determines that said individual does not demonstrate the training or skills to perform the services in a satisfactory fashion or is not performing the services in a professional, effective and efficient manner, Customer shall notify Contractor in writing detailing its objections.  Contractor’s and Customer’s Project Managers (or, if the key individual under discussion is the Project Manager, other representatives of Contractor and Customer) shall meet to resolve Customer’s objections.  If so agreed after said meeting, Contractor shall replace such individual and/or add one or more additional key individuals with appropriate training and skills, and shall agree on any changes to the Project Plan necessitated by the staffing changes.

If any person performing services under a Statement of Work discontinues work on the Project for any reason (including, without limitation, due to having been replaced at the request of Customer pursuant to the preceding paragraph), or becomes sick, disabled or otherwise incapacitated or unable to perform his or her duties, Contractor shall use its best efforts to replace such person with another of like educational background, professional experience, training and skills.  There shall be no charge for (i) the time required by the substitute individual to become knowledgeable enough regarding the services to make a productive contribution substantially equal to that of the person replaced, or for (ii) any work performed by key individuals replaced at the request of Customer that the Parties agree is unsatisfactory or unusable.

13.6Enhancements to NPAC/SMS Software

Certain requests for Additional Services from Customer pursuant to this Article may result in the development of Enhancements to the NPAC/SMS Software by Contractor.  The ownership of such Enhancements shall be determined in accordance with Section 9.1.  Contractor will be free

38

to offer any Enhancement to other customers without any compensation to Customer or adjustment in the fees charged to Users; provided, however, that in the case of a Custom Enhancement or a User Enhancement, Contractor will meet with the Customer or User, as the case may be, to agree upon an equitable method of rebating all or a portion of the development cost for the Custom Enhancement or User Enhancement, taking into account the nature and extent of the proposed usage by Contractor, anticipated revenues, and other equitable considerations.

ARTICLE 14 - BUSINESS RECORDS AND AUDITS

14.1Contractor’s Regular Audits; Customer’s Right to Audit

Contractor shall, at its cost, conduct a regular annual audit of its NPAC/SMS Data Center operations by its internal auditors.  Such audit shall, among other things, address the accuracy of Contractor’s invoices for services; security, back-up, and disaster recovery procedures; and overall compliance with industry standards for similar data center operations.  Contractor shall provide Customer with a copy of each such audit promptly upon its completion.

Customer may, at its expense, and subject to the limitations and restrictions provided elsewhere in this Article 14 - Business Records and Audits, conduct an audit of NPAC/SMS Data Center operations of the same scope as Contractor’s annual audit, upon reasonable advance notice to Contractor; provided, however, that (i) such Customer audit may be conducted no more frequently than once in any twelve (12) month period, except if such audit is required by judicial or regulatory authority, in which case such audit can occur in any number and at any time and (ii) Contractor shall reimburse Customer for the total cost of performing such Customer audit if such audit reveals a condition of material noncompliance by Contractor requiring Contractor to take remedial actions and incur expenses therefor as provided under Section 14.6 below.

14.2Access for Audits

As part of the Services, Contractor shall, subject to reasonable confidentiality restrictions, provide to Customer and its designees reasonable access during Normal Business Hours to:

(a)Contractor’s staff;

(b)books and records and supporting documentation relating to the Services and the fees payable under this Agreement, excluding Contractor’s cost information;

(c)use the NPAC/SMS system and the Software used to perform the Services (without access to the Source Code thereof); and,

(d)the service locations or other facilities, as may be necessary for Customer or its designees to perform the audits described above.

39

Customer and its representatives will comply with any reasonable restrictions imposed by Contractor to minimize any disruption to Contractor’s normal operations.

14.3Provision of Facilities for Audits

For a reasonable period of time, Contractor shall provide to Customer and its designees on Contractor’s premises reasonable amounts of office space, office furnishings (including lockable cabinets), telephone and facsimile service, utilities and office-related equipment and duplicating services as Customer or such auditors and inspectors may reasonably require to perform the audits described in this Article 14.  Customer will comply with any reasonable restrictions imposed by Contractor to minimize any disruption to Contractor’s normal operations.  Such facilities and related assistance shall be provided as part of the Services.

14.4Audit of Fees

Upon reasonable notice from Customer, no more frequently than once in any twelve (12) month period (unless otherwise required by any regulatory authority), Customer may audit the fees charged to Users for any period not previously audited by Customer, for which Contractor is required to retain records, to determine that such fees are accurate and in compliance with this Agreement, except that Customer may audit previously audited fees if, as the result of a current audit or the receipt or discovery of any other information, Customer has reasonable cause to believe that inaccuracies or discrepancies exist which previous audits failed to disclose.  If, as a result of an audit, Customer determines that Contractor has overcharged Users, Customer shall notify Contractor of the amount of such overcharge and if Contractor agrees with the results of Customer’s audit or if Customer prevails in any arbitrated dispute regarding such audit, Contractor shall promptly refund to affected Users the amount of the overcharge, plus interest, at the rate of one and one quarter percent (1 1/4%) per month or the highest rate allowed by law, whichever is lower, from the date payment was received.  In the event any such audit reveals an overcharge to Users during any audited period exceeding five percent (5%) or more of a particular fee category, Contractor shall reimburse Customer for the cost of such audit.  If Contractor disagrees with the results of said audit, Contractor and Customer shall resolve any dispute in accordance with the provisions of Article 26 below.

14.5Record Retention

Contractor shall keep, based upon U.S. generally accepted accounting principles, books, records and supporting documentation sufficient to document the NPAC/SMS and the invoices paid or payable by Users for the NPAC/SMS for the current fiscal year and at least the four (4) immediately preceding fiscal years of Contractor

14.6Compliance with Audit Recommendations

If any audit by an auditor designated by Customer or a regulatory authority results in Contractor being notified that it is not in compliance with any law, regulation, audit requirement or generally

40

accepted accounting principle relating to the NPAC/SMS, Contractor shall take actions to comply with such audit.

Contractor shall bear the expense of any such compliance work,unless such compliance work is required to bring the NPAC/SMS, Customer or a User into compliance with a legal, regulatory or audit requirement that (i) is imposed on Customer or a User and impacts the NPAC/SMS or the Services rendered hereunder and (ii) has not been, by this Agreement (including, without limitation, by any Statement of Work), previously identified to Contractor as a requirement of the NPAC/SMS or Services.  Contractor will not undertake any compliance work, the expense of which is not to be borne by Contractor, without a Statement of Work executed by the Parties.

ARTICLE 15 - CONFIDENTIAL INFORMATION

15.1Confidential Information Defined; Obligations

“Confidential Information” means all information, materials and ideas that relate to the subject matter of this Agreement or the performance by the disclosing party of its obligations hereunder, which is disclosed or otherwise provided by one Party (“the Disclosing Party”) (in writing, electronically, orally, or in any other form, tangible or intangible, except that with respect to oral or intangible disclosures, the substance of such disclosure must be memorialized in writing and delivered to the receiving party within fourteen (14) days of the initial disclosure) to the other Party (“the Receiving Party”) and that is marked as “confidential” and/or “proprietary”, including, without limitation, User Data, Software, proprietary aspects of the functional requirements and the systems interface, pricing and financial information and customer records of either Party or of any Users.  User Data shall be the property of the User furnishing such data.

The Disclosing Party shall have the right to correct any inadvertant failure to designate information as “confidential” and/or “proprietary” by written notification to the Receiving Party.  The Receiving Party shall, from that time forward, treat such information as Confidential Information under this Agreement.

During the course of this Agreement, either Party may receive or have access to Confidential Information of the other Party or a User.  The Receiving Party shall not, without first obtaining the Disclosing Party’s written consent, disclose to any Third Party (other than, in the case of User Data, the rightful owner of such data), commercially exploit or use for any purpose other than the performance of its obligations under this Agreement any Confidential Information, or information or materials developed by the Receiving Party based on Confidential Information, that it has received or to which it has had access.  Each Party shall use no less than the same means it uses to protect its similar confidential and proprietary information, but in any event not less than reasonable means, to prevent the disclosure and to protect the confidentiality of the Confidential Information of the Disclosing Party.

15.2Exclusions

Confidential Information shall not include:

41

(a)information generally available to, or known to, or which becomes known by, the public through no wrongful act of the Receiving Party;

(b)information known by the Receiving Party prior to receipt from the Disclosing Party; where the Receiving Party received such information without knowledge of any obligation of confidentiality with respect thereto in favor of the Disclosing Party;

(c)information disclosed by a Third Party to the Receiving Party, where the Receiving Party received such information without knowledge of any obligation of confidentiality with respect thereto in favor of the Disclosing Party

(d)information independently developed by the Receiving Party without the use of information disclosed by the Disclosing Party;

(e)information disclosed to a Third Party by the Disclosing Party without restriction; and

(f)information lawfully required to be disclosed to any governmental agency or which is otherwise required to be disclosed by law, provided that before making such disclosure the Receiving Party shall give the Disclosing Party an adequate opportunity to object to such disclosure or take action to assure confidential handling of such information.

15.3Return or Destruction

Upon the request of the Disclosing Party, which may be made at any time, the Receiving Party shall return to the Disclosing Party, or, at the option of the Disclosing Party, shall destroy or permanently erase, the Confidential Information provided by the Disclosing Party and all copies thereof (in written, electronic or other form), and shall destroy or permanently erase any information and materials developed by it based on the Disclosing Party’s Confidential Information.  User Data shall be returned to the Disclosing Party, in the form and on the media then in use.  Upon the request of the Disclosing Party, the Receiving Party shall certify that the destruction or permanent erasure of Confidential Information provided for herein has occurred.  Notwithstanding anything to the contrary above, User Data or Confidential Information that is necessary to provide or receive Services and operate the NPAC/SMS, shall not be returned or destroyed

15.4Injunctive Relief

Each Party acknowledges that the unauthorized disclosure or use of Confidential Information may cause irreparable harm and significant injury, the amount of which may be extremely difficult to estimate.  If the Receiving Party fails to abide by its obligations under this Article, the Disclosing Party may seek immediate injunctive relief, in addition to any other rights and remedies available to it at law or in equity.

42

15.5Loss of Confidential Information

In the event of any unauthorized disclosure or loss of, or inability to account for, Confidential Information of the Disclosing Party, the Receiving Party will notify the Disclosing Party immediately.

15.6Third Parties

Customer acknowledges that any Third Party having a need to obtain access to Confidential Information of Contractor as a result of its actions as a representative, agent or subcontractor of Customer, or otherwise through its relationship with Customer shall, as a condition to such access, be required to execute a confidentiality agreement directly with Contractor, which confidentiality agreement shall include the substantive restrictions set forth in this Article 15 and shall otherwise be in a form reasonably satisfactory to Contractor and Customer.

ARTICLE 16 - DELAYS; PERFORMANCE CREDITS AND CORRECTIVE REPORTING; DEFAULTS; FORCE MAJEURE

16.1Notice of Delays

Time is of the essence in Contractor’s performance of its obligations under this Agreement.  Contractor shall promptly notify Customer in writing of any anticipated or known Contractor Delay by the date of performance specified in this Agreement, if any, for the affected obligation, the reasons for the delay, and the expected duration of the delay.  In the event of any failure of Customer or User to perform an obligation which delays or threatens to delay a scheduled performance date of Contractor under this Agreement (“Customer/User Delay”), Contractor shall promptly notify Customer in writing of such delay or threatened delay, and Contractor’s scheduled performance date shall be extended day-for-day for any such actual delay of Customer or User directly affecting such scheduled performance date.  If Contractor fails to notify Customer of a Customer/User Delay of which Customer or the applicable User does not otherwise have prior notice (i.e., pursuant to a Project Plan), Contractor may not use such Customer/User Delay as an excuse for its failure to meet a scheduled performance date.

16.2Delays in Implementation of Initial Services

In the event that Contractor fails to deliver the NPAC/SMS on or before the Final Delivery Date for any reason other than a Force Majeure Event, Contractor shall pay to the Customer, as liquidated damages and not as a penalty, the sum of seventy-five hundred dollars ($7,500)per day for each day following the Final Delivery Date (or such later time as the Force Majeure Event shall have ceased, if applicable) until the first to occur of (i) Contractor’s delivery of the NPAC/SMS or (ii) the termination of this Agreement by Customer in accordance with Section 23.1 hereof; provided, however, that in no event shall the liquidated damages payable pursuant to this Section exceed Four Hundred Thousand Dollars ($400,000) in the aggregate.

43

16.3Performance Credits

Commencing ninety (90) days after the Acceptance Date, or, if Customer elects Target Option B pursuant to Section 6.6(a) hereof, after January 1, 1998,in the event that a Service Affecting Event (as defined below) shall have occurred for any reason other than the occurrence of a Force Majeure Event or a Customer/User Delay, Contractor shall pay to either Customer or affected Users, as applicable, as “Performance Credits” (and as liquidated damages and not as a penalty)an aggregate sum equal to the amount set forth under the heading “Performance Credit Amount” for each such Service Affecting Event, as set forth in Exhibit G, provided, however, that in no event shall the annual aggregate amount of Performance Credits exceed Four Hundred Thousand Dollars ($400,000).For purposes hereof, a “Service Affecting Event” shall mean the failure of Contractor to meet a “Service Affecting” Service Commitment Level set forth in Exhibit G - Service Level Requirements; provided, however, that if the same facts and circumstances directly or indirectly result in the failure to meet more than one Service Level, all such related failures, for purposes of calculating Performance Credits which shall be due in connection therewith, shall be deemed to be a single Service Affecting Event.

In the event that a Non-Service Affecting Event (as defined below) shall have occurred for any reason, Contractor shall not be required to pay any Performance Credits.  For each Non-Service Affecting Event, Contractor shall (i) notify Customer in writing of such Non-Service Affecting Event, including in such notification an explanation of the cause of the Non-Service Affecting Event and a detailed summary of the course of actions, if any, necessary to mitigate the likelihood of such cause recurring and (ii) diligently pursue the identified course of action to completion.  For purposes hereof, a “Non-Service Affecting Event” shall mean the failure of Contractor to meet one of the Service Levels other than those which give rise to Service Affecting Events.

16.4Allocation of Damages Among Users

The aggregate amount of accrued liquidated damages under Sections 16.2 and 16.3 above shall be allocated among Users as directed by Customer and credited against the next succeeding monthly billing to such Users for Service or, in the event Customer terminates this Agreement as a result of any such failure, shall be allocated and credited in the same manner, with the balance, if any, remaining after applying said amounts against any final billings to be paid to such Users by Contractor.  Liquidated damages pursuant to Section 16.2 shall be considered as compensation for direct damages for the delay suffered by the Users other than those specified in Section 19.1(g) and Contractor shall remain liable for any of the direct damages specified in Section 19.1(g).

16.5Contractor Defaults

Contractor shall be in default (“Default”) under this Agreement if Contractor shall:

(a)chronically fail to provide the NPAC/SMS at one or more of the “Service Affecting” Service Levels, which failure is evidenced by recurring events of the same or

44

similar nature that are indicative of a systemic problem and which either have been unaffected by Contractor’s repeated cure efforts or are reasonably unlikely to be cured with Contractor’s diligent efforts over a reasonable period, which in any event shall be no less than thirty (30) days; or

(b)fail to perform any of its other material obligations, i.e., material breach, under this Agreement (including the obligations referred to in Section 21.3, but excluding the obligations referred to in Section 16.5(a) above) and such failure continues for a period of thirty (30) days following receipt of written notice of such failure from Customer; provided, however, that where such failure (other than with respect to a payment obligation) cannot reasonably be cured within such thirty (30) day period, so long as Contractor is diligently pursuing such cure, the time for curing such failure shall be extended for such period as may be necessary for Contractor to complete such cure.

Upon any Default hereunder by Contractor, Customer may, subject to Articles 19 and 26 hereof, pursue any legal remedies it may have under applicable law or principles of equity.

16.6Force Majeure

Any failure or delay by Customer, a User or Contractor in the performance of its obligations under this Agreement shall not be deemed a Default of this Agreement to the extent such failure or delay was caused, directly or indirectly, by fire, flood, earthquake, elements of nature or acts of God, acts of war, terrorism, riots, civil disorders, rebellions or revolutions in the United States, court order, non-performance by the non-performing Party’s first-tier subcontractors (i.e., not subcontractors of subcontractors)due to a Force Majeure Event, or any other similar cause beyond the reasonable control of such Party and without the fault or negligence of such Party and cannot reasonably be circumvented by the non-performing Party through the use of alternate sources, work-around plans or other means (a “Force Majeure Event”).  Notwithstanding the foregoing, any failure or delay by Contractor which results from Contractor’s failure to comply with a requirement of this Agreement intended to prevent such a failure or delay shall not be considered subject to this Article.

Notwithstanding the foregoing, Contractor’s liability for loss or damage to Customer’s material in Contractor’s possession or control shall not be modified by this clause.

ARTICLE 17 - INDEMNIFICATION

17.1Mutual Indemnification

Each Party shall defend against suits, claims and demands and shall indemnify and hold harmless the other, its corporate affiliates, Members, Members’ affiliates and their respective officers, directors, employees, and agents and their successors and assigns against and from any and all losses, liabilities, damages, and expenses (including, without limitation, reasonable attorneys’ fees) included in a settlement (between the indemnifying Party and a Third Party) of such suits, claims or demands,or awarded to a Third Party by a court or appropriate administrative agency

45

of competent jurisdiction, including without limitation, thosebased on contract or tort arising out of or in conjunction with, but only to the extent that such losses, liabilities, damages, claims, demands, and expenses arise out of or in connection with, (i) personal injury (including death) or damage to tangible property arising from the negligent or intentional acts or omissions of the indemnifying Party or its subcontractors, or the officers, directors, employees, agents, successors and assigns of any of them during the term of this Agreement or any transition period as provided for in Article 24 herein, or (ii) assertions under Workers’ Compensation or similar laws made by persons furnished by the indemnifying Party during the term of this Agreement, or any transition period as provided for in Article 24 herein.

17.2Contractor Indemnification

Contractor shall defend, indemnify and hold harmless Customer,  Members and their officers, directors, employees, and agents and their successors and assigns against and from any and all losses, liabilities, suits, damages, claims, demands, and expenses (including, without limitation, reasonable attorneys’ fees) included in a settlement (between Contractor and any Third Party) of such suits, claims or demands, or awarded to a Third Party by a court or appropriate administrative agency of competent jurisdiction, including, without limitation thosebased on contract or tort arising out of or in conjunction with, but only to the extent that such losses, liabilities, damages claims, demands, and expenses arise out of, or in connection with, personal injury (including death) or damage to tangible personal property caused by defective or malfunctioning or improperly provided Software or Services provided by Contractor during the term of this Agreement.  For the purposes of this Article, Third Party includes a regulatory agency having jurisdiction over Customer, its members, or Users.

17.3Procedures

With respect to all indemnification obligations under this Agreement, the indemnified Party shall promptly notify the indemnifying Party of any written claim, loss, or demand for which the indemnifying Party is responsible under this Article and shall cooperate with the indemnifying Party as reasonably required.  An indemnified Party shall be entitled, upon its request and at its expense, to participate in the defense of any lawsuit arising from an indemnifiable claim when and for so long as such Party is a named party to such lawsuit; provided, however, that the indemnified Party may not settle any such lawsuit without the indemnifying Party’s consent.

ARTICLE 18 - INFRINGEMENT

18.1Contractor’s Obligation to Indemnify for Infringement

Contractor shall defend, indemnify and hold harmless Customer, Members, Users and their respective affiliates from and against any losses, damages, expenses (including, without limitation, attorneys’ fees and costs), demands, claims, suits, and liabilities that may result by reason of any alleged violation, infringement or misappropriation of a patent, trade secret, copyright or other proprietary interest based on NPAC/SMS provided by Contractor during the term of this Agreement, including any materials and/or equipment utilized or supplied by

46

Contractor in connection with the provision of NPAC/SMS by Contractor during the term of this Agreement.  Customer shall promptly notify Contractor of any claim of infringement or misappropriation for which Contractor is responsible and shall cooperate with Contractor to facilitate the defense or settlement of such claim.  Contractor shall (i) keep Customer reasonably apprised of the continuing status of any claim, including any lawsuit resulting therefrom and (ii) when and for so long as Customer is a named party to any such lawsuit, shall permit Customer, upon Customer’s written request and at Customer’s expense, to participate in the defense of such lawsuit; provided, however, that Customer may not settle any such lawsuit without Contractor’s consent.

18.2Contractor’s Obligations If Use Is Threatened

If use of NPAC/SMS shall be prevented or appears likely to be prevented by an injunction or court order or by settlement resulting from any such claim, Contractor shall, at its expense, either:

(a)by license or release from claim of violation, infringement or misappropriation, procure for Customer and Users the right to continue using the NPAC/SMS Software; or

(b)modify the NPAC/SMS Software so it is functionally equivalent to the original NPAC/SMS Software, but is no longer subject to a claim of violation, infringement or misappropriation; or

(c)remove any infringing materials and replace same with equally suitable materials free from claim of infringement or misappropriation; or

(d)with regard to Custom Enhancement(s) or User Enhancement(s), ifnone of the foregoing alternatives is reasonably available to Contractor, reimburse the affected User(s) for the total cost of Custom Enhancement(s) or User Enhancement(s) as applicable, as depreciated.  Such reimbursement shall be calculated on the basis of five years straight-line depreciation from the Acceptance Date of the subjectCustom Enhancement or User Enhancement, as applicable.  Contractor shall be relieved of such reimbursement liability five years after such date.

Contractor’s refund to and reimbursement of Users under this Section shall not constitute an election of remedies or otherwise limit the rights and remedies available to affected Users under this Agreement.

ARTICLE 19 - LIABILITY; LIMITATION OF LIABILITY

19.1DIRECT DAMAGES

EACH PARTY SHALL BE LIABLE TO THE OTHER PARTY FOR ANY DIRECT DAMAGES ARISING OUT OF OR RELATING TO A BREACH OF ITS OBLIGATIONS UNDER THIS AGREEMENT.

47

WITHOUT LIMITING THE GENERAL MEANING OF THE TERM “DIRECT DAMAGES”, CONTRACTOR AGREES THAT THE FOLLOWING SHALL BE CONSIDERED “DIRECT DAMAGES” FOR CUSTOMER AND USERS AND THAT CONTRACTOR SHALL NOT ASSERT THAT THEY ARE INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL LOSSES OR DAMAGES TO THE EXTENT THEY RESULT FROM CONTRACTOR’S FAILURE TO FULFILL ITS OBLIGATIONS UNDER THIS AGREEMENT:

(a)COSTS OF RECREATING OR RELOADING ANY SERVICE PROVIDER DATA LOST OR DAMAGED;

(b)COSTS OF IMPLEMENTING A WORK AROUND IN RESPECT OF A FAILURE TO PROVIDE THE SERVICES;

(c)COSTS OF REPLACING LOST OR DAMAGED PROPERTY, EQUIPMENT, SOFTWARE AND MATERIALS;

(d)COSTS AND EXPENSES INCURRED TO CORRECT DEFECTS IN NPAC/SMS SOFTWARE USED IN PROVIDING THE SERVICES;

(e)ANY LIQUIDATED DAMAGES PROVIDED FOR IN THIS AGREEMENT; PROVIDED, HOWEVER, THAT WHERE LIQUIDATED DAMAGES SHALL HAVE BEEN PROVIDED, THEY SHALL BE IN LIEU OF ALL OTHER DIRECT DAMAGES ARISING OUT OF OR ASSOCIATED WITH THE FACTS AND CIRCUMSTANCES GIVING RISE TO THE LIQUIDATED DAMAGES, INCLUDING WITHOUT LIMITATION, THE OTHER TYPES OF DIRECT DAMAGES DESCRIBED ABOVE IN THIS SECTION 19.1, EXCLUDING SECTION 19.1(g) HEREIN;PROVIDED, FURTHER, HOWEVER, THAT RECEIPT OF LIQUIDATED DAMAGES SHALL NOT LIMIT RECOVERY OF DIRECT DAMAGES ARISING OUT OF OR ASSOCIATED WITH THE FACTS OR CIRCUMSTANCES LEADING TO A TERMINATION BY CUSTOMER UNDER SECTION 23.1 OF THIS AGREEMENT;

(f)COSTS AND EXPENSES INCURRED TO PROCURE THE SERVICES FROM AN ALTERNATE SOURCE, TO THE EXTENT IN EXCESS OF CONTRACTOR’S CHARGES UNDER THIS AGREEMENT; AND STRAIGHT TIME, OVERTIME OR RELATED EXPENSES INCURRED BY A USER, INCLUDING OVERHEAD ALLOCATIONS OF THE USER FOR THE USER’S EMPLOYEES, WAGES AND SALARIES OF ADDITIONAL EMPLOYEES, TRAVEL EXPENSES, OVERTIME EXPENSES, TELECOMMUNICATIONS CHARGES AND SIMILAR CHARGES, DUE TO THE FAILURE OF CONTRACTOR TO PROVIDE THE SERVICES;

(g)ANY FINES, PENALTIES, INTEREST OR OTHER COSTS, INCLUDING ATTORNEYS FEES, IMPOSED UPON CUSTOMER OR ANY USER BY ANY

48

REGULATORY AGENCY BECAUSE OF DELAYS, ERRORS OR OMISSIONS ATTRIBUTABLE TO CONTRACTOR; AND

(h)ANY OTHER TYPE OF DAMAGES NORMALLY CONSIDERED DIRECT DAMAGES IN A PARTICULAR CIRCUMSTANCE.

19.2CONSEQUENTIAL DAMAGES

NEITHER PARTY SHALL BE LIABLE TO THE OTHER FOR ANY INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR IN CONNECTION WITH THE FURNISHING, PERFORMANCE OR USE OF ANY SOFTWARE OR SERVICES PROVIDED UNDER THIS AGREEMENT OR ANY STATEMENT OF WORK OR THE PERFORMANCE OR NONPERFORMANCE OF OBLIGATIONS UNDERTAKEN IN THIS AGREEMENT OR ANY STATEMENT OF WORK.  EACH PARTY WAIVES ANY CLAIM TO PUNITIVE DAMAGES AGAINST THE OTHER.

19.3EXCLUSIONS

THE LIMITATIONS OR EXCULPATIONS OF LIABILITY SET FORTH IN THE FIRST SENTENCE OF SECTION 19.2 ARE NOT APPLICABLE TO:

(a)INDEMNIFICATION CLAIMS;

(b)LIABILITY RESULTING FROM THE GROSS NEGLIGENCE OR WILLFUL MISCONDUCT OF A PARTY; OR

(c)ANY BREACH OF A PARTY’S CONFIDENTIALITY OBLIGATIONS.

ARTICLE 20 - INSURANCE

20.1Contractor’s Insurance Requirements

Contractor must maintain and cause Contractor’s subcontractors to maintain: (i) Workers’ Compensation insurance as prescribed by the law of the applicable state, (ii) employer’s liability insurance with limits of at least $2,000,000 each occurrence and in the aggregate, (iii) commercial general liability insurance (including contractual liability and products liability coverage) with combined single limits of at least $10,000,000 for bodily injury and property damage and with limits of $10,000,000 in the general aggregate, and (iv) professional liability insurance with combined single limits of at least $10,000,000 and with limits of $10,000,000 in the general aggregate.  Neither Contractor nor Contractor’s insurer(s) shall have a right of subrogation against Customer based on any loss or liability insured against under the foregoing insurance.  Contractor’s policies for the insurance under clause (iii) and (iv) above must be endorsed to name Customer as an additional insured and state: “Northeast Carrier Acquisition Company, L.L.C. is to be notified in writing at least thirty (30) days prior to cancellation of or any material change in the coverage limits.”  Also, Contractor must furnish certificates

49

evidencing the foregoing insurance coverage within thirty (30) days following execution of this Agreement.

20.2Contractor’s Failure to Maintain Insurance

If Contractor fails to maintain the insurance required by Article 20, Customer may procure such insurance.  In such event, Customer shall invoice Contractor and Contractor shall promptly reimburse Customer for any premiums and other charges paid by Customer for such coverage.

20.3Self Insurance

Contractor may self insure the risks for which insurance is otherwise required under this Article 20 upon written request to and approval, in writing, by Customer.  Approval by Customer of self-insurance shall not be unreasonably withheld and shall be based upon Customer’s reasonable assessment that Contractor’s net worth, financial history and stability appear to be sufficient to satisfy any obligation Contractor could reasonably be expected to incur during the term of this Agreement.

20.4Customer’s Insurance Requirements

Customer must maintain and cause Customer’s subcontractors to maintain: (i) Workers’ Compensation insurance as prescribed by the law of the applicable state, (ii) employer’s liability insurance with limits of at least $2,000,000 each occurrence and in the aggregate, (iii) commercial general liability insurance (including contractual liability and products liability coverage) with combined single limits of at least $10,000,000 for bodily injury and property damage and with limits of $10,000,000 in the general aggregate, and (iv) professional liability insurance with combined single limits of at least $10,000,000 and with limits of $10,000,000 in the general aggregate.  Neither Customer nor Customer’s insurer(s) shall have a right of subrogation against Contractor based on any loss or liability insured against under the foregoing insurance.  Customer’s policies for the insurance under clause (iii) and (iv) above must be endorsed to name Contractor as an additional insured and state: “Lockheed Martin IMS is to be notified in writing at least thirty (30) days prior to cancellation of or any material change in the coverage limits.”  Also, Customer must furnish certificates evidencing the foregoing insurance coverage within thirty (30) days following  execution of this Agreement.

20.5Customer’s Failure to Maintain Insurance

If Customer fails to maintain the insurance required of it by Section 20.4, Contractor may procure such insurance.  In such event, Contractor shall invoice Customer and Customer shall promptly reimburse Contractor for any premiums and other charges paid by Contractor for such coverage.

20.6Additional Insurance

In addition to any insurance required to be maintained pursuant to this Article, Contractor may, at its election, obtain insurance with respect to any losses, liabilities, damages or expenses

50

(including, without limitation, reasonable attorneys’ fees) incurred by Contractor arising out of, resulting from or in connection with any error, omission or failure of the facilities, equipment, systems or personnel of Users or any of their affiliates, agents, successors or assigns used or involved in any way in the provision of services utilizing the NPAC/SMS Services to any end-user customer or any Third Party.  If Contractor obtains such insurance, Contractor shall, on a quarterly basis, invoice Users in accordance with the Allocation Model then in effect for one-half of the premiums or other charges for the first $50,000,000 of such coverage, which amounts shall be invoiced to Users as part of the monthly billing process and reimbursed by Users in accordance with such invoice.  The aggregate maximum amount that can be invoiced to Users per year shall be no more than $25,000.  Any deductible for this insurance shall be paid by Contractor.  This insurance must be purchased from an outside agent and is not to be covered by self-insurance as described in Section 20.3.  In addition, Contractor will provide to Customer a certificate of insurance.  Should Contractor purchase this insurance the level of coverage must be reviewed with Customer with the intent that reductions be based on a risk assessment.

ARTICLE 21 - WARRANTIES

21.1Harmful Code or Data

Contractor warrants that the NPAC/SMS Software will not contain, either now or in the future, any malicious code, program, or other internal component (e.g. software virus, software worm, software time bomb, Trojan Horse or similar component), which could damage, destroy, or alter Software or hardware of Users, or which could, in any manner, reveal, damage, destroy, or alter any data or other information accessed through or processed by the NPAC/SMS Software in any manner or which could adversely affect the operation of a computer or its memory by a User.  Contractor shall immediately advise Customer and Users, in writing, upon reasonable suspicion or actual knowledge that the NPAC/SMS Software provided under this Agreement may result in the harm described above.

21.2No Liens or Violations of Third Party Rights

Contractor warrants that the NPAC/SMS Software and the other Deliverables provided under this Agreement are free from liens and encumbrances.  Contractor further warrants that Contractor will maintain reasonable policies and practices to protect against improper incorporation of Third Party Intellectual Property into the NPAC/SMS Software, Custom Software or other Deliverables.  Contractor represents that it does not have any knowledge of any proceeding or threatened claims, suits, challenges or other legal actions relating to Contractor’s Intellectual Property intended to be used in performance of Contractor’s obligations under this Agreement and warrants that it will promptly notify Customer if it becomes aware of any such legal action.

21.3Conformance with Specifications and Other Standards

Contractor warrants that the NPAC/SMS shall operate without Defects during the term of this Agreement.  In addition to its obligations under Section 10.2, Contractor shall correct any Material Defects within thirty (30) days (or within such shorter period as may be specified

51

elsewhere in this Agreement) after the Material Defect is brought to Contractor’s attention in writing at no additional charge to Customer or Users.  In addition to its obligations under  Section 10.2, Contractor shall correct any Minor Defects within sixty (60) days (or within such shorter period as may be specified elsewhere in this Agreement) after the Defect is brought to Contractor’s attention in writing at no additional charge to Customer or Users.  Contractor’s failure to comply with its obligations under this Article shall constitute a Default for the purposes of Section 16.5.

Contractor warrants that all Services shall be performed in accordance with the highest professional standards and shall be in accordance with such requirements or restrictions as may be lawfully imposed by governmental authority as contemplated in accordance with Article 25 herein.  Services not performed in accordance with the requirements of this Agreement (that may or may not constitute a Default as defined herein) shall be re-performed at no cost to Customer or the Users.

21.4Authority

Each Party represents to the other that it has full authority to enter into and perform all of its obligations under this Agreement, and that the person signing this Agreement on behalf of the Party has been properly authorized to enter into this Agreement.  Each Party further acknowledges that it has read this Agreement, understands it, and agrees to be bound by all of its terms, conditions and provisions.

21.5EXCLUSIVE WARRANTIES

THE WARRANTIES SET FORTH IN THIS AGREEMENT OR A STATEMENT OF WORK ARE THE EXCLUSIVE WARRANTIES MADE BY CONTRACTOR.  ALL OTHER EXPRESS OR IMPLIED WARRANTIES, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE DISCLAIMED.

ARTICLE 22 - ASSIGNMENT, OTHER TRANSFER, AND SUBCONTRACTING

22.1Consent Required

Except as provided otherwise in this Article, neither Party shall (i) assign or otherwise transfer  any rights or obligations under this Agreement or any Statement of Work without the prior written consent of the other Party, or (ii) subcontract any obligations under this Agreement without the prior written consent of the other Party, and, in each case, such consent shall not be unreasonably withheld or delayed.  Notwithstanding anything to the contrary in the preceding sentence, Contractor shall not require the prior consent of Customer to subcontract any portion of the work covered under this Agreement or under any Statement of Work to any subcontractor specifically mentioned in its Proposal..  Any such assignment made without the prior written consent of the other Party shall be void.  Contractor’s request for consent to an assignment or

52

transfer of rights or obligations to any entity which is not a Neutral Third Party shall constitute adequate grounds for withholding such consent.

22.2Assignment of Monies Due

Notwithstanding the foregoing, Contractor may, upon written notice to Customer, assign monies due or that are to become due under a Statement of Work, provided that no such assignment may impose upon Customer or Users any obligations in addition to or different than those set forth in this Agreement or the subject Statement of Work, or preclude Customer or Users from dealing solely and directly with Contractor in all matters pertaining to this Agreement or the subject Statement of Work, including the negotiation of amendments and the settlement of disputed invoices.

ARTICLE 23 - TERMINATION

23.1Termination by Customer

Customer shall have the right, upon written notice to Contractor, to terminate this Agreement or any applicable Statements of Work :

(a)if a Default by Contractor has occurred and is continuing under this Agreement; or,

(b)if (i) a receiver, trustee, administrator, or administrative receiver is appointed for Contractor or its property, (ii) Contractor makes an assignment for the benefit of creditors, (iii) any proceedings are commenced against Contractor under any bankruptcy, insolvency, or debtor’s relief law, and such proceedings are not vacated or set aside within ninety (90) days from the date of commencement thereof, or (iv) Contractor is liquidated or dissolved; or,

(c)if Contractor is merged with or acquired by an entity which is not a Neutral Third Party; or

(d)if Contractor otherwise ceases to be a Neutral Third Party, and such cessation continues for a period of thirty (30) days following the date that an executive officer of Contractor first becomes aware of the event causing the cessation of neutrality (with Contractor having an obligation to diligently conduct quarterly investigations of its affiliates’ activities that may impact Contractor’s neutrality); provided, however, that where such cessation of neutrality cannot reasonably be cured within such thirty (30) day period, so long as Contractor is diligently pursuing such cure, and regulatory authorities having jurisdiction over such matters (after having reviewed the details of the event(s) causing Contractor’s cessation of neutrality) have not specifically required Customer to terminate this Agreement due to such cessation of neutrality, the time for curing such

53

failure shall be extended for such period as may be necessary for Contractor to complete such cure; or

(e)under the circumstances related to a regulatory event as set forth in Article 25.

23.2Nonwaiver

The termination rights provided to Customer under this Article 23 are not intended to constitute an election of remedies, and, except as provided otherwise in this Agreement or the subject Statement of Work, Customer is entitled to any additional rights and remedies available to it at law or in equity, subject to the limitations and exclusions in this Agreement.  All rights and remedies of Customer herein created or otherwise existing at law or in equity are cumulative, and the exercise of one (1) or more rights or remedies shall not be taken to exclude or waive the right to exercise any of the others.

23.3Users’ Liability for Payments

Except as provided in Articles 9 and 24 herein and Section 7 of the NPAC/SMS User Agreement, in the event of termination under this Article, Users shall be liable only for payment to Contractor for Services performed prior to the effective date of the termination, and Users shall not be liable for anticipated profit or fee on Services not performed.  Except as otherwise provided in this Agreement, Customer shall have no liability for any payments to Contractor.

23.4Return of Property Upon Termination

Subject to Article 24 - Transition at Expiration or Termination of this Agreement, upon termination and regardless of any dispute between the Parties, all property, equipment, data, documents or other materials of Customer or the Users pertaining to this Agreement in the possession of Contractor, its employees, agents or subcontractors shall be returned to their owners within fifteen (15) days of the notice of termination or such later date as Customer may designate.

 ARTICLE 24 - TRANSITION AT EXPIRATION OR TERMINATION OF THIS AGREEMENT

24.1Contractor’s Obligation to Assist With Transition

Upon termination of this Agreement by Customer under either Article 23 or Article 12 hereof (hereafter “Termination Event”), or upon expiration of the Agreement as the result of an election not to renew under Article 3 hereof (“Non-Renewal”), Contractor shall assist Customer in the orderly transition of the Services specified herein from Contractor to a successor contractor or administrator for NPAC/SMS (in either case, the “Successor Contractor”), consistent with the requirements of this Article 24 - Transition at Expiration or Termination of this Agreement.

54

24.2Optional Extension Upon Termination or Non-Renewal Without License

Upon the occurrence of a Termination Event (other than a Termination Event under Section 23.1(c), (d), or (e) or Article 12) or Non-Renewal and, in each case, upon Customer’s request in lieu of being granted a license under Article 9 hereof, Contractor shall agree to extend this Agreement with Customer for a period the last day of which shall not extend beyond the earlier of (i) the date that Customer completes its transition to a Successor Contractor for the provision of NPAC/SMS in the Service Area or (ii) the date that is eighteen (18) months after (A) in the case of such a Termination Event, the date notice of termination is given by Customer (“Termination Event Notice Date”), or (B) in the case of Non-Renewal, the date the notice of non-renewal is given or received by Customer, as applicable (“Non-Renewal Notice Date”).  Any such extension shall be at a price and level of Service in effect on the date of such termination or expiration of the Agreement, as applicable, as adjusted pursuant to Section 6.1 if such extension extends beyond the Initial Term.  In addition, upon any such extension, Contractor shall provide any Transition Services (as defined below) requested by Customer; provided that (i) Contractor shall be paid for such services at reasonable rates, consistent with the charges underlying the pricing schedules set forth in Exhibit E and (ii) Contractor shall have no obligation to perform any such Transition Services under this Section 24.2 after the end of the extension period.  Notwithstanding anything to the contrary above, Contractor’s obligation to perform Services during any extension period is subject to Customer using diligent efforts to transition to a Successor Contractor beginning no later than the Termination Event Notice Date or Non-Renewal Notice Date, as applicable.

24.3Optional Extension Upon Termination or Non-Renewal With License, Loss of Neutrality orRegulatory Termination

Upon the occurrence of (A) a Termination Event (other than a Termination Event under Section 23.1(c) or (d) or Article 12) or Non-Renewal and, in each case, under circumstances where Customer has obtained a license under Article 9 hereof,or (B) a Termination Event under Section 23.1(c) or (d), whether or not Customer has obtained a license under Article 9 hereof, or (C) a Termination Event under Section 23.1(e), Contractor shall, upon Customer’s request, extend this Agreement with Customer for a period the last day of which shall not extend beyond the earlier of (i) the date that Customer completes its transition to a Successor Contractor for the provisioning of NPAC/SMS in the Service Area or (ii) the date that is one hundred and eighty (180) days after the Termination Event Notice Date or Non-Renewal Notice Date, as applicable.  Any such extension shall be at a price and level of Service in effect on the date of such termination or the expiration of the Agreement, as applicable, as adjusted pursuant to Section 6.1 if such extension extends beyond the Initial Term.  In addition, upon any such extension, Contractor shall provide any Transition Services (as defined below) requested by Customer; provided that (i) Contractor shall be paid for such services at reasonable rates, consistent with the charges underlying the pricing schedules set forth in Exhibit E and (ii) Contractor shall have no obligation to perform any such Transition Services under this Section 24.3 after the end of the extension period.  Notwithstanding anything to the contrary above, Contractor’s obligation to perform Services during any extension period is subject to Customer using diligent efforts to

55

transition to a Successor Contractor beginning no later than the Termination Event Notice Date or Non-Renewal Notice Date, as applicable.

24.4Transition Services

Contractor shall cooperate with Customer in effecting the orderly transition of the Services to a Successor Contractor by performing the services set forth below (collectively, the “Transition Services”) where requested by Customer upon or in anticipation of a Termination Event or Non-Renewal.  The Transition Services shall be provided through the period of any extension under Section 24.2 or 24.3, or if the Agreement is not being extended pursuant to such Sections, for a period not to exceed one hundred and eighty (180) days after the expiration or termination of the Agreement.  Contractor shall be paid for the performance of such Transition Services at reasonable rates, consistent with the charges underlying the pricing schedules in Exhibit E.  Customer shall submit its request for Transition Services in writing to Contractor on or immediately prior to the expiration or termination date.

At Customer’s request, which request shall be made as provided above, Contractor agrees to provide the following Transition Services in accordance with this Section 24.4:

(a)provide Customer with a list or summary, as applicable, of all hardware, software, and communications inventories and documentation of operational and procedural practices required for the orderly transition to a Successor Contractor for the Services;

(b)consistent with Contractor’s contractual obligations to Third Parties regarding nondisclosure, provide Customer and/or its designees all Contractor information that is reasonably necessary to enable Customer and/or its designees to provide the Services.  Contractor shall use its best efforts to secure in its agreements with Third Parties the right to provide such Third Party information to Customer and/or its designees under these circumstances;

(c)with respect to Third Party Software used to provide the Services, Contractor shall provide reasonable assistance to Customer in obtaining licenses from the appropriate vendors;

(d)with respect to any other agreements for necessary Third Party services being used by Contractor to perform the Services, Contractor shall:

(i)use its best efforts to transfer or assign such agreements to Customer or the Successor Contractor, and

(ii)pay any transfer fee or non-recurring charge imposed by the applicable Third Party vendors, which fee or charge Customer agrees to reimburse to Contractor; and

56

(e)Contractor shall return to Customer (without retaining copies) all intellectual property, including software, documentation, and procedures including all tapes, disks, and printed matter provided by Customer and Users, and the contents of the NPAC/SMS database pertaining to Customer.

Customer agrees to allow Contractor to use, at no charge, those Customer facilities necessary to perform the Transition Services for as long as Contractor is providing the Transition Services.

ARTICLE 25 - REGULATORY AND LEGISLATIVE CONSIDERATIONS

25.1Users are Communications Common Carriers

Contractor expressly recognizes that (i) Customer, Members and the Users and the NPAC/SMS are or may be subject to certain federal and state statutes and rules and regulations promulgated thereunder, as well as rules, regulations, orders, opinions, decisions and possible approval of the FCC, NANC  and other regulatory bodies having jurisdiction or delegated authority over Customer, Member and the Users and the NPAC/SMS and (ii) this Agreement is subject to changes and modifications required as a result of any of the foregoing; provided, however, that the Parties hereby agree that this Agreement and the NPAC/SMS User Agreements shall remain in full force and effect in accordance with their respective terms and each of the Parties and each of the Users shall continue to perform all of its respective obligations under this Agreement and the NPAC/SMS User Agreements, as applicable, in accordance with the respective terms thereof until the Parties can agree upon any amendment (which shall include any Statement of Work) that may be required to this Agreement as a result of any such regulatory change; and provided, further, however, that if the Parties are unable to agree upon any required amendment (or Statement of Work), the Parties agree to resolve such dispute pursuant to an “expedited” arbitration proceeding in accordance with the procedures set forth in Section 4 of the form of Escrow Agreement attached hereto as Exhibit M (“Expedited Arbitration”).  Notwithstanding anything to the contrary above, Customer may terminate this Agreement if the required amendment or Statement of Work is technically or economically unfeasible or if the regulatory change requires Customer to terminate this Agreement, except that Customer agrees it will give Contractor at least ten (10) days advance written notice of its intent to terminate this Agreement on such basis and agrees that if, within ten (10) days of its receipt of such notice, Contractor delivers its written objection to Customer disputing the basis on which Customer is exercising its termination right, Customer will resolve such dispute with Contractor in an Expedited Arbitration proceeding, with the focus of such proceeding being whether the required amendment or Statement of Work is technically or economically unfeasible or whether the regulatory change requires Customer to terminate this Agreement, as applicable.  The Parties shall cooperate fully with each other in obtaining any necessary regulatory approvals of the NPAC/SMS or other regulatory proceeding regarding regarding NPAC/SMS.

25.2Changes in Law and Regulations

Customer shall notify Contractor of any relevant changes in applicable legislative enactment and regulations that Customer becomes aware of in the ordinary course of its business in accordance

57

with the provisions of Section 27.6.  Any necessary modifications to the NPAC/SMS as a result of such changes shall be made in accordance with the provisions of Article 13 and subject to Section 25.1  Contractor shall be responsible for any fines and penalties imposed on Users and/or Contractor arising from any noncompliance by Contractor, its subcontractors or agents with the laws and regulations in respect of the NPAC/SMS.  A User shall be responsible for any fines and penalties imposed on it or Contractor relating to Contractor’s provision of the NPAC/SMS and arising from the failure of such User to comply with laws and regulations to which it is subject.

ARTICLE 26 - INTERNAL DISPUTE RESOLUTION AND ARBITRATION

26.1Internal Dispute Resolution

Except in circumstances where the time required for application of this dispute resolution procedure would cause irreparable harm, any claim, controversy or dispute arising out of or relating to this Agreement, which cannot otherwise be resolved after good faith negotiations by the Parties, shall be resolved as follows:

(a)The dispute shall initially be referred jointly to the Contractor Project Executive and Customer Project Executive.  The Contractor Project Executive and Customer Project Executive shall attempt to resolve the dispute within seven (7) calendar days of such submission.

(b)If the Contractor Project Executive and Customer Project Executive are unable to resolve the dispute within such time period, the dispute shall be submitted in writing to the lead executive officer respectively of Customer and Contractor.  The lead executive officers shall attempt to resolve the dispute within fourteen (14) calendar days of such submission.

(c)If the matter has not been resolved under the above procedure within twenty-one (21) days of the commencement of such procedure , which period may be extended by mutual agreement, any Party wishing to pursue the matter must resort to final and binding arbitration as provided in the Section 26.2.

The above calendar day periods may be extended by mutual written agreement of Customer and Contractor.

26.2Arbitration

Any dispute arising out of or related to this Agreement, which cannot be resolved by negotiation, shall be settled by binding arbitration in New York, New York in accordance with the J.A.M.S/Endispute Arbitration Rules and Procedures (“Endispute Rules”), as amended by this Agreement.  The costs of arbitration, including the fees and expenses of the arbitrator, shall be shared equally by the parties unless the arbitration award provides otherwise.  Each party shall bear the cost of preparing and presenting its case.  The parties agree that this provision and the Arbitrator’s authority to grant relief shall be subject to the United States Arbitration Act, 9 U.S.C.

58

1-16 et seq. (“USAA”), the provisions of this Agreement, substantive law, and the ABA-AAA Code of Ethics for Arbitrators in Commercial Disputes.  The parties agree that the arbitrator shall have no power or authority to make awards for punitive or exemplary damages.  The Arbitrator’s decision shall follow the plain meaning of the provisions of this Agreement and the relevant documents, and shall be final and binding.  The Arbitrator shall render a written and reasoned opinion setting forth both findings of fact and conclusions of law.  Any Party may appeal a decision of the arbitrator to the FCC or a State Commission, if the matter is within the jurisdiction of the FCC or a State Commission.  Any Party aggrieved by a decision on appeal to the FCC or a State Commission may exercise the right to obtain judicial review thereof in accordance with applicable law.  The award may be confirmed and enforced in any court of competent jurisdiction.  All post proceedings, except those before the FCC or a State Commission, shall be governed by the USAA.

26.3Continuation of Services

Contractor agrees to continue to honor its ongoing obligations, if any, under this Agreement without interruption in the event of a bona fide dispute concerning payment or a dispute concerning any provision of this Agreement, pending final resolution of such dispute pursuant to this Article.

26.4Disputes Regarding Customer’s Application of Allocation

Contractor shall be notified of, and be entitled to participate in (without any obligation on the part of Customer to ensure such participation), any dispute resolution proceeding between Customer and Users concerning how Customer has allocated charges to Users under the Allocation Model for the purpose of ensuring that Contractor is made whole with respect to all rates, charges or other amounts at issue and to which Contractor is entitled under this Agreement.

ARTICLE 27 - GENERAL

27.1Successors and Assigns

This Agreement and any Statements of Work entered pursuant to it shall be binding upon the Parties’ respective successors and assigns.

27.2Attorneys’ Fees

The Party substantially prevailing in any legal action between the Parties concerning this Agreement shall receive reimbursement of its reasonable attorneys’ fees and court costs incurred from the other Party.

59

27.3Service Parity

Contractor shall provide the Services under this Agreement in a manner such that each User shall receive the applicable Services for which it contracts under its NPAC/SMS User Agreement at the same Service Levels as every other User receiving such Services.

27.4Advertising or Publicity

Neither Party shall identify, either expressly or by implication, the other Party or its corporate affiliates or use any of their names, trademarks, trade names, service marks, or other proprietary marks in any advertising, sales presentations, news releases, releases to any professional or trade publication, advertising or other promotional materials without such other Party’s prior written consent, which shall not be unreasonably withheld or delayed.

27.5Non-Waiver

No course of dealing or failure of either Party to enforce strictly any term, right, obligation or provision of this Agreement or any Statement of Work or to exercise any option provided hereunder or thereunder shall be construed as a waiver of such provision.

The acceptance by Customer, or the provision by Contractor, of any credits under this Agreement or any Statement of Work shall not be deemed to be a waiver by Customer of any of its rights under this Agreement or any Statement of Work or at law or in equity.

27.6Notices

All notices or other communications required or permitted to be given under this Agreement shall be in writing (unless otherwise specifically provided herein) and delivered or addressed as follows:

If to Customer:	To the Customer’s Project Executive at the address set forth in Exhibit I
With a copy to:	Carville Collins
	Piper & Marbury L.L.P.
	36 South Charles Street
	Baltimore, Maryland 21201
If to Contractor:	To the Contractor’s Project Executive at the address set forth in Exhibit I
With a copy to:	Lockheed Martin IMS
	1200 K Street NW, 11th Floor
	Washington, DC 20005
	Attn:  Mr. Joseph Franlin
	Fax No.:  (202) 408-5922

60

All notices or other communications shall be deemed effectively given: (a) when delivered, if personally delivered, including courier, facsimile or overnight delivery service, (except that notices received after 3:00 p.m. local time will be deemed received on the following Business Day); (b) on the date of delivery (or, if refused, the refusal date shown on the return receipt) if mailed certified or registered mail, return receipt requested; or (c) four (4) days after mailing if mailed first class.

27.7Governing Law

The construction, interpretation and performance of this Agreement and all transactions under it shall be governed by the laws of the State of New York excluding its choice of laws rules. Contractor agrees to submit to the jurisdiction of any court within the Service Area wherein an action is commenced against Customer under this Agreement.

27.8Severability

If any provision of this Agreement shall be held invalid or unenforceable, such provision shall be deemed deleted from the Agreement and replaced by a valid and enforceable provision which so far as possible achieves the Parties’ intent in agreeing to the original provision.  The remaining provisions of the Agreement shall continue in full force and effect.

27.9Remedies

The rights and remedies provided herein shall be cumulative and in addition to any other remedies available at law or in equity.

27.10Survival

All obligations that by their nature survive the expiration or termination of this Agreement, including, but not limited to,  Section 8.9 - Licenses and Permits, Section 8.10 - Laws and Regulations, Section 8.11 - Immigration Law Compliance, Article 9 - Ownership Of Intellectual Property; Source Code Escrow, Article 15 - Confidential Information, Article 17 - Indemnification, Article 18 - Infringement, Article 19 - Liability, Limitation of Liability and Article 24 - Transition Services, shall remain in effect after its expiration or termination until such obligations expire according to their respective terms.

27.11Joint Work Product

This Agreement is the joint work product of representatives of Customer and Contractor; accordingly, in the event of ambiguities, no inferences will be drawn against either Party, including the Party that drafted the Agreement in its final form.

61

27.12Headings

The Article headings contained herein are for purposes of convenience only and shall not be deemed to constitute a part of this Agreement or to affect the meaning or interpretation of this Agreement in any way.

27.13Counterparts

This Agreement may be executed simultaneously in two (2) counterparts, each of which shall be deemed an original, but both of which together shall constitute one (1) and the same instrument.

ARTICLE 28 - NONEXCLUSIVE MARKET RIGHTS

Contractor expressly acknowledges that Customer is not by this Agreement granting, and has no authority to grant, Contractor the exclusive right to provide NPAC/SMS Services in the Service Area.

ARTICLE 29 - CENTRALIZATION

Customer acknowledges that several of the provisions of this Agreement including but not limited to those Sections addressing Benchmarking, Testing, Service Levels, Additional Services, Audits and Security Checks may be affected by a decision by Customer to have Contractor provide a centralized NPAC/SMS solution.  Specifically, such a centralized approach may require coordination among regional limited liability companies that have also contracted with Contractor for the same centralized NPAC/SMS solution (“Centralized NPAC LLCs”).  For instance, Contractor may not be able to provide certain Additional Services requested by Customer (i.e., pursuant to a Statement of Work) because implementation of the requested Additional Services may impact other Centralized NPAC LLCs’ use of the NPAC/SMS.  In such cases, Contractor will notify all affected Centralized NPAC LLCs of such impact and, if Customer desires to pursue the Additional Services within the context of a centralized NPAC/SMS, Customer will undertake to coordinate a joint Statement of Work with the other affected Centralized NPAC LLCs to provide direction to Contractor with respect to the proposed Additional Services and determine the method of payment therefor, if any.  Additionally, with respect to certain provisions of this Agreement that give Customer the right to verify that the NPAC/SMS is operating consistent with certain standards (including, without limitation, Benchmarking, Audits and Safety/Security Visits), Customer will use its best efforts to coordinate and consolidate its visits and activities with respect to the NPAC/SMS with other Centralized NPAC LLCs so as to minimize the disruption to Contractor’s normal operations.

ARTICLE 30 - ENTIRE AGREEMENT

This Agreement constitutes the entire agreement between Contractor and Customer relating to the subject matter hereof and shall not be modified or rescinded in any manner except by a written amendment executed by both Parties.  Other than as expressly provided herein, both Contractor and Customer agree that no prior or contemporaneous oral representations form a part of their agreement.  Estimates and forecasts furnished by Customer shall not constitute commitments.  The provisions of this Agreement supersede all contemporaneous oral agreements

62

and all prior oral and written quotations, communications, agreements and understandings of the Parties with respect to the subject matter of this Agreement.

63

IN WITNESS WHEREOF, Contractor and Customer have executed this Agreement in duplicate on the day and year below written.

LOCKHEED MARTIN IMS		NORTHEAST CARRIER
		ACQUISITION COMPANY, L.L.C.
By:		By:
	(Signature)		(Signature)
(Name & Title Typed or Printed)		(Name & Title Typed or Printed)
(Date)		(Date)

64

EXHIBIT  A

REQUEST FOR PROPOSAL (NORTHEAST NPAC/SMS RFP)

NPAC/SMS SERVICES

[Due to its length, this document is not attached.
The RFP is available on the internet at
http://www.fcc.gov/ccb/nanc
A copy is also

available upon request for the cost of copying and handling from
NECAC, by request made to the attention of Carville Collins]

[Information referred to in this exhibit immediately follows this page.]

65

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	Conflict Resolution Process
	2.4	Disaster Recovery and Backup Process
3.	NPAC DATA ADMINISTRATION
	3.1	Overview
	3.2	NPAC Personnel Functionality
	3.3	System Functionality

	COPYRIGHT	2/6/96
Solely for companies who have a need to know.
Not to be disclosed to or used by any other person
without prior authorization.

i

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

COPYRIGHT

© 1996

NYCAC

ii

	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

iii

	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

iv

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., 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).

5

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.

6

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.

7

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

8

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.

9

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., 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 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, 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 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 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 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,

10

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:  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:  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.

11

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., 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 be awarded to:

12

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

13

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

14

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., 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.

15

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, 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.

16

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.

17

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.

18

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.

19

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.

20

1.6Evaluation 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.

21

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.1Provision 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,

22

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.2Disconnect 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.3Conflict 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.4Disaster 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,

23

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)

24

Section 3:  NPAC Data Administration

3.1Overview

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

3.1.1Service 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.2Service 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.3Subscription Data

Subscription Data consists of information about the ported TNs.

25

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 Item	Size	Type	Src	Default	Input	Comments
1.	TN	10	N	SP		Reqd.	Telephone Number
2.	DD	8	N	SP		Reqd	Expected Due Date of activation
3.	LRN	10	N	SP		Reqd.	Routing information
4.	Facility -based Service Provider ID	4	A-N	SP		Reqd.	Facilities-based service providers. This field can be used for repair, maintenance purposes.
5.	Activation Time Stamp	10	N	SMS			Date/Time of activation request from local service provider, e.g., xx-xx-xxxx/xxxx
6.	Disconnect Date	8	N	SP		Reqd.	Date e.g., xx-xx-xxxx of TN (end user) disconnect.
7.	Disconnect Broadcast Date	8	N	SP		Reqd.	Date e.g., xx-xx-xxxx of TN (end user) disconnect broadcast, if broadcast is deferred.
8.	Status	*	*	SMS		Reqd.	E.g., active, old, invalid, conflict.
9.	DPC for CLASS(1)	9	N	SP		Reqd.	DPC for 10-digit GTT for CLASS features
10.	SSN for CLASS(1)	3	N	SP		Reqd.	Required if type for CLASS DPC is EO
11.	DPC for LIDB	9	N	SP		Reqd.	DPC for 10-digit GTT for LIDB access
12.	DPC for ISVM	9	N	SP			DPC for interswitch voice message waiting indicator
13.	SSN for ISVM	3	N	SP			Subsystem number for ISVM = 0, if gateway.
14.	DPC for CNAM	9	N	SP			DPC for caller ID with name
15.	SSN for CNAM						Subsystem number for CNAM = 0, if gateway.
16.	End-user Location Value	12	N	SP			Value: Zip code, V&H, Longitude and Latitude, rate center (Value not determined yrt. Future Use.
17.	End-user Location Value Type	2	N	SP			Indicates which location value. Future Use.
18.	Billing ID	4	A-N	SP	Facility-based Service Provider ID		Billing ID. Probably NECA’s company number. Future Use.

(1) CLASS is a Service Mark of Bellcore®.

*These data fields will be determined by SMS.

26

Table 3-1  Subscription Data

3.1.4Data 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.2NPAC Personnel Functionality

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

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

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

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

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

27

R3-6Authorized 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-7Authorized 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.3System Functionality

R3-8The 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-9The NPAC SMS shall be able to download network data (e.g. portable NPA-NXX data), to the Local SMSs.

R3-10The 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-11The 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-12The NPAC shall validate the service, service provider, and subscription data against the current network data.

R3-13The 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-14The 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.

28

Section 4:  NPAC/SMS User Data Administration

4.1NPAC/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.1User Functionality

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

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

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

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

R4-4View NPAC/SMS User data.

R4-5View 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.2System 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.1NPAC/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.

29

R4-6When 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-7SMS 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-8If 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-9After the NPAC/SMS User data has been collected, SMS shall validate that all required data has been received as defined in R4-8.

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

R4-11If 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.2NPAC/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-12SMS shall receive a request to modify NPAC/SMS User data.

30

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

R4-14If 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-16When 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-17If the NPAC/SMS User data fails validation, SMS shall issue an appropriate error message to the request originator.

R4-18If 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.3Delete 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-19SMS shall receive a request to delete NPAC/SMS User data.

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

R4-21If 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:

31

(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.3NPAC/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-23An 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-24Authorized 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-25For queries regarding NPAC/SMS User data, SMS shall receive the NPAC/SMS User ID.

R4-26If 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-27For 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).

32

R4-28If 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-29For 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-30If 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.

33

Section 5:  Subscription Administration

5.1Subscription 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.1Record 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.

34

Requirements

Record Status

R5-1At 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-2The 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.

35

R5-3The 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	Parameter value
pending	90 Days
invalid	90 Days
conflict	30 Days

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

R5-5Subscriptions 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-6SMS 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

36

5.1.2Subscription Administration Requirements

5.1.2.1User Functionality

Authorized users(2) can invoke the following functionality in the SMS to administer subscription data:

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

R5-8Modify 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-9Activate a subscription record - activates a pending subscription record in the network.

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

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

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

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

5.1.2.2System 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

(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).

37

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-14When 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.

38

R5-15When 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-16The 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-17When 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

39

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-18If 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-19If 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-20If 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-21If 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.

40

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-22When 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-23If 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.1Modification of a Pending, Invalid, or Conflict Subscription Record

R5-24SMS 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-25If 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-26SMS shall receive the following data from the user to identify the subscription record to be modified: the Ported Telephone Number Subscription ID.

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

41

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-28The 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-29SMS shall revalidate the modified subscription record.  This revalidation process shall include the validations defined in R5-18.

R5-30If 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-31If 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-32Deleted requirement.  Do not respond.

5.1.2.2.2.2Modification of an Active Subscription Record

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

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

42

R5-35SMS 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-36SMS 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-37The 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-38SMS shall validate the modified subscription record.  This validation process shall include the applicable validations defined in R5-18.

R5-39If 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-40If 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.

43

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

5.1.2.2.3Conflict 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.

44

5.1.2.2.3.1  Placing a Subscription Record in Conflict

R5-42SMS 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-43If 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-44If 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-45If 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-48If the record status is conflict, SMS shall validate the subscription record.  This validation process shall include the applicable validations defined in R5-18.

R5-49If 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.

45

R5-50If 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-51SMS 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-52If the record status is not pending, SMS shall generate an error message and send it to the request originator.

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

R5-54If 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-55If the record is valid, SMS shall determine the Local SMS configuration data of all the Local SMSs.

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

R5-57SMS 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-58SMS 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-59If a positive acknowledgment is received from all involved Local SMSs, then the subscription record shall be marked with a status of active in the

46

SMS and the previously active record (if one exists)  for the same subscription (i.e., ported TN)  shall be marked as old.

R5-60If 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-61If 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-62SMS 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.

47

R5-63If 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-64If 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-65If 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-66If 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-67If 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-68If 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

48

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-69SMS shall receive the following data from the user to identify the subscription record to be canceled: the Ported Telephone Number Subscription ID.

R5-70If 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-71If 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.

49

5.1.3Subscription 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-72An 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-73For 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-74If 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)

50

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-75If 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.

51

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.1SOA 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.

[Graphic Omitted:  SOA to NPAC Interface]

6.1.1Request 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-1Associations on these application to application interfaces must use strong authentication.

R6-2Each 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-3Each 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.

52

6.1.2Subscription 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-4Add new records of subscription data, as well as cancel or modify a specific record of subscription data.

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

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

6.1.3Notifications

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-7Notify a new or an old NPAC/SMS User that they haven’t provided authorization for a transfer of service for a TN.

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

53

6.2NPAC 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.

[Graphic Omitted:  Interface diagram]

6.2.1Transaction 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-9Interface users shall specify their user-identification, system identification, and password to be able to use the Interface.

R6-10Each 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-11Each 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-12Each view request sent over the interface shall be for a single transaction or for a range of transactions.

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

R6-14A 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-15Each 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.

54

6.2.2Network 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-16Add new subscription data, as well as delete or modify specific subscription data.

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

6.3Interface 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-18The 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-19The SOA to NPAC SMS Interface and the NPAC SMS to Local SMS Interface shall be an open, non-proprietary interface.

55

6.4.1Protocol 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-21Multiple associations per NPAC/SMS User may be required.

6.4.2Interface Performance Requirements

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

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

R6-24A 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-25A 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-26Any 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-27LSMS users must be able to choose which NPA-NXXs they will receive broadcasts for.

56

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.1Identification

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-1Unique user identification codes (userids) must be utilized to identify individuals and remote machines.

R7-2SMS 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-3SMS must maintain internally the identity of all currently active users.

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

R7-5SMS 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-6SMS must provide a complementary mechanism or procedure for the re-instatement or deletion of disabled userids.

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

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

R7-9SMS 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.

57

7.2Authentication

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-10SMS must authenticate the identity of all system users, both individuals and remote machines, prior to their initially gaining access to SMS.

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

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

7.2.1Password Requirements

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

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

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

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

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

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

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

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

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

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

R7-23SMS 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-24SMS 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.

58

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

R7-26SMS 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-27SMS-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.3Access 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.1System Access

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

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

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

R7-31SMS’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-32SMS must disconnect or re-authenticate users after an NPAC-specifiable period of non-use.  The system supplied default shall be 60 minutes.

R7-33The 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.

59

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

R7-35When 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-36SMS must not suspend the userid upon exceeding the above threshold.

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

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

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

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

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

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

R7-43Since 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-44A mechanism must exist to end the session through secure logoff procedures.

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

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

R7-47SMS 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:

60

NOTICE: This is a private computer system.

Unauthorized access or use may lead to prosecution.

R7-48Upon 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-49SMS must allow only the NPAC well-defined privileged users responsible for security administration to authorize or revoke users.

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

7.3.2Resource Access

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

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

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

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

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

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

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

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

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

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

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

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

61

7.4Data and System Integrity

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

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

R7-65SMS 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-66SMS 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-67NPAC documentation must contain recommendations for running database integrity checking utilities on a regular basis.

7.5Transaction Audit Log Generation

7.5.1Audit Log Generation

R7-68SMS 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-69The user-identification associated with any SMS request or activity must be maintained, so that the initiating user can be traceable.

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

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

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

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

62

(1)  Invalid user authentication attempts

(2)  Logins and activities of NPAC users

(3)  Unauthorized data or transaction access attempts.

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

R7-75For 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-76Actual 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.2Reporting and Intrusion Detection

R7-77SMS 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-78The 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-79SMS must provide tools for the NPAC to monitor the activities of a specific network address or terminal in real time.

R7-80SMS 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.6Continuity of Service

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

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

63

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

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

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

7.7Software Vendor

R7-86The 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-87The 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-88The 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.8OSI 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.

64

7.8.1Threats

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.2Security Services

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

R7-89Authentication (at association setup)

R7-90Data origin authentication for each incoming message

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

R7-92Non-repudiation of origin

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

7.8.3Security 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.1Encryption

R7-94Since 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-95If 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.

65

R7-96The 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.2Authentication

R7-97Strong, 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:

•The unique identity of the sender

•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

•A sequence number (equal to zero for association request and association response messages)

•A key identifier

•Any additional parameters required by the chosen digital signature algorithm, as specified in OIW Stable Implementation Agreement, Part 12, 1995

•The digital signature of the sender’s identity, Generalized Time and sequence number listed above.

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

7.8.3.3Data Origin Authentication

R7-99Every 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.4Integrity and Non-repudiation

R7-100Because 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-101The 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

66

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-102All the notifications shall be sent in the confirmed mode.

7.8.3.5Access Control

R7-104The 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-105The 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.6Audit Trail

R7-106The 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.7Key Exchange

R7-107There 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-108Upon 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

67

recipient shall call the sender by phone for further confirmation, and provide the sender with the MD5 hash of the whole list.

R7-109The 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-110Each 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-111A 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.

68

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.1Service Provider Verify of Data in NPAC SMS

R8-1A 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-2For 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-3Only the old and new service providers can request data for records in a pending or conflict state.

8.2Periodic Audits

R8-4The 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-5NPAC personnel will be able to specify that an audit be initiated either immediately or at a future time.

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

8.3NPAC SMS Verify of Data in Local SMS

R8-7The 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-8For audit requests from the NPAC SMS to a local SMS, the size of the range of TNs will be limited by a tuneable parameter.

69

Section 9:  Report Management

9.1Overview

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:

•List of ported TNs for a service provider

•List of pending subscription orders for a service provider

•Subscriptions without concurrence

•Status of pending subscription order for a TN being ported

•Date/Time Stamp of Subscription Port (Activation)

•Date/Time Stamp of Subscription Disconnect (Activation)

•Records that required conflict resolution

•Previous service providers and dates of service for ported TNs

•Date/Time Stamp of Broadcast time for transactions

•Subscription order records in error

•Download requests in error

•Log of Missing Response from SOA for order matching

•Log of Missing Response from Local SMS for downloads

•Log of Unauthorized Access Attempts

•Counts of events and usage as described in resource accounting.

Performance Reports

•CPU usage.

•Number of transactions handled and transactions per second.

•Measure of time starting from the receipt of subscription order activation to the broadcast of transaction to Local SMSs.

•Measure of time starting from the receipt of subscription order activation to the receipt of response from Local SMSs.

70

•NPAC SMS to Local SMS link utilization.

•NPAC SMS to SOA link utilization.

9.2User Functionality

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

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

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

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

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

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

R9-7Vendors must provide examples of report outputs.

9.3System Functionality

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

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

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

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

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

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

71

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-1It will be available 24 hours a day, 7 days a week.

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

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

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

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

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

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

R10-8If 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-9The design will provide:

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

•Continuous hardware checking without any performance penalty or service degradation.

•Duplexing of all major hardware components for continuous operation in the event of a system hardware failure.

•Hardware that is transparent to the service providers.

R10-10If 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.

72

•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.

•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-11During any maintenance, if resources allow only partial functionality, the capability of receiving, processing and broadcasting updates will be given the highest priority.

R10-12It 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-13For 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:

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

•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-14Reports 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-15The 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-16Describe any capacity requirements related to the NPAC personnel who will be users of the NPAC SMS.

73

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

Assumptions used for estimating the quantity of transactions are:

•8 million possible TNs in an NPA

•3% annual growth rate

•Annual “churn” Rate (ported TNs which port again) is 30%

•Market penetration increases by 4% annually

•Market penetration stabilizes at 20% in 2003

•Nominal porting occurs 4Q97 and is treated as 0 here

•Both old and new service provide send up “create” messages

•There are 30 local service providers

•There are 20 interexchange carriers

•Each new port represents 53 transactions: 2 uploads, 1 activate, and 50 broadcasts

•Combined local/toll carriers ignored, treated as separate

•14.8 million estimated assigned numbers at end of year 1997

•30.8 million estimated assigned numbers at end of year 1998

		Ports Due
Year	Transactions	To Churn
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-18Data 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.

74

R10-19From 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-20The 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-21The NPAC SMS must be expandable to handle any future growth due to circumstances described in section 13.

75

Section 11:  Billing / Resource Accounting

11.1Overview

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)

76

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.2Assumptions

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

11.3User Functionality

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

11.4System Functionality

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

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

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

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

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

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

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

77

Section 12:  Number Portability Administration Center

12.1Number 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.

78

12.2Logon Administration

Key Responsibilities

R12-1Assist with new logon requests

R12-2Verify logon signature approval

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

R12-4Update data base and add new users

R12-5Notify user of logon activation

R12-6Resolve 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.3Customer Record Security

Key Responsibilities

R12-7Establish user boundaries through user access permission classes

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

R12-9Exercise absolute control of access to customer information

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

79

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.4Scheduled System Unavailability Notification

Key Responsibilities

R12-11Notify 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.5Software Release Acceptance Testing

Key Responsibilities

R12-12Update software test plans

R12-13Allocate staff for performing tests

R12-14Execute test plans

R12-15Generate and resolve testing trouble reports

R12-16Document test results

R12-17Certify NPAC SMS software and release for operation

80

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.6Service Administration

Key Responsibilities

R12-18Create and maintain NPAC SMS data table

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

R12-20Create 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:

•Location Routing Number (LRN) tables

•Service Provider GTT information tables

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

81

12.7Mass 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-21Maintain a close working relationship with organizations responsible for NPA mass changes scheduling.

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

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

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

R12-25Coordinate 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.8User 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

82

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.1User Problem Resolution

Key Responsibilities

R12-26Resolve customer record access problems

R12-27Clarify feature capabilities for users

R12-28Resolve customer record input and modification problems

R12-29Perform acceptance testing for new software releases

R12-30Support 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.2Software Release Acceptance Testing

Key Responsibilities

R12-30Update software test plans

R12-31Allocate staff for performing tests

R12-32Execute test plans

83

R12-33Generate and resolve testing trouble reports

R12-34Document test results

R12-35Certify 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:

•Customer record features

•Electronic mailbox features

•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.3Software Update Notification

Key Responsibilities

R12-36Notify 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.

84

12.8.4Training Administration

Key Responsibilities

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

R12-38Ensure 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.5Document Order Administration

Key Responsibilities

R12-39Process documentation requests

R12-40Provide billing documentation

R12-41Initiate documentation update distribution

R12-42Provide 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.6Training and Documentation User Feedback

Key Responsibilities

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

85

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.7LSMS Download Problem Resolution

Key Responsibilities

R12-44Analyze 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.9System 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.

86

12.9.1–NPAC SMS Report Administration

Key Responsibilities

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

R12-46Validate the accuracy of report contents

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

R12-48Resolve 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.2Failure Recovery Administration and User Notification

Key Responsibilities

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

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

87

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.4NPAC SMS Interface Monitoring

Key Responsibilities

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

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

R12-53Generate 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.4Software Release Acceptance Training

Key Responsibilities

R12-54Update software test plans

R12-55Allocate staff for performing tests

88

R12-56Execute test plans

R12-57Generate and resolve testing trouble reports

R12-58Document test results

R12-59Certify 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:

•NPAC SMS report availability verification

•NPAC SMS service maintenance and diagnostic procedures

•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.10NPAC 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.11NPAC 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.)

89

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.12Administration

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-60Plan NPAC staff for software acceptance testing, report acceptance results, and ensure problem resolution of discrepancies.

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

R12-62Analyze documentation and training impact

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

R12-64Coordinate critical software release cutover

R12-65Provide billing for service providers’ usage

R12-66Manage NPAC accounts receivable collection

R12-67Manage NPAC accounts payable responsibilities

R12-68Resolve any NPAC billing disputes

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

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

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

R12-72Manage NPAC facilities

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

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

R12-75List of cleared trouble reports

12.13Facilities 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

90

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-76Be dedicated entirely for NPAC use

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

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

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

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

R12-81Provide 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.14Telecommunications Requirements

Key Requirements

R12-82Individual phone lines for staff members

R12-8324 hour hotline

R12-84Voice messaging system

R12-85Data communication facilities

R12-86FAX Machine

R12-87Each 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.

91

R12-88The 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-89The 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-90The NPAC must provide a 24-hour hotline that will give the NPAC SMS user:

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

•The latest NPAC SMS status available at times when the system may be unavailable during scheduled or unscheduled downtime.

R12-92The 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-93Procurement 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.15Staffing

Key Requirements

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

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

92

12.16Service Objectives

NPAC Availability

R12-96NPAC 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-97Service consistency

R12-98Service reliability

R12-99Service response time

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

93

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.

94

Section 14:  Glossary

Activation Time Stamp	Date/Time Stamp of when the TN porting activation 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 Point Code (DPC)	The DPC is a 9 digit SS7 address which identifies a node in the signaling network.
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 Translation (GTT)	Global Title Translation - performed for feature call processing and LIDB access. A 10-digit GTT is 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

95

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 & Latitude	Coordinates to define geographic location for 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 Center	Geographic locations assigned V & H coordinates between which distances are determined for billing and rating purposes.
Service Portability	The ability to port TNs when changing services, e.g., from POTS to ISDN.
Service Provider	A Service Provider that provides telecommunication 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 Provider Portability	The ability to port TNs when changing service among Local Service Providers.
Subscription	Information record for a TN.
TN	Telephone Number
V&H Coordinates	Vertical and Horizontal Coordinates to define geographic location for billing and rating purposes.
Version	Time-sensitive (or status-sensitive) instance of subscription data.

96

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

97

Section 16:  Attachments

[Graphics omitted: Charts of seven NYS LNP provisioning process, repair process and disconnect process flows.]

98

NEW YORK CARRIER ACQUISITION COMPANY

EVALUATION / PROCUREMENT TEAM

Greg Pattenaude NY State Department of Public Service Three Empire State Plaza Albany, NY 12223 518-474-8717	Art Backman Cablevision Lightpath Inc. 111 New South Road Hicksville, NY 11801
Steve Addicks MCI Metro 2250 Lakeside Blvd. Richardson, Tx. 75082 214-498-5062 / 5022 fax 0002043758@mcimail.com	Tom McGarry NYNEX 1166 Avenue of the Americas, Rm. 11141 NY, NY 10036 212-395-6371 / 212-819-0623 notes.tmcgarry@nynex.com
	Jeff Sambman Time-Warner Communications 5680 Greenwood Plaza Blvd., Suite 150 Englewood, Co. 80111 303-705-4641 / 303-785-1874
Dwight Hakim Teleport Communications Group 1 Teleport Drive Staten Island, NY 10311 718-355-2623 / 4596 fax hakimbo@tcg.com	Phil Triola AT&T 32 Avenue of the Americas, Rm 2060 NY, NY 10013 212-387-4732 / 4763 fax polaurel!ptriola@photon.att.com
Dave Keech Rochester Telephone 180 South Clinton Ave. Rochester, NY 14616 716-777-6932 / 716-325-1355 fax dkeech@frontiercorp.com
Pamela Kenworthy MFS Communications 3 Wing Drive, Suite 200 Cedar Knolls, NJ 07927 201-938-7897 / 201-938-7439 kenworthy.pamela@mfsc.com

Changes per Mark Sugino’s September 19th RFP clarification letter which deleted Meridian Systems and Bellcore from the procurement evaluation team list

99

EXHIBIT  B

NANC NPAC/SMS FUNCTIONAL

REQUIREMENTS SPECIFICATION

NPAC/SMS SERVICES

[Due to its length, this document is not attached.
The FRS is available on the internet at
http://www.npac.com/docs/frs1001.doc
A copy is also

available upon request for the cost of copying and handling from
NECAC, by request made to the attention of Carville Collins]

[Information referred to in this exhibit immediately follows this page.]

[Graphic Omitted:  Lockheed Martin Logo]

NPAC SMS Functional Requirements Specification

Final Version 1.0

Prepared for:

The Illinois Commerce Commission SMS Subcommittee

By:

Lockheed Martin IMS and Evolving Systems, Inc.

October 1, 1996

Copyright ã 1996  Lockheed Martin IMS Corporation All Rights Reserved. Copyright ã 1996  Evolving Systems, Inc. All Rights Reserved.

This Functional Requirements Specification (FRS) contains valuable ideas, know-how and concepts that are considered proprietary. This information is contained throughout the FRS and is not easily separable without significantly reducing the coherence of the FRS as a whole. Therefore, this complete FRS is considered to be proprietary and is marked accordingly at the bottom of each page by the words “Proprietary Data”.

This FRS includes data that shall not be disclosed outside the Illinois Commerce Commission SMS Subcommittee and shall not be duplicated, used, or disclosed on whole or in part for any purpose except for reviewing and approving this document. However, the proprietary nature of this document could change when a contract or other legally binding instrument is executed.

HP is a registered trademark of Hewlett-Packard Corporation.

The symbol and the initials ESI are registered trademarks of Evolving Systems, Inc. Portions of this product are based on copyrighted materials of Oracle Software, Inc.

Table of Contents

Table of Contents

0.	PREFACE
0.1						Document Structure
0.2						Abbreviations and Notations
0.3						Document Language
0.4						Document Version History
1.		INTRODUCTION
1.1					NPAC SMS Platform Overview
1.2					NPAC SMS Functional Overview
1.2.1								Provisioning Service Functionality
1.2.2								Disconnect Service Functionality
1.2.3								Repair Service Functionality
1.2.4								Conflict Resolution Functionality
1.2.5								Disaster Recovery and Backup Functionality
1.2.6								Order Cancellation Functionality
1.2.7								Audit Request Functionality
1.2.8								Report Request Functionality
1.2.9								Data Management Functionality
1.2.9.1									NPAC Network Data
1.2.9.2									Service Provider Data
1.2.9.3									Subscription Version Data
1.3				Background
1.4				Objective
1.5				Assumptions
1.6				Constraints
1.7				Related Publications
2.		BUSINESS PROCESS FLOWS
2.1			Provision Service Process
2.1.1							Service provider-to-service provider activities
2.1.2							Subscription version creation process
2.1.3							Service providers perform physical changes

Lockheed Martin IMS Corporation	Final Version 1.0 NPAC SMS FRS
Proprietary Data	October 1, 1996

i

2.1.4										NPAC SMS “activate and data download” process
2.1.5										Service providers perform network updates
2.2					Disconnect Process
2.2.1										Customer notification, Service Provider initial disconnect service order activities
2.2.2										NPAC waits for effective release date
2.2.3										NPAC performs broadcast download of disconnect data
2.3				Repair Service Process
2.4				Conflict and Conflict Resolution Process
2.4.1									Subscription version in conflict
2.4.2									New Service Provider coordinates conflict resolution activities
2.4.3									New Service Provider notification of conflict resolution
2.4.4									Missing conflict resolution concurrence notification
2.4.5									Subscription version cancellation
2.4.6									Conflict resolved
2.5					Disaster Recovery and Backup Process
2.5.1								NPAC personnel determine downtime requirement
2.5.2								NPAC notifies Service Providers of switch to backup NPAC and start of cutover quiet period
2.5.3								Service providers connect to backup NPAC
2.5.4								Backup NPAC notifies Service Providers of application availability and end of cutover quiet period
2.5.5								Service providers conduct business using backup NPAC
2.5.6								Backup NPAC notifies Service Providers of switch to primary NPAC and start of cutover quiet period
2.5.7								Service providers reconnect to primary NPAC
2.5.8								Primary NPAC notifies Service Providers of availability and end of cutover quiet period
2.6				Service Order Cancellation Process
2.6.1									Service provider issues service order cancellation
2.6.2									NPAC requests missing acknowledgment from Service Provider
2.6.3									NPAC cancels the Subscription Version and notifies both Service Providers
2.7			Audit Request Process
2.7.1							Service provider requests audit
2.7.2							NPAC SMS issues queries to appropriate Service Providers
2.7.3							NPAC SMS compares Subscription Version data
2.7.4							NPAC SMS updates appropriate Local SMS databases
2.8		Report Request Process
2.8.1						Service provider requests report
2.8.2						NPAC SMS generates report
2.8.3						Report delivered via on-line GUI, Email, electronic file, fax, printer
2.9		Data Administration Requests
2.9.1							Service provider requests administration of data by NPAC personnel
2.9.2							NPAC SMS personnel confirms user’s privileges
2.9.3							NPAC SMS personnel inputs user’s request
2.9.4							NPAC SMS performs user’s request
2.9.5							NPAC SMS personnel logs request denial if user’s privileges are not validated
3.	NPAC DATA ADMINISTRATION

ii

3.1					Overview
3.1.1						Data Type Legend
3.1.2						NPAC Customer Data
3.1.3						Subscription Version Data
3.1.4						Network Data
3.2				NPAC Personnel Functionality
3.3				System Functionality
3.4				Requirements Defined in the Proposal
3.5				Requirements Defined in Post-Award Activities
4.	SERVICE PROVIDER DATA ADMINISTRATION
4.1				Service Provider Data Administration and Management
4.1.1						User Functionality
4.1.2						System Functionality
4.1.2.1									Service Provider Data Creation
4.1.2.2									Service Provider Data Modification
4.1.2.3									Delete Service Provider Data
4.1.3						Service Provider Queries
4.1.3.1									User Functionality
4.1.3.2									System Functionality
4.2			Requirements Defined in the Proposal
4.3			Requirements Defined in Post-Award Activities
5.	SUBSCRIPTION MANAGEMENT
5.1				Subscription Version Management
5.1.1						Subscription Version Management
5.1.1.1							Version Status
5.1.2						Subscription Administration Requirements
5.1.2.1									User Functionality
5.1.2.2									System Functionality
5.1.3						Subscription Queries
5.1.3.1								User Functionality
5.1.3.2								System Functionality
6.	NPAC SMS INTERFACES
6.1		SOA to NPAC SMS Interface
6.1.1						Request Administration
6.1.2						Subscription Administration
6.1.3						Audit Requests
6.1.4						Notifications
6.2		NPAC SMS to Local SMS Interface
6.2.1						Transaction Administration

iii

6.2.2								Network Subscription Administration
6.3					Interface Transactions
6.4					Interface and Protocol Requirements
6.4.1									Protocol Requirements
6.4.2									Interface Performance Requirements
6.4.3									Interface Performance Requirements
6.5					Requirements Defined in the Proposal
6.5.1									NPAC Operations GUI
6.6			Network Requirements
6.6.1							NPAC SMS WAN Topology Requirements
6.6.1.1											The NPAC Site LAN
6.6.2								NPAC SMS WAN Hardware Requirements
6.6.2.1											Enterprise Switching Hubs
6.6.2.2											Local Access Servers
7.	SECURITY
7.1						Identification
7.2				Authentication
7.2.1									Password Requirements
7.3				Access Control
7.3.1								System Access
7.3.2								Resource Access
7.4			Data and System Integrity
7.5			Audit
7.5.1									Audit Log Generation
7.5.2									Reporting and Intrusion Detection
7.6			Continuity of Service
7.7		Software Vendor
7.8		OSI Security Environment
7.8.1										Threats
7.8.2										Security Services
7.8.3										Security Mechanisms
7.8.3.1											Encryption
7.8.3.2											Authentication
7.8.3.3											Data Origin Authentication
7.8.3.4											Integrity and Non-repudiation
7.8.3.5											Access Control
7.8.3.6											Audit Trail
7.8.3.7											Key Exchange

iv

8.	AUDIT ADMINISTRATION
8.1				Service Provider User Functionality
8.2				NPAC User Functionality
8.3				System Functionality
8.4				Audit Report Management
8.5				Requirements in the Proposal
8.6				Database Integrity Sampling
9.	REPORTS
9.1					Overview
9.2					User Functionality
9.3					System Functionality
10.	PERFORMANCE AND RELIABILITY
10.1			Availability and Reliability
10.2			Capacity and Performance
10.3			Requirements in RFP Not Given a Unique ID
11.	BILLING
11.1		User Functionality
11.2		System Functionality
11.3		Requirements Defined in the Proposal
Appendix A. Business Process Flows
Appendix B. Glossary
Appendix C. System Tunables

v

List of Figures

List of Figures

Figure 3-1 Entity Relationship Model

Figure 5-1  Version Status

vi

List of Tables

List of Tables

Table 0-1

Table 0-2

Table 3-1

Table 3-1

Table 3-2

Table 3-3

Table 3-4

Table 3-5

Table 3-6

Table 6-1

Table 11-1 Subscription Tunables

Table 11-2 Communications Tunables

Table 11-3 Audit Tunables

Table 11-4 Logs Tunables

Table 11-5 Keys Tunables

vii

Preface

0.Preface

This section describes the organization and typographical conventions used within the document.

0.1Document Structure

This document is organized into sections as defined below:

Preface	This section describes the document structure, conventions, and references used to develop this document.
Section 1	Introduction - This section introduces the project and describes its scope and objectives, constraints, associated assumptions, and related references.
Section 2	Business Process Flows - This section provides the high level processing flows for the NPAC SMS.
Section 3	NPAC Data Administration - This section provides the high level functional requirements related to the NPAC SMS data relationships.
Section 4	Service Provider Data Administration - This section contains the functional requirements for managing service provider information on the NPAC SMS.
Section 5	Subscription Administration - This section contains the functional requirements associated with managing service provider subscriptions for ported numbers on the NPAC SMS.
Section 6	NPAC SMS Interfaces - This section contains the functional requirements associated with the NPAC SMS external interfaces.
Section 7	Security - This section contains the functional requirements for the NPAC SMS system security.

1

Section 8	Audit Administration - This section contains the functional requirements for NPAC SMS audit administration.
Section 9	Reports - This section contains the functional requirements for NPAC SMS reporting capabilities.
Section 10	Performance and Reliability - This section contains the functional requirements for NPAC SMS system performance and reliability.
Section 11	Billing - This section contains the functional requirements for NPAC SMS usage recording for usage billing.
Appendix A	This section contains the flow diagrams depicting the NPAC SMS process flows.
Appendix B	Glossary - This section provides a description of all acronyms and terms used in this document.
Appendix C	System Tunables - This section provides a list of all system tunables and their default values.

0.2Abbreviations and Notations

To uniquely identify requirements, this document follows a naming convention where the first character is always a letter denoting whether the item is an assumption (A), a constraint (C) or a requirement (R).

In order to identify all NPAC SMS functional requirements this document incorporates information from three sources: the Illinois NPAC SMS RFP, Lockheed Martin’s response to the RFP and requirements definition activities performed with the Illinois Number Portability SMS Subcommittee.

If the second character is the letter “N”, the item is a requirement, assumption or a constraint that was stated in the narrative portion of the RFP and not assigned a number.  The number following this character identifies the item’s section in the RFP/requirements document.

If the second character is the letter “P”, the item is a requirement, assumption or a constraint that was stated in the Lockheed Martin Proposal and not in the RFP.

2

These items represent clarifications or enhancements to the RFP.  The number following this character identifies the item’s section in the RFP/requirements document.

If the second character is the letter “R”, the item is a requirement, assumption or a constraint that was identified during requirements analysis and verification activities subsequent to the release of the Lockheed Martin Proposal.  These items represent clarifications or enhancements to the RFP.  The number following this character identifies the item’s section in the RFP/requirements document.

The following labels are used to identify assumptions, constraints, and requirements within the document.  Each label begins with the letter A, C, or R followed either by a number or letter illustrated below:

A-<nnn>	Is a label for each assumption in the document. Assumptions are conditions that are expected to be true during the design and implementation phases of the project. This is an assumption that was a numbered assumption in the RFP.
AN-<nnn>	This is an assumption that was contained in the narrative text in the RFP.
AP-<nnn>	This is an assumption that was contained in the proposal response.
AR-<nnn>	This is an assumption that was identified as a new assumption for the system, during post-award meetings with the Illinois LCC.
C-<nnn>	Is a label for each constraint within the document. Constraints are conditions that restrict the design and implementation scope of the project. This is a constraint that was a numbered constraint in the RFP.
CN-<nnn>	This is a constraint that was contained in the narrative text in the RFP.
CP-<nnn>	This is a constraint that was contained in the proposal response.
CR-<nnn>	This is a constraint that was identified as a new constraint for the system, during post-award meetings with the Illinois LCC.

3

R-<nnn>	Is a label for each requirement in the document. Requirements define the functionality expected of the design and implementation. This is a requirement that was a numbered requirement in the RFP.
RN-<nnn>	This is a requirement that was contained in the narrative text in the RFP.
RP-<nnn>	This is a requirement that was contained in the proposal response.
RR-<nnn>	This is a requirement that was identified as a new requirement for the system, during post-award meetings with the Illinois LCC.

Table 0-1

0.3Document Language

Specific language is used in the document to denote whether a statement is informative or required.  The following words have these connotations when used to describe actions or items:

shall	The use of the term “shall” in this document is intended to precede a required statement. Compliance with “shall” must be demonstrated during design review and system acceptance testing.
is, will, should	Use of the terms “is,” “will,” or “should” in this document is intended to identify guidance or preference. Statements annotated in this manner are to be treated as informative or preference, but not required. Statements following the words “is,” “will,” or “should” are not a mandatory deliverable for the final system.

Table 0-2

0.4Document Version History

Draft version 0.6 created on 7/11/96.

Draft version 0.7 dated 8/9/96 contains the following changes:

•     In Section 5, requirements beginning with the prefix “RR” were renumbered.

4

•     Section 12, Number Portability Administration Center, has been added.

•     Appendix B, Glossary, has been added.

•     Sections 1 through 11 contain changes that were made as a result of the NPAC SMS industry meetings on August 1 and 2, 1996.

Draft version 0.8 dated 8/28/96 contains the following changes:

Global:

•     Changed “NPAC Interoperable Interface” to “SOA to NPAC SMS Interface and NPAC SMS to Local SMS Interface.”

•     Changed “mechanized SOA interface” to “SOA to NPAC SMS Interface.”

•     Changed “subscription version” to “Subscription Version.”

•     Changed “service provider” to “Service Provider.”

Section 1:

•     Clarified third sentence and added word in Section 1.2.1.

•     Minor typographical changes throughout.

•     Updated Section 1.7, Related Publications.

Section 2:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

•     Standardized point size of 3rd level headings throughout section.

•     Made organization of flows consistent throughout section, and consistent with diagrams in Appendix A.

•     Minor typographical changes throughout.

Section 3:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

•     Minor typographical changes throughout.

•     Replaced “Service Provider” with “NPAC Customer” in applicable models.

5

•     Added “Modify Request Timestamp,” “Modify Broadcast Timestamp,” and “Modify Broadcast Complete Timestamp” to Subscription Version Data Model.

Section 4:

•     Clarified wording in R4-2.

•     Divided requirement R4-8 into required and optional data elements, and added items per updates to Section 3.

•     Marked requirements R4-18.1, R4-18.2, and R4-18.3 for deletion.

•     Added “up to a tunable number of Subscription Versions” to requirement R4-30.1.

•     Clarified wording of requirements in sections 4.2 and 4.3.

•     Minor typographical changes throughout.

Section 5:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

•     Differentiated between Inter-Service Provider or “porting to original” ports and Intra-Service Provider ports in sections 5.1.2.2.1, 5.1.2.2.3, 5.1.2.2.4, 5.1.2.2.5, and 5.1.2.2.6.

•     Replaced cross-references to other requirements with appropriate verbage.

•     Added Section 5.1.2.2.7, Subscription Version Resend.

•     Minor typographical changes throughout.

Section 6:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

•     Minor typographical changes throughout.

Section 7:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

6

•     Replaced “Interoperable Interface” with “SOA to NPAC SMS interface and NPAC SMS to Local SMS interface.”

•     Minor typographical changes throughout.

Section 8:

•     No Changes.

Section 9:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

•     Re-labelled “RN” requirements “RP.”

•     Minor typographical changes throughout.

Section 10:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

•     Renumbered Assumptions beginning with 10-1.

•     Renumbered “RN” requirements beginning with 10-1.

•     Minor typographical changes throughout.

Section 11:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

•     Minor typographical changes throughout.

Section 12:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

Appendix A:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

7

Appendix B:

•     Changes/additions/deletions per face-to-face meeting August 19-21, Denver, Colorado.

Draft version 1.0 dated 9/17/96 was modified per the face-to-face meeting held September 9-11 at Ameritech facilities, Chicago, IL.

Final version 1.0 dated 10/1/96 was modified per the face-to-face meeting held September 18-20 at Ameritech facilities, Chicago, IL.

8

Introduction

1.Introduction

This document defines the functional requirements of the Number Portability Administration Center Service Management System (NPAC SMS) enabling Service Provider Portability in Illinois LATA 358.

This introduction gives readers a brief overview of NPAC SMS functionality. It is intended to prepare you for the detailed sections that follow.  If you need more information on any particular area, please consult the applicable detailed sections in the remainder of this document or the NPAC SMS Interoperable Interface Specification.

This introduction is also meant to convey the basic course of events that give the best understanding of the system. Alternate courses of events (variants of the basic course or error paths) are described in the detailed sections later in this document and in the NPAC SMS Interoperable Interface Specification.

1.1NPAC SMS Platform Overview

The Number Portability Administration Center Service Management System (NPAC SMS) is a hardware and software platform which contains the database of information required to effect the porting of telephone numbers.  In general, the NPAC SMS receives customer information from both the old and new Service Providers (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 NPAC SMS also contains a record of all ported numbers and a history file of all transactions relating to the porting of a number.  The NPAC SMS shall also provide audit functionality and the ability to transmit LNP routing information to Service Providers to maintain synchronization of Service Provider’s network elements that support LNP.

1

1.2NPAC SMS Functional Overview

1.2.1Provisioning Service Functionality

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 (SOA).  When the NPAC SMS receives the notification(s), it will perform certain validation checks, and attempt to match the notification received from the new Service Provider with a concurring notification from the old Service Provider. If 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 the new Service Provider is ready to provide service, it will send an activation notice to the NPAC SMS.  The NPAC SMS will broadcast the update out in real time to each local SMS.  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 place the subscription in the “Conflict” state. If it was the new Service Provider that failed to respond, the NPAC will log the failure to respond, cancel the notification, and notify both Service Providers 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 (see Section 1.2.4). 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 customer approval to port a TN.

1.2.2Disconnect Service Functionality

When a ported number is being disconnected, the customer and Service Provider will agree on a date. The current Service Provider will send an update indicating

2

the disconnect to the NPAC SMS. The NPAC SMS will broadcast the update to all Service Providers based on the disconnect effective date 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.

1.2.3Repair Service Functionality

A problem will be detected either by a Service Provider or by a customer contacting a Service Provider.

There will be audit capabilities in the NPAC SMS to aid in isolating problems. If an inaccuracy is found, the NPAC SMS will supply the correct data to any local SMS requesting updates.

1.2.4Conflict Resolution Functionality

If Service Providers disagree on who will serve a particular line number, the NPAC SMS will place the request in the “conflict” state 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 the “conflict” state or cancel it.

1.2.5Disaster Recovery and Backup Functionality

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 of the situation and planned action by electronic notification and telephone calls to the Service Providers’ contact numbers.  The Service Providers will attempt to switch to the backup NPAC.

1.2.6Order Cancellation Functionality

From the time the old or new Service Provider sends a create Subscription Version request to the time the new Service Provider receives the request, a Service Provider may send a message to the NPAC SMS to cancel the Subscription Version. If both Service Providers agree with the cancellation, the NPAC SMS will set the Subscription Version to canceled and notify both Service Providers that the Subscription Version has been canceled.

3

1.2.7Audit Request Functionality

An audit function will be necessary for troubleshooting customer problems and also as a maintenance process to ensure Subscription Version data integrity across the entire LNP network. Audits will be concerned with the process of comparing the NPAC SMS view of the LNP network’s Subscription Version data with one or more of the Service Provider’s views of its network.  In the case of “on demand” audits, audits may be initiated by any Service Provider who has reason to believe a problem may exist in another Service Provider’s network.  These audits are executed via queries to the appropriate Service Provider’s network, and corrected via downloads to those same networks.

In addition, Local Service Providers will be responsible for comparing database extracts of Subscription data written to an FTP site by the NPAC SMS with their own versions of the same Subscription data.

In a third scenario, the NPAC SMS will select a random sample of active Subscription Versions from its own database, then compare those samples to the representation of that same data in the various Local SMS databases.  All three of the methods outlined above are designed to help ensure data integrity across the LNP network.

1.2.8Report Request Functionality

The NPAC SMS supports report generation for pre-defined and ad-hoc reports.  The report generation function creates output report files according to specified format definitions, and distributes reports to output devices as requested.  The report distribution service supports distribution to electronic files local/remote printers, e-mail and FAX machines.

1.2.9Data Management Functionality

The NPAC SMS will support functionality to manage network, Service Provider, and Subscription Version data.

1.2.9.1NPAC Network Data

The NPAC SMS contains data which defines the configuration of the LNP service and network.  This includes such data as: participating Service Providers, NPA-NXXs that are portable, and LRNs associated with each Service Provider.

4

1.2.9.2Service Provider Data

The Service Provider data indicates who the LNP Service Providers are and includes location, contact name, security, routing, and network interface information.

1.2.9.3Subscription Version Data

The subscription data indicates how local number portability should operate to meet subscribers’ needs.

1.3Background

An industry task force was formed in Illinois in April 1995, pursuant to the Illinois Commerce Commission (ICC) Order on Customers First Plan (Docket 94-0096 dated April 7, 1995), to develop a permanent number portability solution for Illinois.  During the year, this task force has made significant progress in defining and resolving the issues related to implementing number portability.

1.4Objective

The target date for LRN implementation is second quarter 1997.

The objective of this document is to uniquely identify the baseline end-user, functional requirements that define the LNP SMS supporting number portability in LATA 358.

1.5Assumptions

A1-1 The Service Providers will be billed in proportion to their usage of the services provided by the NPAC SMS.

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

AR4-1.1 All NPAC Customers will obtain a unique Service Provider ID from a proper source.

5

AR6-1 Range Activations.

A range activate will contain an average of 20 TNs.

AR6-2 Percent of Range Activations.

20% of all downloads as specified in R6-28.1, R6-28.2, R6-29.1 and R6-29.2 will be processed via range activations.

AR10-1 Scheduled Downtime

NPAC initiated downtime as defined in R10-5 does not include downtime needed for software release updates initiated by or collectively agreed to by the Service Providers.

A10-1 Initial Turn-up Number of Service Providers

On initial turn-up, there will be 10 Service Providers each having one SOA to NPAC SMS interface and one NPAC SMS to Local SMS interface.

A10-2 Unknown Number of Updates

The number of updates due to mass changes, the number of audit requests and the number of report requests is not known at this time.

A10-3 Churn of Accumulated Records

It is assumed that there will be thirty percent churn of accumulated records.

A11-2 Accounting Measurements Will Not Degrade the Basic System Performance

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

1.6Constraints

The following constraints shall be adhered to during the development of the software associated with the requirements within this document.

6

C1-1 The NPAC SMS is not involved in real time call processing.

C1-2 The NPAC SMS is not involved in facilitating or tracking Service Provider-to-Service Provider activities.

CN1-1 Initially, only wireline Service Provider portability within Illinois LATA 358 will be implemented.

CN2-1.1.1 Interactions between Service Providers are beyond the scope of the NPAC SMS.

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 customer authorization.  Details of steps in those processes do not involve the NPAC or NPAC SMS, and are beyond the scope of the NPAC SMS functionality.

CN2-1.3.1.Service provider network change activities are beyond the scope of the NPAC SMS.

Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as physical changes performed in the Service Provider’s networks, are beyond the scope of the NPAC SMS functionality.

CN2-1.4.1 Service provider’s internal activities are beyond the scope of this document.

Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as physical changes performed in the Service Provider’s networks are beyond the scope of this document.

CN2.1.5-1.Service Provider’s Network Change Validation Activities Are Beyond The Scope Of The NPAC SMS.

Network testing performed by the Service Providers, such as testing of call processing and testing of Service Provider network elements, is beyond the scope of the NPAC SMS.

7

CN2-1.6.1 Service provider’s internal activities are beyond the scope of this document.

Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as updates to data performed in the Service Providers network elements are beyond the scope of this document.

CN2-2.3.1 Service provider’s internal activities are beyond the scope of this document.

Deleted

Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as updates to data performed in the Service Provider’s network elements are beyond the scope of this document.

CN2-3.1.1 Service provider’s internal activities are beyond the scope of this document.

Deleted

Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as updates to data performed in the Service Provider’s network elements are beyond the scope of this document.

CN2-3.3.1Service provider’s repair activities are beyond the scope of the NPAC SMS.

Details of steps in the repair processes that do not involve the NPAC or NPAC SMS, such as the customer’s notification of problems, the Service Provider’s analysis/troubleshooting activities and the Service Provider’s repair activities are beyond the scope of the NPAC SMS functionality.

CN2-4.1.1 Service provider’s internal activities are beyond the scope of this document.

Deleted

Details of steps in the processes that do not involve the NPAC are beyond the scope of this document.

CN2.4.2-1.Service provider’s conflict resolution activities are beyond the scope of the SMS NPAC.

8

Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as conflict resolution escalation and arbitration activities are beyond the scope of this document.

CN2-6.1.1 Interactions between Service Providers are beyond the scope of this document.

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 customer authorization.  Details of steps in those processes do not involve the NPAC or NPAC SMS, and are beyond the scope of this document.

1.7Related Publications

NPAC SMS Interoperable Interface Specification, Version 1.0 Final, October 1, 1996.

9

NPAC Data Administration

2.Business Process Flows

The following process flows indicate how the NPAC SMS is used by the Service Providers in business processes associated with number portability.  Specific requirements generated by the process flows are included in the appropriate sections later in the document.

The process flows supported by the NPAC SMS are:

•     Service Provisioning

•     Service Disconnection

•     Service Repair

•     Conflict and Conflict Resolution

•     Disaster Recovery and Backup

•     Service Order Cancellation

•     Audit Requests

•     Report Requests

•     Data Administration Requests

2.1Provision Service Process

This process flow defines the provisioning flow in which a customer ports a telephone number to a new Service Provider.  The service provisioning flow activities are shown in Flow 2.1, Appendix A page 3.

2.1.1Service provider-to-service provider activities

The new Service Provider must obtain authorization to port the customer.  The new Service Provider will notify the old Service Provider according to processes internal to the Service Providers.

CN2-1.1.1 Interactions between Service Providers are beyond the scope of the NPAC SMS.

1

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 customer authorization.  Details of steps in those processes do not involve the NPAC or NPAC SMS, and are beyond the scope of the NPAC SMS functionality.

2.1.2Subscription version creation process.

The Subscription Version creation flow activities are shown in Flow 2.1.2, Appendix A page 4.

2.1.2.1  Create Subscription Version.

When a number is ported, both the old and new Service Providers must send a notification to the NPAC SMS.  The NPAC validates the data for each notification and attempts to match the notification with a concurring notification from the other Service Provider.  If a notification is missing from either provider after a tunable time period, the NPAC sends a request for the missing notification.  If the data provided with the notification is valid, the NPAC SMS creates a pending Subscription Version and awaits the concurring notification.  If the data is invalid, the NPAC SMS reports a specific error to the sender of the data and discards the request.

2.1.2.2  Request missing/late notification

If concurring notification or explicit non-concurrence from the old Service Provider is not received, the process flows to 2.4 (Conflict).  If concurring notification or explicit non-concurrence from the new Service Provider is not received, the process flows to 2.6 (Cancel).

2.1.3Service providers perform physical changes.

The two Service Providers involved in the number port will coordinate and perform the physical changes to their respective networks.

CN2-1.3.1. Service provider network change activities are beyond the scope of the NPAC SMS.

Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as physical changes performed in the Service Provider’s networks, are beyond the scope of the NPAC SMS functionality.

2

2.1.4NPAC SMS “activate and data download” process.

The NPAC network data broadcast download flow is shown in Flow 2.1.4, Appendix A page 5.

2.1.4.1New Service Provider sends activation to NPAC SMS.

The new Service Provider sends an activate notification to the NPAC SMS.

2.1.4.2NPAC SMS broadcasts network data to all Service Providers

Upon receipt of the activation notification, the NPAC SMS broadcasts the network update data in real time to all Service Providers’ Local SMSs.

2.1.4.3Failure - notify NPAC

If the NPAC SMS does not receive positive acknowledgment of the broadcast, the NPAC SMS will rebroadcast the network data download to the Service Providers that did not acknowledge the original broadcast.  The NPAC SMS will perform the rebroadcast a tunable number of times within a tunable time frame.

2.1.4.4Initiate repair procedures

If the tunable rebroadcast parameters have been exceeded, the NPAC staff will initiate repair processes with the appropriate Service Providers. The NPAC SMS will send a list of failed Service Providers to the old and new Service Providers.

2.1.5Service providers perform network updates.

Upon receiving the network data download broadcast from the NPAC SMS, all Service Providers’ local SMSs will confirm the receipt of the download broadcast, and update their network elements. The Service Providers may also test their network changes.

CN2-1.5-1. Service Provider’s Network Change Validation Activities Are Beyond The Scope Of The NPAC SMS.

Network testing performed by the Service Providers, such as testing of call processing and testing of Service Provider network elements, is beyond the scope of the NPAC SMS.

3

2.2Disconnect Process

This process flow defines the activities associated with the discontinuance of service for a ported number.  The NPAC Disconnect Service flow is shown in Flow 2.2, Appendix A page 6.

2.2.1Customer notification, Service Provider initial disconnect service order activities.

When a ported number is being disconnected, the customer and Service Provider will agree on a date.  The Service Provider will send a notification to the NPAC SMS indicating the date of the physical disconnect of the number and also the date that the disconnect information is to be broadcast to all Local SMSs (the ‘effective release date’).

2.2.2NPAC waits for effective release date.

The NPAC SMS will send delete actions containing the disconnect information based on the effective release date specified by the Service Provider.  If no effective release date is specified on the disconnect request, the NPAC SMS processes the request immediately.

2.2.3NPAC performs broadcast download of disconnect data.

The NPAC SMS will broadcast the disconnect information to all Service Providers. If the broadcast is not acknowledged, the disconnect information will be resent a tunable number of times within a tunable time frame. If the tunable parameters for the collection of responses have been exceeded, the NPAC staff will initiate repair processes with the appropriate Service Providers (Flow 2.3), and send a list of failed Service Providers to the current Service Provider.

2.3Repair Service Process

This process flow defines the activities performed when a problem is detected either by the NPAC SMS, a Service Provider, or by a customer who contacts a Service Provider.  The repair service flow is shown in Flow 2.3, Appendix A page 7.

4

2.3.1-AService provider receives problem notification from customer.

2.3.1-BService provider receives problem notification from another Service Provider.

2.3.1-CService provider receives problem notification from NPAC SMS.

2.3.2Service provider analyzes the problem.

2.3.3Service provider performs repairs.

There will be audit capabilities in the NPAC SMS to aid in isolating problems.

CN2-3.3.1 Service provider’s repair activities are beyond the scope of the NPAC SMS.

Details of steps in the repair processes that do not involve the NPAC or NPAC SMS, such as the customer’s notification of problems, the Service Provider’s analysis/troubleshooting activities and the Service Provider’s repair activities are beyond the scope of the NPAC SMS functionality.

2.3.4Request broadcast of repaired data.

There will be audit capabilities in the NPAC SMS to aid in isolating problems. A Service Provider may request a download of data to assist in the repair process, if necessary.

2.3.5Broadcast repaired subscription data.

If inaccurate routing data is found, the NPAC SMS will broadcast the correct data to any involved Service Provider’s networks to correct inaccuracies.

2.4Conflict and Conflict Resolution Process

This process flow defines the activities performed when Service Providers disagree on who will serve a particular customer.  The conflict flow is shown in Flow 2.4.1, in Appendix A page 8.

5

2.4.1Subscription version in conflict.

Two different paths may cause the NPAC SMS to place a Subscription Version in conflict status (see Flow 2.4.1 in Appendix A).

2.4.1.1 Change of status upon problem notification.

Subscription version’s conflict status “on” is achieved when a Service Provider notifies NPAC SMS personnel of a disagreement between the new and old Service Providers as to whether or not a TN may be ported, or when the old Service Provider fails to respond to a request for concurrence.

2.4.1.2 Change of status upon non-concurrence.

Non-concurrence between Service Providers causes the NPAC SMS to place the Subscription Version in conflict during the “Create Version” process (2.1.2).

2.4.2New Service Provider coordinates conflict resolution activities.

The New and Old Service Providers use internal and inter-company processes to resolve the conflict. See Flow 2.4.2 for a description of the conflict resolution process.

CN2.4.2-1. Service provider’s conflict resolution activities are beyond the scope of the SMS NPAC.

Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as conflict resolution escalation and arbitration activities are beyond the scope of this document.

2.4.3New Service Provider notification of conflict resolution.

If less than 30 days [tunable parameter] have passed since the Subscription Version status was set to conflict “on” and a resolution was reached, the new Service Provider will initiate the action to change the Subscription Version status to “Conflict Resolution Pending.” See Flow 2.4.3 for a description of the conflict resolution process.

6

2.4.4Missing conflict resolution concurrence notification.

While in “Conflict Resolution Pending” status, the NPAC SMS waits for concurrence notification from both Service Providers. If the conflict resolution concurrence is not received within 18 hours [tunable parameter], the NPAC SMS sends a request for the concurrence. If the conflict resolution concurrence is not received within 18 hours [tunable parameter] of the second notification, the NPAC SMS returns the Subscription Version status to “conflict.”

2.4.5Subscription version cancellation

2.4.5.1  Version cancellation when conflict status “on” for 30 days.

If the Subscription Version status has been set to conflict “on” for 30 days [tunable parameter] and no resolution has occurred, the NPAC SMS will cancel the Subscription Version, and notify both the old and new Service Providers of the cancellation.

2.4.5.2  Cancel pending notification.

If the Subscription Version is in conflict “on” and the new Service Provider requests to cancel the Subscription Version, the NPAC personnel will set the Subscription Version to cancel and both Service Providers will be notified. (Flow 2.6).

2.4.6Conflict resolved.

When both Service Providers agree to resolve the conflict and have notified the NPAC within the allowable time frame, the NPAC SMS will change the Subscription Version status to pending.

2.5Disaster Recovery and Backup Process

This process flow defines the backup and restore activities performed by the NPAC and the Service Providers.  The disaster recovery flow is shown in Flow 2.5, Appendix A page 10.

2.5.1NPAC personnel determine downtime requirement

If there is planned downtime for the NPAC SMS, the NPAC SMS will send an electronic notification to the Service Providers’ SOAs that includes information

7

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 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 electronic notification and telephone calls to the Service Providers’ contact numbers. The notification will describe the situation and the planned action.  The Service Providers will attempt to switch to the backup NPAC.

2.5.2NPAC notifies Service Providers of switch to backup NPAC and start of cutover quiet period

The NPAC Service Providers will switch to the backup or disaster recovery machine as indicated in the notification.

2.5.3Service providers connect to backup NPAC

The Service Providers must use an alternate connection route to the backup NPAC and establish associations with the backup NPAC application.

2.5.4Backup NPAC notifies Service Providers of application availability and end of cutover quiet period

When the backup NPAC application and database are on-line, processes will proceed as normal.  The backup NPAC application will be at the same version level as the primary NPAC application.  The NPAC SMS database will also contain the same routing information as the primary database.

2.5.5Service providers conduct business using backup NPAC

The Service Provider should continue to process as normal when connected to the backup NPAC.  If a Service Provider does use internal processes to request updates to SCPs while waiting to be able to send them to the backup machine, the Service Provider will still resend the updates when the backup NPAC can begin processing them in order to ensure that every Service Provider and the NPAC SMS receive the update.

8

2.5.6Backup NPAC notifies Service Providers of switch to primary NPAC and start of cutover quiet period.

When the primary machine is brought back up, the backup NPAC will advise the Service Providers of the timing of their switch back

to the primary machine.  At this time the backup NPAC will stop taking updates.

2.5.7Service providers reconnect to primary NPAC

The Service Providers re-establish associations with the primary NPAC application using their normal connections.

2.5.8Primary NPAC notifies Service Providers of availability and end of cutover quiet period

When the primary NPAC is available, NPAC personnel will notify Service Providers of the end of the cutover quiet period.

2.6Service Order Cancellation Process

This flow defines the process performed when a Service Provider cancels a service order.  The service order cancellation flow is

shown in Flow 2.6, Appendix A page 11.

2.6.1Service provider issues service order cancellation

From the time a Service Provider sends notification of a new Subscription Version to the time the Subscription Version is activated, either Service Provider may send a message to the NPAC SMS to cancel the Subscription Version. If this occurs, the NPAC SMS will notify both Service Providers that the Subscription Version is in a cancel-pending state.

2.6.2NPAC requests missing acknowledgment from Service Provider.

When notified that a Subscription Version has been set to cancel-pending, both Service Providers must concur by returning a cancel-pending acknowledgment to the NPAC SMS within 18 hours [tunable parameter].  If the NPAC does not receive acknowledgment in the allowable time from one of the Service Providers, a request is sent to that Service Provider for a cancel-pending-acknowledgment. 

9

If the missing cancel-pending-acknowledgment is not received within a tunable time frame, the Subscription Version status is set to “conflict.”  Both Service Providers are then notified that the Subscription Version status is now “conflict.”

2.6.3NPAC cancels the Subscription Version and notifies both Service Providers.

When acknowledgment is received from both Service Providers, within the allowed time frame the NPAC SMS will set the Subscription Version to canceled in its database and notify both Service Providers that the Subscription Version has been canceled. All canceled Subscription Versions are purged from the NPAC database after a tunable period.

2.7Audit Request Process

This process flow defines the activities performed by the NPAC when Service Providers request audits of LNP data.  The audit request flow is shown in Flow 2.7, Appendix A page 12.

2.7.1Service provider requests audit

Any Service Provider can request audits of the entire network or of individual Service Provider’s networks.

2.7.2NPAC SMS issues queries to appropriate Service Providers

Upon receipt of an audit request, the NPAC SMS queries the appropriate Service Provider’s Local SMS databases.

2.7.3NPAC SMS compares Subscription Version data

The NPAC SMS compares its own Subscription Version data to the data it finds in the targeted Local SMS Subscription Version databases.

2.7.4NPAC SMS updates appropriate Local SMS databases

The NPAC SMS updates Subscription Version information in the appropriate Local SMS databases.

10

2.8Report Request Process

This process flow defines the activities performed by the NPAC when the Service Providers request report generation and delivery.  The report request flow is shown in Flow 2.8, Appendix A page 13.

2.8.1Service provider requests report.

2.8.2NPAC SMS generates report.

2.8.3Report delivered via on-line GUI, Email, electronic file, fax, printer.

2.9Data Administration Requests

This section defines the activities performed by the NPAC when Service Providers make a manual request for data administration.

2.9.1Service provider requests administration of data by NPAC personnel

Service provider personnel are able to contact NPAC personnel to request data administration activities.

2.9.2NPAC SMS personnel confirms user’s privileges

Before NPAC personnel fulfill the data administration request, they will confirm the user’s privileges and validate the request.

2.9.3NPAC SMS personnel inputs user’s request

Upon validation of the request, NPAC personnel will input the request.

2.9.4NPAC SMS performs user’s request

The NPAC SMS processes the request.

11

2.9.5NPAC SMS personnel logs request denial if user’s privileges are not validated

If the user’s privileges are not confirmed, or the request cannot be validated, the NPAC personnel log the activity and end the process.

12

3.NPAC Data Administration

3.1Overview

The NPAC SMS manages the ported TN information associated with Service Provider portability for the LNP service.  This section describes the high level requirements associated with managing ported telephone numbers from an operations perspective. Figure 3-1 illustrates the logical data model associated with the data elements for the NPAC SMS.

The figure below illustrates the relationship between NPAC Customer data and other data tracked or created by the system.

[Graphic Omitted:  Diagram of entity relationship model]

Figure 3-1 Entity Relationship Model

3.1.1Data Type Legend

The following table describes the data types used in the data models.

DATA TYPE LEGEND

Data Type	Description
	Network Address: raw binary data stored as unformatted bytes.
Address
B	Boolean (True or False) indicator.
C	Character or Alphanumeric strings.
E	Enumeration.
M	Bit Mask comprised of one or more bytes.
N	Numeric data (up to 32 bit integer, numeric data that can be arithmetically manipulated).
N(x)	Character string of “x” digits only.
T	Timestamp: month, day, year, hour, minute, and seconds.
TN	Telephone Number: 3-digit NPA, 3-digit NXX, 4-digit Station Number.

Table 3-1

13

3.1.2NPAC Customer Data

NPAC Customer Data contains information about NPAC customers participating in the LNP service. The data items that need to be administered by NPAC Customer Data Management are represented in tables 3-1, 3-2, and 3-3:

NOTE:  A check in the Required column means that this attribute must exist in the record before the record is considered useable.

NPAC CUSTOMER DATA MODEL

Attribute Name	Type (Size)	Required	Description
NPAC Customer ID	C (4)		An alphanumeric code which uniquely identifies an NPAC Customer.
NPAC Customer Name	C (40)		A unique NPAC Customer Name.
NPAC Customer Allowable Functions	M		Each bit in the mask represents a boolean indicator for the following functional options: •      SOA Management •      SOA Network Data Management •      LSMS Network Data Management •      LSMS Data Download •      LSMS Queries/Audits
NPAC Customer Download	M		Each bit in the mask represents a boolean indicator for the following download options: •      Download Network Data

Table 3-1

14

NPAC CUSTOMER CONTACT DATA MODEL

Attribute Name	Type (Size)	Required	Description
NPAC Customer Contact ID	N		A unique sequential number assigned upon creation of the Contact record.
NPAC Customer ID	C (4)		An alphanumeric code which uniquely identifies an NPAC Customer.
Contact Type	C (2)		The type of NPAC Customer Contact Organization. Valid values are: •      BI - Billing. •      CF - Conflict Resolution Interface. •      LI - Local SMS Interface. •      NC - NPAC Customer. •      NF - Network and Communications Facilities Interface. •      OP - Operations. •      RE - Repair Center Contact Organization. •      SE - Security. •      SI - SOA System Interface. •      UA - User Administration. •      WI - Web Interface.
Contact	C (40)		Name of NPAC Customer Contact Organization.
Contact Address Line 1	C (40)		Contact Organization address Line 1.
Contact Address Line 2	C (40)		Contact Organization address Line 2.

15

Attribute Name	Type (Size)	Required	Description
Line 2
Contact City	C (20)		Contact Organization city.
Contact State	C (2)		Contact Organization state.
Contact Zip	C (9)		Contact Organization zip code or postal code.
Contact Country	C (2)		Contact Organization country.
Contact Province	C (2)		Contact Organization province.
Contact Phone	TN		Contact Organization phone number.
Contact Fax	TN		Contact Organization Fax phone number.
Contact Pager	TN		Contact Organization Pager phone number.
Contact Pager PIN	C (10)		Contact Organization Pager Personal Identification Number (PIN).
Contact Email	C (60)		Contact Organization E-mail address.

Table 3-2

NPAC CUSTOMER NETWORK ADDRESS DATA MODEL

Attribute Name	Type (Size)	Required	Description
NPAC Customer Network Address ID	N		A unique sequential number assigned upon creation of the Network Address record.
NPAC Customer ID	C (4)		An alphanumeric code which uniquely identifies an NPAC Customer.
Network	C (1)		Type of Network Address.

16

Attribute Name	Type (Size)	Required	Description
Address Type			Valid values are: •      S - SOA interface •      L - Local SMS interface.
NSAP Address	Address (20)		OSI Network Service Access Point Address
TSAP Address	Address (4)		OSI Transport Service Access Point Address.
SSAP Address	Address (4)		OSI Session Service Access Point Address.
PSAP Address	Address (4)		OSI Presentation Service Access Point Address.
Internet Address	Address (12)		Internet address of the Service Provider Web interface.

Table 3-3

3.1.3Subscription Version Data

Subscription Version Data consists of information about the ported TNs. The data items that need to be administered by Subscription Version Data Management functions are identified in table 3-4:

SUBSCRIPTION VERSION DATA MODEL

Attribute Name	Type (Size)	Required	Description
Version ID	N		A unique sequential number assigned upon creation of the Subscription Version.
LRN	TN		The LRN is an identifier for the switch on which portable NPA-NXXs reside.
Old Service Provider ID	C (4)		Old Service Provider ID.

17

Attribute Name	Type (Size)	Required	Description
New Service Provider ID	C (4)		New Service Provider ID.
TN	TN		Subscription Version telephone number.
Local Number Portability Type	E		Number Portability Type. Valid enumerated values are: •      LSPP - Local Service Provider Portability (0) •      LISP - Local Intra-Service Provider Portability (1)
Status	E		Status of the Subscription Version. The default value is P for Pending. Valid enumerated values are: •      X - Conflict (0) •      A - Active (1) •      P - Pending (2) •      S - Sending (3) •      F - Failed (4) •      PF - Partial Failure (5) •      CR - Conflict Resolution Pending (6) •      DP - Disconnect Pending (7) •      O - Old (8) •      C - Canceled (9) •      CP - Cancel Pending (10)
CLASS DPC	N (9)		DPC for 10-digit GTT for CLASS features.
CLASS SSN	N (3)		CLASS SSN for the Subscription Version.

18

Attribute Name	Type (Size)	Required	Description
LIDB DPC	N (9)		DPC for 10-digit GTT for LIDB features.
LIDB SSN	N (3)		LIDB SSN for the Subscription Version.
CNAM DPC	N (9)		DPC for 10-digit GTT for CNAM features.
CNAM SSN	N (3)		CNAM SSN for the Subscription Version.
ISVM DPC	N (9)		DPC for 10-digit GTT for ISVM features.
ISVM SSN	N (3)		ISVM SSN for the Subscription Version.
New Service Provider Due Date	T		The due date planned by the new Service Provider for: •      Subscription Version Transfer of Service or •      Modification of a pending Subscription Version.
Old Service Provider Due Date	T		The due date planned by the old Service Provider for: •      Subscription Version Transfer of Service or •      Modification of a pending Subscription Version.
Old Service Provider Authorization	B		A boolean indicator set by the old Service Provider to indicate authorization or denial of Transfer of Service for the Subscription Version to the new Service Provider.
New Service Provider Create Time Stamp	T		The date and time that the New Service Provider authorized Transfer of Service of the Subscription Version.

19

Attribute Name	Type (Size)	Required	Description
Old Service Provider Authorization Time Stamp	T		The date and time that the old Service Provider authorized Transfer of Service for the Subscription Version.
Activation Request Time Stamp	T		The date and time that the Subscription Version activation request was made by the new Service Provider.
Activation Broadcast Date	T		The date and time that broadcasting began to all local SMS systems for the activation of the Subscription Version.
Activation Broadcast Complete Time Stamp	T		The date and time that all Local SMS systems successfully acknowledged activating the Subscription Version.
Disconnect Request Time Stamp	T		The date and time that the Subscription Version disconnect request was made by the local Service Provider.
Disconnect Broadcast Time Stamp	T		The date and time that broadcasting began to all local SMS systems for the disconnect of the Subscription Version.
Disconnect Broadcast Complete Time Stamp	T		The date and time that all Local SMS systems successfully acknowledged disconnecting the Subscription Version.
Effective Release Date	T		The date that the Subscription Version is to be disconnected from all Local SMS systems.
Customer Disconnect Date	T		The date that the Customer’s service was disconnected.
Pre-Cancellation Status	E		Status of the Subscription Version prior to cancellation. Valid

20

Attribute Name	Type (Size)	Required	Description
			enumerated values are: •      X - Conflict (0) •      P - Pending (2) •      CR - Conflict Resolution Pending (6) •      DP - Disconnect Pending (7)
Old Service Provider Cancellation Time Stamp	T		The date and time that the Old Service Provider acknowledged that the Subscription Version be canceled.
New Service Provider Cancellation Time Stamp	T		The date and time that the New Service Provider acknowledged that the Subscription Version be canceled.
Cancellation Time Stamp	T		The date and time that the Subscription Version became canceled.
Old Time Stamp	T		The date and time that the Subscription Version became old.
Conflict Time Stamp	T		The date and time that the Subscription Version was placed in conflict.
Conflict Resolution Pending Time Stamp	T		The data and time that the Subscription Version was placed in conflict resolution pending.
Old Service Provider Conflict Resolution Time Stamp	T		The date and time that the Old Service Provider acknowledged the resolution of a Subscription Version in conflict.

21

Attribute Name	Type (Size)	Required	Description
Stamp
New Service Provider Conflict Resolution Time Stamp	T		The date and time that the New Service Provider acknowledged the resolution of a Subscription Version in conflict.
Create Time Stamp	T		The date and time that this Subscription Version record was created.
Modified Time Stamp	T		The date and time that this Subscription Version record was last modified. The default value is the Create Time Stamp.
Porting to Original	B		A boolean that indicates whether the Subscription Version created is to be ported back to the original Service Provider. The default value is False.
End User Location Value	C (12)		For future use.
End User Location Value Type	C (2)		For future use.
Modify Request Timestamp	T		The date and time that the Subscription Version Modify request was made.
Modify Broadcast Timestamp	T		The date and time that broadcasting began to all local SMS systems for the modification of the Subscription Version.
Modify Broadcast Complete Timestamp	T		The date and time that all local SMS systems successfully acknowledged modifying the Subscription Version.
Billing ID	C (4)		For future use. The default value is the Facilities Based Service Provider ID.

Table 3-4

22

3.1.4   Network Data

The network data represents the attributes associated with network topology and routing data with respect to local number portability.  This information is used by the respective network elements to route ported numbers to the new termination points.  The data items that need to be administered by Network Data Administration functions are identified in tables 3-5 and 3-6:

PORTABLE NPA-NXX DATA MODEL

Attribute Name	Type (Size)	Required	Description
NPA-NXX Id	N	Ö	A unique sequential number assigned upon creation of the NPA-NXX record.
NPA-NXX	C (6)	Ö	The NPA-NXX open for porting.
NPAC Customer ID	C (4)		An alphanumeric code which uniquely identifies an NPAC customer.
NPA-NXX Effective Date	T	Ö	The date that the NPA-NXX is available for LNP in the NPAC Customer networks.
Split new NPA-NXX	C (6)		The new NPA-NXX for an NPA-NXX split.
Split Activation Date	T		The date that the new NPA-NXX becomes available for use in an NPA-NXX split. This date represents the

23

Attribute Name	Type (Size)	Required	Description
			beginning of the permissive dialing period.
Split Disconnect Date	T		The data that the old NPA-NXX becomes unavailable for use in an NPA-NXX split. This date represents the end of the permissive dialing period.
NPA-NXX has been Ported	B	Ö	A boolean that indicates if any TN within this NPA-NXX has been ported. The default value is false, indicating that no TN within this NPA-NXX has yet been ported.

Table 3-5

LRN DATA MODEL

Attribute Name	Type (Size)	Required	Description
LRN ID	N	Ö	A unique sequential number assigned upon creation of the LRN record.
LRN	TN	Ö	The LRN is the unique identifier for the switch on which the portable NPA-NXXs reside.
NPAC Customer ID	C (4)	Ö	An alphanumeric code which uniquely identifies an NPAC Customer.

Table 3-6

24

3.2   NPAC Personnel Functionality

The following requirements describe the functionality required by the NPAC/SMS to support the daily operation of the Regional LNP SMS support staff.  These requirements define the high level functionality required by the system with the specifics of each requirement defined in more detail in sections 4 and 5.

R3-l

DELETE

R3-2

DELETE

R3-3 Create NPA-NXX data for a Service Provider

NPAC SMS shall allow NPAC personnel to create a new LNP NPA-NXX for a Service Provider.

R3-4.1

(Duplicate - refer to R4-1)

R3-4.2

(Duplicate - refer to R4-3)

R3-5

(Duplicate - refer to R4-2)

R3-6 Administer mass changes for NPA splits, LRN changes, LIDB changes, CLASS, ISVM and CNAM

NPAC SMS shall allow NPAC personnel to perform NPA splits, LRN, LIDB, CLASS, ISVM and CNAM mass changes that affect multiple Subscription Versions, with version statuses of active, pending, conflict, conflict resolution pending, cancel pending, deferred disconnect or failed.

25

R3-7.1 Administer mass changes for one or more Subscription Versions

NPAC SMS shall allow NPAC personnel to select Subscription Versions which match a user defined TN and specify a mass update action to be applied against all Subscription Versions selected (except for Subscription Versions with a status of old, partial failure, sending, or canceled).

R3-7.2 Administer mass changes for one or more Subscription Versions for a TN range

NPAC SMS shall allow NPAC personnel to select Subscription Versions which match a TN range, and specify a mass update action to be applied against all Subscription Versions selected (except for Subscription Versions with a status of old, partial failure, sending, or canceled).

3.3   System Functionality

R3-8 Off-line batch updates for Local SMS Disaster Recovery

NPAC SMS shall support an off-line batch download (via 4mm DAT tape and FTP file download) to mass update Local SMSs with Subscription Versions and Service Provider Network data.

The contents of the batch download are:

•Subscriber data:

•      Version ID

•      TN

•      LRN

•      New Current Service Provider ID

•      Activation Request Timestamp

•      Version Status

•      CLASS DPC

•      CLASS SSN

•      LIDB DPC

•      LIDB SSN

•      ISVM DPC

•      ISVM SSN

•      CNAM DPC

•      CNAM SSN

•      End User Location - Value

•      End User Location - Type

26

•      Billing ID

•      LNP Type

•      Download Reason

•Network data

•NPAC Customer ID

•NPAC Customer name

•NPA-NXX-Download Data:

•NPA-NXX ID

•NPA-NXX Value

•NPAC Customer ID

•Effective TimeStamp

•Download Reason

•LRN-Download Data:

•LRN ID

•LRN Value

•Download Reason

R3-9 NPAC SMS download of network data to the Local SMS

NPAC SMS shall be able to communicate creation or deletion of NPA-NXX data and LRN data for a Service Provider to Local SMSs.

The contents of the network download are:

•Network data:

•NPAC Customer ID

•NPAC Customer Name

•NPA-NXX-Download Data:

•NPA-NXX ID

•NPA-NXX Value

•Effective TimeStamp

•Download Reason

•LRN-Download Data:

•LRN ID

•LRN Value

•Download Reason

R3-10 NPAC SMS notification of NPA-NXX availability to the Service Providers

NPAC SMS shall inform all Service Providers about the availability of the NPA-NXXs for porting via the NPAC SMS to Local SMS interface or the Web bulletin board.  The NPA-NXX data fields sent via the NPAC SMS to Local SMS interface are:

•NPAC Customer ID

27

•NPAC Customer Name

•NPA-NXX ID

•NPA -NXX Value

•Effective Date

•Download Reason

The NPA-NXX data fields sent to the WEB bulletin board are:

•NPAC Customer ID

•NPAC Customer Name

•NPA-NXX Value

•Effective Date

R3-11 NPAC SMS notification of LRN availability to the Service Providers

NPAC SMS shall inform all Service Providers about a new Service Provider and the associated LRNs. NPAC SMS shall post the new Service Providers and/or new LRNs on the Web bulletin board.  The Service Provider data fields sent to the WEB bulletin board are:

•NPAC Customer ID

•NPAC Customer Name

•NPAC Customer Type

•Contact Type

•Contact Name

•Contact Address 1

•Contact Address 2

•Contact City

•Contact State

•Contact Zip

•Contact Province

•Contact Country

•Contact Phone

•Contact Fax

•Contact Pager

•Contact Pager PIN

•Contact Email

The LRN data fields sent to the WEB Bulletin Board are:

28

•NPAC Customer ID

•NPAC Customer Name

•LRN Value

R3-12

(Duplicate - refer to R5-18)

R3-13 NPAC SMS mass change update capability to the Local SMS

NPAC SMS shall have the capability to identify all Subscription Versions affected by mass changes, (such as NPA splits), and automatically carry out the required updates to modified data in the Local SMSs.

3.4   Requirements Defined in the Proposal

RP3-1.1 Service Provider NPA-NXX Data  Addition

NPAC SMS shall allow Service Providers to add their NPA-NXX data via the NPAC SMS to Local SMS interface or the SOA to NPAC SMS interface.

RP3-1.2 Service Provider LRN Data Addition

NPAC SMS shall allow Service Providers to add their LRN data via the NPAC SMS to Local SMS interface or the SOA to NPAC SMS interface.

RP3-2

DELETE

RP3-3.1 Service Provider NPA-NXX Data Deletion

NPAC SMS shall allow Service Providers to delete their NPA- NXX data via the NPAC SMS to Local SMS interface or the SOA to NPAC SMS interface provided the changes do not cause any updates to the Subscription Versions.

RP3-3.2 Service Provider LRN Data Deletion

NPAC SMS shall allow Service Providers to delete their LRN data via the NPAC SMS to Local SMS interface or the SOA to NPAC SMS interface provided the changes do not cause any updates to the Subscription Versions.

29

3.5   Requirements Defined in Post-Award Activities

RN3-1 NPA Split Permissive Dialing

NPAC SMS shall support a permissive dialing period, during which dialing of both NPAs is allowed during NPA splits.

RN3-2 NPA split

NPAC SMS shall accept both the old and new NPAs during the permissive dialing period, but will only respond and download with the new NPA.

RN3-3 NPA Split Permissive Dialing Cleanup

NPAC SMS shall perform an update to remove NPAC SMS mapping and deactivate Subscription Versions associated with an NPA split after the expiration date of the permissive dialing period.

RR3-1 Service Provider Download Indicator

NPAC SMS shall provide a mechanism for the Service Provider to indicate whether or not they want NPA-NXX data and LRN data downloaded to their Local SMS via the NPAC SMS to Local SMS Interface.

RR3-2 Service Provider Download Indicator Default

NPAC SMS shall download NPA-NXX data and LRN data via the NPAC SMS to Local SMS Interface if the indicator is ON.

R3-14 Bulk Database Extracts

NPAC SMS shall periodically perform NPAC SMS database extracts of active Subscription Versions on an NPA-NXX basis to an ASCII file.

R3-15 FTP Site for Database Extracts

NPAC SMS shall store database extract files at the NPAC SMS FTP site for Local SMS file retrieval.

30

R3-16 Database Extract File Creation

NPAC SMS shall allow NPAC personnel to specify database extract file creation on a weekly, monthly, or quarterly basis.

R3-17 Scope of Database Extract File Creation

NPAC SMS shall allow NPAC personnel to specify an NPA-NXX for database extract file creation.

31

Service Provider Data Administration

4.   Service Provider Data Administration

4.1   Service Provider Data Administration and Management

Service Provider Data Administration functions allow NPAC personnel to receive and record data needed to identify authorized LNP Service Providers.  The Service Provider data indicates who the LNP Service Providers are and includes location, contact name, security, routing, and network interface information.

Service Provider Administration supports functionality to manage Service Provider data.  There can be only one instance of Service Provider data for a specific LNP Service Provider.

AR1-1 All NPAC Customers will obtain a unique Service Provider ID from a proper source.

4.1.1   User Functionality

R4-1 Create Service Providers

The NPAC SMS shall allow NPAC Personnel to add a Service Provider.

R4-2 Modify Service Providers

NPAC SMS shall allow modification of Service Provider data via the NPAC SMS to Local SMS interface or the SOA to NPAC SMS interface.  Service Providers can only modify their own data.

R4-3 Delete Service Providers

NPAC SMS shall allow NPAC personnel to delete a Service Provider.

1

R4-4 View of Service Provider Data

NPAC SMS shall allow NPAC personnel to view Service Provider data.

R4-5.1 View List of Service Provider Subscriptions

NPAC SMS shall allow NPAC personnel to view a list of Subscription Versions associated with the Service Provider.

R4-5.2 Authorized Service Providers View Their Own Data

NPAC SMS shall allow authorized Service Provider personnel to view their own Service Provider data via the SOA to NPAC SMS interface, the NPAC SMS to Local SMS interface, and the NPAC Operations GUI.

RP4-2 Authorized Service Providers Modify Their Own Data

NPAC SMS shall allow authorized Service Provider personnel to modify their own Service Provider data.

RR4-4 Broadcast NPAC Customer Names

NPAC SMS shall broadcast all additions, modifications, and deletions of NPAC Customer names via the NPAC SMS to Local SMS interface.

4.1.2   System Functionality

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

4.1.2.1   Service Provider Data Creation

NPAC personnel can request that Service Provider data be created in the NPAC SMS. The functionality described below enables a new instance of Service Provider data for a Service Provider to be created, provided that no other Service Provider data exists for the Service Provider.

2

R4-6 New Service Provider ID

NPAC SMS shall require the following to be entered to identify the Service Provider, when NPAC personnel are creating a new Service Provider:

Service Provider ID - the alphanumeric identifier of the Service Provider. This ID must be unique.

R4-7.1 Examine for Duplicate Service Provider ID

NPAC SMS shall check to see if there is an existing Service Provider with the same Service Provider ID.

R4-7.2 Error notification of Duplicate Service Provider

NPAC SMS shall inform the user that the Service Provider data already exists for the Service Provider, if it does exist, and that the new Service Provider data cannot be created.

R4-8 Service Provider Data Elements

NPAC SMS shall require the following data if there is no existing Service Provider data:

1.Service Provider name, address, phone number, and contact organization.

2.NPAC customer type.

3.Service Provider allowable functions.

4.Service Provider Network Address of NPAC SMS to Local SMS interface.

5.Service Provider Network Address of NPAC SMS to SOA interface.

6.Service Provider Security Contact. Contact data is security data when Contact Type is “SE.”

3

7.Service Provider Repair contact name and phone number. The default Service Provider Repair Contact and phone number shall be the same as the Service Provider contact and phone number, if the Service Provider Repair Contact information is left blank.

8.Service Provider billing name, address, phone number, and billing contact for NPAC SMS billing. The default for the Service Provider Billing data shall be the same as the Service Provider data, if the Service Provider Billing information is left blank.

9.Service Provider Download Indicator

10.Service Provider Maximum Query

The following data is optional:

1.Service Provider Contact Type: SOA Contact, Local SMS, Web, Network Communications, Conflict Resolution, Operations, and User Administration Contact Address Information.

R4-9 Service Provider data validation

NPAC SMS shall validate that all required Service Provider data has been received, after the Service Provider data has been collected.

R4-10 Notification of successful add for new Service Provider

NPAC SMS shall notify NPAC personnel upon successful creation of the new Service Provider.

R4-11 Failure notification of Service Provider creation

NPAC SMS shall issue an appropriate error message upon unsuccessful creation of the new Service Provider.

4

4.1.2.2   Service Provider Data Modification

NPAC personnel and the SOA to NPAC SMS interface and the NPAC to Local SMS interface can request that Service Provider data be modified in the NPAC SMS. The functionality described below enables the user to modify data for the Service Provider.

R4-12

(Duplicate - refer to R4-2)

R4-13 Service Provider Key selection for modifying Service Provider data

NPAC SMS shall require one of the following data items to identify the Service Provider data to be modified:

Service Provider ID

or

Service Provider Name

The Service Provider ID is required over the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.

R4-14 Error notification of invalid Service Provider ID or Name during Modify

NPAC SMS shall issue an appropriate error message to the user if the Service Provider data to be modified does not exist.

R4-15.1 Modify restrictions on Service Provider data - Service Providers

NPAC SMS shall allow Service Provider data to be modified or added to the Service Provider data with the exception of the data listed in Table 3-1.

R4-15.2 Modify restrictions on Service Provider data - NPAC Operations Personnel

NPAC SMS shall allow NPAC Operations personnel to modify the data in Table 3-1 with the exception of the NPAC Customer ID.

5

R4-16 Re-validation of Service Provider data after Modify

NPAC SMS shall revalidate that all required Service Provider data is present when a user attempts to submit modified Service Provider data.

R4-17 Modify Validation Error Message

NPAC SMS shall issue an appropriate error message to the user if the Service Provider data fails validation on a modify.

R4-18.1

DELETE

R4-18.2

DELETE

R4-18.3

DELETE

4.1.2.3   Delete Service Provider Data

NPAC personnel can request that the Service Provider data be deleted. Deleted Service Provider data will be written to a history file. The functionality described below enables a user to delete data for the Service Provider.

R4-19

(Duplicate - refer to R4-3)

R4-20 Service Provider key for delete

NPAC SMS shall require the Service Provider ID and/or Service Provider name from the user to identify the Service Provider data to be deleted.

R4-21 Error Message for Delete key search

NPAC SMS shall generate an error message and send it to the request originator, if the Service Provider data does not exist, or if is has already been deleted and exists only in a history file. NPAC SMS will not proceed further with the deletion request.

6

R4-22.1 No Subscription Versions during Service Provider Delete

NPAC SMS shall perform the deletion of the Service Provider data, notify the user that the deletion request was successful, if there are no affected Subscription Versions, and write the Service Provider data to a history file.

R4-22.2 Subscription during Service Provider Delete

NPAC SMS shall notify the user that the request to delete the Service Provider data cannot be completed until the affected individual Subscription Versions are modified, if affected Subscription Versions are found.

R4-22.3 Service Provider subscription restrictions during Network Data Delete.

NPAC SMS shall determine if there are any Subscription Versions being affected by the NPA-NXX and/or LRN data being deleted.

4.1.3   Service Provider Queries

The query functionality discussed in this section will give users the ability to view Service Provider and Subscription data. A user may not be able to modify a particular data item because they do not have the proper security permissions, therefore the data is made available via NPAC SMS for read-only purposes.

4.1.3.1   User Functionality

R4-23

(Duplicate - refer to R4-5.2)

R4-24.1 Display of Service Provider ID and related subscription data

NPAC SMS shall allow NPAC personnel to view all Subscription Versions associated with a Service Provider ID and/or Service Provider Name.

R4-24.2 Display of LRN and related subscription data

NPAC SMS shall allow NPAC personnel to view all Subscription Versions associated with an LRN.

7

R4-24.3 Display of NPA-NXX and related subscription data

NPAC SMS shall allow NPAC personnel to view all Subscription Versions associated with an NPA-NXX.

4.1.3.2   System Functionality

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

4.1.3.2.1   Service Provider Query

R4-25 Service Provider as Key for queries

NPAC SMS shall require the Service Provider ID and/or the Service Provider Name for queries regarding Service Provider data.

R4-26.1 Error message for unknown Service Provider during a query

NPAC SMS shall provide the request originator with a message indicating that there was no data in the NPAC SMS that matched the search keys for a Service Provider query, if no match was found.

R4-26.2 Results returned to Service Provider during a query

NPAC SMS shall return all Service Provider data associated with the Service Provider ID and/or Service Provider Name, as listed in Tables 3-1, 3-2, and 3-3, if the Service Provider data matches the query criteria.  Service Providers are only allowed to query their own data.

R4-27 Service Provider Query Types

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

8

R4-28 Service Provider Information Message during query

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

4.1.3.2.2   Subscription List Query

R4-29 Service Provider subscription query options

NPAC SMS shall receive the attributes to be searched on for queries regarding Subscription Versions associated with the Service Provider. Allowable attributes are the following data elements from the Subscriber Data Table (Table 3-4):

•Subscription Version ID

•Subscription Version Status

•Local Number Portability Type

•Ported Telephone Number

•Old facilities-based Service Provider Due Date

•New facilities-based Service Provider ID

•Authorization from old facilities-based Service Provider

•Local Routing Number (LRN)

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•Billing Service Provider ID

•End User Location Value

•End User Location Type

•Customer Disconnect Date

•Effective Release Date

9

•Disconnect Broadcast Complete Time Stamp

•Conflict Time Stamp

•Activation Time Stamp

•Cancellation Time Stamp

•New Service Provider Creation Time Stamp

•Old Service Provider Authorization Time Stamp

•Pre-cancellation Status

•Old Service Provider Cancellation Time Stamp

•New Service Provider Cancellation Time Stamp

•Old Time Stamp

•Old Service Provider Conflict Resolution Pending Time Stamp

•New Service Provider Conflict Resolution Pending Time Stamp

•Create Time Stamp

•Modify Time Stamp

•Porting To Original

R4-30.1 Service Provider subscription query

NPAC SMS shall return all active Subscription Versions associated with the Service Provider which satisfy the selection criteria, up to a tunable parameter number of Subscription Versions for queries initiated via the NPAC SMS to Local SMS interface.

R4-30.2 NPAC SMS shall return all Subscription Versions

NPAC SMS shall return all Subscription Versions regardless of Subscription Version status for queries initiated via the NPAC Operations GUI.

R4-30.3

DELETE

R4-30.4

DELETE

10

R4-30.5

DELETE

R4-30.6 Count of subscription information during a query

NPAC SMS shall return an “out of range” error and the count of subscription records returned by a query, if more than a tunable parameter number of Subscription Versions are found.

R4-30.7

DELETE

R4-30.8 Error Message for Service Provider subscription query

NPAC SMS shall provide the request originator with a message indicating that there was no data in NPAC SMS that matched the search keys, if NPAC SMS does not have Subscription Versions as specified by the request originator.

4.2   Requirements Defined in the Proposal

RN4-1 Service Provider Network Data Addition/Deletion

NPAC SMS shall allow Service Providers to add/delete the NPA-NXX and/or LRN data via the NPAC SMS to Local SMS interface and SOA to NPAC SMS interface provided the changes do not cause mass updates to the Subscription Versions.

4.3   Requirements Defined in Post-Award Activities

RR4-1 Removal of Service Provider with Respect to LRNs

NPAC SMS shall allow removal of a Service Provider by NPAC personnel only if all associated LRNs are removed, and no Subscription Versions are associated with the LRN.

11

RR4-2 Removal of Service Provider with Respect to NPA-NXXs

NPAC SMS shall allow removal of a Service Provider by NPAC personnel only if all associated NPA-NXXs are removed, and no Subscription Versions are associated with the NPA-NXX.

RR4-3 Removal of NPA-NXX

NPAC SMS shall allow removal of an NPA-NXX by NPAC personnel only if no Subscription Versions are associated with the NPA-NXX.

12

Subscription Management

5.   Subscription Management

5.1   Subscription Version Management

Subscription Management functions allow NPAC personnel and SOA to NPAC SMS interface 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 service providers via an interface (i.e., the SOA to NPAC SMS interface) from their operations systems to the NPAC SMS and will also be accessible to (and performed by) NPAC personnel.

Subscription Management supports functionality to manage multiple versions of subscription data. See Section 5.1.1, Subscription Version Management for more details on the different states of a version.

RN5-1 Subscription Version Status - Only One Per Subscription

NPAC SMS shall allow only one pending, sending, cancel pending, conflict, conflict resolution pending, disconnect pending, failed or partial failure Subscription Version per subscription.

RN5-2 Subscription Version Status - Only One Active Version

NPAC SMS shall allow only one active Subscription Version per subscription.

RN5-3 Subscription Version Status - Multiple Old/Canceled

NPAC SMS shall allow multiple old and/or canceled Subscription Versions per subscription.

1

5.1.1   Subscription Version Management

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

At any given time, a Subscription Version in the SMS can have one of several statuses (e.g., active, old) and may change status depending on results of different SMS processes (e.g., modification, activation). This section describes the different statuses that a version can have and the SMS processes that can change the status. This section also discusses functionality and data that is needed for Subscription Management.

5.1.1.1   Version Status

[Graphic Omitted:  Version Status state diagram]

Figure 5-1  Version Status

1.Conflict to Canceled

A.NPAC SMS Internal

NPAC SMS automatically sets a Subscription Version in conflict directly to canceled after it has been in conflict for a tunable number of days.

2.     Conflict to Cancel Pending

A.NPAC Operations GUI - NPAC Personnel

User cancels a Subscription Version in conflict.

B. SOA to NPAC SMS Interface

User sends a cancellation request for a Subscription Version with a status of conflict.

3.     Cancel Pending to Conflict

A.NPAC Operations GUI - NPAC Personnel

User sets a Subscription Version with a status of cancel pending to conflict.

B.NPAC SMS Internal

NPAC SMS automatically sets a Subscription Version with a status of cancel pending to conflict if cancel pending acknowledgment has not been received from the old and/or new Service Provider within a tunable timeframe.

2

4.     Conflict Resolution Pending to Cancel Pending

A.NPAC Operations GUI - NPAC Personnel

User cancels a Subscription Version with a status of conflict resolution pending.

B.SOA to NPAC SMS Interface

User sends a cancellation request for a Subscription Version with a status of conflict resolution pending.

5.     Conflict to Conflict Resolution Pending

A.NPAC Operations GUI - NPAC Personnel

User sets a Subscription Version with a status of conflict to conflict resolution pending.

B.SOA to NPAC SMS Interface - New Service Provider

New Service Provider sends a conflict resolution pending request for a Subscription Version with a status of conflict.

C.SOA to NPAC SMS Interface - Old Service Provider

Old Service Provider sends a Subscription Version modification request for a Subscription Version with a status of conflict, which provides the old Service Provider’s authorization for the transfer of service.

6.     Conflict Resolution Pending to Conflict

A.NPAC Operations GUI - NPAC Personnel

User sets a Subscription Version with a status of conflict resolution pending to conflict.

B.NPAC SMS Internal

NPAC SMS automatically sets a Subscription Version with a status of conflict resolution pending to conflict after conflict resolution pending acknowledgment has not been received from old and/or new Service Provider within a tunable timeframe.

C.SOA to NPAC SMS Interface - Old Service Provider

Old Service Provider sends a Subscription Version modification request for a Subscription Version with a status of conflict resolution pending, which revokes the old Service Provider’s authorization for transfer of service.

7.     Pending to Conflict

A.NPAC Operations GUI - NPAC Personnel

1.User sets a Subscription Version with a status of pending to conflict.

3

2.User creates a Subscription Version for an existing pending Subscription Version for the old Service Provider and does not provide authorization for the transfer of service.

B.NPAC SMS Internal

NPAC SMS automatically sets a pending Subscription Version to conflict after authorization for transfer of service has not been received from the old Service Provider within a tunable timeframe.

C.SOA to NPAC SMS Interface - Old Service Provider

1.Old Service Provider sends a Subscription Version creation request for a Subscription Version with a status of pending, which revokes the old Service Provider’s authorization for transfer of service.

2.If the current Service Provider sends an immediate Subscription Version Disconnect request, a pending Subscription Version exists, and the old Service Provider has not authorized transfer of service for the pending Subscription Version, the pending Subscription Version is set to conflict.

8.     Conflict Resolution Pending to Pending

A.NPAC SMS Internal

NPAC SMS automatically sets a conflict resolution pending Subscription Version to pending after receiving conflict resolution pending acknowledgment from the old and new Service Provider.

9.     Pending to Cancel Pending

A.NPAC Operations GUI - NPAC Personnel

User cancels a Subscription Version with a status of pending.

B.SOA to NPAC SMS Interface

User sends a cancellation request for a Subscription Version with a status of pending.

C.NPAC SMS Internal

1.NPAC SMS automatically sets a pending Subscription Version to cancel pending after authorization for the transfer of service has not been received from the new Service Provider within a tunable timeframe.

2.NPAC SMS automatically sets a pending Subscription Version to cancel pending if an activation request is not received a tunable amount of time after the most current of the two due dates: either new Service Provider due date or old Service Provider due date.

10.   Cancel Pending to Canceled

A.NPAC SMS Internal

4

NPAC SMS automatically sets a cancel pending Subscription Version to canceled after receiving cancel pending acknowledgment from the old and new Service Provider.

11.   Creation - Set to Conflict

A.NPAC Operations GUI - NPAC Personnel

User creates a Subscription Version for the old Service Provider and does not provide authorization for the transfer of service.

B.SOA to NPAC SMS Interface - Old Service Provider

User sends an old Service Provider Subscription Version creation request and does not provide authorization for the transfer of service.

12.   Creation - Set to Pending

A.NPAC Operations GUI - NPAC Personnel

User creates a Subscription Version for either the new or old Service Provider. If the create is for the old Service Provider and authorization for the transfer of service is not provided, refer to step 11-A.

B.SOA to NPAC SMS Interface

User sends a Subscription Version creation request for either the new or old Service Provider. If the create is for the old Service Provider, and authorization for the transfer of service is not provided, refer to step 11-B.

13.   Disconnect Pending to Cancel Pending

A.NPAC Operations GUI - NPAC Personnel

User cancels a Subscription Version with a disconnect pending status.

B.SOA to NPAC SMS Interface - New Service Provider

User sends a cancellation request for a disconnect pending Subscription Version.

14.   Disconnect Pending to Sending

A.NPAC SMS Internal

1.NPAC SMS automatically sets a deferred disconnect pending Subscription Version to sending after the effective release date is reached.

15.   Pending to Sending

A.NPAC Operations GUI - NPAC Personnel

User activates a pending Subscription Version.

B.SOA to NPAC SMS Interface - New Service Provider

User sends an activation message for a pending Subscription Version.

16.   Sending to Failed

5

A.NPAC SMS Internal

NPAC SMS automatically sets a Subscription Version from sending to failed after all Local SMSs fail Subscription Version activation or disconnect after the tunable retry period expires.

17.   Failed to Sending

A.NPAC Operations GUI - NPAC Personnel

User re-sends a failed Subscription Version.

18.   Partial Failure to Sending

A.NPAC Operations GUI - NPAC Personnel

User re-sends a partial failure Subscription Version.

19.   Sending to Partial Failure

A.NPAC SMS Internal

NPAC SMS automatically sets a Subscription Version from sending to partial failure after one or more, but not all, of the Local SMSs fail the Subscription Version activation or disconnect after the tunable retry period expires.

20.   Sending to Old

A.NPAC SMS Internal

NPAC SMS automatically sets a sending Subscription Version to old after a disconnect or “porting to original” port to all Local SMSs successfully completes.

21.   Sending to Active

A.NPAC SMS Internal

NPAC SMS automatically sets a sending Subscription Version to active after the Subscription Version activation is successful in all of the Local SMSs.

B.NPAC SMS Internal

NPAC SMS automatically sets a sending Subscription Version to active after the Subscription Version modification is successfully broadcast to any of the Local SMSs.

22.   Active to Old

A.NPAC SMS Internal

NPAC SMS automatically sets the previously active Subscription Version to old once a Subscription Version activation, modification, or disconnect is successful in Local SMSs.

23.   Immediate Disconnect to Sending

6

A.NPAC Operations GUI - NPAC Personnel

User disconnects an active Subscription Version and does not supply an effective release date.

B.    SOA to NPAC SMS Interface - Current Service Provider

User sends a disconnect request for an active Subscription Version and does not supply an effective release date.

24.   Deferred Disconnect - Set to Disconnect Pending

A.NPAC Operations GUI - NPAC Personnel

User disconnects an active Subscription Version and supplies an effective release date.

B.    SOA to NPAC SMS Interface - Current Service Provider

User sends a disconnect request for an active Subscription Version and supplies an effective release date.

25.   Modify Active to Sending

A.NPAC Operations GUI - NPAC Personnel

User modifies an active Subscription Version.

B.    SOA to NPAC SMS Interface - Current Service Provider

User sends a modification request for an active Subscription Version.

R5-1.1 Subscription Version Statuses

NPAC SMS Subscription Version instances shall at any given time have one of the following statuses:

•Active - Version is currently active in the network.

Note: There may be another pre- active version in the system that will eventually supersede this version. Examples: 1) Pending version for the active subscription exists 2) Sending version for the active subscription exists.

•Canceled - A pending, conflict, conflict resolution pending, or disconnect pending version was canceled prior to activation in the network.

•Cancel Pending - Version is awaiting cancellation acknowledgment from both Service Providers, at which time the version will be set to canceled.

•Conflict - Version is in conflict (i.e., a dispute exists between the two Service Providers), awaiting resolution.

7

•Conflict Resolution Pending - Conflict has been resolved and the version is awaiting conflict resolution acknowledgment from both Service Providers, at which time the version will be set to pending.

•Disconnect Pending - Version is awaiting the effective release date, at which time the version will be set to sending and the disconnect request will be sent to all Local SMSs.

•Failed - Version failed activation, modification, or disconnect in ALL of the Local SMSs in the network.

•Old - Version was previously active in the network and was either superseded by either another active version or was disconnected.

•Partial Failure - Version failed activation, modification, or disconnect in one or more, but not all, Local SMSs in the network.

•Pending - Version is either pending activation (approval had been received from both Service Providers) or pending creation/approval from one or the other Service Provider.

•Sending - Version is currently being sent to all of the Local SMSs in the network.

R5-1.2

(Duplicate - refer to R5-20.3)

(Duplicate - refer to R5-30.2

(Duplicate - refer to R5-53)

(Duplicate - refer to R5-54

(Moved - refer to R5-54.2)

R5-2.1 Old Subscription Retention - Tunable Parameter

NPAC SMS shall provide an Old Subscription Retentiontunable parameter which is defined as the length of time that old Subscription Versions shall be retained and accessible through a query request.

R5-2.2 Old Subscription Retention - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify theOld Subscription Retentiontunable.

8

R5-2.3 Old Subscription Retention - Tunable Parameter Default

NPAC SMS shall default the Old Subscription Retentiontunable parameter to 18 months.

R5-3.1 Cancel-Pending Subscription Retention - Tunable Parameter

NPAC SMS shall provide a Cancel-Pending Subscription Retention tunable parameter which is defined as the length of time that canceled Subscription Versions with a pre-cancellation status of pending shall be retained and accessible through a query request.

R5-3.2 Cancel-Pending Subscription Retention - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Cancel-Pending Subscription Retention tunable parameter.

R5-3.3 Cancel-Pending Subscription Retention - Tunable Parameter Default

NPAC SMS shall default the Cancel-Pending Subscription Retention tunable parameter to 90 days.

R5-3.4 Cancel-Conflict Subscription Retention - Tunable Parameter

NPAC SMS shall provide a Cancel-Conflict Subscription Retention tunable parameter which is defined as the length of time that canceled Subscription Versions with a pre-cancellation status of conflict shall be retained and accessible through a query request.

R5-3.5 Cancel-Conflict Subscription Retention - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Cancel-Conflict Subscription Retention tunable parameter.

R5-3.6 Cancel-Conflict Subscription Retention - Tunable Parameter Default

NPAC SMS shall default the Cancel-Conflict Subscription Retention tunable parameter to 30 days.

R5-3.7 Cancel-Conflict Resolution Pending Retention - Tunable Parameter

NPAC SMS shall provide a Cancel-Conflict Resolution Pending Retention tunable parameter, which is defined as the length of time that canceled Subscription Versions with a pre-cancellation status of conflictresolutionpending shall be retained and accessible through a query request.

9

R5-3.8 Cancel-Conflict Resolution Pending Retention - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Cancel-Conflict Resolution Pending Retention tunable parameter.

R5-3.9 Cancel-Conflict Resolution Pending Retention - Tunable Parameter Default

NPAC SMS shall default the Cancel-Conflict Resolution Pending Retention tunable parameter to 30 days.

R5-3.10 Cancel-Disconnect Pending Retention - Tunable Parameter

NPAC SMS shall provide a Cancel-Disconnect Pending Retention tunable parameter which is defined as the length of time that canceled Subscription Versions with a pre-cancellation status of disconnect pending shall be retained and accessible through a query request.

R5-3.11 Cancel-Disconnect Pending Retention - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Cancel-Disconnect Pending Retention tunable parameter.

R5-3.12 Cancel-Disconnect Pending Retention - Tunable Parameter Default

NPAC SMS shall default the Cancel-Disconnect Pending Retention tunable parameter to 90 days.

RR5-1.1 Pending Subscription Retention - Tunable Parameter

NPAC SMS shall provide a Pending Subscription Retention tunable parameter, which is defined as the length of time that a pending Subscription Version shall remain in the system prior to cancellation.

RR5-1.2 Pending Subscription Retention - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Pending Subscription Retention tunable parameter.

RR5-1.3 Pending Subscription Retention - Tunable Parameter Default

NPAC SMS shall default the Pending Subscription Retention tunable parameter to 90 days.

RR5-1.4 Pending Subscription Retention - Tunable Parameter Expiration

NPAC SMS shall cancel a Subscription Version via the cancel pending process after a pending Subscription Version has existed in the system for a Pending Subscription Retention number of days subsequent to the later of the two due dates, old Service Provider Due Date or new Service Provider Due Date.

10

R5-4

(Duplicate - Refer to RN5-1)

R5-5 Subscription Versions Creation for TN Ranges

NPAC SMS shall create individual Subscription Versions when a Subscription Version creation request is received for a TN range.

R5-6 Subscription Administration Transaction Logging

NPAC SMS shall log all subscription administration transactions. The log entries shall include:

•Activity Type: create, modify, activate, query, all status types, and all acknowledgments.

•Service Provider ID

•Initial Version Status

•New Version Status

•Userid and/or Login

•Local Number Portability Type

•Date

•Time

•Ported Telephone Number

•Status Flag - successful or failed

•Subscription Version ID (when assigned)

5.1.2   Subscription Administration Requirements

5.1.2.1   User Functionality

Authorized users can invoke the following functionality in the NPAC SMS to administer subscription data:

R5-7 Creating a Subscription Version

NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to create a Subscription Version.

11

R5-8.1 Modifying a Subscription Version

NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to modify a Subscription Version.

R5-8.2

(Duplicate - refer to R5-25)

R5-9 Activating a Subscription version

NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to activate a Subscription Version.

RN5-9

DELETE

R5-10.1 Setting a Subscription Version to Conflict

NPAC SMS shall allow NPAC personnel to set a Subscription Version to conflict or conflict resolution pending.

R5-10.2 Subscription Version Conflict Status Rule

NPAC SMS shall prohibit a Subscription Version in conflict from being activated.

R5-11 Disconnecting a Subscription Version

NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to disconnect a Subscription Version.

R5-12 Canceling a Subscription Version

NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to cancel a Subscription Version.

R5-13 Querying a Subscription Version

NPAC SMS shall allow NPAC personnel, Local SMS/ SOA to NPAC SMS interface to query for a Subscription Version.

12

5.1.2.2   System Functionality

This section describes NPAC SMS functionality required to support NPAC personnel and SOA to NPAC SMS interface user requests defined in the above section.

Additionally, NPAC SMS functionality will perform operations which are not invoked by a direct user request. Some examples of this are: monitor a Subscription Version to determine whether the old and the new facilities-based Service Providers have authorized the transfer of service for a ported number, issue appropriate notifications to Service Providers, and change the status of a Subscription Version based on tunable parameters.

5.1.2.2.1   Subscription Version Creation

This section provides the requirements for the Subscription Version Create functionality, which is executed upon the user requesting to create a Subscription Version.

5.1.2.2.1.1   Subscription Version Creation - Inter-Service Provider and Porting to Original Ports

This section provides the Subscription Version Creation requirements for performing an Inter-Service Provider or a “porting to original” port of a TN. These two type of ports are specified in the same section because of the similarities of their functions.

An Inter-Service Provider port of a TN is the porting of a TN to a new Service Provider.

A “porting to original port” implies that all porting data will be removed from the Local SMSs and the TN will revert to the default routing, which ultimately results in the TN returning to the original “donor” Service Provider.

The primary differences in functionality between these two types of ports is that for a “porting to original” port, the routing data is not supplied and upon activation, a delete request is broadcast to the Local SMSs instead of a create request.

Both port types require authorization for the transfer of service from the old and new Service Providers.

13

RR5-3 Activate Subscription Version - Notify NPA-NXX First Usage Upon Concurrence

NPAC SMS shall notify all Local SMSs of an NPA-NXX being used for the first time immediately after creation validation of the Subscription Version activation.

R5-14 Create Subscription Version - Old Service Provider Input Data

NPAC SMS shall require the following data from the NPAC personnel or old Service Provider upon Subscription Version creation for an Inter-Service Provider or “porting to original” port:

•Local Number Portability Type -Port Type.

•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 Subscription Versions 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 initially planned to occur.

•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.

•Authorization from old facilities-based Service Provider - indication that the transfer of service is authorized by the ported-from Service Provider.

R5-15.1 Create “Inter-Service Provider Port” Subscription Version - New Service Provider Input Data

NPAC SMS shall require the following data from NPAC personnel or the new Service Provider upon Subscription Version creation for an Inter-Service Provider Port:

•Local Number Portability Type - Port Type.  This field must be set to “LSPP” for Inter-Service Provider ports.

•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 Subscription Versions that share the same attributes.

14

•Due Date - date on which transfer of service from old facilities-based Service Provider to new facilities-based Service Provider is initially planned to occur.

•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.

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•Porting to Original - flag indicating whether or not this is a “porting to original” port.  This flag must be set to “FALSE” for an inter-Service Provider port.

R5-15.2 Create “porting to original” Subscription Version - New Service Provider Input Data

NPAC SMS shall require the following data from NPAC personnel or the new Service Provider upon Subscription Version creation for a “porting to original” port:

•Local Number Portability Type - Port Type.  This field must be set to “LSPP” for “porting to original” ports.

•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 Subscription Versions 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 initially planned to occur.

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

15

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

•Porting to original - flag indicating whether or not this is a “porting to original” port.  This flag must be set to “TRUE” for “porting to original” port.

R5-16 Create Subscription Version - New Service Provider Optional input data

NPAC SMS shall accept the following optional fields from NPAC personnel or the new Service Provider upon Subscription Version creation for an Inter-Service Provider port:

•Billing Service Provider ID

•End-User Location - Value

•End-User Location - Type

R5-17.1

(Duplicate - Refer to R5-18.7 and R5-20.1)

R5-17.2

(Duplicate - Refer to R5-18.8 and R5-20.1)

R5-18.1 Create Subscription Version - Field-level Data Validation

NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-4 upon Subscription Version creation for an Inter-Service Provider or “porting to original” port:

•LNP Type

•Ported TN(s)

•Old Service Provider Due Date

•New Service Provider Due Date

•Old Service Provider ID

•New Service Provider ID

•Authorization from old facilities-based Service Provider

16

•LRN

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•Porting to Original

•Billing Service Provider ID

•End-User Location - Value

•End-User Location - Type

R5-18.2 Create Subscription Version - Due Date Consistency Validation

NPAC SMS shall verify the old and new Service Provider due dates are the same upon Subscription Version creation for an Inter-Service Provider or ‘porting to original” port.

R5-18.3 Create Subscription Version - Due Date Validation

NPAC SMS shall verify that the due date is the current or a future date upon Subscription Version creation for an Inter-Service Provider or “porting to original” port.

R5-18.4 Create Subscription Version - Ported TN NPA-NXX  Validation

NPAC SMS shall verify that the NPA-NXX to be ported exists as a ported TN in the NPAC SMS system upon Subscription Version creation for an Inter-Service Provider or “porting to original” port.

R5-18.5 Create Subscription Version - Service Provider ID Validation

NPAC SMS shall verify that the old and new Service Provider IDs exist in the NPAC SMS system upon Subscription Version creation for an Inter-Service Provider or “porting to original” port.

17

R5-18.6 Create Subscription Version - LRN Validation

NPAC SMS shall verify that an input LRN is associated with the new Service Provider in the NPAC SMS system upon Subscription Version creation for an Inter-Service Provider port.

R5-18.7 Create Subscription Version - Originating Service Provider Validation

NPAC SMS shall verify that the originating user is identified as the new or old Service Provider on the incoming Subscription Version upon Subscription Version creation for an Inter-Service Provider or “porting to original” port.

R5-18.8 Create Subscription Version - Duplicate Authorization Validation

NPAC SMS shall verify that authorization for transfer of service for a given Service Provider does not already exist when a Service Provider creates a Subscription Version for an Inter-Service Provider or “porting to original” port.

R5-18.9 Create Subscription Version - Service Provider ID Validation

NPAC SMS shall verify that the incoming New and Old Service Provider IDs match the IDs in the current pending version, if one exists, upon Subscription Version creation for an Inter-Service Provider or “porting to original” port.

R5-19 Create Subscription Version - Old Service Provider ID Validation

NPAC SMS shall verify that the old Service Provider ID on the version being created is equal to the new Service Provider ID on the active Subscription Version, if an active version exists upon Subscription Version creation for an Inter-Service Provider or “porting to original” port.

R5-20.1 Create Subscription Version - Validation Failure  Notification

NPAC SMS shall send an appropriate error message to the originating NPAC personnel or SOA to NPAC SMS interface user if any of the validations fail upon Subscription Version creation for an Inter-Service Provider or “porting to original” port.

18

R5-20.2 Create Subscription Version - Validation Failure - No Update

NPAC SMS shall not apply the incoming data to an existing subscription if any of the validations fail upon Subscription Version creation for an Inter-Service Provider or “porting to original” port.

R5-20.3 Create Subscription Version - Validation Failure - No Create

NPAC SMS shall not create a new Subscription Version, if a version does not exist, if any of the validations fail upon Subscription Version creation for an Inter-Service Provider or “porting to original” port.

R5-20.4 Create Subscription Version - Validation Success - Update Existing

NPAC SMS shall apply the incoming data to an existing Subscription Version if all validations pass upon Subscription Version creation for an Inter-Service Provider or “porting to original” port.

R5-20.5 Create Subscription Version - Validation Success - Create New

NPAC SMS shall create a new Subscription Version, if a version does not already exist, if all validations pass at the time of Subscription Version creation for an Inter-Service Provider or “porting to original” port.

R5-21.1 Initial Concurrence Window - Tunable Parameter

NPAC SMS shall provide an Initial Concurrence Windowtunable parameter which is defined as the number of hours subsequent to the time the Subscription Version was initially created by which both Service Providers are expected to authorize transfer of service if this is an Inter-Service Provider or “porting to original” port.

R5-21.2 Initial Concurrence Window - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Initial Concurrence Windowdate tunable parameter.

R5-21.3 Initial Concurrence Window - Tunable Parameter Default

NPAC SMS shall default the Initial Concurrence Windowdate tunable parameter to 18 hours.

19

R5-21.4

(Duplicate - Refer to R5-21.1)

R5-21.5

(Duplicate - Refer to R5-21.1)

R5-21.6 Create Subscription Version - Set to Pending

NPAC SMS shall set a Subscription Version to pending upon successful subscription creation and the Old Service Provider has authorized transfer of service if this is an Old Service Provider create request for an Inter-Service Provider or “porting to original” port.

R5-21.7 Create Subscription Version - Notify User Success

NPAC SMS shall notify the old and new Service Providers when a Subscription Version is set to pending upon successful subscription creation for an Inter-Service Provider or “porting to original” port.

RR5-2.1 Create Subscription Version - Set to Conflict

NPAC SMS shall set a Subscription Version directly to conflict if the Subscription Version passed validations, but this is a create request from the Old Service Provider and the Old Service Provider did not authorize transfer of service for an Inter-Service Provider or “porting to original” port.

RR5-2.2 Create Subscription Version - Set Conflict Timestamp

NPAC SMS shall set the conflict timestamp to the current time when a Subscription Version is set to conflict at the time of subscription version creation for an Inter-Service Provider or “porting to original” port.

RR5-2.3 Create Subscription Version - Conflict Notification

NPAC SMS shall notify the Old and New Service Provider when a Subscription Version is set to conflict at the time of Subscription Version creation for an Inter-Service Provider or “porting to original” port.

20

R5-22 Create Subscription Version - Initial Concurrence Window Tunable Parameter Expiration

NPAC SMS shall send a notification to the Service Provider (old or new) who has not yet authorized the transfer of service, when the Initial Concurrence Window tunable parameter for a pending Subscription Version has expired.

R5-23.1 Final Concurrence Window - Tunable Parameter

NPAC SMS shall provide a Final Concurrence Windowtunable parameter which is defined as the number of hours after the concurrence request is sent by the NPAC SMS by which time both Service Providers are expected to authorize transfer of subscription service for an Inter-Service Provider or “porting to original” port.

R5-23.2 Final Concurrence Window Tunable - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Final Concurrence Windowtunable parameter.

R5-23.3 Final Concurrence Window Tunable - Tunable Parameter Default

NPAC SMS shall default the Final Concurrence Windowtunable parameter to 18 hours.

R5-23.4 New Service Provider Fails to Authorize Transfer of Service

NPAC SMS shall cancel a Subscription Version, according to the cancel processing when the Final ConcurrenceWindow tunable parameterexpires anda new Service Provider has not sent authorization for the transfer of service.

R5-23.5 Old Service Provider Fails to Authorize Transfer of Service

NPAC SMS shall place a Subscription Version in conflict, according to the cancel processing when the time associated with the Final Concurrence Window tunable parameter has expired andan old Service Provider has not sent authorization for the transfer of service.

5.1.2.2.1.2   Subscription Version Creation - Intra-Service Provider Port

This section provides the Subscription Version Creation requirements for performing an Intra-Service Provider port of a TN. An Intra-Service Provider port of a TN is when a TN is ported to a new location within the current Service Provider network (i.e., the routing data is modified, but the Service Provider remains the same).

21

RR5-4 Create “Intra-Service Provider Port” Subscription Version - Current Service Provider Input Data

NPAC SMS shall require the following data from the NPAC personnel or the Current (New) Service Provider at the time of Subscription Version Creation for an Intra-Service Provider port:

•LNP Type - port type This field must be set to “LISP for Intra-Service Provider support.

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

•Due Date - date on which Intra-Service Provider port is planned to occur.

•New facilities-based Service Provider ID - current Service Provider within which the Intra-Service Provider port will occur.

•Old facilities-based Service Provider ID - current Service Provider within which the Intra-Service Provider port will occur.

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

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

RR5-5 Create “Intra-Service Provider Port” Subscription Version - Current Service Provider Optional Input Data

NPAC SMS shall accept the following optional fields from the NPAC personnel or the Current Service Provider upon a Subscription Version Creation for an Intra-Service Provider port:

•Billing Service Provider ID

•End-User Location - Value

•End-User Location - Type

22

RR5-6.1 Create “Intra-Service Provider Port” Subscription Version - Field-level Data Validation

NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-4 upon Subscription Version creation for an Intra-Service Provider port:

•LNP Type

•Ported TN(s)

•Current Service Provider Due Date

•Old Service Provider ID

•New Service Provider ID

•LRN

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•Billing Service Provider ID

•End-User Location - Value

•End-User Location - Type

RR5-6.2 Create “Intra-Service Provider Port” Subscription Version - New and Old Service Provider ID Match

NPAC SMS shall validate that the new and old Service Provider IDs are identical to the ID of the requesting user at the time of Subscription Version creation for an Intra-Service Provider port.

23

RR5-6.3 Create “Intra-Service Provider Port” Subscription Version - Due Date Validation

NPAC SMS shall verify that the input due date is the current or a future due date upon Subscription Version creation for an Intra-Service Provider port.

RR5-6.4 Create “Intra-Service Provider Port” Subscription Version - Ported TN NPA-NXX Validation

NPAC SMS shall verify that the NPA-NXX for the TN to be ported exists as a ported TN in the NPAC SMS system upon Subscription Version creation for an Intra-Service Provider port.

RR5-6.5 Create “Intra-Service Provider Port” Subscription Version - LRN Validation

NPAC SMS shall verify that the LRN is associated with the new Service Provider in the NPAC SMS system upon Subscription Version creation for an Intra-Service Provider port.

RR5-6.6 Create “Intra-Service Provider Port” Subscription Version - Duplicate Authorization Validation

NPAC SMS shall verify that the authorization for transfer of service for a given Service Provider does not already exist when a Service Provider creates a Subscription Version for an Intra-Service Provider port.

RR5-6.7 Create “Intra-Service Provider Port” Subscription Version - Old Service Provider ID Validation

NPAC SMS shall verify that the old Service Provider ID on the version being created is equal to the new Service Provider ID on the active Subscription Version, if an active version exists, upon Subscription Version creation for an Intra-Service Provider port.

RR5-6.8 Create “Intra-Service Provider Port” Subscription Version - Active Version Exists

NPAC SMS shall validate that an active version exists at the time of Subscription Version creation for an Intra-Service Provider port.

RR5-7.1 Create “Intra-Service Provider Port” Subscription Version - Validation Failure Notification

NPAC SMS shall send an appropriate error message to the originating NPAC personnel or SOA to NPAC SMS Interface if any of the validations fail at the time of Subscription Version creation for an Intra-Service Provider port.

24

RR5-7.2 Create “Intra-Service Provider Port” Subscription version - Validation Failure - No Create

NPAC SMS shall not create a new Subscription Version if any of the validations fail at the time of Subscription Version creation for an Intra-Service Provider port.

RR5-8 Create “Intra-Service Provider Port” Subscription version - Set to Pending

NPAC SMS shall set a Subscription Version to pending upon successful creation of a Subscription Version for an Intra-Service Provider port.

RR5-9 Create “Intra-Service Provider Port” Subscription version - Notify User of Creation

NPAC SMS shall notify the current Service Provider when a Subscription Version is set to pending upon a successful creation of a Subscription Version for an Intra-Service Provider port.

5.1.2.2.2   Subscription Version Modification

This section provides the requirements for the Subscription Version Modification functionality, which is executed upon the user requesting modify Subscription Version.

5.1.2.2.2.1   Modification of a Pending, Conflict, or Conflict Resolution Pending Subscription Version

R5-24.1

(Duplicate - refer to R5-27 and R5-28

R5-24.2

(Duplicate - refer to R5-27 and R5-28

R5-24.3

(Duplicate - refer to R5-27 and R5-28

R5-25 Modify Subscription Version - Invalid Version Status Notification

NPAC SMS shall return an error to the originating NPAC personnel or SOA to NPAC SMS interface user if the version status is sending, failed, partial failure,

25

canceled, cancel pending, old or disconnect pending upon Subscription Version modification.

R5-26 Modify Subscription Version - Version Identification

NPAC SMS shall receive the following data from the originating NPAC personnel or SOA to NPAC SMS interface user to identify a pending, conflict, or conflict resolution pending Subscription Version to be modified:

Ported Telephone Number and status or

Subscription Version ID

R5-27.1 Modify Subscription Version - New Service Provider Data Values

NPAC SMS shall allow the following data to be modified in a pending, conflict, or conflict resolution pending Subscription Version for an Inter-Service Provider or Intra-Service Provider port by the new/current Service Provider or NPAC personnel:

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

•Due Date - date on which transfer of service from old facilities-based Service Provider to new facilities-based Service Provider is planned to occur.

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

R5-27.2 Modify “porting to original” Subscription Version - New Service Provider Data Values

NPAC SMS shall allow the following data to be modified in a pending, conflict, or conflict resolution pending Subscription Version for a “porting to original” port by the new Service Provider or NPAC personnel:

26

•Due Date - New Service Provider date on which “port to original” is planned to occur.

R5-27.3 Modify Subscription Version - Old Service Provider Data Values

NPAC SMS shall allow the following data to be modified in a pending, conflict, or conflict resolution pending Subscription Version for an Inter-Service Provider or “porting to original” port by the old Service Provider or NPAC personnel:

•Due Date - date on which transfer of service from old facilities-based Service Provider to new Service Provider is planned to occur.

•Old Service Provider Authorization

R5-28 Modify Subscription Version - New Service Provider Optional input data.

NPAC SMS shall accept the following optional fields from the NPAC personnel or the new Service Provider upon modification of a pending, conflict, or conflict resolution pending Subscription version:

•Billing Service Provider ID

•End-User Location - Value

•End-User Location - Type

R5-29.1 Modify Subscription Version - Field-level Data Validation

NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-4 upon Subscription Version modification.

•LNP Type

•Ported TN(s)

•Old Service Provider Due Date

•New Service Provider Due Date

•Old Service Provider Authorization

•Old Service Provider ID

•New Service Provider ID

27

•LRN

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•Billing Service Provider ID

•End-User Location - Value

•End-User Location - Type

R5-29.2 Modify Subscription Version - Due Date Validation

NPAC SMS shall verify that an input due date is the current or future due date upon Subscription Version modification.

R5-29.3 Modify Subscription Version - LRN Validation

NPAC SMS shall verify that an input LRN is associated with the new Service Provider in the NPAC SMS system upon Subscription Version modification.

R5-29.4 Modify Subscription Version - Originating Service Provider Validation

NPAC SMS shall verify that the originating user is identified as the new or old Service Provider on the current Subscription Version, if one exists, upon Subscription Version modification.

R5-30.1 Modify Subscription Version - Validation Failure Notification

NPAC SMS shall send an error message to the originating user if the modified pending, conflict, or conflict resolution pending Subscription Version fails validations.

28

R5-30.2 Modify Subscription Version - Validation Error Processing

NPAC SMS shall leave the original version intact upon validation failure of a modified pending, conflict, or conflict resolution pending Subscription Version.

R5-31.1

DELETE

R5-31.2 Modify Subscription Version - Retain Status

NPAC SMS shall retain the original status of pending, conflict, or conflict resolution pending upon successful Subscription Version modification and the Old Service Provider has not revoked authorization for the transfer of service if this is an Old Service Provider Subscription Version modification request.

R5-31.3 Modify Subscription Version - Successful Modification Notification

NPAC SMS shall send an appropriate message to the old and new Service Providers upon successful modification of a Subscription Version.

R5-32

(Duplicate - refer to R5-31.3)

RR5-10.1 Modify Subscription Version - Set to Conflict

NPAC SMS shall set a Subscription Version directly to conflict if the Subscription Version passed validations, but this is a modification request from the Old Service Provider and the Old Service Provider revoked authorization for the transfer of service.

RR5-10.2 Modify Subscription Version - Set Conflict Timestamp

NPAC SMS shall set the conflict timestamp to the current time when a Subscription Version is set to conflict upon Subscription Version modification.

RR5-10.3 Modify Subscription Version - Conflict Notification

NPAC SMS shall notify the Old and New Service Provider when a Subscription Version is set to conflict upon Subscription Version modification.

29

RR5-10.4 Modify Subscription Version - Set to Conflict Resolution Pending

NPAC SMS shall set a Subscription Version directly to Conflict Resolution Pending if the Subscription Version passes validations, the current Subscription Version is set to Conflict, this is a Subscription Version modification request from the old Service Provider, and the old Service Provider has now provided authorization for the transfer of service.

RR5-10.5 Modify Subscription Version - Conflict Resolution Pending Processing

NPAC SMS shall execute the Conflict Resolution Pending process when a Subscription Version is set to Conflict Resolution Pending upon a Subscription Version modification request.

5.1.2.2.2.2   Modification of an Active Subscription Version

R5-33

(Duplicate - refer to R5-35 and R5-36)

RR5-11 Modify Active Subscription Version - Service Provider Owned

NPAC SMS shall allow only NPAC personnel and the current Service Provider to modify their own active Subscription Versions.

R5-34 Modify Active Subscription Version - Create New Subscription Version with Status of  Sending

NPAC SMS shall create a new Subscription Version with a status of sending upon successful modification of an active Subscription Version.

R5-35 Modify Active Subscription Version - Version Identification

NPAC SMS shall require the following data from NPAC personnel or SOA to NPAC SMS interface users to identify the active Subscription Version to be modified:

Ported Telephone Numbers and status of Active or

Subscription Version ID

30

R5-36 Modify Active Subscription Version - Input Data

NPAC SMS shall allow the following data to be modified for an active Subscription Version:

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

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

R5-37 Active Subscription Version - New Service Provider Optional  input data.

NPAC SMS shall accept the following optional fields from the new Service Provider or NPAC personnel for an active Subscription Version to be modified:

•Billing Service Provider ID

•End-User Location - Value

•End-User Location - Type

R5-38.1 Modify Active Subscription Version - Field-level Data Validation

NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-4 upon Subscription Version modification of an active version:

•LRN

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

31

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•Billing Service Provider ID

•End-User Location - Value

•End-User Location - Type

R5-38.2 Modify Active Subscription Version - LRN Validation

NPAC SMS shall verify that an input LRN is associated with the new Service Provider in the NPAC SMS system upon Subscription Version modification of an active version.

R5-39.1 Modify Active Subscription Version - Validation Failure Notification

NPAC SMS shall send an appropriate error message to the originating user if the modified active Subscription Version fails validations.

R5-39.2 Modify Active Subscription Version - Validation Error Processing

NPAC SMS shall leave the original version intact upon validation failure of a modified active Subscription Version.

R5-40.1 Modify Active Subscription Version - Broadcast Date/Time Stamp

NPAC SMS shall record the current date and time as the broadcast date and time stamp upon successful revalidation of the modified active Subscription Version.

R5-40.2

(Duplicate - refer to R5-34)

R5-40.3 Modify Active Subscription Version - Modification Success User Notification

NPAC SMS shall notify the originating user indicating successful modification of an active Subscription Version.

32

R5-41 Activation Of A Modified Subscription Version

NPAC SMS shall proceed with the activation process immediately upon successful modification of an active Subscription Version.

5.1.2.2.3 Subscription Version Conflict

This section provides the requirements for the functionality to place a Subscription Version in to conflict and remove it from conflict.

5.1.2.2.3.1 Placing a Subscription Version in Conflict

R5-42 Conflict Subscription Version - Version Identification

NPAC SMS shall require the following data from NPAC personnel to identify the Subscription Version to be placed in conflict:

Ported Telephone Number or

Subscription Version ID

R5-43 Conflict Subscription Version - Invalid Status Notification

NPAC SMS shall send an error message to the NPAC personnel if the version status is not pending, cancel pending, or conflict resolution pending upon attempting to set the Subscription Version to conflict.

RN5-11

(Duplicate - Refer to R5-42 and R5-43)

R5-44.1 Conflict Subscription Version - Set Status to Conflict

NPAC SMS shall, upon placing a Subscription Version into conflict, set the version status to conflict.

R5-44.2 Conflict Subscription Version - Set Conflict Date and Time

NPAC SMS shall, upon placing a Subscription Version into conflict, record the current date and time as the conflict date and time stamp.

33

R5-44.3 Conflict Subscription Version - Successful Completion Message

NPAC SMS shall issue an appropriate message to the originating user and the Old and New Service Providers indicating successful completion of the process to place a subscription in conflict.

R5-45.1 Conflict Expiration Window - Tunable Parameter

NPAC SMS shall provide a Conflict Expiration Windowtunable parameter which is defined as a number of days a Subscription Version will remain in conflict prior to cancellation.

R5-45.2 Conflict Expiration Window - Tunable Parameter Default

NPAC SMS shall default the Conflict Expiration Windowtunable parameter to 30 days.

R5-45.3 Conflict Expiration Window - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administration to modify the Conflict Expiration Windowtunable parameter.

R5-45.4 Conflict Subscription Version - Set to Cancel

NPAC SMS shall set the status of the Subscription Version to cancel after a Subscription Version has been in conflict for a Conflict Expiration Windowtunable parameter number of days.

R5-45.5 Conflict Subscription Version - Set Cancellation Date Timestamp

NPAC SMS shall set a Subscription Version cancellation date timestamp to the current time upon setting a conflict Subscription Version to cancel.

R5-45.6 Conflict Subscription Version - Inform Service Providers of Cancel Status

NPAC SMS shall notify both Service Providers after a Subscription Version status is set to cancel from conflict.

5.1.2.2.3.2 Removing a Subscription Version from Conflict

34

R5-46 Conflict Resolution Pending Subscription Version - Version Identification

NPAC SMS shall require the following data from the NPAC personnel user or new Service Provider to identify the Subscription Version to be set to conflict resolution pending:

Ported Telephone Number or

Subscription Version ID

R5-47 Conflict Resolution Pending Subscription Version - Invalid Status Notification

NPAC SMS shall send an error message to the originating user if the Subscription Version status is not in conflict upon attempting to set the Subscription Version to conflict resolution pending.

R5-48

DELETE

R5-49.1

DELETE

R5-49.2

DELETE

R5-50.1 Conflict Resolution Pending Subscription Version - Set Status

NPAC SMS shall set the version status to conflict resolution pending if the Subscription Version is in conflict upon a request to set a Subscription Version to conflict resolution pending.

R5-50.2 Conflict Resolution Pending Subscription Version - Status Message

NPAC SMS shall send an appropriate message to the originating user indicating successful completion of the process to set a subscription to conflict resolution pending.

35

RR5-12.1 Conflict Resolution Pending Subscription Version - Inform Both Service Providers of Conflict Resolution Pending Status

NPAC SMS shall inform both Service Providers when the status of a Subscription Version is set to conflict resolution pending for an Inter-Service Provider or “porting to original” port.

RR5-12.2 Conflict Resolution Pending Subscription Version - Inform Current Service Provider of Conflict Resolution Pending Status

NPAC SMS shall inform the current Service Provider when the status of a Subscription Version is set to conflict resolution pending for an Intra-Service Provider port.

RR5-13.1 Conflict Resolution Pending Acknowledgment - Update Old Service Provider Conflict Resolution Date and Time Stamp

NPAC SMS shall update the old Service Provider conflict resolution date and time stamp with the current date and time when conflict resolution pending acknowledgment is received from the old Service Provider.

RR5-13.2 Conflict Resolution Pending Acknowledgment - Set Old Authorization Flag

NPAC SMS shall restore the old Service Provider Authorization flag to its value prior to entering conflict when conflict resolution pending acknowledgment is received from the old Service Provider.

RR5-14 Conflict Resolution Pending Acknowledgment - Update New Service Provider Conflict Resolution Pending Date and Time Stamp

NPAC SMS shall update the new Service Provider conflict resolution pending date and time stamp with the current date and time when conflict resolution pending acknowledgment is received from the new Service Provider.

RR5-15.1 Conflict Resolution Pending Acknowledgment - Complete, Set Pending - Both Service Providers

NPAC SMS shall set the Subscription Version status to pending when both Service Providers have acknowledged the conflict resolution pending message for a given Inter-Service Provider or “porting to original” Subscription Version.

36

RR5-15.2 Conflict Resolution Pending Acknowledgment - Complete, Set Pending - Current Service Provider

NPAC SMS shall set the Subscription Version status to pending when the current Service Provider has acknowledged the conflict resolution pending message for a given Intra-Service Provider Subscription Version.

RR5-16.1 Conflict Resolution Pending Acknowledgment - Complete, Notification - Both Service Providers

NPAC SMS shall notify the old and new Service Providers when a Subscription Version is set to pending after both Service Providers have acknowledged the conflict resolution pending message for an Inter-Service Provider or “porting to original” port.

RR5-16.2 Conflict Resolution Pending Acknowledgment - Complete, Notification - Current Service Provider

NPAC SMS shall notify the current Service Provider when a Subscription Version is set to pending after the current Service Provider has acknowledged the conflict resolution pending message for an Intra-Service Provider port.

RR5-17.1 Conflict Resolution-Initial Concurrence Window - Tunable Parameter

NPAC SMS shall provide a Conflict Resolution-Initial Concurrence Windowtunable parameter which is defined as the number of hours after the version is set to Conflict Resolution Pending by which both Service Providers are expected to acknowledge the conflict resolution.

RR5-17.2 Conflict Resolution-Initial Concurrence Window - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Conflict Resolution-Initial Concurrence Windowtunable parameter.

RR5-17.3 Conflict Resolution-Initial Concurrence Window - Tunable Parameter Default

NPAC SMS shall default theConflict Resolution-Initial Concurrence Windowtunable parameter to 4 hours.

37

RR5-17.4 Conflict Resolution-Initial Concurrence Window - Tunable Parameter Expiration

NPAC SMS shall send a notification to the Service Provider (new or old) who has not yet acknowledged the conflict resolution pending status when the Conflict Resolution-Initial Concurrence Window tunable parameter expires.

RR5-18.1 Conflict Resolution-Final Concurrence Window - Tunable Parameter

NPAC SMS shall provide a Conflict Resolution-Final Concurrence Windowtunable parameter which is defined as the number of hours after the second conflict resolution pending notification is sent, by which time both Service Providers are expected to acknowledge the conflict resolution.

RR5-18.2 Conflict Resolution-Final Concurrence Window - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Conflict Resolution-Final Concurrence Windowtunable parameter.

RR5-18.3 Conflict Resolution-Final Concurrence Window - Tunable Parameter Default

NPAC SMS shall default the Conflict Resolution-Final Concurrence Windowtunable parameter to 4 hours.

RR5-19 Conflict Resolution-Final Concurrence Window - Tunable Parameter Expiration

NPAC SMS shall set the Subscription Version status to conflict when the NPAC SMS has not received the conflict resolution pending acknowledgment either from the old and/or the new Service Providers and the Conflict Resolution-Final Concurrence Windowtunable parameter expires.

RR5-20 Conflict Resolution-Final Concurrence Window - Tunable Parameter Expiration Notification

NPAC SMS shall notify the old and new Service Providers upon setting a Subscription Version to conflict after the NPAC SMS has not received the conflict resolution pending acknowledgment from both Service Providers and the Conflict Resolution-Final Concurrence Windowtunable parameterexpires.

5.1.2.2.4 Subscription Version Activation

This section provides the requirements for the Subscription Version Activation functionality, which is executed upon the NPAC personnel or SOA to NPAC SMS interface user requesting to activate a Subscription Version.

38

R5-51.1 Activate Subscription Version - Version Identification

NPAC SMS shall require the following data from the NPAC personnel or new service provider to identify the Subscription Version to be activated:

Ported Telephone Number or

Subscription Version ID

RR5-21 Activate “porting to original” Subscription Version

NPAC SMS shall proceed with the “immediate” disconnect processing when a “porting to original” Subscription Version is activated.

RR5-22 Activate Subscription Version - Set Activation Received Timestamp

NPAC SMS shall set the Activation Received timestamp to the current date and time upon receiving a Subscription Version activation request.

R5-51.2 Activate Subscription Version - Date and Time Stamp

NPAC SMS shall record the current date and time as the Activation Date and Time Stamp, after all Local SMSs have successfully acknowledged activating the new Subscription Version.

R5-52 Activate Subscription Version - Invalid Status Notification

NPAC SMS shall send an error message to the originating user if the version status is not pending upon Subscription Version activation.

R5-53.1 Activate Subscription Version - Validation

NPAC SMS verify that a Subscription Version is in a valid pending state by checking that a new Service Provider time stamp exists, and that the old Service Provider authorization is TRUE.

R5-53.2 Activate Subscription Version Validation Error Message

NPAC SMS shall send an error message to the originating user if the Subscription validation fails.

39

R5-54.1

DELETE

R5-54.2

DELETE

R5-55 Activate Subscription Version - Local SMS Identification

NPAC SMS shall determine which Local SMSs to send the Subscription Version to by identifying all Local SMS that are accepting Subscription Version data downloads.

R5-56

(Duplicate - refer to R5-57.1

R5-57.1 Activate Subscription Version - Send to Local SMSs

NPAC SMS shall send the activated Subscription Version for an activated Inter or Intra-Service Provider port via the NPAC SMS to Local SMS Interface to the Local SMSs.

R5-57.2 Activate Subscription Version - Set to Sending

NPAC SMS shall set the subscription status to sending upon sending the activated Subscription Version to the Local SMSs.

R5-57.3 Activate Subscription Version - Date and Time Stamp

NPAC SMS shall record the current date and time as the broadcast date and time stamp upon sending the activated subscription to the Local SMSs.

R5-58.1 Local SMS Activation message logging

NPAC SMS shall log the activation responses resulting from the activation requests sent to the Local SMSs.

R5-58.2 Local SMS Activation Log Retention Period - Tunable Parameter

NPAC SMS shall provide a Local SMS Activation Log Retention Period tunable parameter which is defined as the number of days Local SMS activation responses will remain in the log.

40

R5-58.3 Local SMS Activation Log Retention Period - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify theLocal SMS Activation Log Retention Period tunable parameter.

R5-58.4 Local SMS Activation Log Retention Period - Tunable Parameter Default

NPAC SMS shall default the Local SMS Activation Log Retention Period tunable parameter to 90 days.

R5-58.5 Local SMS Activation Message Log - Viewing

NPAC SMS shall allow NPAC personnel to view the Local SMS Activation Message log.

R5-59.1 Activate Subscription Version - Set Status of Current to Active

NPAC SMS shall, upon receiving successful activation acknowledgment from all involved Local SMSs, set the sending Subscription Version status to active.

R5-59.2 Activate Subscription Version - Set Status of Previous to Old

NPAC SMS shall upon receiving successful activation acknowledgment from all involved Local SMSs, set the previous active Subscription Version status to old.

R5-60.1 Subscription Activation Retry Attempts - Tunable Parameter

NPAC SMS shall provide a Subscription Activation Retry Attemptstunable parameter which defines the number of times a new Subscription Version will be sent to a Local SMS which has not acknowledged receipt of the activation request.

R5-60.2 Subscription Activation Retry Interval - Tunable Parameter

NPAC SMS shall provide a Subscription Activation Retry Intervaltunable parameter, which defines the delay between sending new Subscription Versions to a Local SMS that has not acknowledged receipt of the activation request.

41

R5-60.3 Subscription Activation Retry Attempts - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Subscription Activation Retry Attemptstunable parameter.

R5-60.4 Subscription Activation Retry Interval - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Subscription Activation Retry Intervaltunable parameter.

R5-60.5 Subscription Activation Retry Attempts - Tunable Parameter Default

NPAC SMS shall default the Subscription Activation Retry Attemptstunable parameter to 3 times.

R5-60.6 Subscription Activation Retry Interval - Tunable Parameter Default

NPAC SMS shall default the Subscription Activation Retry Intervaltunable parameter to 2 minutes.

R5-60.7 Subscription Version Activation Failure Retry

NPAC SMS shall resend the activated Subscription Version a Subscription Activation Retry Attemptstunable parameter number of times to a Local SMS that has not acknowledged the receipt of the activation request once the Subscription Activation Retry Intervaltunable parameter expires.

R5-60.8 Subscription Version Activation Failure - After Retries

NPAC SMS shall consider the Subscription Version activation for a given Local SMS failed once the applicable Activation Retry tunable parameter number of retries has been exhausted for that Local SMS.

R5-60.9 Subscription Version Activation Failure - Status Sending

NPAC SMS shall retain the status for the Subscription Version being activated as sending until the Subscription Version retry period expires for all Local SMSs, or until all Local SMSs have acknowledged the activation.

R5-60.10 Subscription Version Activation Failure - Local SMS Identification

NPAC SMS shall notify the NPAC SMS Administrator of all Local SMSs where new activation failed, once each Local SMS has successfully responded or failed to respond during the activation retry period.

42

R5-60.11 Subscription Version Activation Failure - Set Status to Partial Failure

NPAC SMS shall set the Subscription Version status to partial failure if the activation failed in one or more, but not all, of the Local SMSs.

R5-60.12 Subscription Version Partial Activation Failure - Set Status of Previous to Old

NPAC SMS shall set the status of a previous active version to old when a Subscription Version activation succeeds for at least one of the Local SMSs.

R5-61.1 Subscription Version Activation Subscription Version - Set Status to Failure

NPAC SMS shall set the status of the Subscription Version to failed if the Subscription Version fails activation in allthe Local SMSs to which itwas sent.

R5-61.2 Subscription Version Activation Subscription Version - Failure Notification

NPAC SMS shall notify the NPAC System Administrator when a Subscription Version fails activation at all of the Local SMSs.

R5-61.3 Subscription Version Activation - Resend to Failed Local SMSs

NPAC SMS shall provide NPAC SMS personnel with the functionality to re-send activate Subscription Version requests to all failed Local SMSs.

RR5-22.1 Subscription Version Activation - Failed Local SMS Notification - Both Service Providers

NPAC SMS shall send a list to the Old and New Service Providers of all Local SMSs that failed activation when a Subscription Version is set to failed or partial failure subsequent to Subscription Version activation for an Inter-Service Provider or “porting to original” port.

RR5-22.2 Subscription Version Activation - Failed Local SMS Notification - Current Service Provider

NPAC SMS shall send a list to the current Service Provider of all Local SMSs that failed activation when a Subscription Version is set to failed or partial failure subsequent to Subscription Version activation for an Intra-Service Provider port.

43

5.1.2.2.5 Subscription Version Disconnect

This section provides the requirements for the Subscription Version Disconnect functionality, which is executed upon the NPAC personnel or SOA to NPAC SMS interface user requesting to have a Subscription Version disconnected.

R5-62 Disconnect Subscription Version - Version Identification

NPAC SMS shall receive the following data from the NPAC personnel or current Service Provider to identify an active Subscription Version to be disconnected:

Ported Telephone Numbers or

Subscription Version ID

RR5-23.1 Disconnect Subscription Version - Required Input Data

NPAC SMS shall require the following input data upon a Subscription Version disconnect:

•Customer Disconnect Date - Date upon which the customer’s service is disconnected.

RR5-23.2 Disconnect Subscription Version - Optional Input Data

NPAC SMS shall accept the following optional input data upon a Subscription Version disconnect:

•Effective Release Date - Future date upon which the disconnect should be broadcast to all Local SMSs.

RN5-10 Disconnect Subscription Version - Invocation by Current Service Provider

NPAC SMS shall allow only NPAC personnel or the Current Service Provider to invoke the functionality to disconnect a Subscription Version.

R5-63 Disconnect Subscription Version - Invalid Status Notification

NPAC SMS shall send an appropriate error message to the originating user that the Subscription Version is not active in the network and cannot be disconnected or set to disconnect pending if there is no Subscription Version with a status of active.

44

R5-64.1 Disconnect Subscription Version - Cancel Other Version Notification

NPAC SMS shall notify the originating user that the active Subscription Version cannot be disconnected until a failed, cancel pending, conflict, or conflict resolution pending Subscription Version is canceled, if such a Subscription Version exists.

R5-64.2 Disconnect Subscription Version - Wait for Other Version to Complete Notification

NPAC SMS shall notify the originating user that the active Subscription Version cannot be disconnected until a sending Subscription Version successfully completes or a failed or partial failure Subscription Version is re-sent and successfully completes.

R5-64.3 Disconnect Subscription Version - Disallow Immediate Disconnect with Pending Subscription Version

NPAC SMS shall disallow an immediate disconnect request if a pending Subscription Version exists and the old Service Provider has authorized for transfer of service for the pending Subscription Version.

R5-64.4 Disconnect Subscription Version - Disallow Deferred Disconnect with Pending Subscription Version

NPAC SMS shall disallow a deferred disconnect request if a pending Subscription Version exists.

R5-64.5 Disconnect Subscription Version - Allow Immediate Disconnect with Pending Subscription Version

NPAC SMS shall allow an immediate disconnect request to proceed if a pending Subscription Version exists and the old Service Provider has not authorized for transfer of service for the pending Subscription Version.

R5-64.6 Disconnect Subscription Version - Immediate Disconnect - Set Pending Subscription Version to Conflict

NPAC SMS shall set a pending Subscription Version to conflict upon allowing an immediate disconnect request to proceed.

R5-64.7 Disconnect Subscription Version - Send Denied Disconnect Request Message to Originating User

NPAC SMS shall send a denied disconnect request message to the originating user when a disconnect request is disallowed.

45

RR5-24 Disconnect Subscription Version -Set to Disconnect Pending

NPAC SMS shall set the status of a Subscription Version to disconnect pending upon a Subscription Version disconnect request when an effective release date is specified.

RR5-25.1 Disconnect Subscription Version - Disconnect Pending Status Notification

NPAC SMS shall inform the current Service Provider when the status of a Subscription Version is set to Disconnect Pending.

RR5-25.2 Disconnect Subscription Version - Customer Disconnect Date Notification

NPAC SMS shall notify the new Service Provider (donor) of the Subscription Version Customer Disconnect Date and Effective Release Date immediately prior to broadcasting a Subscription Version disconnect.

R5-65.1 Disconnect Subscription Version -Immediate Broadcast

NPAC SMS shall immediately proceed with the broadcasting of the disconnect after the Customer Disconnect Date notification is sent if no Effective Release Date was specified with the request.

R5-65.2 Disconnect Subscription Version - Deferred Broadcast

NPAC SMS shall proceed with the broadcasting of the disconnect when the specified Effective Release Date is reached if an Effective Release Date was specified with the request.

R5-65.3

DELETE

R5-65.4 Disconnect Subscription Version - Broadcast Interface Message to Local SMSs

NPAC SMS shall broadcast the disconnect Subscription Version message to the Local SMSs via the NPAC SMS to Local SMS Interface.

R5-65.5 Disconnect Subscription Version - Disconnect Broadcast Date and Time Stamp

NPAC SMS shall record the current date and time as the disconnect broadcast date and time stamp upon sending of disconnect messages to the Local SMSs.

46

R5-65.6 Disconnect Subscription Version - Set to Sending

NPAC SMS shall set a Subscription Version status to sending upon sending the disconnect messages to the Local SMSs.

R5-66.1 Disconnect Subscription Version Complete - Set Active to Old

NPAC SMS shall set the active Subscription Version status to old upon a successful disconnect in all Local SMSs.

R5-66.2 Disconnect Subscription Version Complete - Set Disconnect Broadcast Complete Date

NPAC SMS shall set the Disconnect Broadcast Complete timestamp to the current date in the previously active, now old, Subscription Version upon a successful disconnect in all Local SMSs.

R5-66.3 Disconnect Subscription Version Complete - Set Disconnect to Old

NPAC SMS shall set the sending disconnect Subscription Version to old upon a successful disconnect in all Local SMSs.

R5-67.1 Disconnect Subscription Version - Set Status to Failed

NPAC SMS shall set the status of the disconnect Subscription Version to failed if the disconnect fails in allthe Local SMSs to which itwas sent.

R5-67.2 Disconnect Pending Subscription Version - Failure Notification

NPAC SMS shall notify the NPAC SMS System Administrator when a disconnect Subscription Version fails in all of the Local SMSs.

R5-67.3 Disconnect Subscription Version - Resend Disconnect Requests to All Local SMSs

NPAC SMS shall provide authorized NPAC SMS personnel with the functionality to resend all failed disconnect requests to the Local SMSs.

R5-68.1 Disconnect Subscription Version - Subscription Disconnect Retry Attempts - Tunable Parameter

NPAC SMS shall allow the NPAC SMS Administrator to modify the Subscription Disconnect Retry Attemptstunable parameter, which is defined as the number of

47

times the NPAC SMS will resend a disconnect message to an unresponsive Local SMS.

R5-68.2 Disconnect Pending Subscription Version - Subscription Disconnect Retry Attempts - Tunable Parameter Default

NPAC SMS shall default the Subscription Disconnect Retry Attemptstunable parameter to 3 times.

R5-68.3 Disconnect Subscription Version - Subscription Disconnect Retry Interval - Tunable Parameter

NPAC SMS shall allow the NPAC SMS Administrator to modify the Subscription Disconnect Retry Intervaltunable parameter, which is defined as the amount of time that shall elapse between disconnect retries.

R5-68.4 Disconnect Subscription Version - Subscription Disconnect Retry Interval - Tunable Parameter Default

NPAC SMS shall default the Subscription Disconnect Retry Intervaltunable parameter to 2 minutes.

R5-68.5 Disconnect Subscription Version - Retry Processing

NPAC SMS shall resend a Subscription Version disconnect message a Subscription Disconnect Retry Attemptstunable parameter number of times to a Local SMS that has not acknowledged the receipt of a disconnect once the Subscription Disconnect Retry Intervaltunable parameter expires.

R5-68.6 Disconnect Subscription Version - Sending Status during Retries

NPAC SMS shall retain the status for the Subscription Version being disconnected as sending until the Subscription Disconnect Retry Attemptstunable parameterperiod expires for all Local SMSs, or until all Local SMSs have acknowledged the disconnect.

R5-68.7 Disconnect Subscription Version - Retry Failed

NPAC SMS shall consider the disconnect Subscription Version request to have failed at a specific Local SMS after the Subscription Disconnect Retry Attempts tunable parameter count for the specific Local SMS has been exhausted.

48

R5-68.8 Disconnect Subscription Version - Failure Notification after Retries Complete

NPAC SMS shall send a list of the Local SMSs where the disconnect request failed to the NPAC SMS System Administrator after every local SMS has either succeeded or failed with the disconnect.

R5-68.9 Disconnect Subscription Version - Set to Partial Failure

NPAC SMS shall set the disconnect Subscription Version status to partial fail if the disconnect request failed at one or more, but not all, of the Local SMSs.

R5-68.10 Disconnect Subscription Version - Resend Disconnect Requests to Failed Local SMSs

NPAC SMS shall provide authorized NPAC SMS personnel with the functionality to resend disconnect requests to all Local SMSs that failed to register the disconnect request.

5.1.2.2.6 Subscription Version Cancellation

This section provides the requirements for the Subscription Version Cancellation functionality, which is executed upon the NPAC personnel or SOA to NPAC SMS interface user requesting to cancel a Subscription Version.

RR5-26.1 Cancel Subscription Version - Inform Both Service Providers of Cancel Pending Status

NPAC SMS shall inform both old and new Service Providers when the status of a Subscription Version is set to cancel pending for an Inter-Service Provider or “porting to original” port.

RR5-26.2 Cancel Subscription Version - Inform Current Service Provider of Cancel Pending Status

NPAC SMS shall inform the current Service Provider when the status of a Subscription Version is set to cancel pending for an Intra-Service Provider port.

R5-69 Cancel Subscription Version - Version Identification

NPAC SMS shall receive the following data from the NPAC personnel to identify a Subscription Version to be canceled:

Ported Telephone Number or

49

Subscription Version ID

R5-70 Cancel Subscription Version - Invalid Status Notification

NPAC SMS shall send an appropriate error message to the originating user if the status is not pending, conflict, conflict resolution pending, or disconnect pending.

RR5-27 Cancel Subscription Version - Validate Service Provider

NPAC SMS shall send an appropriate error message to the originating user if the originating user is neither the New nor the Old Service Provider in the existing Subscription Version upon Subscription Version cancellation.

R5-71.1 Cancel Subscription Version - Set to Canceled.

(Superseded - refer to RR5-28.)

R5-71.2 Cancel Subscription Version - Set Cancellation Date and Time Stamp

NPAC SMS shall set the Subscription Version cancellation date and time to current upon setting the Subscription Version status to canceled.

RR5-28.1 Cancel Subscription Version - Set to Cancel After Both Service Providers Acknowledge

NPAC SMS shall set the Subscription Version status to cancel upon receiving cancellation pending acknowledgment from both Service Providers for an Inter-Service Provider or “porting to original” port.

RR5-28.2 Cancel Subscription Version - Set to Cancel After Current Service Provider Acknowledges

NPAC SMS shall set the Subscription Version status to cancel upon receiving cancellation pending acknowledgment from the current Service Provider for an Intra-Service Provider port.

RR5-29.1 Cancel Subscription Version - Inform Both Service Providers of Cancel Status

NPAC SMS shall notify both old and new Service Providers after a Subscription Version’s status is set to canceled for an Inter-Service Provider or “porting to original” port.

50

RR5-29.2 Cancel Subscription Version - Inform Current Service Provider of Cancel Status

NPAC SMS shall notify the current Service Provider after a Subscription Version’s status is set to canceled for an Intra-Service Provider port.

RR5-30 Cancel Subscription Version Acknowledgment - Update Old Service Provider Date and Time Stamp

NPAC SMS shall update the old Service Provider cancellation date and time stamp with the current date and time when the cancellation acknowledgment is received from the old Service Provider.

RR5-31 Cancel Subscription Version Acknowledgment - Update New Service Provider Date and Time Stamp

NPAC SMS shall update the new Service Provider cancellation date and time stamp with the current date and time when the cancellation acknowledgment is received from the new Service Provider.

RR5-32.1 Cancellation-Initial Concurrence Window - Tunable Parameter

NPAC SMS shall provide a Cancellation-Initial Concurrence Windowtunable parameter, which is defined as the number of hours after the version is set to Cancel Pending by which both Service Providers are expected to acknowledge the pending cancellation.

RR5-32.2 Cancellation-Initial Concurrence Window - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Cancellation-Initial Concurrence Windowtunable parameter.

RR5-32.3 Cancellation-Initial Concurrence Window - Tunable Parameter Default

NPAC SMS shall default the Cancellation-Initial Concurrence Windowtunable parameter to 4 hours.

RR5-33.1 Cancellation-Final Concurrence Window - Tunable Parameter

NPAC SMS shall provide a Cancellation-Final Concurrence Window tunable parameter which is defined as the number of hours after the second cancel pending notification is sent by which both Service Providers are expected to acknowledge the pending cancellation.

51

RR5-33.2 Cancellation-Final Concurrence Window Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Cancellation-Final Concurrence Window tunable parameter.

RR5-33.3 Cancellation-Final Concurrence Window - Tunable Parameter Default

NPAC SMS shall default the Cancellation-Final Concurrence Window tunable parameter to 4 hours.

RR5-34 Cancellation-Initial Concurrence Window - Tunable Parameter Expiration

NPAC SMS shall send a notification to the Service Provider (new and/or old) who has not yet acknowledged the cancel pending status when the Cancellation-Initial Concurrence Window tunable parameter expires.

RR5-35 Cancellation-Final Concurrence Window - Tunable Parameter Expiration

NPAC SMS shall set the Subscription Version status to conflict when the NPAC SMS has not received the cancellation acknowledgment from the old and/or new Service Providers and the Cancellation-Final Concurrence Window tunable parameter has expired.

RR5-36 Cancel Subscription Version - Inform Service Providers of Conflict Status

NPAC SMS shall notify the old and new Service Providers upon setting a Subscription Version to conflict.

5.1.2.2.7 Subscription Version Resend

This section provides the requirements for the Subscription Version resend functionality, which is executed upon the NPAC personnel requesting to resend a Subscription Version.

RR5-38.1 Resend Subscription Version - Identify Subscription Version

NPAC SMS shall receive the following data from NPAC personnel to identify a failed or partial failure version to be resent:

•Ported Telephone Number or Subscription Version ID

52

RR5-38.2 Resend Subscription Version - Input Data

NPAC SMS shall require the following input data from NPAC personnel upon a Subscription Version resend:

•List of “failed” Local SMSs to resend to.

RR5-38.3 Resend Subscription Version - Error Message

NPAC SMS shall send an error message to the originating user if the version status is not partial failure or failed upon Subscription Version resend.

RR5-38.4 Resend Subscription Version - Activation Request

NPAC SMS shall resend a Subscription Version activation request, if either the Subscription Version previously failed activation or an active Subscription Version previously failed modification, to the designated list of failed Local SMSs via the NPAC SMS to Local SMS Interface upon a Subscription Version resend request.

RR5-38.5 Resend Subscription Version - Disconnect Request

NPAC SMS shall resend a Subscription Version disconnect request, if the Subscription Version failed disconnect, to the designated list of failed Local SMSs upon a Subscription Version resend request.

RR5-38.6 Resend Subscription Version - Failed or Partial Failure

NPAC SMS shall set a failed or partial failure Subscription Version to sending subsequent to resending to the Local SMSs.

RR5-38.7 Resend Subscription Version - Standard Activation Processing

NPAC SMS shall proceed with the standard activation processing subsequent to resending a Subscription Version activation request to the Local SMSs.

RR5-38.8 Resend Subscription Version - Standard Disconnect Processing

NPAC SMS shall proceed with the standard disconnect processing subsequent to resending a Subscription Version disconnect request to the Local SMSs.

53

5.1.3Subscription Queries

This section provides the requirements for the Subscription Version Query functionality, which is executed upon the user requesting a query of a Subscription Version (R5-13).

5.1.3.1User Functionality

R5-72 Query Subscription Version - Request

NPAC SMS shall allow NPAC personnel, SOA to NPAC SMS interface users, and NPAC SMS to Local SMS interface users to query data maintained by the NPAC SMS for a Subscription and all its Versions.

5.1.3.2System Functionality

The following requirements specify the NPAC SMS query functionality defined above.

R5-73 Query Subscription Version - Version Identification

NPAC SMS shall receive the following data to identify a Subscription Version to be queried:

Ported Telephone Numbers and status (optional) or

Subscription Version ID

R5-74.1 Query Subscription Version - Status Supplied

NPAC SMS shall only retrieve Subscription Versions with a specific status when the user supplies a specific Subscription Version status as part of the query criteria.

R5-74.2 Query Subscription Version - Return All Subscription Versions for Ported TN

NPAC SMS shall return all Subscription Versions associated with a ported TN that the requester is eligible to view if the originating user has not provided a Subscription Version status as part of the query criteria.

R5-74.3 Query Subscription Version - Output Data

NPAC SMS shall return the following output data for a Subscription Version query request initiated by NPAC personnel or a SOA to NPAC SMS interface user:

54

•Subscription Version ID

•Subscription Version Status

•Local Number Portability Type

•Ported Telephone Number

•Old facilities-based Service Provider Due Date

•New facilities-based Service Provider Due Date

•New facilities-based Service Provider ID

•Old facilities-based Service Provider ID

•Authorization from old facilities-based Service Provider

•Location Routing Number (LRN)

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•Billing Service Provider ID

•End-User Location Value

•End User Location Type

•Customer Disconnect Date

•Effective Release Date

•Disconnect Broadcast Complete Time Stamp

•Conflict Time Stamp

•Activation Time Stamp

•Cancellation Time Stamp

•New Service Provider Creation Time Stamp

•Old Service Provider Authorization Time Stamp

•Pre-cancellation Status

55

•Old Service Provider Cancellation Time Stamp

•New Service Provider Cancellation Time Stamp

•Old Time Stamp

•Old Service Provider Conflict Resolution Pending Time Stamp

•New Service Provider Conflict Resolution Pending Time Stamp

•Create Time Stamp

•Modified Time Stamp

•Porting to Original

•List of all Local SMSs that failed activation, modification, or disconnect.

R5-74.4 Query Subscription Version - Output Data

NPAC SMS shall return the following output data for a Subscription Version query request initiated over the NPAC SMS to Local SMS interface:

•Subscription Version ID

•Ported Telephone Number

•Location Routing Number (LRN)

•New facilities-based Service Provider ID

•Activation Time Stamp

•Customer Disconnect Date

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•End-User Location Value

•End-User Location Type

•Billing Service Provider ID

•Local Number Portability Type

56

R5-75 Query Subscription Version -No Data Found

NPAC SMS shall send the originating user an appropriate message indicating that there was no data found if no Subscription Versions were found for a query.

RN5-4 Query Subscription Version - Retrieve Data, Modification Not Allowed

NPAC SMS shall allow NPAC personnel or SOA to NPAC SMS interface users to retrieve subscription data that they cannot modify.

RN5-5 Query Subscription Version - Retrieve Data Based on Single Ported TN Only

NPAC SMS shall allow authorized NPAC personnel, SOA to NPAC SMS interface users, or NPAC SMS to Local SMS interface users to submit query requests for Subscription Version data based on a single ported TN only.

RN5-6 Query Subscription Version - View for Any Ported TN

NPAC SMS shall allow old and new Service Providers or NPAC personnel to view a Subscription Version for any ported TN.

RR5-39 Query Subscription Version - View Old or Active Only

NPAC SMS shall allow NPAC Customers who are neither the old nor the new Service Provider to view only those Subscription Versions for a ported TN with a status of active, canceled, or old.

RR5-40 Query Subscription Version - Online Records Only

NPAC SMS shall only allow Subscription Version queries of online subscription Versions that have not been archived.

57

NPAC SMS Interfaces

6.NPAC SMS Interfaces

Two CMIP-based, mechanized interfaces to the NPAC SMS were defined in the Illinois NPAC RSMS RFP. One interface supports the Service Provider’s Service Order Administration (SOA) systems. This interface is referred to as the SOA to NPAC SMS interface. The second interface supports the Service Providers Local Service Management System (LSMS). This interface is referred to as the NPAC SMS to LSMS interface. Both of the interfaces support two-way communications.

The Lockheed Martin NPAC SMS supports an additional World Wide Web (WWW) interface that performs a subset of the SOA to NPAC SMS functions. The interface is referred to as the NPAC Operations GUI. The requirements for this interface are defined in Section 6.5.1.

6.1SOA 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. The interface will require security features to ensure that data is not corrupted by unauthorized access. Security management is covered in Section 7.

6.1.1Request Administration

R6-1 Strong authentication for application-to-application associations.

Application-to-application associations across the SOA to NPAC SMS interface shall be implemented using strong authentication.

R6-2.1 Support for multiple Subscription Versions administration requests.

Each Subscription Version administration request sent over the interface shall be capable of supporting aggregated transactions.

1

R6-2.2 Support for independent Subscription Versions administration requests within aggregated download transactions.

A failure of a single Subscription Version administration request within a set of aggregated transactions shall not cause other requests in the set to fail.

R6-3 The NPAC SMS shall respond to each Subscription Versions administration request.

Each request from the SOA to NPAC SMS Interface shall be acknowledged with at least one response message from the NPAC SMS.

6.1.2Subscription Administration

Subscription Administration provides functionality in creating or modifying subscriptions and activating or deleting them from the networks.

R6-4.1 Administration of Subscription Version creation.

NPAC SMS shall allow users of the SOA to NPAC SMS interface to add new versions of subscription data.

R6-4.2 Administration of Subscription Version data modification.

NPAC SMS shall allow users of the SOA to NPAC SMS interface to modify a specific version of subscription data.

R6-4.3 Administration of Subscription Version data cancellation.

NPAC SMS shall allow users of the SOA to NPAC SMS interface to cancel a specific version of subscription data.

R6-5.1 Query a version.

NPAC SMS shall allow users of the SOA to NPAC SMS interface to retrieve a specific version of a subscription.

2

R6-5.2 Retrieval of multiple Subscription Versions.

NPAC SMS shall allow users of the SOA to NPAC SMS interface to retrieve all versions of a subscription.

R6-6.1 Activation of a Subscription Version.

NPAC SMS shall allow users of the SOA to NPAC SMS interface to request the activation of a specific Subscription Version.

R6-6.2 Disconnect of a Subscription Version.

NPAC SMS shall allow users of the SOA to NPAC SMS interface to request the disconnection of a specific Subscription Version.

6.1.3Audit Requests

Audit Request functionality enables users of the SOA to NPAC SMS interface to obtain audits of a specific subscription or range of subscriptions for all Service Providers or selected Service Providers.

R6-7.1 Request audits based on a specific subscription.

Users of the SOA to NPAC SMS Interface shall be able to request an audit based on specific Subscription Versions.

R6-7.2 Request audits based on multiple Subscription Versions.

Users of the SOA to NPAC SMS Interface shall be able to request an audit based on multiple Subscription Versions.

R6-8.1 Request audits based on a specific Service Provider.

Users of the SOA to NPAC SMS Interface shall be able to request an audit of a specific Service Provider.

R6-8.2 Request audits based on multiple Service Providers

Users of the SOA to NPAC SMS Interface shall be able to request an audit of multiple Service Providers.

3

R6-9.1 Request audits based on specific TNs

Users of the SOA to NPAC SMS Interface shall be able to request an audit based on specific TNs.

R6-9.2 Request audits based on a range of TNs.

Users of the SOA to NPAC SMS Interface shall be able to request an audit based on a range of TNs.

R6-9.3 Request audits based on a specific Subscription Versions parameters.

Users of the SOA to NPAC SMS Interface shall be able to request an audit based on specific Subscription Version parameters.

R6-10.1 Audit request acknowledgment when discrepancies reported.

Each audit request shall be acknowledged with at least one response transaction from the NPAC SMS. This response shall include a list of the discrepancies derived from the comparison of the data in the NPAC SMS to the data in the Local SMS.

R6-10-2 Audit request acknowledgment when no discrepancies reported.

Each audit request shall be acknowledged with one response when no discrepancy are reported.

R6-10.3 Audit request acknowledgment response per TN error.

Each audit request shall be acknowledged with one response per erroneous telephone number when discrepancies are reported.

6.1.4Notifications

R6-11 Notification of authorization to transfer service.

NPAC SMS shall notify a new or an old Service Provider that they have not provided authorization or concurrence, within a tunable parameter time frame, for a transfer of service for a TN via the SOA to NPAC SMS Interface.

4

R6-12 Notification of Subscription Versions due date modification.

NPAC SMS shall notify both the old and new Service Providers that the Due Date for a Subscription Version has been modified via the SOA to NPAC SMS Interface.

6.2NPAC 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 Service Provider 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.

6.2.1Transaction Administration

R6-13 Interface user authentication

NPAC SMS shall require users of the NPAC SMS to Local SMS interface to specify their system identification to be able to use the interface.

R6-14.1 Support for multiple subscription-versions data-download transactions.

The NPAC SMS to Local SMS interface shall be capable of supporting aggregated data download transactions.

R6-14.2 Failed Data Download Transactions

The NPAC SMS to Local SMS interface shall not allow one failed item in a download request to cause other items in the request to fail.

5

R6-15.1 NPAC SMS to Local SMS interface support of subscription-data-download response transactions from Local SMSs.

NPAC SMS shall receive subscription-data-download transaction responses from Local SMSs via the NPAC SMS to Local SMS interface. A minimum of one response will be received.

R6-15.2 NPAC SMS to Local SMS interface support of subscription-data-download response transactions positive acknowledgment.

NPAC SMS shall receive a positive subscription-data-download transaction response from Local SMSs via the NPAC SMS to Local SMS interface when the download was successful.

R6-15.3 NPAC SMS to Local SMS interface support of subscription-data-download response transactions negative acknowledgment.

NPAC SMS shall receive a negative subscription-data-download transaction response from Local SMSs via the NPAC SMS to Local SMS interface when the download was not successful.

R6-16.1 Subscription requests for a single Subscription Version transaction.

NPAC SMS shall send requests over the NPAC SMS to Local SMS interface for a single Subscription Version.

R6-16.2 Subscription requests for a range of Subscription Versions transactions.

NPAC SMS shall send requests over the NPAC SMS to Local SMS interface for a range of contiguous Subscription Versions.

R6-17.1 Receipt of subscription request response acknowledgments.

NPAC SMS to Local SMS interface shall receive subscription request response acknowledgment transactions from the Local SMS.

R6-17.2

DELETE

R6-17.3

DELETE

6

R6-18.1 Receipt of Local SMS Subscription Versions resend requests (single TN).

NPAC SMS to Local SMS interface shall receive requests from the Local SMS for download of Subscription Versions data based on a single TN.

R6-18.2 Receipt of Local SMS Subscription Versions resend requests (range of TNs).

NPAC SMS to Local SMS interface shall receive requests from the Local SMS for download of Subscription Versions data based on a range of TNs.

R6-18.3 Receipt of Local SMS Subscription Versions resend requests (range of time).

NPAC SMS to Local SMS interface shall receive requests from the Local SMS for download of Subscription Versions data based on a range of time.

R6-19 Network data download responses.

NPAC SMS shall receive one response transaction from the Local SMS for each network data download.

6.2.2Network Subscription Administration

Network Subscription Administration provides functionality in activating, modifying, or deleting subscription data from the network and in supporting audits.

R6-20.1 Add new Subscription Versions data via the NPAC SMS to Local SMS.

NPAC SMS shall generate a request to the Local SMS to add new Subscription Versions data via NPAC to Local SMS interface.

R6-20.2 Modify specific Subscription Versions data via the NPAC SMS to Local SMS.

NPAC SMS shall generate a request to the Local SMS to modify specific Subscription Versions data via NPAC to Local SMS interface.

7

R6-20.3 Delete specific Subscription Versions data via the NPAC SMS to Local SMS.

NPAC SMS shall generate a request to the Local SMS to delete specific Subscription Versions data via NPAC to Local SMS interface.

R6-21

DELETE

6.3Interface Transactions.

The CMIP protocol provides for six types of transactions over the interface (Reference: ISO 9595 and 9596). They are Create, Delete, Set, Get,

M-Action, and Event Report. Refer to Requirements RN6-1.1, RN6-1.2, RN6-1.3, RN6-1.4, RN6-1.5, RN6-1.6 noted in Section 6.5.1 (CMIP transactions) for the definition of the requirements for these transactions.

R6-22 Manager-agent relationship of interface transactions.

NPAC SMS Interoperable Interface shall be designed in terms of CMIP transactions in a manager-agent relationship.

6.4Interface 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-23 Open interfaces.

The SOA to NPAC SMS Interface and the NPAC SMS to Local SMS Interface shall be open, non-proprietary interfaces.

8

6.4.1Protocol Requirements

R6-24 Interface protocol stack.

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

Application	CMISE, ACSE, ROSE
Presentation	ANSI T1.224
Session:	ANSI T1.224
Transport:	TCP, RFC1006
Network:	IP
Link	PPP, MAC, Frame Relay, ATM (IEEE 802.3)
Physical	DS1, DS-0 x n , V.34

Table 6-1

R6-25 Multiple application associations.

NPAC SMS shall support multiple application associations per Service Provider.

6.4.2Interface Performance Requirements

R6-26 Interface availability.

Both the SOA to NPAC SMS and the NPAC SMS to Local SMS interfaces shall be available on a 24 by 7 basis, consistent with other availability requirements in this specification.

R6-27 Interface reliability.

A 99.9 % reliability rate shall be maintained for both the SOA to NPAC SMS and NPAC SMS to Local SMS interfaces.

AR6-1 Range Activations.

A range activate will contain an average of 20 TNs.

9

AR6-2 Percent of Range Activations.

20% of all downloads as specified in R6-28.1, R6-28.2, R6-29.1 and R6-29.2 will be processed via range activations.

R6-28.1 SOA to NPAC SMS interface transaction rates - sustained

A transaction rate of 2 CMIP transactions (sustained) per second shall be supported by each SOA to NPAC SMS interface association.

R6-28.2 SOA to NPAC SMS interface transaction rates - peak

NPAC SMS shall support a rate of 5.2 CMIP operations per second (peak) over a single SOA to NPAC SMS interface association.

R6-29.1 NPAC SMS to Local SMS interface transaction rates.

A transaction rate of 25 TN downloads per second shall be supported by each NPAC SMS to Local SMS interface.

R6-29.2 NPAC SMS to Local SMS interface transaction rates - sustained

NPAC SMS shall, given a transaction rate of 25 TN downloads per second and the assumptions concerning range activations expressed above, support a rate of 5.2 CMIP operations per second (sustained) over each NPAC SMS to Local SMS interface association.

6.4.3Interface Performance Requirements

R6-30.1 Interface specification.

NOT A SYSTEM REQUIREMENT-CANNOT BE TESTED

The interoperable interface model defining both the NPAC to Local SMS and the SOA to NPAC SMS shall be specified in terms of ISO 10165-4, “Generalized Definition of Managed Objects (GDMO)”

10

R6-30.2 Interface specification identification.

NOT A SYSTEM REQUIREMENT-CANNOT BE TESTED

The interface specification shall be referred to as the “NPAC SMS Interoperable Interface Specification” (NPAC SMS IIS).

R6-30.3 Interface specification ownership.

NOT A SYSTEM REQUIREMENT-CANNOT BE TESTED

The NPAC SMS Interoperable Interface Specification will become the property of the consortium.

R6-31 NPAC SMS Interoperable Interface Specification phased-delivery.

NOT A SYSTEM REQUIREMENT-CANNOT BE TESTED

The model and interface specification shall be delivered in stages.

R6-32 NPAC SMS Interoperable Interface Specification draft content.

NOT A SYSTEM REQUIREMENT-CANNOT BE TESTED

The draft model shall be provided at the object and attribute level. The draft shall include tables that show how the interface functions required by this specification are mapped into the services provided by the model.

R6-33 NPAC SMS Interoperable Interface Specification delivery schedule.

NOT A SYSTEM REQUIREMENT-CANNOT BE TESTED

The selected Primary vendor shall deliver a complete interoperable interface specification one month after the announcement of the vendor selection.

R6-34 NPAC SMS Interoperable Interface Specification detail.

NOT A SYSTEM REQUIREMENT-CANNOT BE TESTED

The application to application interfaces shall be specified in sufficient detail to allow local Service Providers to build applications utilizing the SOA and Local SMS interfaces with minimal or no interaction between the suppliers of the interoperable systems. For example the interoperable interface specification shall provide for error handling of error conditions

11

appropriate to all of the functional requirements. It shall also define the security relationship between the systems.

R6-35 NPAC SMS Interoperable Interface Specification extensibility.

NOT A SYSTEM REQUIREMENT-CANNOT BE TESTED

The interface specified shall be capable of extension to account for evolution of the interface requirements.

6.5Requirements Defined in the Proposal

6.5.1NPAC Operations GUI

NPAC SMS supports an HTTPS (World Wide Web) interface that performs a subset of the SOA functions. The HTTPS interface is referred to as the NPAC Operations GUI. The NPAC Operations GUI supports the request functionality of the SOA to NPAC SMS interface.

RP6-2.1 HTTPS interface.

NPAC SMS shall provide an NPAC Operations GUI consisting of a secure HTTPS interface to the World Wide Web.

RP6-2.2 SOA to NPAC SMS Create Subscription Versions administration requests via an NPAC Operations GUI interface.

NPAC SMS shall support Create Subscription Version requests via a secure, NPAC Operations GUI interface.

RP6-2.3 SOA to NPAC SMS Cancel Subscription Versions administration requests via an NPAC Operations GUI interface.

NPAC SMS shall support Cancel Subscription Version requests via a secure, NPAC Operations GUI interface.

12

RP6-2.4 SOA to NPAC SMS Modify Subscription Versions administration requests via an NPAC Operations GUI interface.

NPAC SMS shall support Modify Subscription Version requests via a secure, NPAC Operations GUI interface.

RP6-2.5 SOA to NPAC SMS Query Subscription Versions administration requests via an NPAC Operations GUI interface

NPAC SMS shall support query of Subscription Versions via a secure, NPAC Operations GUI interface.

RP6-2.6 SOA to NPAC SMS Activate Subscription Versions administration requests via an NPAC Operations GUI interface.

NPAC SMS shall support Activation of Subscription Versions via a secure, NPAC Operations GUI interface.

RP6-2.7 SOA to NPAC SMS Disconnect Subscription Versions administration requests via an NPAC Operations GUI interface.

NPAC SMS shall allow NPAC personnel and users of the SOA to NPAC SMS interface to request disconnection of a Subscription Version via a secure, NPAC Operations GUI interface.

RP6-3 SOA to NPAC SMS audit requests

NPAC SMS shall support SOA to NPAC SMS audit via the NPAC Operations GUI interface.

RP6-3.1 SOA to NPAC SMS audit requests via an NPAC Operations GUI interface (single Service Provider network).

NPAC SMS shall support audit requests on single Service Provider networks via a secure, NPAC Operations GUI interface.

RR6-1 Acknowledgment of a Cancel Pending for a Subscription Version

NPAC SMS shall acknowledge receiving a cancel pending request for a Subscription Version via the SOA to NPAC SMS Interface.

13

RR6-2 Acknowledgment of a Conflict Resolution for a Subscription Version

NPAC SMS shall acknowledge receiving a conflict resolution request for a Subscription Version via the SOA to NPAC SMS Interface.

RR6-3 Deferred Disconnect of a Subscription Version

NPAC SMS shall allow a specific Subscription Version to be placed into a deferred disconnect status by having the effective date in the future via the SOA to NPAC SMS Interface.

RR6-4 Cancel Request Notification

NPAC SMS shall notify a Service Provider of a request for a Subscription Version status to be changed to cancel via the SOA to NPAC SMS Interface.

RR6-5 Conflict Resolution Request Notification

NPAC SMS shall notify a Service Provider of a request for a Subscription Version status to be changed to conflict resolution via the SOA to NPAC SMS Interface.

RR6-6 SOA to NPAC SMS Downtime Operational Information Notification.

NPAC SMS shall notify all Service Providers of planned downtime via the SOA to NPAC SMS Interface.

RR6-7 NPAC SMS to Local SMS Downtime Operational Information Notification

NPAC SMS shall notify all Service Providers of planned downtime via the NPAC SMS to Local SMS interface.

RR6-8 Tunable Parameter Number of Aggregated Download Records

NPAC SMS shall allow NPAC System Administrators to specify a tunable parameter value for the maximum number of download records.

14

RR6-9 Download Time Tunable Parameter to Restricted Time Range

NPAC SMS shall allow NPAC System Administrators to specify a tunable parameter value for the maximum time range for a download.

RR6-10

DELETE

RR6-11

(Duplicate - refer to RP6-2.5)

RR6-12

DELETE (moved to RP6-2.6)

RR6-13 Queries Constrained by NPA-NXX

NPAC SMS shall constrain all queries on the NPAC SMS to Local SMS Interface to one NPA-NXX plus additional filter criteria.

6.6Network Requirements

6.6.1NPAC SMS WAN Topology Requirements

6.6.1.1The NPAC Site LAN

RP6-4 NPAC Site Connection to the Internet

The NPAC site shall connect to the Internet using a DS0 ISDN circuit through a bastion server firewall to the NPAC LAN/WAN.

RP6-5 Support of DS0 Connections

The NPAC site shall support 20 DS0 dial-up connections to the Public Switched Telephone Network through the dial-up remote access server.

15

6.6.2NPAC SMS WAN Hardware Requirements

6.6.2.1Enterprise Switching Hubs

RP6-6 Enterprise Switching Hub

The NPAC LAN/WAN shall utilize an Enterprise switching hub that supports switching Dual 100 Mbps fast ethernet.

6.6.2.2Local Access Servers

RP6-7 NPAC LAN/WAN Connectivity

The NPAC LAN/WAN shall support at least 10 dedicated BR1 or DS0 ports for the purpose of WAN connectivity.

RP6-8 Inter-LAN Segments

The NPAC LAN/WANs shall support IP filtering and bridging between LAN segments.

RP6-9 Client Access

The NPAC LAN/WAN shall support PPP and MPP for the purpose of client access.

RP6-10 Security

The NPAC LAN/WAN shall support CHAP, TACACS, Callback, Caller Number ID verification, Password, and SmartCard for security purposes.

16

Security

7.Security

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 SMS to SMS and SMS to SOA interfaces).

7.1Identification

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

R7-l Unique User Identification Codes - Individuals

NPAC SMS shall require unique user identification codes (userids) to identify all NPAC and Service Provider personnel.

R7-2 Assigned Userid Identification

NPAC SMS shall require NPAC and Service Provider personnel to identify themselves with their assigned userid before performing any actions.

R7-3 Current Active User List Maintenance

NPAC SMS shall maintain internally the identity of all NPAC and Service Provider personnel logged on to the NPAC SMS.

R7-4 User Invoked Processes

NPAC SMS shall have for every process running an associated userid of the invoking user (or the userid associated with the invoking process).

1

R7-5.1 Userids, Unused - Disabling

NPAC SMS shall disable userids after a period of time during which the userid has not been used.

R7-5.2 Unused Userid Disable Period - Tunable Parameter

NPAC SMS shall provide an Unused Userid Disable Period tunable parameter which is defined as the number of days for which the userid has not been used.

R7-5.3 Unused Userid Disable Period - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS administrator to modify the Unused Userid Disable Period tunable parameter time period.

R7-5.4 Unused Userid Disable Period - Tunable Parameter Default

NPAC SMS shall default the Unused Userid Disable Period tunable parameter to 60 days.

R7-6.1 Userids, Disabled - Reinstatement

NPAC SMS shall provide a complementary mechanism or procedure for the re-instatement disabled userids.

R7-6.2 Userids - Deletion

NPAC SMS shall provide a procedure for the deletion of userids.

R7-7 Userids - Temporary Disabling

NPAC SMS shall support the temporary disabling of userids.

R7-8 Userids, Disabled - Automatic Reactivation

NPAC SMS shall provide an option for automatic reactivation of disabled userids.

R7-9.1 Userids - One Active Login

NPAC SMS shall control and limit simultaneous active usage of the same userids by allowing only one active login.

2

R7-9.2 Second Login Attempt

NPAC SMS shall present the NPAC or Service Provider personnel with an option of disconnecting the first login and continuing the second login or terminating the second login, when a second login is entered.

7.2Authentication

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

R7-10 User Authentication

NPAC SMS shall authenticate the identity of all NPAC and Service Provider users of the NPAC Operations GUI prior to their initially gaining access to NPAC SMS.

R7-11

(Duplicate - refer to R7-10)

R7-12 Authentication Data Protection

NPAC SMS shall protect all internal storage of authentication data so that it can only be accessed by an NPAC Security Administrator user.

7.2.1Password Requirements

R7-13 Passwords - Non-shared

NPAC SMS shall require a single password entry for each userid.

R7-14 Passwords - Userid Unique

NPAC SMS shall allow a user to define a password that is already associated with another userid.

3

R7-15 Passwords - One-Way Encrypted

NPAC SMS shall store passwords in a one-way encrypted form.

R7-16 Passwords, Encrypted - Privileged Users Access Control

NPAC SMS shall only allow access to encrypted passwords by authorized users.

R7-17

(Duplicate - refer to R7-15)

R7-18 Passwords, Entry - Automatic Clear Text Suppression

NPAC SMS shall automatically suppress or fully blot out the clear-text representation of the password on the data entry device.

R7-19 Passwords - Network Transmission Clear Text Suppression

NPAC SMS shall ensure that passwords sent over public or external shared data networks are encrypted.

R7-20 Passwords - Non-Null

NPAC SMS shall require non-null passwords.

R7-21 Passwords - User-Changeable

NPAC SMS shall provide a mechanism to allow passwords to be user-changeable. This mechanism shall require re-authentication of the user identity.

R7-22 Passwords - Reset Capability

The NPAC SMS shall have a mechanism to reset passwords.

R7-23.1 Passwords - Aging Enforcement

NPAC SMS shall enforce password aging.

4

R7-23.2 Password Aging Default

NPAC SMS shall default the system password aging to 90 days.

R7-24.1 Passwords - Expiration Notification

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

R7-24.2 Passwords - Expiration Notification Default

NPAC SMS shall default the password expiration notification time period to seven days

R7-24.3 Passwords - Require User to Enter New Password

NPAC SMS shall require any user whose password has expired to enter a new password before allowing that user access to the system.

R7-25.1 Passwords - Non-Reusable

NPAC SMS shall ensure that a password can not be reused by the same individual for specifiable period of time.

R7-25.2 Password Reuse Default

NPAC SMS shall default the time period in which a password can not be reused to six months.

R7-26.1 Passwords - Minimum Structure Standard #1

Passwords shall contain a combination of at least six case-sensitive alphanumeric characters including at least one alphabetic and one numeric or punctuation character.

R7-26.2 Passwords - Associated Userid

NPAC SMS shall ensure that passwords do not contain the associated userid.

R7-27.1 Password Generator

NPAC SMS shall provide a password generator.

5

R7-27.2 Passwords, System Generated - Attack Resistant

NPAC SMS shall ensure that generated passwords are “reasonably” resistant to brute-force password guessing attacks.

R7-27.3 Passwords, System Generated - Random

NPAC SMS shall ensure that the generated sequence of passwords have the property of randomness.

7.3Access Control

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

7.3.1System Access

R7-28.1 System Access - Individuals

NPAC SMS shall allow access to authorized individual users.

R7-28.2 System Access - Remote Machines

NPAC SMS shall allow access to authorized remote systems.

R7-29.1 System Access, User Information - Entry

NPAC SMS shall provide a facility for the initial entry of authorized user and associated authentication information.

R7-29.2 System Access, User Information - Modification

NPAC SMS shall provide a facility for the modification of authorized user and associated authentication information.

6

R7-30

(Duplicate - refer to R7-10)

R7-31 System Access, Login - Trusted Communication

NPAC SMS’s login procedure shall be able to be reliably initiated by the user, i.e., a trusted communications path should exist between NPAC SMS and the user during the login procedure.

R7-32.1 System Access - Disconnect User

NPAC SMS shall disconnect end users after a period of non-use.

R7-32.2 Non-use Disconnect Tunable Parameter

NPAC SMS shall default the Non-use Disconnect tunable parameter to 60 minutes.

R7-33.1 System Access - User Authentication Failure

NPAC SMS shall exit and end the session if the user authentication procedure is incorrectly performed a specifiable number of times.

R7-33.2 Incorrect Login Exit Default

NPAC SMS shall default the number of allowable incorrect login attempts to 3.

R7-34 System Access, User Authentication Failure - Notification

NPAC SMS shall provide a mechanism to immediately notify the NPAC SMS system administrator when the threshold in R7-33.1 is exceeded.

R7-35.1 System Access - Login Process I/O Port Restart

NPAC SMS shall restart the login process when the threshold in R7-33.1 has been exceeded and a specified interval of time has passed.

R7-35.2 Login Process Restart Default

NPAC SMS shall default the time interval to restart the login process to 60 seconds.

7

R7-36 System Access, User Authentication Failure - Userid Non-Suspension

NPAC SMS shall not suspend the userid upon exceeding the threshold in R7-33.1.

R7-37 System Access, User Authentication Procedure - Entry

NPAC SMS shall perform the entire user authentication procedure even if the userid that was entered was not valid.

R7-38 System Access, User Authentication Procedure Entry - Error Feedback

NPAC SMS shall only provide error feedback of “invalid”.

R7-39 System Access, User Authentication Procedure Entry - Time Parameters

NPAC SMS shall provide a mechanism to restrict user login based on time-of-day, day-of-week, calendar date.

R7-40.1 System Access, User Authentication Procedure Entry - Method

ISSUE

NPAC SMS shall provide a mechanism to restrict user login based on method of entry.

R7-40.2 System Access, User Authentication Procedure Entry - Location

NPAC SMS shall provide a mechanism to restrict user login based on user system location.

R7-41 System Access, User Authentication Procedure Entry - Dial-Up Limitations

NPAC SMS shall provide a mechanism to limit the users authorized to access the system via dial-up facilities.

R7-42.1 System Access - Network Basis

NPAC SMS shall provide a mechanism to limit system entry for privileged NPAC SMS users on a specifiable network access.

8

R7-42.2 System Access - Per-Port Basis

NPAC SMS shall provide a mechanism to limit system entry for privileged NPAC SMS users on a specifiable per-port basis.

R7-43.1 System Access, Network Authentication

NPAC SMS shall provide a strong authentication mechanism for network access.

R7-43.2 Internet Access

NPAC SMS shall use authentication of public encryption keys for users accessing the NPAC SMS over the Internet.

R7-43.3 Dial-in Access

NPAC SMS shall use smart cards to authenticate users accessing the NPAC SMS via dial-up.

R7-44 System Access - Secure Logoff Procedures

NPAC SMS shall provide a mechanism to end the session through secure logoff procedures.

R7-45

(Duplicate - refer to R7-47)

R7-46 System Access, Unauthorized Use Message - Specifiable

NPAC SMS shall ensure that the message is NPAC SMS-specifiable to meet their own requirements, and any applicable laws.

R7-47.1 System Access, Unauthorized Use Message - Specifiable

NPAC SMS shall be able to display an advisory warning message of up to 20 lines in length prior to login.

9

R7-47.2 Advisory Warning Message Default

NPAC SMS shall default the pre-login advisory warning message to the following:

NOTICE: This is a private computer system.

Unauthorized access or use may lead to prosecution.

R7-48.1 System Access - User’s Last Successful Access

NPAC SMS shall display the date and time of the user’s last successful system access upon successful login.

R7-48.2 System Access - User’s Unsuccessful Access Attempts

NPAC SMS shall display the number of unsuccessful attempts by that userid to access the system, since the last successful access by that userid upon successful login.

R7-49.1 System Access, Security Administration - Authorize Users

NPAC SMS shall only allow the NPAC Security Administrator to authorize users.

R7-49.2 System Access, Security Administration - Revoke Users

NPAC SMS shall only allow the NPAC Security Administrator to revoke users.

R7-50.1 System Access, Security Administration -Adding Users

NOT A SYSTEM REQUIREMENT-CANNOT BE TESTED

NPAC SMS shall provide security documentation that defines and describes procedures for adding users.

R7-50.2 System Access, Security Administration -Deleting Users

NOT A SYSTEM REQUIREMENT- CANNOT BE TESTED

NPAC SMS shall provide security documentation that defines and describes procedures for deleting users.

10

7.3.2Resource Access

R7-51 Data Access for Authorized Users

NPAC SMS shall allow only authorized users to access the data that is part of or controlled by the SMS system.

R7-52 Service Provider Data Protected

NPAC SMS shall protect service provider data from access by unauthorized users.

R7-53.1 Authorized User Access to Software

NPAC SMS shall ensure that only NPAC system administrators can access the software files that constitutes the NPAC SMS.

R7-53.2 Authorized User Access to Transactions

NPAC SMS shall ensure that only authorized users can access the transactions that constitute the NPAC SMS.

R7-53.3 Authorized User Access to Data

NPAC SMS shall ensure that only authorized NPAC Operations GUI users can access the data generated by the transactions that constitutes the SMS.

R7-54.1 Access Control of Executable Software

NPAC SMS shall ensure that the executable and loadable software is access controlled for overwrite and update, as well as execution rights.

R7-55 Access Control of Resources

NPAC SMS shall ensure that control of access to resources is based on authenticated user identification.

R7-56 Use of Encryption

NPAC SMS shall ensure that userid and password is used as a primary access control for direct login and system ID is used for primary access control to the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.

11

R7-57 Resource Access to Users

NPAC SMS shall ensure that for software resources controlled by NPAC SMS, it must be possible to grant access rights to a single user or a group of users.

R7-58 Resource Access Denied to Users

NPAC SMS shall ensure that for software resources controlled by NPAC SMS, it must be possible to deny access rights to a single user or a group of users.

R7-59

(Duplicate - refer to R7-53.3)

R7-60 Only NPAC Personnel Can Modify User Access

NPAC SMS shall allow only NPAC personnel to modify access rights to a resource.

R7-61 Removal of User Access Rights

NPAC SMS shall provide a mechanism to remove access rights to all software resources for a user or a group of users.

R7-62.1

(Duplicate - refer to R7-12)

R7-62.2

(Duplicate - refer to R7-12)

7.4Data and System Integrity

R7-63 Identify Originator of System Resources

NPAC SMS shall identify the originator of any accessible system resources.

12

R7-64 Identify Originator of Information Received Across Communication Channels

NPAC SMS shall be able to identify the originator of any information received across communication channels.

R7-65.1 Monitor System Resources

NPAC SMS NMS shall use SNMP to monitor the system resources.

R7-65.2 Detect Error Conditions

NPAC SMS NMS shall use SNMP to detect error conditions.

R7-65.3 Detect Communication Errors

NPAC SMS NMS shall use SNMP to detect communication errors.

R7-65.4 Detect Link Outages

NPAC SMS NMS shall use SNMP to detect link outages.

R7-66.1 Rule Checking on Update

NPAC SMS shall ensure proper rule checking on data update.

R7-66.2 Handling of Duplicate Inputs

NPAC SMS shall handle duplicate/multiple inputs.

R7-66.3 Check Return Status

NPAC SMS shall check return status.

R7-66.4 Validate Inputs

NPAC SMS shall validate inputs for reasonable values.

R7-66.5 Transaction Serialization

NPAC SMS shall ensure proper serialization of update transactions.

13

R7-67 Database Integrity Checking

NPAC SMS shall include database integrity checking utilities for the NPAC SMS database.

7.5Audit

7.5.1Audit Log Generation

R7-68.1 Security Audit Log for After the Fact Investigation

NPAC SMS shall generate a security audit log that contains information sufficient for after the fact investigation of loss or impropriety for appropriate response, including pursuit of legal remedies.

R7-68.2 Security Audit Data Availability

NPAC SMS shall ensure that the security audit data is available on-line for a minimum of 90 days.

R7-68.3 Security Audit Data Archived

NPAC SMS shall archive the security audit data off-line for a minimum of two years.

R7-69 User Identification Retained

NPAC SMS shall ensure that the user-identification associated with any NPAC SMS request or activity is maintained, so that the initiating user can be traceable.

R7-70 Protection of Security Audit Log Access

NPAC SMS shall protect the security audit log from unauthorized access.

R7-71.1

DELETE

14

R7-71.2 NPAC Personnel Delete Security Audit Log

NPAC SMS shall ensure that only authorized NPAC personnel can archive and delete any or all of the security audit log(s) as part of the archival process.

R7-72 Security Audit Control Protected

NPAC SMS shall ensure that the security audit control mechanisms are protected from unauthorized access.

R7-73.1 Log Invalid User Authentication Attempts

NPAC SMS shall write a record to the security audit log for each invalid user authentication attempt.

R7-73.2 Log NPAC SMS End User Logins

NPAC SMS shall write a record to the security audit log for logins of NPAC users.

R7-73.3 Log NPAC Personnel Activities

NPAC SMS shall write a record to the security audit log for security controlled activities of NPAC users.

R7-73.4 Log Unauthorized Data Access

NPAC SMS shall write a record to the security audit log for unauthorized data access attempts.

R7-73.5 Log Unauthorized Transaction Access

NPAC SMS shall write a record to the security audit log for unauthorized NPAC SMS transaction functionality access attempts.

R7-74 No Disable of Security Auditing

NPAC SMS shall ensure that NPAC audit capability cannot be disabled.

15

R7-75 Security Audit Record Contents

NPAC SMS shall ensure that for each recorded event, the audit log contains the following:

•Date and time of the event

•User identification including relevant connection information

•Type of event

•Name of resources accessed or function performed

•Success or failure of the event

R7-76.1 Recorded Login Attempts

NPAC SMS shall record actual or attempted logins in audit logs after an NPAC-tunable parameter threshold of consecutive login failures.

7.5.2Reporting and Intrusion Detection

R7-77.1 Exception Reports on Data Items

NPAC SMS shall provide post-collection audit analysis tools that can produce exception reports on items relating to system intrusions.

R7-77.2 Exception Reports on Users

NPAC SMS shall provide post-collection audit analysis tools that can produce exception reports on users relating to system intrusions.

R7-77.3 Exception Reports on Communication Failures

NPAC SMS shall provide post-collection audit analysis tools that can produce exception reports on communication failures relating to system intrusions.

R7-77.4 Summary Reports on Data Items

NPAC SMS shall provide post-collection audit analysis tools that can produce summary reports on data items relating to system intrusions.

16

R7-77.5 Summary Reports on Users

NPAC SMS shall provide post-collection audit analysis tools that can produce summary reports on users relating to system intrusions.

R7-77.6 Summary Reports on Communication Failures

NPAC SMS shall provide post-collection audit analysis tools that can produce summary reports on communication failures relating to system intrusions.

R7-77.7 Detailed Reports on Data Items

NPAC SMS shall provide post-collection audit analysis tools that can produce detailed reports on data items relating to system intrusions.

R7-77.8 Detailed Reports on Users

NPAC SMS shall provide post-collection audit analysis tools that can produce detailed reports on users relating to system intrusions.

R7-77.9 Detailed Reports on Communication Failures

NPAC SMS shall provide post-collection audit analysis tools that can produce detailed reports on communication failures relating to system intrusions.

R7-78 Review User Actions

NPAC SMS shall provide a capability to review a summary of the actions of any one or more users, including other NPAC users, based on individual user identity.

R7-79.1 Monitor Network Address

NPAC SMS shall provide tools for the NPAC to monitor the message passing activities to and from a specific network address as they occur.

R7-80.1 Real-time Security Monitor

NPAC SMS NMS shall provide a real-time mechanism to monitor the occurrence or accumulation of security auditable events. Where possible, NPAC SMS shall determine and execute the least disruptive action to terminate the event.

17

R7-80.2 Security Event Notification

NPAC SMS NMS shall notify the NPAC personnel immediately when security event thresholds are exceeded through the SNMP agent.

7.6Continuity of Service

R7-81 System Made Unavailable by Service Provider

NPAC SMS shall ensure that no service provider action, either deliberate or accidental, should cause the system to be unavailable to other users.

R7-82 Detect Service Degrading Conditions

NPAC SMS shall report conditions that would degrade service below a pre-specified minimum, including high memory, CPU, network traffic, and disk space utilization.

R7-83 System Recovery After Failure

NPAC SMS shall provide procedures or mechanisms to allow recovery after a system failure without a security compromise.

R7-84.1 Software Backup Procedures

NPAC SMS shall have documented procedures for software backup.

R7-84.2 Data Backup Procedures

NPAC SMS shall have documented procedures for data backup.

R7-84.3 Software Restoration Procedures

NPAC SMS shall have documented procedures for software restoration.

R7-84.4 Data Restoration Procedures

NPAC SMS shall have documented procedures for data restoration.

R7-85.1 Software Version Number

NPAC SMS shall record the exact revision number of the latest software installed.

18

R7-85.2 Software Version Number

NPAC SMS shall display for viewing the exact revision number of the latest software via a Web bulletin board, and also through the NPAC Operations GUI upon completion of the user login sequence.

7.7Software Vendor

R7-86 Software Development Methodology

NPAC SMS shall be developed using a corporate policy governing the development of software.

R7-87 Bypass of Security

NOT A SYSTEM REQUIREMENT - CANNOT BE TESTED

NPAC SMS shall not support any mode of entry into NPAC SMS for maintenance, support, or operations that would violate or bypass any security procedures.

R7-88 Documented Entry

NPAC SMS shall document any mode of entry into the SMS for maintenance, support, or operations.

7.8OSI Security Environment

7.8.1Threats

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

19

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

7.8.2Security Services

R7-89 Authentication

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support Authentication (at association setup).

R7-90 Data Origin Authentication

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support data origin authentication for each incoming message.

R7-91.1 Detection of Message Replay

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support detection of replay.

R7-91.2 Deletion of a Message

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support detection of message deletion.

R7-91-3 Modification of a Message

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support detection of message modification.

R7-91.4 Delay of a Message

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support detection of message delay.

R7-92 Non-repudiation of Origin

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support non-repudiation of origin.

20

R7-93 Access Control

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall allow only authorized parties (i.e., carriers serving a given customer) to cause changes in the NPAC SMS database.

7.8.3Security Mechanisms

This section outlines the requirements to specify security mechanisms.

7.8.3.1Encryption

R7-94.1 Public Key Crypto System (PKCS)

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall use a public key crypto system (PKCS) to provide digital signatures. Since there is no requirement for confidentiality service there is no need for any additional encryption algorithms.

R7-94.2 Digital Signature Algorithms

NPAC SMS shall support one of the digital signature algorithms listed in the OIW Stable Implementation Agreement, Part 12, 1995.

R7-95 RSA Encryption Modulus Size

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall require the size of the modulus of each key to be at least 600 bits for RSA encryption.

7.8.3.2Authentication

R7-96 Digital Signature Algorithm

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall apply the digital signature algorithm to the fields specified below without any separators between those fields or any other additional characters.

•The unique identity of the sender

•The Generalized Time, corresponding to the issuance of the message

21

•A sequence number

•A key identifier

•Key list ID

R7-97 Authenticator Contents

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall provide authentication consisting of the following:

•The unique identity of the sender

•The Generalized Time, corresponding to the issuance of the message

•A sequence number

•A key identifier

•The digital signature of the sender’s identity, Generalized Time and sequence number listed above

•Key list ID

R7-98 Authenticator in Access Control Field

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall convey the authenticator in the CMIP access control field.

7.8.3.3Data Origin Authentication

R7-99.1 Subsequent Messages Contain Access Control Field

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall ensure that every subsequent CMIP message that contains the access control field carries the authenticator.

R7-99.2 Separate Counter for Association Sequence Numbers

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall verify that each party maintains a separate sequence number counter for each association it uses to send messages.

22

R7-99.3 Increment Sequence Numbers

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall verify that every time the authenticator is used the value of the sequence number will be incremented by one.

7.8.3.4Integrity and Non-repudiation

R7-100.1 Security Field

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall ensure that all the notifications defined for the number portability application contain a security field.

R7-100.2 Security Field Syntax

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall ensure that the syntax of the security field used for the notification corresponds to the authenticator.

R7-101.1 Digital Signature Applied

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall ensure that the digital signature applies to all the fields in the notification, except the security field, in the order in which they appear, followed by the sender’s identity.

R7-101.2

(Duplicate - refer to R7-91.1)

R7-101.3

(Duplicate - refer to R7-91.2)

R7-101.4

(Duplicate - refer to R7-91.3)

R7-101.5

(Duplicate - refer to R7-91.4)

23

R7-102 Notifications in Confirmed Mode

NPAC SMS shall ensure that all the notifications are sent in the confirmed mode.

R7-103 MISSING in RFP

7.8.3.5Access Control

R7-104 Responsible for Access Control

NPAC SMS shall be responsible for access control on the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.

R7-105.1

(Duplicate - refer to R7-97 and R7-98)

R7-105.2 Generalized Time

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall ensure that external messages received have a generalized time in the access control information within 5 minutes of the NPAC SMS system clock.

7.8.3.6Audit Trail

R7-106 Log Contents

SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall keep a log (as defined in ISO/EC 10164 parts 6 and 8, 1992) of all of the following:

•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)

•all incoming messages that may cause changes to the NPAC SMS database.

24

7.8.3.7Key Exchange

R7-107.1 Lists of Keys

NPAC SMS shall ensure that during a security key exchange, each party provide the other with a list of keys.

R7-107.2 Keys in Electronic Form

NPAC SMS shall provide the list of keys in a secure electronic form.

R7-107.3 Paper copy of MD5 Hashes of the Keys

NOT A SYSTEM REQUIREMENT- CANNOT BE TESTED

The originator of the list of keys shall also provide the receiver with signed (in ink) paper copy of the MD5 hashes of the keys in the list.

R7-107.4 Key List Exchange

NPAC SMS shall support exchange of the list of keys in person or remotely.

R7-107.5 Remote Key List Exchange

NPAC SMS shall convey the lists via two different channels, diskette sent via certified mail, and a file sent via Email or FTP using encryption mechanisms if the keys are exchanged remotely.

R7-108.1 Remote Reception Acknowledgment

NPAC SMS shall support the Service Providers’ acknowledgment via 2 secure electronic forms, Email or FTP using encryption mechanisms.

R7-108.2 Acknowledgment Contents

NPAC SMS shall support the acknowledgment consisting of the MD5 hash of each one of the keys in the list.

R7-108.3 Phone Confirmation

NOT A SYSTEM REQUIREMENT- CANNOT BE TESTED

The recipient shall call the sender by phone for further confirmation and provide the sender with the MD5 hash of the whole list.

25

R7-109.1 Periodic Paper List of Public Keys NPAC Uses

NPAC SMS shall generate a paper list to each Service Provider of the MD5 hashes of all the public keys used by a Service Provider once a month.

R7-109.2 Acknowledgment of Paper List of Public Keys

NPAC SMS shall verify the identity of the Service Provider to whom the MD5 hashes of the public keys was sent.

R7-110.1 List Encryption Keys

NPAC SMS shall provide each Service Provider with a numbered list of encryption keys, numbered from 1 to 1000.

R7-110.2

(Duplicate - refer to R7-107.2)

R7-110.3 List Encryption Keys

NPAC SMS shall ensure unique numbering of the keys.

R7-111.1 New Encryption Key Can Be Chosen

NPAC SMS shall allow a new encryption key to be chosen with every message that contains a key identifier.

R7-111.2 Keys Not Reused

NPAC SMS shall reject messages that use a key whose usage has stopped.

R7-111.3 Compromised Keys

NPAC SMS shall allow authorized NPAC SMS personnel to initiate a new key for messages.

26

R7-111.4 Key Change Once Per Year

NPAC SMS shall change the key used between the NPAC SMS and Service Provider after one year of usage.

R7-111.5 Key Size Increase Per Year

NPAC SMS shall allow NPAC SMS personnel to change key sizes for Service Providers as needed to ensure secure communications between the NPAC SMS and the Service Providers.

R7-111.6 Per Service Provider Basis

NPAC SMS shall expect new key initiation to be requested on a per Service Provider basis.

RR7-1 Load Key List

NPAC SMS shall be able to load a new key list in 15 minutes or less.

RN7-1 Authenticator Contents - Individual System Clock Accuracy

NPAC SMS shall be responsible for ensuring that the system clock is accurate to within two minutes of GMT.

RN7-2 Authenticator Contents - Zero Sequence Number

A sequence number equal to zero shall be required for association request and association response messages.

RR7-2 Modifying User Name

NPAC SMS shall provide a mechanism for authorized NPAC personnel to change a user name in the NPAC SMS.

27

Audit Administration

8.Audit Administration

An audit function will be necessary for troubleshooting a customer problem and also as a maintenance process to ensure data integrity across the entire LNP network. Audit will be concerned with the process of comparing the NPAC view of the LNP network with one or more of the Service Provider’s view of its network.  In the case of “on demand” audits, audits may be initiated by any Service Provider who has reason to believe a problem may exist in another Service Provider’s network.  Such audits are executed via queries to the appropriate Service Provider’s network, and corrected via downloads to those same networks.  Requirements pertaining to these requirements are given in Sections 8.1 through 8.5.

With audits, two different scenarios are supported, one designed to “sync up” the information contained in the various Local SMS databases with the content of the NPAC SMS database, the other for the NPAC to perform random integrity checks of its own database.

The local SMS will be responsible for comparing database extracts written to an FTP site by the NPAC SMS with its own version of that same data.  Note that the Service Provider network may contain several network nodes designated for local number portability and may also choose to keep its own copy in its respective SMS.  In the second scenario, the NPAC SMS will select a random sample of active Subscription Versions from its own database, then compare those samples to the representation of that same data in the various Local SMS databases.  Requirements pertaining to periodic audits are given in Section 8.6.

A8-1 Service Provider Audits Issued Immediately

NPAC SMS will process audit requests from service providers immediately.

8.1Service Provider User Functionality

R8-1 Service Providers Audit Request - Single TN

NPAC SMS shall receive an audit request on a single telephone number from the Service Providers.

1

R8-2.1 Service Providers Audit Request - Range of TNs

NPAC SMS shall receive an audit request for a range of telephone numbers from the Service Providers.

R8-2.2

DELETE

R8-3 Service Providers Specify Audit Scope

NPAC SMS shall allow Service Providers to specify the scope of an audit by specifying one or more of the following parameters:

•Specific Service provider network or ALL Service Providers networks

•Full audit for all LNP attributes or a partial audit where the Service Provider can specify one or more of the following LNP attributes:

• LIDB data

• CLASS data

• LRN data

• CNAM data

• ISVM data

Default: Full audit

8.2NPAC User Functionality

R8-4 NPAC Personnel Audit Request - Single TN

NPAC SMS shall allow NPAC personnel to issue an audit request on a single telephone number.

R8-5.1 NPAC Personnel Audit Request - Range of TNs

NPAC SMS shall allow NPAC personnel to issue an audit request for a range of telephone numbers.

2

R8-5.2

DELETE

R8-6.1 Specify an Immediate Audit Request

NPAC SMS shall provide NPAC personnel and users of the SOA to NPAC SMS interface the capability to issue an audit request to be executed immediately.

R8-6.2

DELETE

R8-7.1

DELETE

R8-7.2

DELETE

R8-7.3

DELETE

R8-8

DELETE

R8-9 NPAC Personnel Specify Audit Scope

NPAC SMS shall allow NPAC SMS Personnel to specify the scope of an audit by specifying one or more of the following parameters:

•Specific Service Provider network or ALL Service Providers networks.

•Full audit for all LNP attributes or a partial audit where the Service Provider can specify one or more of the following LNP attributes:

• LIDB data

• CLASS data

• LRN data

• CNAM data

3

• ISVM data

Default: Full audit

•Specify an activation Date/Time stamp range, i.e., only audit records activated between a specific time window.

R8-10 NPAC Personnel Status of Audit Request

NPAC SMS shall allow NPAC personnel to obtain the final results of an audit request.

R8-11 Audit Progress Indicators

NPAC SMS shall indicate the progress of an audit as the percentage of records audited, when supplying the status of an audit request.

R8-12 NPAC Personnel Cancel of an Audit

NPAC SMS shall allow NPAC personnel to cancel an audit request.

R8-13

DELETE

R8-14.1

DELETE

R8-14.2

DELETE

8.3System Functionality

R8-15.1 NPAC Personnel View of ALL Audit Requests

NPAC SMS shall allow NPAC Personnel to view ALL audit requests including requests issued by the Service Providers.

4

R8-15.2 Mechanized SOA Interface Obtain Audit Requests

NPAC SMS shall allow the mechanized SOA interface to obtain all audit requests issued from that particular mechanized SOA interface.

R8-15.3 Send Audit Results to Originating SOA

NPAC SMS shall send audit results to the originating SOA.

R8-16.1 Flow of Audit Execution

NPAC SMS shall send the query resulting from the audit request to the local Service Providers’ networks via the NPAC SMS to Local SMS interface described in the NPAC SMS Interoperable Interface Specifications.

R8-16.2

DELETE

R8-16.3

DELETE

R8-16.4

DELETE

R8-17.1 Compare NPAC SMS Subscription Versions to Service Provider Subscription Versions

NPAC SMS shall conduct a comparison of the Subscription Versions belonging to the Service Provider to its own Subscription Versions.

R8-17.2 Add TNs to Service Provider Subscription Versions

NPAC SMS shall, following the comparison of its own Subscription Versions to the Service Provider’s Subscription Versions, add any TN found to be absent back into the Service Provider’s Subscription Version database.

R8-17.3 Modify Erroneous TNs

NPAC SMS shall, following the comparison of its own Subscription Versions to the Service Provider’s Subscription Versions, modify any TN found to be in error.

5

R8-17.4 Delete Discrepant TNs from Service Provider Subscription Versions

NPAC SMS shall, following the comparison of its own Subscription Versions to the Service Provider’s Subscription Versions, delete any discrepant TNs from the Service Provider’s Subscription Version database.

R8-18

(Duplicate - refer to R8-7.3)

R8-19 Record Audit Results in an Audit Log

NPAC SMS shall record all audit results in an audit log.

8.4Audit Report Management

R8-20 Service Providers Audit Retrieval

NPAC SMS shall allow NPAC personnel and Service Provider personnel to retrieve an audit report for a specific audit request.

R8-21.1 Generate an Audit Report

NPAC SMS shall be capable of generating an audit report for each audit request that has been requested.

R8-21.2 Audit Report Contents

NPAC SMS shall generate an audit report indicating the one of the following:

•Audit request parameters which identified the scope of the audit.

•Date and Time of Audit.

•Progress indication.

•Service Provider network which contains database conflict.

•A difference indicator which indicates one of the following:

• mismatch between the NPAC SMS and local SMS

• record missing in local SMS

6

• an audit failure

• no discrepancies found

R8-22 NPAC Personnel Generate and View an Audit Report

NPAC SMS shall allow NPAC personnel and SOA to NPAC SMS interface to generate and view an audit report on-line.

R8-23.1 NPAC Personnel View an In-progress Audit Report

NPAC SMS shall allow NPAC personnel to view an audit report while the audit is in progress so the current audit results can be viewed on-line up to this point.

R8-23.2 Service Providers View Results of Audits They Have Requested

NPAC SMS shall ensure that Service Providers can only view the results of those audits which they have requested.

R8-24

(Duplicate - refer to R9-2)

R8-25 NPAC Personnel Specify Time Audit Results Retained

NPAC SMS shall allow NPAC personnel to specify the length of time audit results will be retained in the audit log.

8.5Requirements in the Proposal

RP8-1 Valid Audit Statuses

NPAC SMS shall support the following valid audit statuses:

•In-progress

•Canceled

•Complete

7

8.6Database Integrity Sampling

RR8-1 Random Sampling of Active Subscription Versions

NPAC SMS shall select a random sample of active Subscription Versions to query over the NPAC SMS to Local SMS interface to monitor NPAC SMS data integrity.

RR8-2.1 Data Integrity Sample Size - Tunable Parameter

NPAC SMS shall provide a Data Integrity Sample Size tunable parameter which is defined as the number of active Subscription Versions in the sample to monitor NPAC SMS data integrity.

RR8-2.2 Data Integrity Sample Size - Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Data Integrity Sample Size tunable parameter.

RR8-2.3 Data Integrity Sample Size - Tunable Parameter Default

NPAC SMS shall default the Data Integrity Sample Size tunable parameter to 1000.

8

Reports

9.Reports

9.1Overview

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.

9.2User Functionality

R9-1 NPAC Personnel Report Selection

NPAC SMS shall allow NPAC personnel using the NPAC Operations GUI to select the type of report required.

R9-2 NPAC Personnel Selection of Output Destination

NPAC SMS shall allow NPAC personnel using the NPAC Operations GUI to select the predefined report output destination. Destinations are printer, file system, email, display or FAX.

R9-3 NPAC Personnel Re-print of Reports

NPAC SMS shall allow NPAC personnel using the NPAC Operations GUI to re-print reports from previously saved report outputs.

R9-4 NPAC Personnel Create Customized Reports

NPAC SMS shall allow NPAC personnel to create customized reports through an ad-hoc facility.

1

R9-5 NPAC Personnel Define Scope and Filtering

NPAC SMS shall allow NPAC personnel to define scope and filtering for items to be included in the customized reports.

R9-6 Service Providers Receive Reports on Their Activities

NPAC SMS shall allow Service Provider personnel to receive reports on information related to their activities.

R9-7 Not a Functional Requirement

Vendors must provide examples of report outputs.

RP9-1 Service and Network Data Reports

NPAC SMS shall support the following service and network data reports for NPAC personnel and Service Provider personnel using the NPAC Operations GUI:

1.NPAC Service Tunable Parameters Report

2.List of Service Provider’s LRNs

3.Open NPA-NXXs List

RP9-2 Service Provider Reports

NPAC SMS shall support the following Service Provider reports for NPAC and Service Provider personnel using the NPAC Operations GUI:

4.Service Provider Profile (Service Provider’s own data only)

5.Service Provider’s Subscription List by Status (Service Provider’s own data only)

RP9-3 Subscription Data Reports

NPAC SMS shall support the following subscription data reports for NPAC and Service Provider personnel using the NPAC Operations GUI:

6.Subscriptions Listed by Status

7.Subscriptions Listed by Service Provider by Status

2

RP9-4 System Reports

NPAC SMS shall support the following system reports for NPAC system administration personnel using the NPAC Operations GUI:

8.Overall CPU System Utilization

9.Storage Utilization

10.NPAC SMS Application Performance (Downloads per Second)

11.NPAC SMS Application Performance (Subscription Activation Time)

12.NPAC SMS-SOA Link Utilization

13.NPAC SMS-LSMS Link Utilization

14.NPAC SMS Application Performance (SOA/LSMS Response Time)

15.NPAC SMS Application Performance (Interface Transaction Rate)

16.NPAC SMS Application Performance (Provider SMS Database Sampling)

RP9-5 Security Reports

NPAC SMS shall support the following security reports for NPAC security administration personnel using the NPAC Operations GUI:

17.Access Privileges Matrix

18.Authorized Users List

19.Security Log

20.Invalid Access Attempts

21.Encryption Keys List

RP9-6 Log File Reports

NPAC SMS shall support the following log file reports for NPAC personnel using the NPAC Operations GUI:

22.History Report

23.Error Report

24.Service Provider Notification Report

25.Subscription Transaction Report

26.Service Provider Administration Report

27.Subscription Administration Report

3

RP9-7 Audit Reports

NPAC SMS shall support an Audit Results Report.

RP9-8 Regularly Scheduled Reports

NPAC SMS shall support the generation of regularly scheduled standard or ad hoc reports, to be provided at the request of a Service Provider.

RR9-1 Data Integrity Report

NPAC SMS shall generate an NPAC SMS data integrity report.

9.3System Functionality

R9-8

(Duplicate - refer to R9-2)

R9-9 Verification of User Privileges

NPAC SMS shall verify whether the user requesting the report has the proper viewing privileges for the selected data.

R9-10 Support of On-line File Transfer

NPAC SMS shall support on-line file transfer capabilities to transfer report files.

R9-11 Transaction History Log

NPAC SMS shall maintain a History Log to keep track of transactions processed.

R9-12.1 Error Log - Transaction Errors

NPAC SMS shall maintain an Error Log to keep track of transaction errors.

R9-12.2 Error Log - Transmission Errors

NPAC SMS shall maintain an Error Log to keep track of transmission errors.

4

R9-12.3

(Duplicate - refer to RP9-5 number 20)

R9-13

(Duplicate - refer to R9-2)

5

Performance and Reliability

10.Performance and Reliability

This section defines the reliability, availability, performance and capacity requirements for the NPAC SMS. The NPAC SMS will be designed for high reliability, including fault tolerance and data integrity features, symmetrical multi-processing capability, and allow for economical and efficient system expansion.

Note that throughout this section, “downtime” refers to the unavailability of the NPAC service.  This is to be distinguished from cases where users can still switch to a backup machine.

The following are the availability, reliability, performance and capacity requirements for the NPAC SMS system.

10.1Availability and Reliability

R10-1 System Availability

NPAC SMS shall be available 24 hours a day, 7 days a week with the exception of scheduled downtime and unscheduled downtime within the time frame defined in R10-3 and R10-5.

R10-2 System Reliability

NPAC SMS shall be 99.9 percent reliable. This applies to functionality and data integrity.

R10-3 Unscheduled Downtime

NPAC SMS shall have unscheduled downtime per year less than or equal to 9 hours.

1

R10-4 Mean Time to Repair for Unscheduled Downtime

NPAC SMS shall support a mean time to repair of less than or equal to 1 hour, for unscheduled downtime.

R10-5 Scheduled Downtime

NPAC SMS shall have NPAC initiated, scheduled downtime of less than or equal to 24 hours per year.

AR10-1 Scheduled Downtime

NPAC initiated downtime as defined in R10-5 does not include downtime needed for software release updates initiated by or collectively agreed to by the Service Providers.

R10-6.1 Communication Link Monitoring

NPAC shall be capable of monitoring the status of all of its communication links.

R10-6.2 Detecting Communication Link Failures

NPAC shall be capable of detecting and reporting all communication link failures.

R10-7 Detecting Single Bit Data Transmission Errors

NPAC SMS shall be capable of detecting and correcting single bit errors during data transmission between hardware components (both internal and external).

R10-8 Continue Transaction Processing After Downtime

NPAC SMS shall complete processing of all sending transactions at the time of system failure when the NPAC SMS resumes processing.

R10-9.1 Self Checking Logic

NPAC SMS shall support functional components with on board automatic self checking logic for immediate fault locating.

2

R10-9.2 Continuous Hardware Checking

NPAC SMS shall support continuous hardware checking without any performance penalty or service degradation.

R10-9.3 Duplexing of Hardware

NPAC SMS shall support duplexing of all major hardware components for continuous operation in the event of a system hardware failure.

R10-9.4 Transparent Hardware Fault Tolerance

NPAC SMS shall support hardware fault tolerance that is transparent to the Service Providers.

R10-10.1 Service Provider Notification of System Unavailability

NPAC SMS shall notify Service Providers of the system unavailability via the NPAC SMS to Local SMS interface if the system becomes unavailable for normal operations due to any reason, including both scheduled and unscheduled maintenance.

R10-10.2 System Availability Notification Method

NPAC SMS shall notify Service Providers via their contact numbers if electronic communication is not possible.

R10-10.3 System Availability Notification Contents

NPAC SMS shall include the following information in the notification:

•the functionality that is unavailable

•the reason for the downtime

•when the down time will start

•when the down time will stop

•switch to backup or disaster recovery machine required

•an NPAC contact number

3

R10-11 Updates Highest Priority

NPAC SMS shall ensure the capability of receiving, processing and broadcasting updates will be given the highest priority during any maintenance, if resources allow only partial functionality.

R10-12.1 Tolerance to Communication Link Outages

NPAC SMS shall provide tolerance to communication link outages and offer alternate routing for such outages.

R10-12.2 Alternate routing

NPAC SMS shall offer alternate routing during communication link outages.

R10-13.1 Switch to Backup or Disaster Recovery Machine

NPAC SMS shall, in cases where Service Providers have been switched to a backup or disaster recovery machine, adhere to a maximum time to repair of 4 hours for the primary machine.

R10-13.2 Time to Switch Machines

NPAC SMS shall ensure that the time to switch the Service Providers to another machine and provide full functionality must not exceed the mean time to repair.

R10-13.3 Total Disaster Recovery

NPAC SMS shall restore the capability of receiving, processing and broadcasting updates within 24 hours in the event of a disaster that limits the ability of both the NPAC and NPAC SMS to function.

R10-13.4 Full Functionality Restored

NPAC SMS shall restore full functionality within 48 hours, in the event of a disaster that limits both the NPAC and NPAC SMS ability to function.

R10-14 Reports on Reliability

NPAC shall provide reliability reports documenting the following:

•schedule down time

4

•unscheduled down time

•mean time to repair

•system availability on a monthly basis to the Service Provider

10.2Capacity and Performance

R10-15 Number of Service Providers

NPAC SMS shall allow for a minimum of 30 Service Providers each having one SOA to NPAC SMS interface and one NPAC SMS to Local SMS interface.

A10-1 Initial Turn-up Number of Service Providers

On initial turn-up, there will be 10 Service Providers each having one SOA to NPAC SMS interface and one NPAC SMS to Local SMS interface.

R10-16 Capacity

NPAC SMS will have the capacity to support a user group in the NPAC sized for 30 Service Providers.

R10-17 Number of Ported Numbers Supported

NPAC SMS shall be capable of initially handling 200,000 ported numbers.

A10-2 Unknown Number of Updates

The number of updates due to mass changes, the number of audit requests and the number of report requests is not known at this time.

R10-18 History File Data Storage

NPAC SMS shall ensure that the data storage of the History file must keep track of all transactions made for a tunable parameter period of time (default of one year).

A10-3 Churn of Accumulated Records

It is assumed that there will be thirty percent churn of accumulated records.

5

R10-19 Broadcast Update Response Time

NPAC SMS shall ensure that from the time an activation notice, modification or deletion request is received from a Service Provider until the time the broadcast of the update is started to all Service Provider local SMS will be less than 60 seconds.

R10-20 Request/Transaction Response Time

NPAC SMS, under normal operating conditions, shall ensure that the response time from when a request or transaction is received in the system to the time an acknowledgment is returned will be less than 3 seconds for 95% of all transactions. This does not include the transmission time across the interface to the Service Providers’ SOA or Local SMS.

R10-21 Future System Growth

NPAC SMS shall be expandable to handle future growth due to circumstances described as follows:

•Added areas of portability

•Added Service Providers

10.3Requirements in RFP Not Given a Unique ID

RN10-1 Allowable Connection to Backup

NPAC SMS shall ensure that Service Providers cannot connect to the backup machine if the primary machine is available.

RN10-2 Return to the Primary Machine SOA Notification

NPAC SMS shall send an electronic notification to the Service Provider’s SOA indicating the time the NPAC will switch them back to the primary machine.

RN10-3 Return to the Primary Machine Local SMS Notification

NPAC SMS shall send an electronic notification to the Service Provider’s Local SMS indicating the time the NPAC will switch them back to the primary machine.

6

RN10-4 Database Sync After Return to the Primary Machine

NPAC SMS shall sync up the database in its primary SMS with any updates sent to the backup or disaster recovery machine during the downtime.

7

Appendix A: Business Process Flows

11.Billing

A11-1

DELETE

A11-2 Accounting Measurements Will Not Degrade the Basic System Performance

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

11.1User Functionality

R11-1 Toggling the Generation of Usage Measurements

NPAC SMS shall allow the NPAC administrator to turn on and off the recording of Service Provider usage statistics for the service elements.

11.2System Functionality

R11-2  Generating Usage Measurements for NPAC Resources

NPAC SMS shall measure and record the usage of NPAC resources on a per Service Provider basis.

R11-3 Generating Usage Measurements for Allocated Connections

NPAC SMS shall generate usage measurements for allocated connections for each Service Provider.

R11-4 Generating Usage Measurements for Allocated Mass Storage

NPAC SMS shall generate usage measurements for the allocated mass storage (number of records stored) for each Service Provider.

A-1

R11-5 Generating Usage Measurements for the Number of Transactions Processed

NPAC SMS shall measure the number of transactions processed for each Service Provider.

R11-6 Generating Usage Measurements for the Number of Transactions Downloaded

NPAC SMS shall measure the number of transactions downloaded to each Service Provider.

R11-7

(Duplicate - refer to RP11-5)

R11-8 Generating Detailed Usage Measurement Reports

NPAC shall produce detailed NPAC usage reports for the contracting entity.

R11-9 Billing Report Types

NPAC SMS shall be capable of creating the following billing reports:

•Login Session Per User ID

•Allocated Mass Storage

•Transactions Processed (to include download data and data resent by request)

•Audits Requested and Processed

•Requested Report Generation

•Service Establishment (to include Service Provider establishment, user login ID addition to the NPAC SMS, and mechanized Interface Activation)

R11-10 Full Billing Report

The NPAC SMS shall be capable of creating a full billing report, with all of the report types in R11-9 included.

A-2

R11-11 Billing Report Creation by NPAC Personnel

NPAC SMS shall allow NPAC personnel to create billing reports for all Service Provider usage. For all report types in R11-9 and R11-10, the NPAC personnel will be able to specify whether the report is an aggregation/summary of stored data or a detailed report containing every item stored for the report type.

R11-12 Billing Report Creation by Service Provider

NPAC SMS shall allow Service Providers to gather billing report data on only their NPAC SMS usage. Service Providers will not be able to create reports on any other Service Provider’s usage. For all report types in R11-9 and R11-10, the NPAC SMS shall create an aggregation/summary of stored data for the report type.

R11-13 NPAC Personnel Billing Report Destination

NPAC SMS shall allow NPAC personnel to determine the output destination of the billing report. The destinations will include: on-line (on screen), printer, file, or FAX. The default selection is on-line.

R11-14 Service Provider Billing Report Destination

NPAC SMS shall allow Service Provider users to determine the output destination of the billing report. The destinations will include: on-line (on screen) or file. The default selection is on-line.

R11-15 NPAC Personnel Only Can Access Billing System

The NPAC billing system shall be accessible only to NPAC personnel.

11.3Requirements Defined in the Proposal

RP11-1 Service Element Usage Records

NPAC SMS shall generate service element usage records representing the use or invocation of a single instance of a potentially billable service element.  As a minimum, service element records capture the following information:

•Date/time of service element invoked.

•Service element category (on demand, recurring, one time).

•Service element type.

A-3

•Service element subtype, where appropriate (e.g., type of transactions, such as audit, activate, download, etc.).

•Quantity, if multi-service element usage is indivisible (e.g. grouped operation), otherwise defaults to 1.

•TN (telephone number) or other information identifying subject of service.

•Requesting Service Provider.

RP11-2 Aggregation of Resource Accounting Records into Service Element Usage Records

NPAC SMS shall generate service element usage records by aggregating and processing detailed resource accounting records on a periodic basis.

RP11-3 Flexible Service Element Usage Definition

The aggregation function on the NPAC SMS shall permit flexible definition of service elements and their association to the underlying resource accounting records.  Multiple resource accounting records may be associated with the creation of a single service element usage event.

RP11-4 Service Element Record Export

The NPAC SMS shall make service element record datasets available in a format that may be imported into a third party billing system.  Such a billing system may not necessarily execute on the NPAC SMS hardware platform itself.

RP11-5 Initial Types of Service Elements

The initial set of service elements to be generated by the NPAC SMS shall be:

Category	Type	Sample Subtypes	Metric
Monthly	Dial-up Port	• ISDN	Dial-up port reserved or dialup number allocated.
		• V.34
	Dedicated Port	• ISDN	Nailed-up connection port.
		• DS-0 x n
		• DS-1
	Database Record	-	subscription version record (any state) stored in database.

A-4

Category	Type	Sample Subtypes	Metric
Per Request	Transaction	• Subscription create	Transaction of subtype indicated
		• Activate
		• Cancel
		• Download
		• Audit
		• Resend
	Reports	• Download	Report generated.
		• TNs active
		• Audits
	Support Call	• Phone call	NPAC user support contact/request initiated.
		• Email
		• fax
	Ad Hoc Report	-	Number of hours of report development time.
Non-recurring	Service establishment	-	New Service Provider activation as NPAC user.
	Log-on Id	-	New log-on id assigned.
	Mechanized interface activation	-	New mechanized interface activated.

RP11-6 Service Element Usage Aggregation

The NPAC billing system shall accept service element usage records and aggregate service elements for a time period (e.g., month) into the following types of categories, and combinations of these categories:

1.By service element category and type.

2.By Service Provider (NPAC user company).

3.By type or group of Service Provider (e.g., LLC member vs. non-member).

4.By usage-level threshold amounts (separates basic service element usage levels from higher discretionary amounts, e.g., for audits).

RP11-7 Service Element Rating

For each of the aggregate service element category counts, the NPAC billing system shall support the capability to apply a service element price to each

A-5

category combination identified in the service element pricing schedule (e.g., by service element type by Service Provider type by usage-level threshold amount).

RP11-8 Discounting

Within a given price schedule category, the NPAC billing system shall support the capability to apply volume discounts to service element quantities in that category.  Discounts will be defined as a percentage discount applied or separate price for quantities ‘n’ through ‘m’ of the service element usage for the period, where ‘n’ is the quantity at which the discount bracket starts and where ‘m’ is the start of the next discount bracket, if one exists, or is unlimited if not.

RP11-9 Flexible Service Element Categorization, Rating, and Discounting

The NPAC billing system shall support the capability to provide flexible service element rating, enabling price schedule amounts, rating category definitions, and discounts, to be modified without software changes.

RP11-10 Miscellaneous Transactions

The NPAC billing system shall support the capability to provide a means, via a user interface, for the entering, editing, or deleting of manual billing entries for miscellaneous activities such as training, task order billing, and manual adjustments, for example.  Manual entries must be specified with sufficient information that unambiguously enables them to be categorized, rated, and rendered on an invoice.  Information such as that identified in RP11-1 should be captured.

RP11-11 Minimums Applied

The NPAC billing system shall provide the capability to calculate if total amounts due within or across certain categories fall below certain minimum amounts.  If so, a miscellaneous transaction will be generated which will bring the sum totals due in those categories to the minimum required amount.

RR11-12 Cost Re-Apportionment

The NPAC billing system shall support the capability to enable the total amounts due in certain categories to be aggregated and re-apportioned amongst certain groups of individual companies (e.g., LLC member companies) in proportion to a specified basis, such as proportion of portable TNs or proportion of portable NXXs.  Where cost re-apportionment is performed, explicit calculation of the re-apportionment must be detailed on the invoice statement.  Both service element-based

A-6

amounts as well as minimum calculations may be subject to re-apportionment.

RR11-13 Cost Aggregation

The NPAC billing system shall support the capability to enable classes of NPAC user companies to be grouped and invoiced as a whole, e.g., invoice an LLC for all LLC member company’s usage.

RR11-14 Discretionary Amounts

The NPAC billing system shall, in categorizing and aggregating service element usage records, support the capability to be able to group usage for certain service elements into a shared-group category (i.e., one subject to cost aggregation or apportionment) and overflow service element usage amounts over a tunable parameter per-company threshold into NPAC user company-specific categories (accounts).  This enables certain basic usage levels to be subject to cost aggregation or apportionment, while forwarding costs for usage above those levels to the specific requesting company.

RR11-15 Non-member Rating

The NPAC billing system shall support the capability to provide service element categorization and category-specific pricing so as to allow differential prices for the same types of service elements provided to different classes of NPAC user companies, e.g., allow different prices for LLC member companies vs. non-member companies.

RR11-16 Non-member Subsidization

The NPAC billing system shall support the capability to enable adjustment transactions to a category (e.g., LLC member costs subject to re-apportionment) whose amount is determined by a per unit amount applied to another category’s volume.  This enables cross-category subsidization or cost apportionment, such as might be used to by LLC member companies to subsidize non-member use of the NPAC.

RR11-17 Discount Volume Aggregation

The NPAC billing system shall support the capability to allow discount bracket quantities to be derived from a different category than the category whose unit price is subject to discounts.  This enables volumes for per-request service elements (e.g., transactions) to be aggregated between user groups or companies prior to applying discounts to usage actually incurred by that company or group.

A-7

RP11-18 Invoice Rendering

The NPAC billing system shall support the capability to render invoices reporting the amounts of service element usage by category applicable to the invoiced entity (LLC, LLC member, or non-member company), indicating also all miscellaneous entries, minimums applied, discounts, payment credits, adjustments, late fees, and cost apportionments or aggregation applied.

RP11-19 Accounts Receivable Tracking

The NPAC billing system shall support the capability to track all invoices rendered using an accounts receivable tracking capability, and track and report all invoice amounts due.  Current, overdue, negative and positive, account balances for all NPAC user companies receiving invoices will be tracked.

RP11-20 Payment Credits

The NPAC billing system shall support the capability to note all payments received, either from invoiced companies or other entities, and reflect such payments in the accounts receivable tracking and note such received payments on the next applicable invoice.

RP11-21 Receivables Aging

The NPAC billing system shall support the capability to age receivables (past due invoice amounts) and generate appropriate dunning notices and calculate late payment penalties, where applicable.

RP11-22 Financial Accounting Integration

The NPAC billing system shall support the capability to integrate with a financial accounting system, including export and import of account activity, invoice amounts, and payment events.

RP11-23 Billing System Internal Operations

The NPAC billing system shall support the capability to provide an operations interface, enabling personnel to perform various normal billing system functions, as well as administrative and maintenance functions.  Normal billing system functions include obtaining resource accounting records, generating service element usage records, executing rating and categorization processes, generating invoices and internal reports, and exporting data to an integrated financial accounting system.  Administration and maintenance activities include backup, restore, and updating billing system process definitions (such as price schedules,

A-8

category definitions, matrix formulas, minimums, discounts, and apportionment formula).

Appendix A.Business Process Flows

This appendix contains pictorial representations of the business process flows discussed in Section 2, Business Process Flows.

[Graphics Omitted: Pictorial representations of process flows described]

A-9

Appendix B.  Glossary

Appendix B.Glossary

This glossary provides a comprehensive list of definitions and acronyms that apply to NPAC SMS.

APDU	Application Protocol Data Unit
ASN.1	Abstract Syntax Notation 1
BAU	Business As Usual
BER	Basic Encoding Rules
CARE	Customer Account Record Exchange
CER	Canonical Encoding Rules
CLASS	Custom Local Area Signaling Services. Premium local service features, such as call forwarding or automatic callback.
CME	Conformance Management Entity
CMIP	Common Management Information Protocol
CMISE	Common Management Information Service Element
CNAM	Caller Id with Name
DER	Distinguished Encoding Rules
DES	Data Encryption Standard
DPC	Destination Point Code
FR	Frame Relay
GDMO	Generalized Definitions of Managed Objects
GMT	Greenwich Mean Time
GTT	Global Title Translation
ICC	Illinois Commerce Commission
IEC	International Electrotechnical Commission
ISO	International Organization of Standardization
ISVM	Inter-Switch Voice Mail
KEK	Key Encryption Key

B-1

LIDB	Line Information Database
LNP	Local Number Portability
LRN	Location Routing Number. A proposed implementation solution for providing LNP which utilizes AIN triggers, SS7 signaling, and unique 10-digit code for switch identification. LRN has been endorsed by the Illinois LNP Task Force and major network telecommunications vendors as an optimum long term implementation solution for Local Number Portability.
LSMS	Local Service Management System
LSPP	Local Service Provider Portability
MAC	Media Access Control
MD5	Message Digest (Version 5)
NANP	North American Numbering Plan. A 10-digit numbering scheme used in North America to uniquely identify a directory number.
NE	Network Element
NMF	Network Management Forum
NPA	Numbering Plan Area
NPAC Customer	Any customer of the NPAC SMS.
NPAC SMS	Number Portability Administration Center and Service Management System
NSAP	Network Layer Service Access Point
NXX	Exchange
OCN	Operating Company Number
OSI	Open Systems Interconnect
OG	Operational GUI
PKCS	Public Key Crypto System
POP	Point-Of-Presence. Location in which a long distance company has installed transmission equipment that serves as, or relays calls to, a network switching center of that long distance company.
Ported TN	A TN ported to a switch that is not the NANP-assigned switch.

B-2

PPP	Point-To-Point Protocol
PSAP	Presentation Layer Service Access Point
RFP	Request for Proposal
RSA	A popular encryption algorithm whose name is derived from the initials of its inventors: Rivest, Shamir, and Adelman.
SCP	Service Control Point
SMS	Service Management System
SOA	Service Order Activation
SP	Service Provider. Generally refers to a facilities-based user of the NPAC SMS.
SSAP	Session Layer Service Access Point
SSN	Subsystem Number
STP	Signal Transfer Point. A packet switch that transmits messages between switches and other network components. Also transmits messages between switches in the process of normal call set-up and routing.
TCAP	Transaction Capabilities Action Part. A message protocol for the SS7 network.
TMN	Telecommunications Management Network
TN	Telephone Number
TSAP	Transport Layer Service Access Point
Version	Time-sensitive or status-sensitive instance of a subscription.

B-3

Appendix C.  System Tunables

Appendix C.System Tunables

This appendix provides a comprehensive list of tunables identified throughout the FRS and their default values.

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Initial Concurrence Window	SP_Initial_Concurrence_Window	18	hours	1-72
The hours subsequent to the time the subscription version was initially created by which both Service Providers are expected to authorize transfer of service if this is an Inter-Service Provider or “porting to original” port.
Final Concurrence Window	SP_Final_Concurrence_Window	18	hours	1-72
The number of hours after the concurrence request is sent by the NPAC SMS by which time both Service Providers are expected to authorize transfer of subscription service for an Inter-Service Provider or “porting to original” port.
Conflict Expiration Window	SV_Conflict_Cancellation _Window	30	days	1-180
The length of time conflict subscriptions will remain in the conflict state before cancellation.
Maximum Subscriber Query	Max_Subscriber_Query	50	records	10-150
The maximum number of active subscription versions returned by a query to the NPAC.
Pending Subscription Retention	Pending_SV_Cancellation	90	days	1-180
The length of time pending subscriptions will remain in the pending state before cancellation.

C-1

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Conflict Resolution-Initial Concurrence Window	Conflict_Resolution_Initial_Ack _Window	4	hours	1-72
The number of hours after the version is set to conflict resolution pending by which both Service Providers are expected to acknowledge the conflict resolution.
Conflict Resolution-Final Concurrence Window	Conflict_Resolution_Final_Ack _Window	4	hours	1-72
The number of hours after the second conflict resolution pending notification is sent, by which both Service Providers are expected to acknowledge the conflict resolution.
Cancellation-Initial Concurrence Window	Cancellation_Initial_Ack _Window	4	hours	1-72
The numbers of hours after the version is set to cancel pending by which both Service Providers are expected to acknowledge the pending cancellation.
Cancellation-Final Concurrence Window	Cancellation_Final_Ack_Window	4	hours	1-72
The number of hours after the second cancel pending notification is sent by which both Service Providers are expected to acknowledge the pending cancellation.
Old Subscription Retention	Purge_Old_SV	18	months	1-36
The length of time old subscriptions will be retained.
Cancel-Pending Subscription Retention	Purge_Canceled_Pending_SV	90	days	1-360
The length of time canceled subscriptions, with last status of pending, will be retained.

C-2

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Cancel-Conflict Subscription Retention	Purge_Canceled_Conflict_SV	30	days	1-360
The length of time canceled subscriptions, with last status of conflict, will be retained.
Cancel-Conflict Resolution Pending Retention	Purge_Canceled_Conflict _Resolution_Pending_SV	30	days	1-360
The length of time canceled subscriptions, with last status of conflict resolution pending, will be retained.
Cancel-Disconnect Pending Retention	Purge_Canceled_Disconnect _Pending_SV	90	days	1-360
The length of time canceled subscriptions, with last status of disconnect pending, will be retained.

Table 11-1 Subscription Tunables

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Subscription Activation Retry Attempts	Subscription_Version_Activation_Retry	3	attempts	1-10
The number of times a new subscription version will be sent to a Local SMS which has not acknowledged receipt of the activation request.
Subscription Activation Retry Interval	Subscription_Version_Activation _Retry_Interval	2	minutes	1-60
The delay between sending new Subscription Versions to a Local SMS that has not acknowledged receipt of the activation request.

C-3

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Subscription Modification Retry Attempts	Subscription_Version _Modification_Retry	3	attempts	1-10
The number of times a modified active subscription version will be sent to a Local SMS which has not acknowledged receipt of the modification request.
Subscription Modification Retry Interval	Subscription_Version_Modification_Retry_Interval	2	minutes	1-60
The delay between sending modified active subscription versions to a Local SMS that has not acknowledged receipt of the modification request.
Subscription Disconnect Retry Attempts	Subscription_Version_Disconnect _Retry	3	attempts	1-10
The number of times the NPAC SMS will resend a subscription disconnect message to an unresponsive Local SMS.
Subscription Disconnect Retry Interval	Subscription_Version_Disconnect _Retry_Interval	2	minutes	1-60
The amount of time that shall elapse between subscription disconnect retries.
Local SMS Retry Attempts	LSMS_Retry_Attempts	3	attempts	1-10
The default number of times the NPAC SMS will resend a message to an unresponsive Local SMS.
Local SMS Retry Interval	LSMS_Retry_Interval	2	minutes	1-60
The default delay between sending messages to an unresponsive Local SMS.
SOA Retry Attempts	SOA_Retry_Attempts	3	attempts	1-10
The default number of times the NPAC SMS will resend a message to an unresponsive SOA.

C-4

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
SOA Retry Interval	SOA_Retry_Interval	2	minutes	1-60
The default delay between sending messages to an unresponsive SOA.
Failed Login Attempts	Failed_Login_Attempts	3	attempts	0-10
The number of allowable incorrect logon attempts
Failed Login Shutdown Period	Failed_Login_Shutdown_Period	60	seconds	0-300
The amount of time the NPAC SMS will wait to restart the logon process after a user has exceeded the Failed_Login_Attempts tunable.
Unused User Id Disable Period	Unused_User_Id_Disable_Period	60	days	1-360
The number of days for which a userid has not been used before the NPAC SMS disables that userid.
Password Age Limit	Password_Age_Limit	90	days	1-360
The amount of time for password aging.
Password Expiration Notice	Password_Expiration_Notice	7	days	1-30
The amount of time prior to a password expiring that the NPAC SMS will notify a user.
Post Expiration Logins	Post_Expiration_Logins	2	logins	0-10
The number of logins a user is permitted after the user’s password has expired.
Password Reuse Limit	Password_Reuse_Limit	6	months	1-36
The amount of time in which a password cannot be reused.

C-5

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Record Logons After Failure	Record_Logons_After_Failure	10	attempts	0-100
The threshold for consecutive failed logon attempts after which logon attempts will be recorded in the audit log.
Non-Use Disconnect	Non_Use_Disconnect	60	minutes	1-1440
The amount of idle (non-use) time before the NPAC SMS will disconnect a user’s logon session.

Table 11-2 Communications Tunables

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Canceled Audit Retention Period	Canceled_Audit_Retention _Period	30	days	1-360
The length of time canceled audits will be retained.
Data Integrity Sample Size	Data_Integrity_Sample_Size	1000	SVs	1-5000
The number of active Subscription Versions in a sample to be monitored by the NPAC SMS.

Table 11-3 Audit Tunables

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Local SMS Activation Log Retention Period	Local_SMS_Activation_Log_Duration	90	days	1-360
The number of days Local SMS activation responses will remain in the log.

C-6

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Audit Log Retention Period	Audit_Log_Retention_Period	90	days	1-360
The length of time audit logs will be retained.
Error Log Retention Period	Error_Log_Retention_Period	90	days	1-360
The length of time system error logs will be retained.
History File Data Storage	History_File_Data_Storage	90	days	1-360
The length of time history logs will be retained.
Usage Log Retention	Usage_Log_Retention	90	days	1-360
The length of time usage logs will be retained.

Table 11-4 Logs Tunables

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Key Change Interval	Key_Change_Interval	7	days	1-365
How often the key is changed automatically.
Reverification Acknowledgment Period	Reverification_Acknowledgment _Period	3	days	0-30
The maximum number of days allowed for the reverification acknowledgment period.

Table 11-5 Keys Tunables

C-7

EXHIBIT  C

NANC NPAC/SMS INTEROPERABLE

INTERFACE SPECIFICATION

NPAC/SMS SERVICES

[Due to its length, this document is not attached.
The IIS is available on the internet at
http://www.npac.com/docs/iis1001.doc
A copy is also

available upon request for the cost of copying and handling from
NECAC, by request made to the attention of Carville Collins]

[Information referred to in this exhibit immediately follows this page.]

NPAC SMS

INTEROPERABLE INTERFACE SPECIFICATION

Version 1.0

Final

Prepared for:
The Illinois Commerce Commission SMS Subcommittee

By:

Lockheed Martin IMS and Evolving Systems, Inc. (ESI)

October 1, 1996

NPAC SMS

INTEROPERABLE INTERFACE SPECIFICATION

Version 1.0

Final

Prepared for:
The Illinois Commerce Commission SMS Subcommittee

By:

Lockheed Martin IMS and Evolving Systems, Inc. (ESI)

October 1, 1996

© 1996 LOCKHEED MARTIN IMS CORPORATION

The Work is subject to the terms of the GNU General Public License (the “GPL”), a copy of which may be found at ftp://prep.ai.mit.edu/pub/gnu/GPL.  Any use of this Work is subject to the terms of the GPL.  The “Work” covered by the GPL by operation of this notice and license is this document and any and all modifications to or derivatives of this document. Where the words “Program,” “software,” “source code,” “code,” or “files” are used in the GPL, users understand and agree that the “Work” as defined here is substituted for purposes of this notice and license.

Table Of Contents

1. Introduction
1.1. DOCUMENT OVERVIEW
1.2. HOW TO USE THIS DOCUMENT
1.3. DOCUMENT VERSION HISTORY
1.4. REFERENCES
	1.4.1. Standards
	1.4.2. Related Publications
1.5. ABBREVIATIONS/DEFINITIONS
2. Interface Overview
2.1. OVERVIEW
2.2. OSI PROTOCOL SUPPORT
2.3. SOA TO NPAC SMS INTERFACE
	2.3.1. Subscription Administration
	2.3.2. Audit Requests
	2.3.3. Notifications
	2.3.4. Service Provider Data Administration
2.4. NPAC SMS TO LOCAL SMS INTERFACE
	2.4.1. Subscription Version and Network Data Download
	2.4.2. Service Provider Data Administration
	2.4.3. Notifications
3. Hierarchy Diagrams
3.1. OVERVIEW
	3.1.1. Managed Object Model Inheritance Hierarchy
	3.1.2. Log Record Managed Object Hierarchy
	3.1.3. NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS
	3.1.4. NPAC SMS to Local SMS Naming Hierarchy for the Local SMS
	3.1.5.SOA to NPAC SMS Naming Hierarchy for the NPAC SMS
4. Interface Functionality to CMIP Definition Mapping
4.1. OVERVIEW
	4.1.1. Primary NPAC Mechanized Interface Operations
	4.1.2. Managed Object Interface Functionality
	4.1.3. Attribute Interface Functionality
	4.1.4. Action Interface Functionality
	4.1.5. Notification Interface Functionality
5. Secure Association Establishment
5.1. OVERVIEW
5.2. SECURITY
	5.2.1. Authentication and Access Control Information
		5.2.1.1. System Id

October 1, 1996	Version 1.0 Final	NPAC SMS Interoperable Interface Specification
ã 1996 LOCKHEED MARTIN IMS CORPORATION

i

				5.2.1.2. System Type
				5.2.1.3. User Id
				5.2.1.4. List Id
				5.2.1.5. Key Id
				5.2.1.6. CMIP Departure Time
				5.2.1.7. Sequence Number
				5.2.1.8. Signature
				5.2.1.9. Association Functions
				5.2.1.10. Recovery Mode
	5.2.2. Association Establishment
	5.2.3. Data Origination Authentication
	5.2.4. Audit Trail
5.3. ASSOCIATION MANAGEMENT AND RECOVERY
	5.3.1. Establishing Associations
			5.3.1.1. Error Handling
			5.3.1.2. NPAC SMS Behavior
			5.3.1.3. Service Provider SOA and Local SMS Procedures
	5.3.2. Releasing or Aborting Associations
	5.3.3. CMIP Error Handling
	5.3.4. Resynchronization
		5.3.4.1. Local SMS Resynchronization
		5.3.4.2. SOA Resynchronization
6. Message Flow Diagrams
6.1. OVERVIEW
6.2. AUDIT SCENARIOS
	6.2.1. SOA Initiated Audit
	6.2.2. SOA Initiated Audit Cancellation by the SOA
	6.2.3. SOA Initiated Audit Cancellation by the NPAC
	6.2.4. NPAC Initiated Audit
	6.2.5. NPAC Initiated Audit Cancellation by the NPAC
	6.2.6. Audit Query on the NPAC
6.3. SERVICE PROVIDER SCENARIOS
	6.3.1. Service Provider Creation by the NPAC
	6.3.2. Service Provider Deletion by the NPAC
	6.3.3. Service Provider Modification by the NPAC
	6.3.4. Service Provider Modification by the Local SMS
	6.3.5. Service Provider Modification by the SOA
	6.3.6. Service Provider Query by the Local SMS
	6.3.7. Service Provider Query by the SOA
	6.3.8. NPA-NXX Scenarios
					6.3.8.1. NPA-NXX Creation by the NPAC
					6.3.8.2. NPA-NXX Deletion by the NPAC
					6.3.8.3. NPA-NXX Creation by the Local SMS
					6.3.8.4. NPA-NXX Creation by the SOA
					6.3.8.5. NPA-NXX Deletion by the Local SMS
					6.3.8.6. NPA-NXX Deletion by the SOA
					6.3.8.7. NPA-NXX Query by the Local SMS
					6.3.8.8. NPA-NXX Query by the SOA
	6.3.9. LRN Scenarios

ii

						6.3.9.1. LRN Creation by the NPAC
						6.3.9.2. LRN Creation by the SOA
						6.3.9.3. LRN Deletion by the SOA
						6.3.9.4. LRN Query by the SOA
						6.3.9.5. LRN Deletion by the NPAC
						6.3.9.6. LRN Creation by the Local SMS
						6.3.9.7. LRN Deletion by the Local SMS
						6.3.9.8. LRN Query by the Local SMS
						6.3.9.9. Network Data Download
						6.3.9.10. Scoped/Filtered GET of Network Data
6.4. SUBSCRIPTIONVERSION FLOW SCENARIOS
			6.4.1. SubscriptionVersion Create Scenarios
					6.4.1.1. SubscriptionVersion Create by the Initial SOA (Old Service Provider)
					6.4.1.2. SubscriptionVersion Create by the Initial SOA (New Service Provider)
					6.4.1.3. SubscriptionVersion Create by Second SOA (New Service Provider)
					6.4.1.4. SubscriptionVersion Create by Second SOA (Old Service Provider)
					6.4.1.5.SubscriptionVersion Activated by New Service Provider SOA
					6.4.1.6. Active SubscriptionVersion Create on Local SMS
					6.4.1.7. Active Subscription Version Create on Local SMS Using Create Action
					6.4.1.8. SubscriptionVersion Create: No Create Action from a SOA After Concurrence Window
					6.4.1.9. Subscription Version Create: Failure to Receive Response from Old SOA
					6.4.1.10. Subscription Version Create: Failure to Receive Response from New SOA
					6.4.1.11. SubscriptionVersionCreate M-CREATE Failure to Local SMS
		6.4.2. SubscriptionVersion M-CREATE: Partial Failure to Local SMS
		6.4.3. Modify Scenarios
					6.4.3.1. SubscriptionVersion Modify Active Version Using M-ACTION by a Service Provider SOA
		6.4.4. SubscriptionVersion Modify Prior to Activate Using M-ACTION
					6.4.4.1. SubscriptionVersion Modify Prior to Activate Using M-SET
		6.4.5. Cancel Scenarios
					6.4.5.1. SubscriptionVersion Cancel by Service Provider SOA
					6.4.5.2. SubscriptionVersionCancel: No Acknowledgment from a SOA
			6.4.6. Disconnect Scenarios
				6.4.6.1. SubscriptionVersion Immediate Disconnect
				6.4.6.2. SubscriptionVersion Disconnect With Effective Release Date
	6.4.7. Conflict Scenarios
				6.4.7.1. SubscriptionVersion Conflict and Conflict Resolution Pending by the NPAC SMS
				6.4.7.2. Subscription Version Conflict Resolution Pending by the New Service Provider SOA
			6.4.8. SubscriptionVersion Conflict: No Acknowledgment from SOA
			6.4.9. SubscriptionVersion Conflict: No Conflict Resolution
			6.4.10. SubscriptionVersion Create for Intra-Service Provider Port
			6.4.11. SubscriptionVersion Query
			6.4.12. Subscription Data Download
6.5. MISCELLANEOUS
			6.5.1. Sequencing of Events on Initialization/Resynchronization of Local SMS
6.6. SOA/Local SMS Notification of Scheduled NPAC Downtime
			6.6.1. NPA-NXX Split
6.7. Mass Update
7. GDMO Definitions
7.1. OVERVIEW
7.2. OBJECT DEFINITIONS
7.3. NAME BINDING DEFINITIONS
7.4. ATTRIBUTE DEFINITIONS
7.5. PACKAGE DEFINITIONS

iii

7.6. PARAMETER DEFINITIONS
7.7. ACTION DEFINITIONS
7.8. NOTIFICATION DEFINITIONS
8. General ASN.1 Definitions
8.1. OVERVIEW
8.2. LNP ASN.1 OBJECT IDENTIFIER DEFINITIONS
8.3. LNP GENERAL ASN.1 DEFINITIONS
9. Managed Object Conformance Statements
9.1. OVERVIEW
9.2. LNPAUDITS TABLES
	9.2.1. lnpAudits Packages
	9.2.2. lnpAudits Name Bindings
	9.2.3. lnpAudits Attributes
	9.2.4. lnpAudits Actions
	9.2.5. lnpAudits Notifications
9.3. LNPLOCALSMS TABLES
	9.3.1. lnpLocalSMS Packages
	9.3.2. lnpLocalSMS Name Bindings
	9.3.3. lnpLocalSMS Attributes
	9.3.4. lnpLocalSMS Actions
	9.3.5. lnpLocalSMS Notifications
9.4. LNPLOGAUDIT-DISCREPANCYRPTRECORD TABLES
	9.4.1. lnpLogAudit-DiscrepancyRptRecord Packages
	9.4.2. lnpLogAudit-DiscrepancyRptRecord Name Bindings
	9.4.3. lnpLogAudit-DiscrepancyRptRecord Attributes
	9.4.4. lnpLogAudit-DiscrepancyRptRecord Actions
	9.4.5. lnpLogAudit-DiscrepancyRptRecord Notifications
9.5. LNPLOGAUDITRESULTSRECORD TABLES
	9.5.1. lnpLogAuditResultsRecord Packages
	9.5.2. lnpLogAuditResultsRecord Name Bindings
	9.5.3. lnpLogAuditResultsRecord Attributes
	9.5.4. lnpLogAuditResultsRecord Actions
	9.5.5. lnpLogAuditResultsRecord Notifications
9.6. LNPLOGCANCELLATIONACKNOWLEDGEREQUESTRECORD
	9.6.1. lnpLogCancellationAcknowledgeRequest Packages
	9.6.2. lnpLogCancellationAcknowledgeRequest Name Bindings
	9.6.3. lnpLogCancellationAcknowledgeRequest Attributes
9.7. LNPLOGCONFLICTRESOLUTIONACKNOWLEDGEREQUESTRECORD
	9.7.1. lnpLogConflictResolutionAcknowledgeRequest Packages
	9.7.2. lnpLogConflictResolutionAcknowledgeRequest Name Bindings
	9.7.3. lnpLogConflictResolutionAcknowledgeRequest Attributes
9.8. LNPLOGNEWSP-CREATEREQUESTRECORD TABLES
	9.8.1. lnpLogNewSP-CreateRequestRecord Packages
	9.8.2. lnpLogNewSP-CreateRequestRecord Name Bindings

iv

	9.8.3. lnpLogNewSP-CreateRequestRecord Attributes
	9.8.4. lnpLogNewSP-CreateRequestRecord Actions
	9.8.5. lnpLogNewSP-CreateRequestRecord Notifications
9.9. LNPLOGOLDSP-CONCURRENCEREQUESTRECORD TABLES
	9.9.1. lnpLogOldSP-ConcurrenceRequestRecord Packages
	9.9.2. lnpLogOldSP-ConcurrenceRequestRecord Name Bindings
	9.9.3. lnpLogOldSP-ConcurrenceRequestRecord Attributes
	9.9.4. lnpLogOldSP-ConcurrenceRequestRecord Actions
	9.9.5. lnpLogOldSP-ConcurrenceRequestRecord Notifications
9.10. LNPLOGOPERATIONAL-INFORMATIONRECORD TABLES
	9.10.1. lnpLogOperational-InformationRecord Packages
	9.10.2. lnpLogOperational-InformationRecord Name Bindings
	9.10.3. lnpLogOperational-InformationRecord Attributes
	9.10.4. lnpLogOperational-InformationRecord Actions
	9.10.5. lnpLogOperational-InformationRecord Notifications
9.11. LNPLOGSTATUSATTRIBUTEVALUECHANGERECORD TABLES
	9.11.1. lnpLogStatusAttributeValueChangeRecord Packages
	9.11.2. lnpLogStatusAttributeValueChangeRecord Name Bindings
	9.11.3. lnpLogStatusAttributeValueChangeRecord Attributes
	9.11.4. lnpLogStatusAttributeValueChangeRecord Actions
	9.11.5. lnpLogStatusAttributeValueChangeRecord Notifications
	9.11.6. lnpNetwork Packages
	9.11.7. lnpNetwork Name Bindings
	9.11.8. lnpNetwork Attributes
	9.11.9. lnpNetwork Actions
	9.11.10. lnpNetwork Notifications
9.12. LNPNPAC-SMS TABLES
	9.12.1. lnpNPAC-SMS Packages
	9.12.2. lnpNPAC-SMS Name Bindings
	9.12.3. lnpNPAC-SMS Attributes
	9.12.4. lnpNPAC-SMS Actions
	9.12.5. lnpNPAC-SMS Notifications
9.13. LNPSERVICEPROVS TABLES
	9.13.1. lnpServiceProvs Packages
	9.13.2. lnpServiceProvs Name Bindings
	9.13.3. lnpServiceProvs Attributes
	9.13.4. lnpServiceProvs Actions
	9.13.5. lnpServiceProvs Notifications
9.14. LNPSUBSCRIPTIONS TABLES
	9.14.1. lnpSubscriptions Packages
	9.14.2. lnpSubscriptions Name Bindings
	9.14.3. lnpSubscriptions Attributes
	9.14.4. lnpSubscriptions Actions
	9.14.5. lnpSubscriptions Notifications
9.15. SERVICEPROV TABLES
	9.15.1. serviceProv Packages
	9.15.2. serviceProv Name Bindings
	9.15.3. serviceProv Attributes
	9.15.4. serviceProv Actions

v

	9.15.5. serviceProv Notifications
9.16. SERVICEPROVLRN TABLES
	9.16.1. serviceProvLRN Packages
	9.16.2. serviceProvLRN Name Bindings
	9.16.3. serviceProvLRN Attributes
	9.16.4. serviceProvLRN Actions
	9.16.5. serviceProvLRN Notifications
9.17. SERVICEPROVNETWORK TABLES
	9.17.1. serviceProvNetwork Packages
	9.17.2. serviceProvNetwork Name Bindings
	9.17.3. serviceProvNetwork Attributes
	9.17.4. serviceProvNetwork Actions
	9.17.5. serviceProvNetwork Notifications
9.18. SERVICEPROVNPA-NXX TABLES
	9.18.1. serviceProvNPA-NXX Packages
	9.18.2. serviceProvNPA-NXX Name Bindings
	9.18.3. serviceProvNPA-NXX Attributes
	9.18.4. serviceProvNPA-NXX Actions
	9.18.5. serviceProvNPA-NXX Notifications
9.19. SUBSCRIPTIONAUDIT TABLES
	9.19.1. subscriptionAudit Packages
	9.19.2. subscriptionAudit Name Bindings
	9.19.3. subscriptionAudit Attributes
	9.19.4. subscriptionAudit Actions
	9.19.5. subscriptionAudit Notifications
9.20. SUBSCRIPTIONVERSION TABLES
	9.20.1. subscriptionVersion Packages
	9.20.2. subscriptionVersion Name Bindings
	9.20.3. subscriptionVersion Attributes
	9.20.4. subscriptionVersion Actions
	9.20.5. subscriptionVersion Notifications
9.21. SUBSCRIPTIONVERSIONNPAC TABLES
	9.21.1. subscriptionVersionNPAC Packages
	9.21.2. subscriptionVersionNPAC Name Bindings
	9.21.3. subscriptionVersionNPAC Attributes
	9.21.4. subscriptionVersionNPAC Actions
	9.21.5. subscriptionVersionNPAC Notifications
10. Subscription Version Status
Appendix A: Errors

vi

Introduction

1.Introduction

1.1.Document Overview

The NPAC SMS Interoperable Interface Specification contains the information model for the Number Portability Administration Center and Service Management System (NPAC SMS) mechanized interfaces. Both Service Order Activation (SOA) and Local Service Management System (LSMS or Local SMS) interfaces to the NPAC SMS are described in this document.

1.2.How To Use This Document

The NPAC SMSInteroperable Interface Specification contains the following chapters:

Chapter 1 Introduction — This chapter describes the conventions and organization of this document. It also lists related documentation.

Chapter 2 Interface Overview — This chapter contains an overview of protocol requirements and a brief description of the functionality provided in each interface.

Chapter 3 Hierarchy Diagrams — This chapter contains the class hierarchy diagrams for all managed objects defined in the interoperable interface.

Chapter 4 Interface Functionality to CMIP Definition Mapping — This chapter contains the mapping of the interface functionality to the managed objects, attributes, actions, and notifications.

Chapter 5 Secure Association Establishment— This chapter contains information on secure association establishment.

Chapter 6 Message Flow Diagrams — This chapter contains the message flow diagrams.

Chapter 7 GDMO Definitions — This chapter contains the GDMO interface definitions supporting the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface

Chapter 8 General ASN.1 Definitions — This chapter contains the ASN.1 definitions that support the GDMO definitions in Chapter 7.

Chapter 9 Managed Object Conformance Statements — This chapter contains the Managed Object Conformance tables.

Chapter 10 Subscription Version Status — This chapter contains a Subscription Version Status diagram, which illustrates the transition from one subscription version state to another.

Appendix A Errors — This appendix contains the valid errors associated with CMISE confirmed primitives used in the interoperable interface definitions.

1

1.3.Document Version History

Version 1.0 released on 8/15/96.

Version 1.0 Draft 3, released on 9/17/96.

Version 1.0 FINAL, released on 10/01/96, contains the following changes:

Global:

•Miscellaneous typographical and formatting corrections.

Chapter 1:

•In Section 1.3 Document History, remove the bullet for Section 9 under the September 16, 1996 updates.

Chapter 2:

•In Section 2.2 OSI Protocol Support, changed OSI protocol stack to HP OTS9000.

•In Section 2.3 SOA to NPAC SMS Interface, added “service provider and network” information to functionality.

•In Section 2.3.1 Subscripton Administration, added “or range of versions” to modify, activate and disconnect bullets.

•In Section 2.3.4 and 2.4.2 Service Provider Administration, added [as well] “as add and delete” [their own network data].

Chapter 3:

•In Section 3.1.4 NPAC SMS to Local SMS Naming Hierarchy for the Local SMS, fixed formatting.

•In Exhibit 5 The NPAC SMS to Local SMS Naming Hierarchy for the Local SMS, removed lnpAudits container.

Chapter 4:

•In all exhibits, removed reference to NPAC SMS to Local SMS interface in releation to audit functionality..

•In Exhibit 8 for the serviceProvLRN and serviceProvNPA-NXX, changed “service provider’s switch” to “service provider”.

Chapter 5:

•In Exhibit 13, removed subscriptionAuditLSMS reference.

•In 5.1.2., Association Establishment, removed bullet related to audit functional group.

Chapter 6:

•In 6.5.1.5 Subscription Version Activated by New Service Provider SOA, added support in item a for a tn-range.

•In 6.5.1.6.2 Subscription Version Create: No Create Action from a SOA After Concurrence Window, corrected formatting.

•In 6.5.1.7 Subscription Version Create M-CREATE Failure to Local SMS, changed ‘failure’ to ‘failed’ in flow diagram items and supporting text.

•In 6.6.1 Sequencing of Events on Initialization/Resynchronization of Local SMS, corrected spacing on items b and d in the diagram.

•In 6.5.1.3 Subscription Version Create by Second SOA (New Service Provider), change M-CREATE to M-SET and ‘object creation’ to ‘attributeValueChange’.

Chapter 7:

•Created subscriptionLocalSMS-Create action.

•Created subscriptionLocalSMS-Create package.

2

•Created subscriptionLocalSMS-CreateResults notification.

•Modified the operational notification to only have the following fields: downTime, npacContactNumber, additionalDownTimeInformation and accessControl.

•Modified the lnpLogOperational-InformationRecord.

•Add versionStatus to the modify action.

•Add TN range to action request data for activate, disconnects and modifies.

•Removed Local SMS references from lnpAuditsBehavior.

•In the subscriptionVersion object, clarified definition of subscriptionActivationTimeStamp and subscriptionCustomerDisconnectDate.

Chapter 8:

•Renamed DPC-Optional to DPC. Changed dpc-value type from ‘DPC’ to ‘OCTET STRING (SIZE(3))’.

•Renamed SSN-Optional to SSN. Changed ssn-value type from ‘SSN’ to ‘INTEGER(0...255)’.

•Added to ActivateAction the choice of tn and subscription version id OR tn-range.

•Added to DisconnectAction the choice of tn and subscription version id OR tn-range.

•Added to ModifyAction the choice of tn and subscription version id OR tn-range and status.

•Removed dependency between LRN and NPA-NXX data in the lnpDownLoadReply.

•Removed switch-to-backup, ReasonCode and FunctionalityUnavailble variables.

•Renamed ‘outageTime’ to ‘downTime’ and ‘additionalOutageInformation’ to ‘additionalDownTimeInformation’.

•Added create action supporting data.

•Removed  ‘processAudits’ from LSMSUnits type of association functions.

Chapter 9:

•Updated for gdmo additions and deletions.

•Add top class attributes to all objects.

Chapter 10:

•Updated per requirement changes related to the subscription version status attribute.

Appendix A:

•Add resourceLimitation definition and usage.

1.4.References

1.4.1.Standards

ANSI T1.224-1992, Operations, Administration, Maintenance, and Provisioning (OAM&P) - Protocols for Interfaces between Operations Systems in Different Jurisdictions.

ANSI T1.243-1995, Telecommunications, Operations, Administration, Maintenance and Provisioning (OAM&P) - Baseline Security Requirements for the Telecommunications Management Network (TMN).

ANSI 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).

Belcore TA- 1253, Generic Requirements for Operations Interfaces Using OSI Tools: Network Element Security Administration.

3

Committee T1 Technical Report No, 40, Security Requirements for Electronic Bonding Between Two TMNs.

ISO/IEC 11183-1:1992, Information Technology - International Standardized Profiles AOM ln OSI Management - Management Communications - Part 1  Specification of ACSE, Presentation and Session Protocols for the use by ROSE and CMISE.

ISO/IEC 11183-2:1992, Information Technology - International Standardized Profiles AOM ln OSI Management - Management Communications - Part 2:  CMISE/ROSE for AOM12 - Enhanced Management Communications.

ISO/IEC 11183-3:1992, Information Technology - International Standardized Profiles AOM ln OSI Management - Management Communications - Part 3: CMISE/ROSE for AOM12 - Basic Management Communications.

ITU X.509, Information Technology - Open Systems Interconnection - The Directory Authentication Framework.

ITU X.690/ISO IS 8825-1 Annex D, ASNI/BER Encoding of Digital Signatures and Encrypted Cyphertext.

ITU X.741, OSI Systems Management, Objects and Attributes for Access Control

ITU X.803, Upper Layers Security Model.

NMF Forum 016, Issue 1.0, 1992, OMNIPoint 1 Specifications and Technical Reports, Application Services Security of Management.

OIW Stable Implementation Agreement, Part 12, 1995.

Rec. M.3100:1992 & 1995 draft, Generic Network Information Model.

Rec. X.701 | ISO/IEC 10040:1992, Information Technology - Open System Interconnection - Common Management Overview.

Rec. X.710 | ISO/IEC 9595:1990, Information Technology - Open System Interconnection - Common Management Information Service Definitions.

Rec. X.711 | ISO/IEC 9596-1:1991, Information Technology - Open System Interconnection - Common Management Information Protocol - Part 1: Specification.

Rec. X.720 | ISO/IEC 10165-1:1991, Information Technology - Open System Interconnection - Structure of Management Information - Part 1 Management Information Model.

Rec. X.721 | ISO/IEC 10165-2:1992, Information Technology - Open System Interconnection - Structure of Management Information:  Guidelines for the Definition of Managed Objects.

Rec. X.722 | ISO/IEC 10165-4:1992, Information Technology - Open System Interconnection - Structure of Management Information:  Guidelines for the Definition of Managed Objects.

Rec. X.730 | ISO/10164-1:1992, Information Technology - Open System Interconnection - System Management - Part 1:  Object Management Function.

Rec. X.734 | ISO/10164-5:1992, Information Technology - Open System Interconnection - System Management - Part 5:  Event Report Management Function.

Rec. X.735 | ISO/10164-6:1992, Information Technology - Open System Interconnection - System Management - Part 6:  Log Control Function.

Rec. X.209:  1988, Specification for Basic Encoding Rules for Abstract Syntax Notation One (ANS.1).

Rec. X.690:  1994, ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER).

4

Rec. X.208:  1988, Specification of Abstract Syntax Notation One (ASN.1).

Rec. X.680 | ISO/IEC 8824-1:  1994, Information Technology - Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation.

Rec. X.680 Amd.1 | ISO/IEC 8824-1 Amd.1, Information Technology - Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation 1 Amendment 1:  Rules of Extensibility.

ITU-T Recommendations are available from the US Department of Commerce, National Technical Information Service, 5285 Port Royal Road, Springfield, VA 22161.  ISO standard are available from the American National Standards Institute, 11 West 42nd Street, New York, NY 10036.

1.4.2.Related Publications

Illinois Commerce Commission Number Portability Administration Center and Service Management System Request for Proposal (ICC NPAC/SMS RFP), February 6, 1996.

Lockheed Martin Team Response to the Illinois Commerce Commission Number Portability Administration Center and Management System Request for Proposal, March 18, 1996.

Scoggins, Sophia and Tang, Adrian 1992. Open networking with OSI. Englewood Cliffs, NJ, Prentice-Hall.

Stallings, William 1993. SNMP, SNMPv2, and CMIP, The Practical Guide to Network-Management Standards, Reading Massachusetts, Addison-Wesley.

5

1.5.Abbreviations/Definitions

A-PDU	Application Protocol Data Unit
ASN.1	Abstract Syntax Notation 1
BER	Basic Encoding Rules
CARE	Customer Account Record Exchange
CER	Canonical Encoding Rules
CLASS	Custom Local Area Signaling Services
CME	Conformance Management Entity
CMIP	Common Management Information Protocol
CMISE	Common Management Information Service Element
CNAM	Caller Id with Name
GDMO	Generalized Definitions of Managed Objects
DER	Distinguished Encoding Rules
DES	Data Encryption Standard
FR	Frame Relay
IEC	International Electrotechnical Commission
ISO	International Organization of Standardization
ISVM	Inter-Switch Voice Mail
LIDB	Line Information Database
LNP	Local Number Portability
LRN	Location Routing Number
LSMS	Local Service Management System
LSPP	Local Service Provider Portability
MAC	Media Access Control
MD5	Message Digest (Version 5)
NE	Network Element
NMF	Network Management Forum
NPAC SMS	Number Portability Administration Center and Service Management System
NPA	Numbering Plan Area
NXX	Exchange
OCN OSI	Operating Company Number Open Systems Interconnect
PPP	Point-To-Point Protocol
RFP	Request for Proposal
RSA	Encryption Scheme
SOA	Service Order Activation
TMN	Telecommunications Management Network
SMS	Service Management System
TN	Telephone Number

6

Interface Overview

2.Interface Overview

2.1.Overview

This specification defines the interfaces between the NPAC SMS and the service providers’ Service Order Entry System and Local SMS.  The interfaces, defined using the CMIP protocol, are referred to as the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface respectively.  CMISE M-CREATE, M-DELETE, M-SET, M-GET, M-CANCEL-GET, M-EVENT-REPORT, and M-ACTION primitives are fully supported in a confirmed mode.  The relationship from the SOA to the NPAC SMS is a manager to agent relationship.  The relationship between the Local SMS to NPAC SMS is a manager to agent or an agent to manager relationship depending on the function being performed. The SOA and Local SMS interfaces are defined by Association Functions. These functions allow each association to define the services it supports. Association establishment from the SOAs and Local SMSs to the NPAC SMS, Association Function and security for each of these interfaces is discussed in Chapter 5, Secure Association Establishment.

The sections that follow provide an overview of protocol requirements and a brief description of the functionality provided in each interface.  Complete functional descriptions for the interfaces are provided in the process flow diagrams in Chapter 6, Message Flow Diagrams, as well as the behavior for the managed objects.

2.2.OSI Protocol Support

The SOA to NPAC SMS and NPAC SMS to Local SMS interfaces must be implemented over the protocol stack shown in Exhibit 1.

Exhibit 1. NPAC/SMS Primary Network Protocol Stacks

Layer	Mechanized Interface	Function
	CMIP Agent Server	User
7	CMISE, ACSE, ROSE	Application
6	ANSI T1.224	Presentation
5	ANSI T1.224	Session
4	TCP, RFC1006, TPO	Transport
3	IP	Network
2	PPP, MAC, FRAME Relay, ATM (IEEE 802.3)	Link
1	DS-1, DS-0 x n, ISDN, V.34	Physical

7

The DSET agent development tools and the Stratus RFC 1006 compliant HP OTS-9000 stack will be used to create the NPAC SMS interface used by the SOA systems and Local SMSs.  Multiple associations per service provider to the NPAC SMS can be supported.  The secure association establishment is described in Chapter 5.

2.3.SOA to NPAC SMS Interface

The SOA to NPAC SMS interface, which allows communication between a service provider’s Service Provisioning Operating Systems and/or Gateway systems and the NPAC SMS, supports the retrieval and update of subscription, service provider, and network information.  The following transactions occur to support local number portability functionality:

•SOA requests for subscription administration to the NPAC SMS and responses from the NPAC SMS to the SOA.

•Audit requests from the SOA to the NPAC SMS and responses from the NPAC SMS to the SOA.

•Notifications from the NPAC SMS to the SOA of subscription version data changes, need for concurrence or authorization for number porting, conflict-resolution, cancellation, outage information, or customer disconnect dates.

•Service provider data administration from the SOA to the NPAC SMS.

Mapping of this functionality into the CMIP Definitions is provided in Chapter 4 (see Exhibit 7.)

2.3.1.Subscription Administration

Service provider subscription administration functionality includes the capability to:

•Create a subscription version

•Cancel a subscription version

•Acknowledge cancellation of a subscription version

•Acknowledge resolution of a subscription version conflict

•Modify a subscription version or range of versions

•Retrieve a specific subscription version or range of versions

•Activate a version or range of versions

•Disconnect a subscription version or range of versions

•Remove a subscription version from conflict

2.3.2.Audit Requests

Audit functionality allows the SOAs to request audits for a subscription version or group of subscription versions based on a Telephone Number (TN) for a specified service provider or all service provider networks. The action SOA receives discrepancy reports as they are found in the network. Upon audit completion it receives a notification of the success or failure of the audit and the total number of discrepancies found.

2.3.3.Notifications

SOAs are sent notifications to ensure that they are fully informed of relevant events for their subscriptions.  Notification of creation, deletion, or data value changes for

8

subscription versions will be sent to the SOA as they occur. Notification will be sent to the SOA if the service provider has not authorized transfer of service for a TN in the number of days specified in the “Service Provider Concurrence Interval” defined on the NPAC. This notification will indicate to the service provider that authorization is needed for the pending subscription version. If the service provider has not acknowledged version conflict resolution or cancellation within a timeframe specified by the NPAC SMS, notifications will be sent requesting conflict resolution acknowledgment or cancellation acknowledgment. The donor service provider SOA is notified of the customer’s disconnect date. SOA systems are also sent notifications to insure they are aware of planned down time in the NPAC SMS.

2.3.4.Service Provider Data Administration

Service providers can use, read, and update their own service provider information on the NPAC SMS using the SOA to NPAC SMS interface.  Service providers can update information in their service provider profile as well as add and delete their own network data.  Changes to network data that result in mass updates are prevented by the NPAC SMS to SOA interface.  Mass changes must be initiated by the service provider contacting the NPAC personnel directly.

2.4.NPAC SMS to Local SMS Interface

The NPAC SMS to Local SMS interface is used for communications between a service provider’s Local SMS and the NPAC SMS for support of LNP network element provisioning.  The following transactions occur to support Local Number Portability:

•Subscription version and network data download from the NPAC SMS to the Local SMS.

•Service provider data administration from the Local SMS to the NPAC SMS.

•Notifications from the NPAC SMS to the Local SMS of planned NPAC SMS outages and the first use of a new NPA-NXX.

Mapping of this functionality into the CMIP Definitions is provided in Chapter 4 (see Exhibit 7.)

2.4.1.Subscription Version and Network Data Download

When new network (new switches, NPA-NXX, or LRN data for service providers) or subscription data is created or existing network or subscription data is modified on the NPAC SMS, the data is automatically downloaded from the NPAC SMS to the Local SMS.  The Local SMS may request that data be downloaded using a download request that is sent from the Local SMS to the NPAC SMS.  The Local SMS then receives the data to be downloaded in the request response.  Subscriber data to be downloaded can be requested based on time range, a TN, or a TN range and an optional local number portability type.  Network data to be downloaded can be requested based on a time range, service provider or all service providers, an NPA-NXX range or all NPA-NXX data, an LRN range or all LRN data, or all network data can be requested.

Service providers can also directly read data they wish to download from the NPAC SMS MIB.

2.4.2.Service Provider Data Administration

Service providers can use, read, and update their own service provider information on the NPAC SMS using the Local SMS to NPAC SMS interface.  Service providers can update

9

information in their service provider profile as well as add and delete their own network data.  Changes to network data that result in mass updates are prevented by the NPAC SMS to Local SMS interface.  Mass changes must be initiated by the service provider contacting the NPAC personnel directly.

2.4.3.Notifications

Local SMS are sent notifications to insure they are aware of planned down time in the NPAC SMS. Local SMS are also sent notifications when a new NPA-NXX is to be used for the first time in a subscription version.

10

Hierarchy Diagrams

3.Hierarchy Diagrams

3.1.Overview

The following five exhibits show the class hierarchy diagram for all managed objects (Exhibit 2), Log Record Objects (Exhibit 3), the Local SMS (Exhibit 4), the NPAC SMS naming hierarchies for the Local SMS (Exhibit 5) and the SOA (Exhibit 6.)  These exhibits will help the user gain a better understanding of the structure of the interface definitions provided.

3.1.1.Managed Object Model Inheritance Hierarchy

The Managed Object Model Inheritance Hierarchy shows the inheritance hierarchy used for object definitions in the NPAC SMS to Local SMS and the SOA to NPAC SMS interfaces.

[Exhibit 2. Graphic omitted:. Diagram of the Managed Object Model Inheritance Hierarchy.]

3.1.2.Log Record Managed Object Hierarchy

The Log Record Managed Object Hierarchy shows the inheritance hierarchy of the log records used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces.

[Exhibit 3. Graphic omitted:. Diagram of the Log Record Managed Object Hierarchy]

11

3.1.3.NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS

The NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS shows the naming hierarchy used in the NPAC SMS to instantiate objects defined in the NPAC SMS to Local SMS interface.

Shaded objects are instantiated at NPAC SMS start-up and are not created via M-CREATE or M-DELETE requests. All other objects are created at start-up from a persistent object store on the NPAC SMS or from actions taken while the NPAC SMS is running.

Each object class belongs to one or more Association Functions.

Refer to Section 5.2.1.9, Association Functions.

[Exhibit 4. Graphic omitted: Diagram of the NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS.]

12

3.1.4.NPAC SMS to Local SMS Naming Hierarchy for the Local SMS

The NPAC SMS to Local SMS Naming Hierarchy for Local SMS shows the naming hierarchy used in the Local SMS to instantiate objects defined in the NPAC SMS to Local SMS interface.

Shaded objects are instantiated at Local SMS start-up and are not created via M-CREATE or M-DELETE requests. All other objects are created at start-up from a persistent object store on the Local SMS or from actions taken while the Local SMS is running.

Each object class belongs to one or more Association Functions.
Refer to Section 5.2.1.9, Association Functions.

[Exhibit 5. Graphic omitted:. Diagram of the NPAC SMS to Local SMS Naming Hierarchy for the Local SMS.]

13

3.1.5.SOA to NPAC SMS Naming Hierarchy for the NPAC SMS

The SOA to NPAC SMS Naming Hierarchy for the NPAC SMS shows the naming hierarchy used in the NPAC SMS to instantiate objects defined in the SOA to NPAC SMS interface.

Shaded objects are instantiated at NPAC SMS start-up and are not created via M-CREATE or M-DELETE requests. All other objects are created at start-up from a persistent object store on the NPAC SMS or from actions taken while the NPAC SMS is running.

Each object class belongs to one or more Association Functions.
Refer to Section 5.2.1.9, Association Functions.

[Exhibit 6. Graphic omitted:. Diagram of the SOA to NPAC SMS Naming Hierarchy for the NPAC SMS.]

14

Interface Functionality to CMIP Definition Mapping

4.Interface Functionality to CMIP Definition Mapping

4.1.Overview

The following tables, Exhibits 7-11, contain the mapping of the interface functionality to managed objects, attributes, actions, and notifications.

4.1.1.Primary NPAC Mechanized Interface Operations

The primary interface functions in support of the NPAC requirements are described in the table below, as well as their corresponding Common Management Information Exchange (CMISE) operation and referenced object type for that operation.  This table does not include miscellaneous operations, such as service provider network data querying or downloading, etc.  These functions are described in the object behaviors in the GDMO source below.

Exhibit 2. Primary NPAC Mechanized Interface Operations Table

Function	Direction (To/From)	CMIP Operation	Referenced Object Type
Abort/Cancel Audit Request	from SOA	M-DELETE	subscriptionAudit
Audit Complete	to SOA	M-EVENT-REPORT: subscriptionAuditResults	subscriptionAudit
Audit Discrepancy	to SOA	M-EVENT-REPORT: subscriptionAuditDiscrepancyRpt	subscriptionAudit
Audit Request SOA	from SOA	M-CREATE	subscriptionAudit
Cancellation Acknowledge-ment	from SOA (new service provider)	M-EVENT-REPORT: subscription VersionNewSP CancellationAcknowledge	lnpSubscriptions
Cancellation Acknowledg-ment	from SOA (old service provider)	M-EVENT-REPORT: subscription VersionOldSPCancellationAcknowledge	lnpSubscriptions
Conflict Resolution Acknowledg-ment	from SOA (new service provider)	M-EVENT-REPORT: subscription VersionNewSP-Conflict ResolutionAcknowledge	lnpSubscriptions
Conflict Resolution Acknowledg-ment	from SOA (old service provider)	M-EVENT-REPORT: subscription VersionOldSP-Conflict ResolutionAcknowledge	lnpSubscriptions

15

Function	Direction (To/From)	CMIP Operation	Referenced Object Type
Conflict Resolution Pending	from SOA (new service provider)	M-ACTION: subscriptionVersionNewSP-ConflictResolutionPending	lnpSubscriptions
Customer Disconnect Date	to SOA	M-EVENT-REPORT: subscriptionVersionDonorSP-CustomerDisconnectDate	subscriptionVersionNPAC
Network Data Download	from LOCAL SMS	M-ACTION: lnpDownload or M-GET: scoped and filtered for intended serviceProvLRN, serviceProvNPA-NXX service provider attributes	lnpNetwork
Network Data Update	from LOCAL SMS or from SOA	M-CREATE: or M-SET: on relevant serviceProvLRN, serviceProvNPA-NXX service provider attributes	serviceProvLRN, serviceProvNPA-NXX
New NPA-NXX	to LOCAL SMS	M-EVENT-REPORT: subscriptionVersionNewNPA-NXX	subscriptionVersionNPAC
Recovery Complete	from LOCAL SMS	M-ACTION: lnpRecoveryComplete	lnpNPAC-SMS
Request for Cancellation Acknowledg-ment	to SOA	M-EVENT-REPORT: subscription VersionCancellationAcknowledgment Request	subscriptionVersionNPAC
Request for Conflict Resolution Acknowledg-ment	to SOA	M-EVENT-REPORT: subscription VersionConflictResolutionAcknowledgment Request	subscriptionVersionNPAC
Request for Version Create	to SOA (new service provider)	M-EVENT-REPORT: subscriptionVersionNewSPCreate Request	subscriptionVersionNPAC
Request for Version Create	to SOA (old service provider)	M-EVENT-REPORT: subscriptionVersionOldSPConcurrence Request	subscriptionVersionNPAC
Subscription Version Activate	from SOA	M-ACTION: subscriptionVersionActivate	lnpSubscriptions
Subscription Version Cancel	from SOA	M-ACTION subscriptionVersionCancel	lnpSubscriptions
Subscription Version Change Notification	to SOA	M-EVENT-REPORT: attributeValueChangeNotification or subscriptionVersionStatusAttributeValue Change	subscriptionVersionNPAC

16

Function	Direction (To/From)	CMIP Operation	Referenced Object Type
Subscription Version Conflict	from SOA (old service provider)	M-ACTION: subscriptionVersionOldSP-Create setting subscriptionOldSP-Authoriztion = FALSE Note: This is an enhancement based on the current IIS, superceding RFP narrative 5.1.2.2 for manual-only conflict on/off	subscriptionVersion
Subscription Version Create	to LOCAL SMS	M-ACTION: subscriptionVersionLocalSMS-Create	lnpSubscriptions
Subscription Version Create	from SOA	M-ACTION: subscriptionVersionOldSP-Create or subscriptionVersionNewSP-Create	lnpSubscriptions
Subscription Version Delete	to LOCAL SMS	M-DELETE: scoped and filtered for intended subscriptionVersion criteria	subscriptionVersion
Subscription Version Disconnect	from SOA	M-ACTION: subscriptionVersionDisconnect	lnpSubscriptions
Subscription Version Download	to LOCAL SMS	M-ACTION: subscriptionVersionLocalSMS-Create or M-CREATE: for an individual subscriptionVersion	lnpSubscriptions
Subscription Version Download Request	from LOCAL SMS	M-ACTION: lnpDownload or M-GET: scoped and filtered for intended subscriptionVersionNPAC criteria	lnpSubscriptions
Subscription Version Modify	from SOA	M-ACTION: subscriptionVersion Modify or M-SET: on relevant subscriptionVersionNPAC attributes for pending, active, conflict-pending, conflict versions	lnpSubscriptions
Subscription Version Modify	to LOCAL SMS	M-SET: scoped and filtered for intended subscriptionVersion criteria setting relevant attributes	lnpSubscriptions
Subscription Version Query	from SOA from LOCAL SMS	M-GET: scoped and filtered for intended subscriptionVersionNPAC criteria setting relevant attributes	lnpSubscriptions
Subscription Version Query	to LOCAL SMS	M-GET: scoped and filtered for intended subscriptionVersion criteria	lnpSubscriptions

17

4.1.2.Managed Object Interface Functionality

The table below contains the mapping of the SOA to NPAC SMS and the Local SMS to NPAC SMS managed objects to the interface functionality described in the RFP.

Exhibit 3. Managed Object Interface Functionality Table

Managed Object Name	Interface Functionality Mapping
lnpAudits	Container object used to contain all subscription audit objects on the NPAC SMS and the Local SMS. It is used in the SOA to NPAC SMS interface to support audit functionality.
lnpLocal SMS	Container object used to contain all objects on a Local SMS. It is used in the NPAC SMS to Local SMS interface to support NPAC SMS communication to the service provider Local SMS system.
lnpLogAudit-DiscrepancyRptRecord	Object used to log information from a subscriptionAudit-DiscrepancyRpt notification.
lnpLogAuditResultsRecord	Object used to log information from a subscriptionAuditResults notification.
lnpLogCancellation AcknowledgeRequest Record	Object used to log information from a subscriptionVersionCancellationAcknowledgeRequest notification.
lnpLogConflictResolution AcknowledgeRequest Record	Object used to log information from a subscriptionVersionConflictResolutionAcknowledgeRequest.
lnpLogNewSP-CreateRequestRecord	Object used to log information from a subscriptionVersionNewSP-CreateRequest notification.
lnpLogOldSP-ConcurrenceRequestRecord	Object used to log information from a subscriptionVersionOldSP-ConcurrenceRequest notification.
lnpLogOperational-InformationRecord	Object used to log information from a lnpNPAC-SMS-Operational-Information notification.
lnpLogStatusAttributeValueChange Record	Object used to log information from a subscriptionVersionStatusAttributeValueChange notification.
lnpNetwork	Container object used to contain all service provider network data on the NPAC SMS and the Local SMS It is used in the NPAC SMS to Local SMS interface to support downloading of network data to the Local SMS and the Lockheed Martin extended functionality that allows service providers to create/delete their network data on the NPAC SMS.
lnpNPAC-SMS	Container object used to contain all objects on a NPAC SMS. It is used in the NPAC SMS to Local SMS interface to support NPAC SMS communication from the service provider Local SMS and the SOA systems.
lnpServiceProvs	Container object used to contain all service provider data on the NPAC SMS. It is used in the NPAC SMS to Local SMS interface to support retrieving of service

18

Managed Object Name	Interface Functionality Mapping
	provider data from the Local SMS and the Lockheed Martin extended functionality that allows service providers to update their service provider data on the NPAC SMS. Service providers can only retrieve their own service provider data.
lnpSubscriptions	Container object used to contain all subscription versions on the NPAC SMS and the Local SMS. It is used in the NPAC SMS to Local SMS interface to support query of subscription data on the NPAC SMS and downloading of subscription data to the Local SMS.
serviceProv	Object used to represent a service provider and its associated data on the NPAC SMS. These objects are used in the NPAC SMS to Local SMS interface to support retrieving of service provider data from the Local SMS and the Lockheed Martin extended functionality that allows service providers to update their service provider data on the NPAC SMS except serviceProvId and serviceProvType. Service providers can only retrieve their own service provider data.
serviceProvLRN	Object used to represent an LRN associated with a service provider on the NPAC SMS or the Local SMS. These objects are used to support downloading of network LRN data to the Local SMS and the Lockheed Martin extended functionality that allows service providers to create/delete their own network LRN data. The service provider will have to add a new object and delete the old one to modify the data.
serviceProvNetwork	Container object used to contain network data for a service provider on the NPAC SMS and the Local SMS. It is used in the NPAC SMS to Local SMS interface to support downloading of network data to the Local SMS and the Lockheed Martin extended functionality that allows service providers to update their network data on the NPAC SMS.
serviceProvNPA-NXX	Object used to represent an NPA-NXX associated with a service provider on the NPAC SMS or the Local SMS. These objects are used to support downloading of network NPA-NXX data to the Local SMS and the Lockheed Martin extended functionality that allows service providers to create/delete their own network NPA-NXX data. NPA splits are supported only through direct contact with NPAC personnel.
subscriptionAudit	Object used to represent a subscription audit request on the NPAC SMS. These objects are used to support subscription audit requests from the SOA to the NPAC SMS using the SOA to NPAC SMS interface. The object supports notifications for audit discrepancies found and audit completion results.
subscriptionVersion	Object used to represent a subscription version on the Local SMS. These objects are used to support subscription version download from the NPAC SMS to the Local SMS using the NPAC SMS to Local SMS interface
subscriptionVersionNPAC	Object used to represent a subscription version on the NPAC SMS. These objects are used to support subscription administration from the SOA using the SOA to NPAC SMS interface. Capability is provided for version creation, activation, modification, cancellation, and disconnect.

4.1.3.Attribute Interface Functionality

The table below contains the mapping of the SOA to NPAC SMS and the Local SMS to NPAC SMS attributes to the interface functionality described in the RFP.

19

Exhibit 4. Attribute Interface Functionality Table

Attribute Name	Interface Requirements Mapping
accessControl	This attribute is used to define access control information for security. It is used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces.
actionResultsStatus	This attribute is used to store the status of an action that sends back an asynchronous notification with the results.
additionalDownTimeInformation	This attribute is used to provide additional information about a planned NPAC SMS outage. It is used to support the notification of operational outages to the service provider SOA and Local SMS systems using the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.
auditDiscrepancyFailureReason	This attribute is used to specify the failure reason for a discrepancy in the lnpLogAudit-DiscrepancyRptRecord.
auditDiscrepancyLSMS-SP-Id	This attribute is used to specify the service provider Id of the Local SMS on which a discrepancy was found in the lnpLogAudit-DiscrepancyRptRecord.
auditDiscrepancyTn	This attribute is used to specify the TN for which a discrepancy was found in the lnpLogAudit-DiscrepancyRptRecord.
auditDiscrepancyVersionId	This attribute is used to specify the version Id for which a discrepancy was found in the lnpLogAudit-DiscrepancyRptRecord.
auditResponseLevel	This attribute is used to store the level to which an audit was performed (SCP, Local SMS).
auditResultCompletionTime	This attribute is used to specify the completion time of an audit in the lnpLogAuditResultsRecord.
auditResultFailed-SP-List	This attribute is used to specify the list of failed service provider Local SMSs for a failed audit. It is used to support the audit functionality from the service provider SOA using the SOA to NPAC SMS interface.
auditResultNumberDiscrepancies	This attribute is used to specify the number of discrepancies found in an audit in the lnpLogAuditResultsRecord.
auditResultStatus	This attribute is used to specify the final status of an audit in the lnpLogAuditResultsRecord.
downTime	This attribute is used to specify the down time in the lnpLogOperational-InformationRecord.
failedTN-List	This attribute is used to indicate the TN(s) and errors for a failed action in the return asynchronous notification.
lnpAuditsName	This attribute is used to specify the name of the audit container. It is used to support audit functionality in the NPAC SMS using the SOA to NPAC SMS interface.
lnpLocal-SMS-Name	This attribute is used to specify the name of the Local SMS data container. It is used to support the NPAC SMS to Local SMS interface.
lnpNetworkName	This attribute is used to specify the name of the network data container. It is used to support download functionality to the

20

Attribute Name	Interface Requirements Mapping
	Local SMS in the NPAC SMS to Local SMS interface.
lnpNPAC-SMS-Name	This attribute is used to specify the name of the NPAC SMS data container. It is used to support the NPAC SMS to Local SMS interface.
lnpServiceProvsName	This attribute is used to specify the name of the service provider data container. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
lnpSpecificInfo	This attribute is used to pass specific error information in the case of a cmip processing failure error.
lnpSubscriptionsName	This attribute is used to specify the name of the subscription container. It is used to support subscription download functionality to the service provider Local SMS systems and subscription administration functionality for the SOA systems using the SOA to NPAC SMS and Local SMS to NPAC SMS interfaces.
npacContactNumber	This attribute is used to indicate the NPAC contact number to be called concerning an NPAC SMS outage. It is used to support the notification of operational outages to the service provider SOA and Local SMS systems using the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.
npacCustomerAllowableFunctions	This attribute is used to specify what functions a service provider can perform on the SOA to NPAC SMS and NPAC SMS to Local SMS interfaces.
resultsCompletionTime	This attribute is used to store the completion time of the action in the action results notification.
serviceProvAddress	This attribute is used to specify the service provider address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvBillingAddress	This attribute is used to specify the service provider billing address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvConflictAddress	This attribute is used to specify the service provider conflict address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvDownloadReason	This attribute is used to specify the reason for download in the serviceProvLRN and serviceProvNPA-NXX objects. It is used in the NPAC SMS to Local SMS Interface.
serviceProvID	This attribute is used to specify the service provider Id to

21

Attribute Name	Interface Requirements Mapping
	uniquely identify a service provider object. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvLRN-ID	This attribute is used to specify the service provider LRN unique identifier. It is used to support downloading of network LRN data to the Local SMS and the Lockheed Martin extended functionality that allows service providers to update their own network LRN data.
serviceProvLRN-CreationTimeStamp	This attribute is used to specify the last date and time the serviceProvLRN object was created on the NPAC SMS. It is used in the NPAC SMS to Local SMS Interface.
serviceProvLRN-Value	This attribute is used to specify the value for a service provider LRN associated with an NPA-NXX.
serviceProvLSMS-Address	This attribute is used to specify the service provider Local SMS contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvName	This attribute is used to specify the service provider English name. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvNetAddress	This attribute is used to specify the service provider Network operations contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvNPA-NXX-EffectiveTimeStamp	This attribute is used to specify the effective date on which the service provider NPA-NXX is available for LNP. It is used in the NPAC SMS to Local SMS interface.
serviceProvNPA-NXX-ID	This attribute is used to specify the service provider NPA-NXX unique identifier. It is used to support downloading of network NPA-NXX data to the Local SMS and the Lockheed Martin extended functionality that allows service providers to update their own network NPA-NXX data.
serviceProvNPA-NXX-CreationTimeStamp	This attribute is used to specify the date and time the serviceProvNPA-NXX object was created. It is used in the NPAC SMS to Local SMS Interface.
serviceProvNPA-NXX-Value	This attribute is used to specify the service provider NPA-NXX value. It is used to support downloading of network NPA-NXX data to the Local SMS.
serviceProvOperationsAddress	This attribute is used to specify the service provider operations contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service

22

Attribute Name	Interface Requirements Mapping
	provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvRepairCenterInfo	This attribute is used to specify the repair center information for a service provider.
serviceProvSOA-Address	This attribute is used to specify the service provider SOA contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvSysLinkInfo	This attribute is used to specify the service provider network address connectivity data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS interface and the SOA to NPAC SMS interface.
serviceProvTunables	This attribute is used to specify the service provider tunables for the NPAC SMS to Local SMS interface.
serviceProvUserAdminAddress	This attribute is used to specify the service provider user administration contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvWebAddress	This attribute is used to specify the service provider web contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
subscriptionActivationTimeStamp	This attribute is used to specify the subscription version activation time stamp. It is used to support service provider data administration in NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionAuditAttributeList	This attribute is used to specify a list of attributes in a subscription version that are to be audited. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditId	This attribute is used to uniquely identify an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditName	This attribute is used to give an English name to an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS.
subscriptionAuditNonPortedTNs	This attribute is used to specify if non-ported TNs should be audited in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.

23

Attribute Name	Interface Requirements Mapping
subscriptionAuditNumberOfTNs	This attribute is used to specify the number of TNs being audited in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditNumberOfTNsComplete	This attribute is used to specify the number of TNs that have been successfully audited in a complete or in progress audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditRequestingSP	This attribute is used to specify the service provider Id that requested the audit.
subscriptionAuditServiceProvIdRange	This attribute is used to identify a specific service provider or if all service providers should be audited in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditStatus	This attribute is used to specify the status of an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditTN-ActivationRange	This attribute is used to specify the activation date and time range for TNs to be audited in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditTN-AtSuspend	This attribute is used to specify the last TN that was audited when an audit request was suspended in the network. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditTN-NotificationNumber	This attribute is used to specify the number of TNs that have completed audit before the number of subscriptionAuditNumberOfTNsComplete gets incremented in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditTN-Range	This attribute is used specify the range of TNs to be audited in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionBillingId	This attribute is used to specify the subscription version service provider billing Id. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionBroadcastTimeStamp	This attribute is used to specify the subscription version’s broadcast from the NPAC SMS to the Local SMS systems time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.

24

Attribute Name	Interface Requirements Mapping
subscriptionCancellationTimeStamp	This attribute is used to specify the subscription version cancellation time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionCLASS-DPC	This attribute is used to specify the subscription version CLASS DPC Type. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionCLASS-SSN	This attribute is used to specify the subscription version CLASS SSN. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionCNAM-DPC	This attribute is used to specify the CNAM DPC in the subscriptionVersion object. It is used in the both the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS Interface.
subscriptionCNAM-SSN	This attribute is used to specify the CNAM SSN in the subscriptionVersion object. It is used in the both the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS Interface.
subscriptionConflictTimeStamp	This attribute is used to specify the subscription conflict time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionCreationTimeStamp	This attribute is used to specify the subscription version creation time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionCustomerDisconnectDate	This attribute is used to specify the timestamp of when the customer was disconnected.
subscriptionDisconnectCompleteTimestamp	This attribute is used to specify the timestamp of when the subscription version was disconnect. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionDownloadReason	This attribute is used to specify the reason for download in the subscriptionVersion objects. It is used in the NPAC SMS to Local SMS Interface.

25

Attribute Name	Interface Requirements Mapping
subscriptionEffectiveReleaseDate	This attribute is used to specify the subscription version disconnect date. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionEndUserLocationType	This attribute is used to specify the subscription version end user location type. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionEndUserLocationValue	This attribute is used to specify the subscription version end user location value. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionFailed -SP-List	This attribute is used to store the failed service providers after a subscription version broadcast results in a failed or partially-failed subscription version status.
subscriptionISVM-DPC	This attribute is used to specify the ISVM DPC in the subscriptionVersion object. It is used in both the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS Interface.
subscriptionISVM-SSN	This attribute is used to specify the ISVM SSN in the subscriptionVersion object. It is used in both the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS Interface.
subscriptionLIDB-DPC	This attribute is used to specify the subscription version LIDB DPC. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionLIDB-SSN	This attribute is used to specify the LIDB SSN in the subscriptionVersion object. It is used in both the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS Interface.
subscriptionLNPType	This attribute is used to specify the subscription version LNP Type. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionLRN	This attribute is used to specify the LRN data for the subscription version. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionModifiedTimeStamp	This attribute is used to specify the timestamp of any

26

Attribute Name	Interface Requirements Mapping
	modifications to the subscription version. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionNewCurrentSP	This attribute is used to specify the current or new service provider for the subscription version. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionNewSP-CreationTimeStamp	This attribute is used to specify the subscription version new service provider creation time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionNewSP-CancellationTimeStamp	This attribute is used to specify the time stamp of the subscription version cancellation pending acknowledgment by the new service provider. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionNewSP-ConflictResolutionTimeStamp	This attribute is used to specify the time stamp of the subscription version conflict resolution pending acknowledgment by the new service provider. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionNewSP-DueDate	This attribute is used to specify the new service provider activation date and time for the subscription version. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionOldSP	This attribute is used to specify the old SP for the subscription version. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionOldSP-Authorization	This attribute is used to specify the subscription version old service provider authorization indication. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.

27

Attribute Name	Interface Requirements Mapping
subscriptionOldSP-AuthorizationTimeStamp	This attribute is used to specify the subscription version old service provider authorization time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionOldSP-CancellationTimeStamp	This attribute is used to specify the time stamp of the subscription version cancellation pending acknowledgment by the old service provider. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionOldSP-ConflictResolutionTimeStamp	This attribute is used to specify the time stamp of the subscription version conflict resolution pending acknowledgment by the old service provider. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionOldSP-DueDate	This attribute is used to specify the subscription version cutover time stamp to the new service provider. It is used to support service provider data administration in NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionOldTimeStamp	This attribute is used to specify the subscription version time stamp when the version became old. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionPortingToOriginal-SPSwitch	This attribute is used to specify that subscription version is being ported back to the original service provider. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionPreCancellationStatus	This attribute is used to specify the previous status of a cancel-pending subscription version. Valid values are pending, conflict, sending, active, failed, failed partial, conflict-resolution-pending, and disconnect-pending.
subscriptionTN	This attribute is used to specify the subscription version TN for a subscription version. It is used to support service provider data administration using the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.
subscriptionVersionAttributeValueChangeInfo	This attribute is used to specify the attribute value change information in the lnpLogVersionAttributeValueChangeRecord.

28

Attribute Name	Interface Requirements Mapping
subscriptionVersionId	This attribute is used to specify the unique version id for the subscription version in the NPAC SMS. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionVersionStatus	This attribute is used to specify the subscription version status. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.

4.1.4.Action Interface Functionality

The table below contains the mapping of the SOA to NPAC SMS and the Local SMS to NPAC SMS actions to the interface functionality described in the RFP.

Exhibit 5. The Action Interface Functionality Table

Action Name	Interface Requirements Mapping
lnpDownload	This action is used to support the downloading of subscription and network data to the Local SMS from the NPAC via the NPAC SMS to Local SMS interface.
lnpRecoveryComplete	This action is used to specify the system has recovered from down time and the transactions performed since the association establishment can now be sent to the Local SMS from the NPAC SMS using the Local SMS to NPAC SMS interface.
subscriptionVersionActivate	This action is used to support subscription version activation by the new service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionCancel	This action is used to support subscription version cancellation by a service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionDisconnect	This action is used to support subscription version disconnection by the current service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionLocalSMS-Create	This action can be used by the NPAC SMS to create multiple subscription versions via the Local SMS to NPAC SMS interface.
subscriptionVersionModify	This action is used to support subscription version modification by a service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionNewSP-CancellationAcknowledge	This action is used to support the acknowledgment of subscription versions with a status of conflict-resolution-pending by the old service from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionNewSP-ConflictResolutionAcknowledge	This action is used to support the acknowledgment of subscription versions with a status of conflict-resolution-pending by the new service from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.

29

Action Name	Interface Requirements Mapping
subscriptionVersionNewSP-ConflictResolutionPending	This action is used on the NPAC SMS via the SOA to NPAC SMS interface to set the subscriptionversion status from conflict to conflict resolution pending.
subscriptionVersionNewSP-Create	This action is used to support subscription version creation by the new service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionOldSP-CancellationAcknowledge	This action is used to support the acknowledgment of subscription versions with a status of cancel-pending by the old service from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionOldSP-ConflictResolutionAcknowledge	This action is used to support the acknowledgment of subscription versions with a status of conflict-resolution-pending by the old service from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionOldSP-Create	This action is used to support subscription version creation by the old service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.

4.1.5.Notification Interface Functionality

The table below contains the mapping of the SOA to NPAC SMS and the Local SMS to NPAC SMS notifications to the interface functionality described in the RFP.

Exhibit 6. The Notification Interface Functionality Table

Notification Name	Interface Requirements Mapping
lnpNPAC-SMS-Operational-Information	This notification is used to support the reporting of NPAC SMS scheduled down time. This notification can be issued from the lnpNPAC-SMS object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface or from the NPAC SMS to the Local SMS via the NPAC SMS to Local SMS interface.
subscriptionAudit-DiscrepancyRpt	This notification is used to support the reporting of audit discrepancies found during audit processing. This notification can be issued from an audit object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface.
subscriptionAudit-Results	This notification is used to support the reporting of audit processing results. This notification can be issued from an audit object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface.
subscriptionVersionCancellationAcknowledgeRequest	This notification is issued to new and old service providers to request that a cancellation acknowledgment be sent for a subscriber version in a cancel-pending state. This notification is issued via the SOA to NPAC SMS interface from the NPAC subscription version object if the service provider fails to acknowledge the cancellation after a tunable amount of time specified in the NPAC SMS service data table.
subscriptionVersionConflictResolutionAcknowledge Request	This notification is issued to new and old service providers

30

Notification Name	Interface Requirements Mapping
	to request that a conflict resolution acknowledgment be sent for a subscriber version in a conflict-resolution-pending state. This notification is issued via the SOA to NPAC SMS interface from the NPAC subscription version object if the service provider fails to acknowledge the conflict resolution after a tunable amount of time specified in the NPAC SMS service data table.
subscriptionVersionDonorSP-CustomerDisconnectDate	This notification informs the donor service provider SOA that a subscription version is being disconnected. This notification is issued from a subscription version object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface.
subscriptionVersionLocalSMS-ActionResults	This notification contains the results of a subscriptionVersionLocalSMS-Create action once all the create requests have been attempted. It is issued from the Local SMS to the NPAC SMS via the NPAC SMS to Local SMS interface.
subscriptionVersionNew-NPA-NXX	This notification informs the Local SMS of a pending subscription version involving a new NPA-NXX.
subscriptionVersionNewSP-CreateRequest	This notification is issued to the new service provider to request that a create request be sent for the subscriber version created by the old service provider to provide authorization and/or porting information. This notification is issued via the SOA to NPAC SMS interface from the NPAC subscription version object if the new service provider failed to authorize porting of a number after a tunable amount of time specified in the NPAC SMS service data table.
subscriptionVersionOldSP-ConcurrenceRequest	This notification is issued to the old service provider to request that a create request be sent for the subscriber version created by the new service provider to provide concurrence for porting. This notification is issued via the SOA to NPAC SMS interface from the NPAC subscription version object if the old service provider failed to authorize porting of a number after a tunable amount of time specified in the NPAC SMS service data table.
subscriptionVersionStatusAttributeValueChange	This notification is issued when the subscription version status is modified. This notification is issued from both the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface from the subscriptionVersionNPAC object.

31

Secure Association Establishment

5.Secure Association Establishment

5.1.Overview

This chapter describes the security, the association management and recovery procedures for the service provider SOAs and Local SMSs to follow, and how error information will be passed between interfaces.

The first section describes the security and authentication procedures used in the NPAC SMS interface. The second section describes the NPAC SMS’s behavior and error handling and suggests how a service provider SOA or Local SMS should proceed when establishing an association.

5.2.Security

This section describes the security processes and procedures necessary for service provider SOA systems and Local SMSs to establish a secure association and maintain secure communication with the NPAC SMS.  Security threats to the NPAC SMS include:

•Spoofing - An intruder may masquerade as either the SOA, Local SMS, or NPAC SMS to falsely report information.

•Message Tampering - An intruder may modify, delete, or create messages passed.

•Denial or Disruption of Service - An intruder may cause denial or disruption of service by generating or modifying messages.

•Diversion of Resources - An intruder may generate or modify messages that cause resources to be diverted to unnecessary tasks.

•Slamming - An intruder may generate or modify messages that cause customer’s service to be moved between service providers.

Security threats are prevented in the NPAC SMS by use of the following methods:

•Strong two way authentication at association.

•Insuring data integrity by detection of replay, deletion, or modification to a message.

•Insuring non-repudiation of data by guaranteeing integrity and supporting data origination authentication for each incoming message.

•Implementation of access control and application level security that allows only authorized parties to cause changes to the NPAC SMS database.

5.2.1.Authentication and Access Control Information

32

The following access control information definition will be used in the AccessControl field of the association and CMIP PDUs to insure a secure communication for both the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface:

LnpAccessControl ::= SEQUENCE {
	systemId	SystemID,
	systemType	SystemType,
	userId	GraphicString60 OPTIONAL,
	listId	INTEGER,
	keyId	INTEGER,
	cmiDepartureTime	GeneralizedTime,
	sequenceNumber	INTEGER (04294967295),
	signature	BITSTRING
	function	AssociationFunction,
	recoveryMode	BOOLEAN
}
ServiceProvID ::= NumberString(SIZE(8))
SystemID ::= CHOICE {
	serviceProvID [0] ServiceProvId,
	npac-sms [1] GraphicsString60
}
SystemType ::= ENUM {
	soa(0),
	local-sms(1),
	soa-and-local-sms(2),
	npac-sms(3) —value is only valid for AccessControl definition
}
AssociationFunction ::= SEQUENCE {
	soaUnits [0] SoaUnits,
	lsmsUnits [1] LSMSUnits
}
SoaUnits ::= SEQUENCE {
	soaMgmt [0] NULL OPTIONAL,
	networkDataMgmt [1] NULL OPTIONAL
}
LsmsUnits ::= SEQUENCE {
	processAudits [0] NULL OPTIONAL,
	dataDownload [1] NULL OPTIONAL,
	networkDataMgmt [2] NULL OPTIONAL,
	query [3] NULL OPTIONAL
}

33

Exhibit 7 Access Control

5.2.1.1.System Id

The system Id is the unique Id for the system using an interoperable interface and must be specified in the systemId field. For a service provider using the SOA and/or Local SMS interfaces, this is the OCN. For the NPAC SMS, it is the unique identifier for the regional SMS.

5.2.1.2.System Type

The system type that indicates the type of system using the interoperable interface must be specified in the systemType field. The valid types are SOA and/or Local SMS and NPAC SMS.

5.2.1.3.User Id

The user Id of the user of the interface can optionally be specified in the userId field for the SOA interface. This is the 60 character graphics string user identifier for a user on a SOA system. It is not validated on the NPAC SMS, however, it is used for logging purposes.

5.2.1.4.List Id

The list Id must be specified as an integer in the listId field to identify a key list.  This key list is one of the key lists exchanged outside of the interface process that is known to both the NPAC SMS and the Local SMS or SOA system it is communicating with.

5.2.1.5.Key Id

The key Id of a key in the key list must be specified as an integer in the keyId field.  This uniquely identifies the key in the key list used to create the digital signature. The size of the modulus for the key is 600 bits as specified by the ICC.

5.2.1.6.CMIP Departure Time

The CMIP departure time must be specified in GeneralizedTime in the cmipDepartureTime field as the time the PDU departed the sending system.  In order to insure data integrity and no-repudiation the NPAC SMS system must be synchronized to within two minutes of the Local SMS and SOA systems that it communicates.

5.2.1.7.Sequence Number

The sequence number is a 32 bit integer that must be specified in the sequenceNumber field.  It should be specified as zero at association time and incremented by one for every message sent over the association. Once the sequence number reaches 4294967295 the counter will be reset to one for the association. Please note that each sender independently keeps its own counter for the sequence number of messages sent and received. For example, after association is established, a Local SMS could send three messages to the NPAC SMS with sequence numbers 1, 2, and 3 respectively.  The NPAC SMS when sending it’s first message to the Local SMS would use sequence number 1 not sequence number 4.

34

5.2.1.8.Signature

The signature field contains the MD5 hashed and encrypted systemId, the system type, the userId, the cmipDepartureTime, and sequenceNumber without separators between those fields or other additional characters. Encryption is done using RSA encryption using the key from the key list specified. Validation of this field insures data integrity and non-repudiation of data.

5.2.1.9.Association Functions

The Association Function(s) must be specified on the initial association request (AARQ PDU). The following table lists the possible Association Functions that can be specified for each of the Association Request Initiators:

Exhibit 8 Association Functions

	Association Request Initiator
Association Function	SOA	Local SMS
SOA Management (Audit and Subscription Version) Classes: lnpSubscriptions subscriptionAudit subscriptionVersion subscriptionVersionNPAC	X
Service Provider and Network Data Management Classes: lnpNetwork lnpNPAC-SMS lnpServiceProvs serviceProv serviceProvLRN serviceProvNetwork serviceProv-NPA-NXX	X	X
Network and Subscription Data Download Classes: lnpNetwork lnpSubscriptions		X
Query Classes: All		X

Note that the multiple Association Functions can be specified for an association. For example, a Local SMS can establish an association for both the process audit and network and subscription data download association functions.

35

5.2.1.10.Recovery Mode

The recovery mode flag is set to TRUE when a Local SMS is establishing a connection after a downtime. This flag indicates to the NPAC SMS to hold all current transactions until the Local SMS sends the Recovery Complete action. Once an association is established in recovery mode, the Local SMS should request subscription and network downloads. The Local SMS should also query for active audits and remove any outstanding audits on its system.  After these steps are complete, the Local SMS should submit the Recovery Complete action. The NPAC SMS will respond with all updates since association establishment and then normal processing will resume. See Chapter 6, Section 6.5.1, Sequencing of Events on Initialization/Resynchronization of Local SMS.

The recovery mode flag applies only to the Network and Subscription Data Download Association Function.

5.2.2.Association Establishment

Strong two way authentication at association is done for both the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.  This secure association establishment is done at the application level using the access control field described above.  The access control information used during association set-up is sent in the association control messages. Association establishment can be done by the SOA to NPAC SMS or Local SMS to NPAC SMS. The NPAC SMS cannot initiate an association. The initiator of the association specifies its information in the AARQ PDU message and the responder in the AARE PDU.

The following is an example of the information exchanged in the AARQ and AARE PDUs and the processing involved.  Assume for the example:

•A Local SMS is making an association with the NPAC SMS.

•The Local SMS systemId is “Company XYZ User Id.”

•The NPAC SMS systemId is “NPAC SMS User Id.”

•The listId for the key list is 1.

•The keyId is 32.

•The key in listId 1 with a keyId of 32 is “ABC123.”

•The sequence number is 0 (as required).

The Local SMS initiates the association request by creating and sending an AARQ PDU to the NPAC SMS.  This AARQ PDU contains the following access control information in the syntax described above:

•The systemId of “Company XYZ User Id.”

•The listId of 1.

•The keyId of 32.

•The current Local SMS GMT time in the cmipDepartureTime.

•A sequence number of 0.

36

•The signature contains MD5 hashed and encrypted systemId, systemType, userId, cmipDepartureTime, and the sequenceNumber using the encryption key “ABC123” as found in key list 1 with key id 32.

•And all BOOLEAN items are set to FALSE in the functional groups field, except for the processAudits item which is set to TRUE.

Once the AARQ PDU is sent, the sender (in this case the Local SMS), starts a tunable timer (with a default value of 2 minutes).  If the timer expires before the AARE PDU is received then the Local SMS will terminate the association attempt.

When the NPAC SMS receives the association request it validates the data received.  The data is validated as follows:

•Insure the systemId is present and valid for the association.

•Insure the sequence number is 0.

•Insure the cmipDepartureTime is within 5 minutes of the current NPAC SMS GMT time.

•Find the key specified and decrypt the signature insuring that the systemId, systemType, userId, cmipDepartureTime, and sequenceNumber are the same as those specified in the PDU.

•The functional groups requested are valid for the system type that requested the association. In this example, the system type must be “local-sms(1)” or “soa-and-local-sms(2).”

If validation of the AARQ PDU fails then an A-ABORT will be issued by the NPAC SMS without any additional information.  This will prevent network resources from being used by intruders.  If the validation of the AARQ PDU is successful then an AARE PDU would be sent back to the Local SMS.  This AARE PDU contains the following access control information in the syntax described above:

•The systemId of “NPAC SMS User Id.”

•The listId of 1.

•The keyId of 32.

•The current NPAC SMS GMT time in the cmipDepartureTime.

•A sequence number of 0.

•And the signature contains MD5 hashed and encrypted systemId, systemType, userId, cmipDepartureTime, and the sequenceNumber using the encryption key “ABC123” as found in key list 1 with key id 32.

The NPAC SMS may choose to optionally specify a new listId and keyId if for any reason it wants to make a key change. When the Local SMS receives the association response it validates the data received.  The data is validated as follows:

•Insure the systemId is present and valid for the association. (Note: the userId field is not required for Local SMS and NPAC SMS associations).

•Insure the sequence number is 0.

37

•Insure the cmipDepartureTime is within 5 minutes of the current Local SMS GMT time.

•Find the key specified and decrypt the signature insuring that the systemId, systemType, userId, cmipDepartureTime, and sequenceNumber are the same as those specified in the PDU.

If validation of the AARE PDU fails then an A-ABORT will be issued by the Local SMS without any additional information.  This will prevent network resources from being used by intruders.  If validation is successful then an secure association has been established.

5.2.3.Data Origination Authentication

For M-GET, M-SET, M-CREATE, M-DELETE, and M-ACTION, the access control field described above is used for data origination authentication.  Please note that any of the messages sent between manager and agent must be sent in confirmed mode.  The following is an example of the information exchanged in the CMIP PDUs and the processing involved.  Assume for the example:

•A Local SMS is making an association with the NPAC SMS.

•The Local SMS systemId is “Company XYZ User Id.”

•The NPAC SMS systemId is “NPAC SMS User Id.”

•The listId for the key list is 1.

•The keyId is 32.

•The key in listId 1 with a keyId of 32 is “ABC123.”

•The sequence number is 1.

The Local SMS sends an M-GET to the NPAC SMS.  The M-GET PDU contains the following access control information in the syntax described above:

•The systemId of “Company XYZ User Id.”

•The listId of 1.

•The keyId of 32.

•The current Local SMS GMT time in the cmipDepartureTime.

•A sequence number of 1.

•And the signature contains MD5 hashed and encrypted systemId, systemType, userId, cmipDepartureTime, and the sequenceNumber using the encryption key “ABC123” as found in key list 1 with key Id 32.

Once the M-GET is sent, the sender (in this case the Local SMS), starts a tunable timer (with a default value of 2 minutes).  If the timer expires before the M-GET Response is received then the Local SMS will terminate and reestablish the association.

When the NPAC SMS receives the M-GET request it validates the data received.  The data is validated as follows:

38

•Insure the systemId is present and valid for the association. (Note: the userId field is not required for Local SMS and NPAC SMS associations).

•Insure the sequence number is the next sequence number expected. (In this case 1).

•Insure the cmipDepartureTime is within 5 minutes of the current NPAC SMS time.

•Find the key specified and decrypt the signature, insuring that the systemId, systemType, userId, cmipDepartureTime, and sequenceNumber are the same as those specified in the PDU.

If validation of the M-GET PDU fails then an A-ABORT will be issued by the NPAC SMS without any additional information to prevent tampering and unauthorized use of network resources by intruders. If the validation of the M-GET PDU is successful then the NPAC SMS would get the data requested and send an M-GET Response would be sent back to the Local SMS.

Since CMIP notifications (M-EVENT-REPORT) do not have access control fields, all notifications defined contain the access control information in the notification definition. The values and authentication for the notification access control fields are the same as above except for the signature field. The signature field must contain all of the notification data, the generalized time, and the sequence number MD5 hashed and encrypted. Please note that CMIP notifications are confirmed.

5.2.4.Audit Trail

Audit trails will be maintained in logs on the NPAC SMS for the following association information:

•Association set-up messages.

•Association termination messages.

•Invalid messages:

•Invalid digital signature.

•Sequence number out of order.

•Generalized time out of range.

•Invalid origination address.

•All incoming messages regardless of whether or not they cause changes to data stored in the NPAC SMS.

This information will be made available for report generation on the NPAC SMS system.  It will not be made available through the NPAC SMS Interoperable Interface.

5.3.Association Management and Recovery

5.3.1.Establishing Associations

5.3.1.1.Error Handling

All association establishment requests and responses will include the following data elements.  This includes the NPACAssociationInfo which will contain any error information transferred between the interfaces.

39

A successful response will always be defined as an errorCode of 0 (zero).

The CMIPUserInfo structure defined in:

CMIPAssoc {

joint-iso-ccitt ms(9) cmip(1) modules(0)
aAssociateUserInfo(1)

}

will be passed in the user-information field of all association PDUs (AARQ,  AARE, RLRQ, RLRE, ABRT).  The ASN.1 basic definition is as follows:

CMIPUserInfo::= SEQUENCE

{

protocolVersion[0] IMPLICIT ProtocolVersion

DEFAULT {version1-cmip-assoc},

functionalUnits[1] IMPLICIT FunctionalUnits

DEFAULT {},

accessControl                  [2] EXTERNAL OPTIONAL,

userInfo[3] EXTERNAL OPTIONAL

}

The LnpAccessControl structure (defined earlier) will be passed in the accessControl field on all association PDUs.  The following ASN.1 structure will be passed in the userInfo field on AARE, RLRE, and ABRT PDUs generated from the NPAC SMS:

NpacAssociationInfo ::= SEQUENCE

{

errorCode[0] IMPLICIT ErrorCode,

errorText[1] IMPLICITGraphicString(SIZE(1..80))

}

ErrorCode ::= ENUMERATION

{

success (0),

access-denied (1),— accessControl information failed
— validation

retry-same-host (2),—  this NPAC SMS host is the
— primary, but is temporarily
— down, try this host again later

try-other-host (3)— this NPAC SMS is no longer the
— primary, try the backup host

}

40

The errorText field may contain further information to be defined later.

5.3.1.2.NPAC SMS Behavior

Under normal conditions, the primary NPAC SMS will be responding by accepting association requests while the secondary NPAC SMS will be responding by denying association requests with an error code of TRY _OTHER_HOST.

When the primary NPAC SMS needs to go down for a short period of time (secondary will not take over),  the primary NPAC SMS will either not be responding (if down) or be denying association requests with an error code of RETRY _SAME_HOST (if partially up). The secondary NPAC SMS will be responding by denying association requests with an error code of TRY _OTHER_HOST.

When the primary NPAC SMS goes down (scheduled or unscheduled) and the secondary NPAC SMS is re-synchronizing to become active, the primary NPAC SMS will be denying association requests with an error code of TRY  _OTHER_HOST. The secondary NPAC SMS will be responding by denying association requests with an error code of RETRY_SAME_HOST. Once the secondary NPAC SMS is done re-synchronizing, it will then start accepting association requests.

5.3.1.3.Service Provider SOA and Local SMS Procedures

The following is an algorithm that can be used by a service provider SOA or Local SMS when trying to establish an association with the NPAC SMS:

try to establish an association on the primary NPAC SMS if a response was obtained

{

  if the response was an AARE

  {

    switch (error code)

    {

      case SUCCESSFUL

        done

      case ACCESS_DENIED

        find out what is causing the error and fix it

        retry the association on the primary NPAC SMS

      case RETRY_SAME_HOST

        wait X seconds

        retry the association on the primary NPAC SMS

      case TRY_OTHER_HOST

        wait X seconds

        execute this algorithm again substituting

        “secondary” for “primary”

    }

  }

41

  else

  {

    if the response was an ABRT

    {

      if the reason for the abort indicates some hope

      for a successful retry

      {

        wait X seconds

        retry primary NPAC SMS

      }

      else

      {

        find out what is causing the error and fix it

        retry the association on either the primary or

        secondary NPAC SMS

      }

    }

  }

else

{

  # timeout - some type of network error has occurred

  # a number of different things can be done:

  #

  #   wait X seconds

  #   retry primary

  #

  #       or

  #

  #   find out what is causing the error and fix it

  #   retry the association on the primary NPAC SMS

  #

  #       or

  #

  #   wait X seconds

  #   execute this algorithm again substituting

  #   “secondary” for “primary”

}

5.3.2.Releasing or Aborting Associations

Any of the systems, NPAC SMS, service provider SOA or Local SMS can release or abort an association at any time. Once a scheduled outage has arrived, the NPAC SMS

42

will deny associations (error code of “Try Other Host” or “Retry Same Host” depending on the type of outage) and begin to terminate any associations that are outstanding. The NPAC SMS will first try to terminate the associations gracefully by sending an association release PDU. Any associations that are still outstanding will be issued an association abort.

5.3.3.CMIP Error Handling

In addition to the standard CMIP error reporting mechanisms, the following attribute will be passed in the SpecificErrorInfo structure on CMIP errors that return a PROCESSING FAILURE error. This structure will be used to detail errors not covered by the standard CMIP error codes.

GDMO Definition

lnpSpecificInfo ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpSpecificInfo;

    MATCHES FOR EQUALITY;

    BEHAVIOUR lnpSpecificInfoBehavior;

    REGISTERED AS {lnp-attribute 8};

lnpSpecificInfoBehavior BEHAVIOUR

    DEFINED AS !

This attribute is used to return more detailed error text information upon a CMIP Processing Failure error.

!;

ASN.1 Definition

LnpSpecificInfo ::= GraphicString(SIZE(1..256))

5.3.4.Resynchronization

The SOA and Local SMS associations are viewed to be permanent connections by the NPAC SMS. Thus when the association is broken for any reason, the system connecting to the NPAC SMS must assume responsibility to resynchronize themselves with the NPAC SMS.

5.3.4.1.Local SMS Resynchronization

To resynchronize itself, the Local SMS starts by setting the recoveryMode flag of the access control parameter. This flag signals the NPAC SMS to hold all data updates to this Local SMS. The Local SMS should then request the downloads it needs.  Once this is complete, the Local SMS should issue the lnpRecoveryComplete action to turn off the recoveryMode flag and receive back any other updates that have occurred since the association was established.

5.3.4.2.SOA Resynchronization

The SOA interface resynchronizes itself by issuing the necessary queries that inform it of updates made to objects it is concerned with since it last had an association with the NPAC SMS. For subscription objects, a query should be launched based upon the new or old service provider equal to the SOA service

43

provider and the subscriptionModifiedTimeStamp to be greater than the time when the association was lost.

Audit results may only be viewed from the NPAC SMS GUI and are not available on the mechanized interface.

44

Attribute Name	Interface Requirements Mapping
	Local SMS in the NPAC SMS to Local SMS interface.
lnpNPAC-SMS-Name	This attribute is used to specify the name of the NPAC SMS data container. It is used to support the NPAC SMS to Local SMS interface.
lnpServiceProvsName	This attribute is used to specify the name of the service provider data container. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
lnpSpecificInfo	This attribute is used to pass specific error information in the case of a cmip processing failure error.
lnpSubscriptionsName	This attribute is used to specify the name of the subscription container. It is used to support subscription download functionality to the service provider Local SMS systems and subscription administration functionality for the SOA systems using the SOA to NPAC SMS and Local SMS to NPAC SMS interfaces.
npacContactNumber	This attribute is used to indicate the NPAC contact number to be called concerning an NPAC SMS outage. It is used to support the notification of operational outages to the service provider SOA and Local SMS systems using the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.
npacCustomerAllowableFunctions	This attribute is used to specify what functions a service provider can perform on the SOA to NPAC SMS and NPAC SMS to Local SMS interfaces.
resultsCompletionTime	This attribute is used to store the completion time of the action in the action results notification.
serviceProvAddress	This attribute is used to specify the service provider address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvBillingAddress	This attribute is used to specify the service provider billing address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvConflictAddress	This attribute is used to specify the service provider conflict address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvDownloadReason	This attribute is used to specify the reason for download in the serviceProvLRN and serviceProvNPA-NXX objects. It is used in the NPAC SMS to Local SMS Interface.
serviceProvID	This attribute is used to specify the service provider Id to

45

Attribute Name	Interface Requirements Mapping
	uniquely identify a service provider object. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvLRN-ID	This attribute is used to specify the service provider LRN unique identifier. It is used to support downloading of network LRN data to the Local SMS and the Lockheed Martin extended functionality that allows service providers to update their own network LRN data.
serviceProvLRN-CreationTimeStamp	This attribute is used to specify the last date and time the serviceProvLRN object was created on the NPAC SMS. It is used in the NPAC SMS to Local SMS Interface.
serviceProvLRN-Value	This attribute is used to specify the value for a service provider LRN associated with an NPA-NXX.
serviceProvLSMS-Address	This attribute is used to specify the service provider Local SMS contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvName	This attribute is used to specify the service provider English name. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvNetAddress	This attribute is used to specify the service provider Network operations contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvNPA-NXX-EffectiveTimeStamp	This attribute is used to specify the effective date on which the service provider NPA-NXX is available for LNP. It is used in the NPAC SMS to Local SMS interface.
serviceProvNPA-NXX-ID	This attribute is used to specify the service provider NPA-NXX unique identifier. It is used to support downloading of network NPA-NXX data to the Local SMS and the Lockheed Martin extended functionality that allows service providers to update their own network NPA-NXX data.
serviceProvNPA-NXX-CreationTimeStamp	This attribute is used to specify the date and time the serviceProvNPA-NXX object was created. It is used in the NPAC SMS to Local SMS Interface.
serviceProvNPA-NXX-Value	This attribute is used to specify the service provider NPA-NXX value. It is used to support downloading of network NPA-NXX data to the Local SMS.
serviceProvOperationsAddress	This attribute is used to specify the service provider operations contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service

46

Attribute Name	Interface Requirements Mapping
	provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvRepairCenterInfo	This attribute is used to specify the repair center information for a service provider.
serviceProvSOA-Address	This attribute is used to specify the service provider SOA contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvSysLinkInfo	This attribute is used to specify the service provider network address connectivity data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS interface and the SOA to NPAC SMS interface.
serviceProvTunables	This attribute is used to specify the service provider tunables for the NPAC SMS to Local SMS interface.
serviceProvUserAdminAddress	This attribute is used to specify the service provider user administration contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
serviceProvWebAddress	This attribute is used to specify the service provider web contact address data. It is used to support service provider data query and the Lockheed Martin functionality for service provider data update in the NPAC SMS using the Local SMS to NPAC SMS or SOA to NPAC SMS interface.
subscriptionActivationTimeStamp	This attribute is used to specify the subscription version activation time stamp. It is used to support service provider data administration in NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionAuditAttributeList	This attribute is used to specify a list of attributes in a subscription version that are to be audited. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditId	This attribute is used to uniquely identify an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditName	This attribute is used to give an English name to an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS.
subscriptionAuditNonPortedTNs	This attribute is used to specify if non-ported TNs should be audited in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.

47

Attribute Name	Interface Requirements Mapping
subscriptionAuditNumberOfTNs	This attribute is used to specify the number of TNs being audited in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditNumberOfTNsComplete	This attribute is used to specify the number of TNs that have been successfully audited in a complete or in progress audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditRequestingSP	This attribute is used to specify the service provider Id that requested the audit.
subscriptionAuditServiceProvIdRange	This attribute is used to identify a specific service provider or if all service providers should be audited in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditStatus	This attribute is used to specify the status of an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditTN-ActivationRange	This attribute is used to specify the activation date and time range for TNs to be audited in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditTN-AtSuspend	This attribute is used to specify the last TN that was audited when an audit request was suspended in the network. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditTN-NotificationNumber	This attribute is used to specify the number of TNs that have completed audit before the number of subscriptionAuditNumberOfTNsComplete gets incremented in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionAuditTN-Range	This attribute is used specify the range of TNs to be audited in an audit request. It is used to support audit functionality from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionBillingId	This attribute is used to specify the subscription version service provider billing Id. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionBroadcastTimeStamp	This attribute is used to specify the subscription version’s broadcast from the NPAC SMS to the Local SMS systems time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.

48

Attribute Name	Interface Requirements Mapping
subscriptionCancellationTimeStamp	This attribute is used to specify the subscription version cancellation time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionCLASS-DPC	This attribute is used to specify the subscription version CLASS DPC Type. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionCLASS-SSN	This attribute is used to specify the subscription version CLASS SSN. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionCNAM-DPC	This attribute is used to specify the CNAM DPC in the subscriptionVersion object. It is used in the both the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS Interface.
subscriptionCNAM-SSN	This attribute is used to specify the CNAM SSN in the subscriptionVersion object. It is used in the both the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS Interface.
subscriptionConflictTimeStamp	This attribute is used to specify the subscription conflict time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionCreationTimeStamp	This attribute is used to specify the subscription version creation time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionCustomerDisconnectDate	This attribute is used to specify the timestamp of when the customer was disconnected.
subscriptionDisconnectCompleteTimestamp	This attribute is used to specify the timestamp of when the subscription version was disconnect. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionDownloadReason	This attribute is used to specify the reason for download in the subscriptionVersion objects. It is used in the NPAC SMS to Local SMS Interface.

49

Attribute Name	Interface Requirements Mapping
subscriptionEffectiveReleaseDate	This attribute is used to specify the subscription version disconnect date. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionEndUserLocationType	This attribute is used to specify the subscription version end user location type. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionEndUserLocationValue	This attribute is used to specify the subscription version end user location value. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionFailed -SP-List	This attribute is used to store the failed service providers after a subscription version broadcast results in a failed or partially-failed subscription version status.
subscriptionISVM-DPC	This attribute is used to specify the ISVM DPC in the subscriptionVersion object. It is used in both the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS Interface.
subscriptionISVM-SSN	This attribute is used to specify the ISVM SSN in the subscriptionVersion object. It is used in both the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS Interface.
subscriptionLIDB-DPC	This attribute is used to specify the subscription version LIDB DPC. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionLIDB-SSN	This attribute is used to specify the LIDB SSN in the subscriptionVersion object. It is used in both the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS Interface.
subscriptionLNPType	This attribute is used to specify the subscription version LNP Type. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionLRN	This attribute is used to specify the LRN data for the subscription version. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionModifiedTimeStamp	This attribute is used to specify the timestamp of any

50

Attribute Name	Interface Requirements Mapping
	modifications to the subscription version. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionNewCurrentSP	This attribute is used to specify the current or new service provider for the subscription version. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionNewSP-CreationTimeStamp	This attribute is used to specify the subscription version new service provider creation time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionNewSP-CancellationTimeStamp	This attribute is used to specify the time stamp of the subscription version cancellation pending acknowledgment by the new service provider. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionNewSP-ConflictResolutionTimeStamp	This attribute is used to specify the time stamp of the subscription version conflict resolution pending acknowledgment by the new service provider. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionNewSP-DueDate	This attribute is used to specify the new service provider activation date and time for the subscription version. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionOldSP	This attribute is used to specify the old SP for the subscription version. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionOldSP-Authorization	This attribute is used to specify the subscription version old service provider authorization indication. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.

51

Attribute Name	Interface Requirements Mapping
subscriptionOldSP-AuthorizationTimeStamp	This attribute is used to specify the subscription version old service provider authorization time stamp. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionOldSP-CancellationTimeStamp	This attribute is used to specify the time stamp of the subscription version cancellation pending acknowledgment by the old service provider. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionOldSP-ConflictResolutionTimeStamp	This attribute is used to specify the time stamp of the subscription version conflict resolution pending acknowledgment by the old service provider. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionOldSP-DueDate	This attribute is used to specify the subscription version cutover time stamp to the new service provider. It is used to support service provider data administration in NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionOldTimeStamp	This attribute is used to specify the subscription version time stamp when the version became old. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionPortingToOriginal-SPSwitch	This attribute is used to specify that subscription version is being ported back to the original service provider. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to the NPAC SMS interface.
subscriptionPreCancellationStatus	This attribute is used to specify the previous status of a cancel-pending subscription version. Valid values are pending, conflict, sending, active, failed, failed partial, conflict-resolution-pending, and disconnect-pending.
subscriptionTN	This attribute is used to specify the subscription version TN for a subscription version. It is used to support service provider data administration using the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.
subscriptionVersionAttributeValueChangeInfo	This attribute is used to specify the attribute value change information in the lnpLogVersionAttributeValueChangeRecord.

52

Attribute Name	Interface Requirements Mapping
subscriptionVersionId	This attribute is used to specify the unique version id for the subscription version in the NPAC SMS. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.
subscriptionVersionStatus	This attribute is used to specify the subscription version status. It is used to support service provider data administration in the NPAC SMS using the SOA to NPAC SMS interface and subscription version download from the NPAC SMS to the Local SMS using the Local SMS to NPAC SMS interface.

4.1.4.Action Interface Functionality

The table below contains the mapping of the SOA to NPAC SMS and the Local SMS to NPAC SMS actions to the interface functionality described in the RFP.

Exhibit 5. The Action Interface Functionality Table

Action Name	Interface Requirements Mapping
lnpDownload	This action is used to support the downloading of subscription and network data to the Local SMS from the NPAC via the NPAC SMS to Local SMS interface.
lnpRecoveryComplete	This action is used to specify the system has recovered from down time and the transactions performed since the association establishment can now be sent to the Local SMS from the NPAC SMS using the Local SMS to NPAC SMS interface.
subscriptionVersionActivate	This action is used to support subscription version activation by the new service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionCancel	This action is used to support subscription version cancellation by a service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionDisconnect	This action is used to support subscription version disconnection by the current service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionLocalSMS-Create	This action can be used by the NPAC SMS to create multiple subscription versions via the Local SMS to NPAC SMS interface.
subscriptionVersionModify	This action is used to support subscription version modification by a service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionNewSP-CancellationAcknowledge	This action is used to support the acknowledgment of subscription versions with a status of conflict-resolution-pending by the old service from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionNewSP-ConflictResolutionAcknowledge	This action is used to support the acknowledgment of subscription versions with a status of conflict-resolution-pending by the new service from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.

53

Action Name	Interface Requirements Mapping
subscriptionVersionNewSP-ConflictResolutionPending	This action is used on the NPAC SMS via the SOA to NPAC SMS interface to set the subscriptionversion status from conflict to conflict resolution pending.
subscriptionVersionNewSP-Create	This action is used to support subscription version creation by the new service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionOldSP-CancellationAcknowledge	This action is used to support the acknowledgment of subscription versions with a status of cancel-pending by the old service from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionOldSP-ConflictResolutionAcknowledge	This action is used to support the acknowledgment of subscription versions with a status of conflict-resolution-pending by the old service from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
subscriptionVersionOldSP-Create	This action is used to support subscription version creation by the old service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.

4.1.5.Notification Interface Functionality

The table below contains the mapping of the SOA to NPAC SMS and the Local SMS to NPAC SMS notifications to the interface functionality described in the RFP.

Exhibit 6. The Notification Interface Functionality Table

Notification Name	Interface Requirements Mapping
lnpNPAC-SMS-Operational-Information	This notification is used to support the reporting of NPAC SMS scheduled down time. This notification can be issued from the lnpNPAC-SMS object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface or from the NPAC SMS to the Local SMS via the NPAC SMS to Local SMS interface.
subscriptionAudit-DiscrepancyRpt	This notification is used to support the reporting of audit discrepancies found during audit processing. This notification can be issued from an audit object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface.
subscriptionAudit-Results	This notification is used to support the reporting of audit processing results. This notification can be issued from an audit object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface.
subscriptionVersionCancellationAcknowledgeRequest	This notification is issued to new and old service providers to request that a cancellation acknowledgment be sent for a subscriber version in a cancel-pending state. This notification is issued via the SOA to NPAC SMS interface from the NPAC subscription version object if the service provider fails to acknowledge the cancellation after a tunable amount of time specified in the NPAC SMS service data table.
subscriptionVersionConflictResolutionAcknowledge Request	This notification is issued to new and old service providers

54

Notification Name	Interface Requirements Mapping
	to request that a conflict resolution acknowledgment be sent for a subscriber version in a conflict-resolution-pending state. This notification is issued via the SOA to NPAC SMS interface from the NPAC subscription version object if the service provider fails to acknowledge the conflict resolution after a tunable amount of time specified in the NPAC SMS service data table.
subscriptionVersionDonorSP-CustomerDisconnectDate	This notification informs the donor service provider SOA that a subscription version is being disconnected. This notification is issued from a subscription version object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface.
subscriptionVersionLocalSMS-ActionResults	This notification contains the results of a subscriptionVersionLocalSMS-Create action once all the create requests have been attempted. It is issued from the Local SMS to the NPAC SMS via the NPAC SMS to Local SMS interface.
subscriptionVersionNew-NPA-NXX	This notification informs the Local SMS of a pending subscription version involving a new NPA-NXX.
subscriptionVersionNewSP-CreateRequest	This notification is issued to the new service provider to request that a create request be sent for the subscriber version created by the old service provider to provide authorization and/or porting information. This notification is issued via the SOA to NPAC SMS interface from the NPAC subscription version object if the new service provider failed to authorize porting of a number after a tunable amount of time specified in the NPAC SMS service data table.
subscriptionVersionOldSP-ConcurrenceRequest	This notification is issued to the old service provider to request that a create request be sent for the subscriber version created by the new service provider to provide concurrence for porting. This notification is issued via the SOA to NPAC SMS interface from the NPAC subscription version object if the old service provider failed to authorize porting of a number after a tunable amount of time specified in the NPAC SMS service data table.
subscriptionVersionStatusAttributeValueChange	This notification is issued when the subscription version status is modified. This notification is issued from both the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface from the subscriptionVersionNPAC object.

55

Secure Association Establishment

5.Secure Association Establishment

5.1.Overview

This chapter describes the security, the association management and recovery procedures for the service provider SOAs and Local SMSs to follow, and how error information will be passed between interfaces.

The first section describes the security and authentication procedures used in the NPAC SMS interface. The second section describes the NPAC SMS’s behavior and error handling and suggests how a service provider SOA or Local SMS should proceed when establishing an association.

5.2.Security

This section describes the security processes and procedures necessary for service provider SOA systems and Local SMSs to establish a secure association and maintain secure communication with the NPAC SMS.  Security threats to the NPAC SMS include:

•Spoofing - An intruder may masquerade as either the SOA, Local SMS, or NPAC SMS to falsely report information.

•Message Tampering - An intruder may modify, delete, or create messages passed.

•Denial or Disruption of Service - An intruder may cause denial or disruption of service by generating or modifying messages.

•Diversion of Resources - An intruder may generate or modify messages that cause resources to be diverted to unnecessary tasks.

•Slamming - An intruder may generate or modify messages that cause customer’s service to be moved between service providers.

Security threats are prevented in the NPAC SMS by use of the following methods:

•Strong two way authentication at association.

•Insuring data integrity by detection of replay, deletion, or modification to a message.

•Insuring non-repudiation of data by guaranteeing integrity and supporting data origination authentication for each incoming message.

•Implementation of access control and application level security that allows only authorized parties to cause changes to the NPAC SMS database.

5.2.1.Authentication and Access Control Information

56

The following access control information definition will be used in the AccessControl field of the association and CMIP PDUs to insure a secure communication for both the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface:

LnpAccessControl ::= SEQUENCE {
	systemId	SystemID,
	systemType	SystemType,
	userId	GraphicString60 OPTIONAL,
	listId	INTEGER,
	keyId	INTEGER,
	cmiDepartureTime	GeneralizedTime,
	sequenceNumber	INTEGER (04294967295),
	signature	BITSTRING
	function	AssociationFunction,
	recoveryMode	BOOLEAN
}
ServiceProvID ::= NumberString(SIZE(8))
SystemID ::= CHOICE {
	serviceProvID [0] ServiceProvId,
	npac-sms [1] GraphicsString60
}
SystemType ::= ENUM {
	soa(0),
	local-sms(1),
	soa-and-local-sms(2),
	npac-sms(3) —value is only valid for AccessControl definition
}
AssociationFunction ::= SEQUENCE {
	soaUnits [0] SoaUnits,
	lsmsUnits [1] LSMSUnits
}
SoaUnits ::= SEQUENCE {
	soaMgmt [0] NULL OPTIONAL,
	networkDataMgmt [1] NULL OPTIONAL
}
LsmsUnits ::= SEQUENCE {
	processAudits [0] NULL OPTIONAL,
	dataDownload [1] NULL OPTIONAL,
	networkDataMgmt [2] NULL OPTIONAL,
	query [3] NULL OPTIONAL
}

57

Exhibit 7 Access Control

5.2.1.1.System Id

The system Id is the unique Id for the system using an interoperable interface and must be specified in the systemId field. For a service provider using the SOA and/or Local SMS interfaces, this is the OCN. For the NPAC SMS, it is the unique identifier for the regional SMS.

5.2.1.2.System Type

The system type that indicates the type of system using the interoperable interface must be specified in the systemType field. The valid types are SOA and/or Local SMS and NPAC SMS.

5.2.1.3.User Id

The user Id of the user of the interface can optionally be specified in the userId field for the SOA interface. This is the 60 character graphics string user identifier for a user on a SOA system. It is not validated on the NPAC SMS, however, it is used for logging purposes.

5.2.1.4.List Id

The list Id must be specified as an integer in the listId field to identify a key list.  This key list is one of the key lists exchanged outside of the interface process that is known to both the NPAC SMS and the Local SMS or SOA system it is communicating with.

5.2.1.5.Key Id

The key Id of a key in the key list must be specified as an integer in the keyId field.  This uniquely identifies the key in the key list used to create the digital signature. The size of the modulus for the key is 600 bits as specified by the ICC.

5.2.1.6.CMIP Departure Time

The CMIP departure time must be specified in GeneralizedTime in the cmipDepartureTime field as the time the PDU departed the sending system.  In order to insure data integrity and no-repudiation the NPAC SMS system must be synchronized to within two minutes of the Local SMS and SOA systems that it communicates.

5.2.1.7.Sequence Number

The sequence number is a 32 bit integer that must be specified in the sequenceNumber field.  It should be specified as zero at association time and incremented by one for every message sent over the association. Once the sequence number reaches 4294967295 the counter will be reset to one for the association. Please note that each sender independently keeps its own counter for the sequence number of messages sent and received. For example, after association is established, a Local SMS could send three messages to the NPAC SMS with sequence numbers 1, 2, and 3 respectively.  The NPAC SMS when sending it’s first message to the Local SMS would use sequence number 1 not sequence number 4.

58

5.2.1.8.Signature

The signature field contains the MD5 hashed and encrypted systemId, the system type, the userId, the cmipDepartureTime, and sequenceNumber without separators between those fields or other additional characters. Encryption is done using RSA encryption using the key from the key list specified. Validation of this field insures data integrity and non-repudiation of data.

5.2.1.9.Association Functions

The Association Function(s) must be specified on the initial association request (AARQ PDU). The following table lists the possible Association Functions that can be specified for each of the Association Request Initiators:

Exhibit 8 Association Functions

	Association Request Initiator
Association Function	SOA	Local SMS
SOA Management (Audit and Subscription Version) Classes: lnpSubscriptions subscriptionAudit subscriptionVersion subscriptionVersionNPAC	X
Service Provider and Network Data Management Classes: lnpNetwork lnpNPAC-SMS lnpServiceProvs serviceProv serviceProvLRN serviceProvNetwork serviceProv-NPA-NXX	X	X
Network and Subscription Data Download Classes: lnpNetwork lnpSubscriptions		X
Query Classes: All		X

Note that the multiple Association Functions can be specified for an association. For example, a Local SMS can establish an association for both the process audit and network and subscription data download association functions.

59

5.2.1.10.Recovery Mode

The recovery mode flag is set to TRUE when a Local SMS is establishing a connection after a downtime. This flag indicates to the NPAC SMS to hold all current transactions until the Local SMS sends the Recovery Complete action. Once an association is established in recovery mode, the Local SMS should request subscription and network downloads. The Local SMS should also query for active audits and remove any outstanding audits on its system.  After these steps are complete, the Local SMS should submit the Recovery Complete action. The NPAC SMS will respond with all updates since association establishment and then normal processing will resume. See Chapter 6, Section 6.5.1, Sequencing of Events on Initialization/Resynchronization of Local SMS.

The recovery mode flag applies only to the Network and Subscription Data Download Association Function.

5.2.2.Association Establishment

Strong two way authentication at association is done for both the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.  This secure association establishment is done at the application level using the access control field described above.  The access control information used during association set-up is sent in the association control messages. Association establishment can be done by the SOA to NPAC SMS or Local SMS to NPAC SMS. The NPAC SMS cannot initiate an association. The initiator of the association specifies its information in the AARQ PDU message and the responder in the AARE PDU.

The following is an example of the information exchanged in the AARQ and AARE PDUs and the processing involved.  Assume for the example:

•A Local SMS is making an association with the NPAC SMS.

•The Local SMS systemId is “Company XYZ User Id.”

•The NPAC SMS systemId is “NPAC SMS User Id.”

•The listId for the key list is 1.

•The keyId is 32.

•The key in listId 1 with a keyId of 32 is “ABC123.”

•The sequence number is 0 (as required).

The Local SMS initiates the association request by creating and sending an AARQ PDU to the NPAC SMS.  This AARQ PDU contains the following access control information in the syntax described above:

•The systemId of “Company XYZ User Id.”

•The listId of 1.

•The keyId of 32.

•The current Local SMS GMT time in the cmipDepartureTime.

•A sequence number of 0.

60

•The signature contains MD5 hashed and encrypted systemId, systemType, userId, cmipDepartureTime, and the sequenceNumber using the encryption key “ABC123” as found in key list 1 with key id 32.

•And all BOOLEAN items are set to FALSE in the functional groups field, except for the processAudits item which is set to TRUE.

Once the AARQ PDU is sent, the sender (in this case the Local SMS), starts a tunable timer (with a default value of 2 minutes).  If the timer expires before the AARE PDU is received then the Local SMS will terminate the association attempt.

When the NPAC SMS receives the association request it validates the data received.  The data is validated as follows:

•Insure the systemId is present and valid for the association.

•Insure the sequence number is 0.

•Insure the cmipDepartureTime is within 5 minutes of the current NPAC SMS GMT time.

•Find the key specified and decrypt the signature insuring that the systemId, systemType, userId, cmipDepartureTime, and sequenceNumber are the same as those specified in the PDU.

•The functional groups requested are valid for the system type that requested the association. In this example, the system type must be “local-sms(1)” or “soa-and-local-sms(2).”

If validation of the AARQ PDU fails then an A-ABORT will be issued by the NPAC SMS without any additional information.  This will prevent network resources from being used by intruders.  If the validation of the AARQ PDU is successful then an AARE PDU would be sent back to the Local SMS.  This AARE PDU contains the following access control information in the syntax described above:

•The systemId of “NPAC SMS User Id.”

•The listId of 1.

•The keyId of 32.

•The current NPAC SMS GMT time in the cmipDepartureTime.

•A sequence number of 0.

•And the signature contains MD5 hashed and encrypted systemId, systemType, userId, cmipDepartureTime, and the sequenceNumber using the encryption key “ABC123” as found in key list 1 with key id 32.

The NPAC SMS may choose to optionally specify a new listId and keyId if for any reason it wants to make a key change. When the Local SMS receives the association response it validates the data received.  The data is validated as follows:

•Insure the systemId is present and valid for the association. (Note: the userId field is not required for Local SMS and NPAC SMS associations).

•Insure the sequence number is 0.

61

•Insure the cmipDepartureTime is within 5 minutes of the current Local SMS GMT time.

•Find the key specified and decrypt the signature insuring that the systemId, systemType, userId, cmipDepartureTime, and sequenceNumber are the same as those specified in the PDU.

If validation of the AARE PDU fails then an A-ABORT will be issued by the Local SMS without any additional information.  This will prevent network resources from being used by intruders.  If validation is successful then an secure association has been established.

5.2.3.Data Origination Authentication

For M-GET, M-SET, M-CREATE, M-DELETE, and M-ACTION, the access control field described above is used for data origination authentication.  Please note that any of the messages sent between manager and agent must be sent in confirmed mode.  The following is an example of the information exchanged in the CMIP PDUs and the processing involved.  Assume for the example:

•A Local SMS is making an association with the NPAC SMS.

•The Local SMS systemId is “Company XYZ User Id.”

•The NPAC SMS systemId is “NPAC SMS User Id.”

•The listId for the key list is 1.

•The keyId is 32.

•The key in listId 1 with a keyId of 32 is “ABC123.”

•The sequence number is 1.

The Local SMS sends an M-GET to the NPAC SMS.  The M-GET PDU contains the following access control information in the syntax described above:

•The systemId of “Company XYZ User Id.”

•The listId of 1.

•The keyId of 32.

•The current Local SMS GMT time in the cmipDepartureTime.

•A sequence number of 1.

•And the signature contains MD5 hashed and encrypted systemId, systemType, userId, cmipDepartureTime, and the sequenceNumber using the encryption key “ABC123” as found in key list 1 with key Id 32.

Once the M-GET is sent, the sender (in this case the Local SMS), starts a tunable timer (with a default value of 2 minutes).  If the timer expires before the M-GET Response is received then the Local SMS will terminate and reestablish the association.

When the NPAC SMS receives the M-GET request it validates the data received.  The data is validated as follows:

62

•Insure the systemId is present and valid for the association. (Note: the userId field is not required for Local SMS and NPAC SMS associations).

•Insure the sequence number is the next sequence number expected. (In this case 1).

•Insure the cmipDepartureTime is within 5 minutes of the current NPAC SMS time.

•Find the key specified and decrypt the signature, insuring that the systemId, systemType, userId, cmipDepartureTime, and sequenceNumber are the same as those specified in the PDU.

If validation of the M-GET PDU fails then an A-ABORT will be issued by the NPAC SMS without any additional information to prevent tampering and unauthorized use of network resources by intruders. If the validation of the M-GET PDU is successful then the NPAC SMS would get the data requested and send an M-GET Response would be sent back to the Local SMS.

Since CMIP notifications (M-EVENT-REPORT) do not have access control fields, all notifications defined contain the access control information in the notification definition. The values and authentication for the notification access control fields are the same as above except for the signature field. The signature field must contain all of the notification data, the generalized time, and the sequence number MD5 hashed and encrypted. Please note that CMIP notifications are confirmed.

5.2.4.Audit Trail

Audit trails will be maintained in logs on the NPAC SMS for the following association information:

•Association set-up messages.

•Association termination messages.

•Invalid messages:

•Invalid digital signature.

•Sequence number out of order.

•Generalized time out of range.

•Invalid origination address.

•All incoming messages regardless of whether or not they cause changes to data stored in the NPAC SMS.

This information will be made available for report generation on the NPAC SMS system.  It will not be made available through the NPAC SMS Interoperable Interface.

5.3.Association Management and Recovery

5.3.1.Establishing Associations

5.3.1.1.Error Handling

All association establishment requests and responses will include the following data elements.  This includes the NPACAssociationInfo which will contain any error information transferred between the interfaces.

63

A successful response will always be defined as an errorCode of 0 (zero).

The CMIPUserInfo structure defined in:

CMIPAssoc {

joint-iso-ccitt ms(9) cmip(1) modules(0)
aAssociateUserInfo(1)

}

will be passed in the user-information field of all association PDUs (AARQ,  AARE, RLRQ, RLRE, ABRT).  The ASN.1 basic definition is as follows:

CMIPUserInfo::= SEQUENCE

{

protocolVersion[0] IMPLICIT ProtocolVersion

DEFAULT {version1-cmip-assoc},

functionalUnits[1] IMPLICIT FunctionalUnits

DEFAULT {},

accessControl                  [2] EXTERNAL OPTIONAL,

userInfo[3] EXTERNAL OPTIONAL

}

The LnpAccessControl structure (defined earlier) will be passed in the accessControl field on all association PDUs.  The following ASN.1 structure will be passed in the userInfo field on AARE, RLRE, and ABRT PDUs generated from the NPAC SMS:

NpacAssociationInfo ::= SEQUENCE

{

errorCode[0] IMPLICIT ErrorCode,

errorText[1] IMPLICITGraphicString(SIZE(1..80))

}

ErrorCode ::= ENUMERATION

{

success (0),

access-denied (1),— accessControl information failed
— validation

retry-same-host (2),—  this NPAC SMS host is the
— primary, but is temporarily
— down, try this host again later

try-other-host (3)— this NPAC SMS is no longer the
— primary, try the backup host

}

64

The errorText field may contain further information to be defined later.

5.3.1.2.NPAC SMS Behavior

Under normal conditions, the primary NPAC SMS will be responding by accepting association requests while the secondary NPAC SMS will be responding by denying association requests with an error code of TRY _OTHER_HOST.

When the primary NPAC SMS needs to go down for a short period of time (secondary will not take over),  the primary NPAC SMS will either not be responding (if down) or be denying association requests with an error code of RETRY _SAME_HOST (if partially up). The secondary NPAC SMS will be responding by denying association requests with an error code of TRY _OTHER_HOST.

When the primary NPAC SMS goes down (scheduled or unscheduled) and the secondary NPAC SMS is re-synchronizing to become active, the primary NPAC SMS will be denying association requests with an error code of TRY  _OTHER_HOST. The secondary NPAC SMS will be responding by denying association requests with an error code of RETRY_SAME_HOST. Once the secondary NPAC SMS is done re-synchronizing, it will then start accepting association requests.

5.3.1.3.Service Provider SOA and Local SMS Procedures

The following is an algorithm that can be used by a service provider SOA or Local SMS when trying to establish an association with the NPAC SMS:

try to establish an association on the primary NPAC SMS if a response was obtained

{

  if the response was an AARE

  {

    switch (error code)

    {

      case SUCCESSFUL

        done

      case ACCESS_DENIED

        find out what is causing the error and fix it

        retry the association on the primary NPAC SMS

      case RETRY_SAME_HOST

        wait X seconds

        retry the association on the primary NPAC SMS

      case TRY_OTHER_HOST

        wait X seconds

        execute this algorithm again substituting

        “secondary” for “primary”

    }

  }

65

  else

  {

    if the response was an ABRT

    {

      if the reason for the abort indicates some hope

      for a successful retry

      {

        wait X seconds

        retry primary NPAC SMS

      }

      else

      {

        find out what is causing the error and fix it

        retry the association on either the primary or

        secondary NPAC SMS

      }

    }

  }

else

{

  # timeout - some type of network error has occurred

  # a number of different things can be done:

  #

  #   wait X seconds

  #   retry primary

  #

  #       or

  #

  #   find out what is causing the error and fix it

  #   retry the association on the primary NPAC SMS

  #

  #       or

  #

  #   wait X seconds

  #   execute this algorithm again substituting

  #   “secondary” for “primary”

}

5.3.2.Releasing or Aborting Associations

Any of the systems, NPAC SMS, service provider SOA or Local SMS can release or abort an association at any time. Once a scheduled outage has arrived, the NPAC SMS

66

will deny associations (error code of “Try Other Host” or “Retry Same Host” depending on the type of outage) and begin to terminate any associations that are outstanding. The NPAC SMS will first try to terminate the associations gracefully by sending an association release PDU. Any associations that are still outstanding will be issued an association abort.

5.3.3.CMIP Error Handling

In addition to the standard CMIP error reporting mechanisms, the following attribute will be passed in the SpecificErrorInfo structure on CMIP errors that return a PROCESSING FAILURE error. This structure will be used to detail errors not covered by the standard CMIP error codes.

GDMO Definition

lnpSpecificInfo ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpSpecificInfo;

    MATCHES FOR EQUALITY;

    BEHAVIOUR lnpSpecificInfoBehavior;

    REGISTERED AS {lnp-attribute 8};

lnpSpecificInfoBehavior BEHAVIOUR

    DEFINED AS !

This attribute is used to return more detailed error text information upon a CMIP Processing Failure error.

!;

ASN.1 Definition

LnpSpecificInfo ::= GraphicString(SIZE(1..256))

5.3.4.Resynchronization

The SOA and Local SMS associations are viewed to be permanent connections by the NPAC SMS. Thus when the association is broken for any reason, the system connecting to the NPAC SMS must assume responsibility to resynchronize themselves with the NPAC SMS.

5.3.4.1.Local SMS Resynchronization

To resynchronize itself, the Local SMS starts by setting the recoveryMode flag of the access control parameter. This flag signals the NPAC SMS to hold all data updates to this Local SMS. The Local SMS should then request the downloads it needs.  Once this is complete, the Local SMS should issue the lnpRecoveryComplete action to turn off the recoveryMode flag and receive back any other updates that have occurred since the association was established.

5.3.4.2.SOA Resynchronization

The SOA interface resynchronizes itself by issuing the necessary queries that inform it of updates made to objects it is concerned with since it last had an association with the NPAC SMS. For subscription objects, a query should be launched based upon the new or old service provider equal to the SOA service

67

provider and the subscriptionModifiedTimeStamp to be greater than the time when the association was lost.

Audit results may only be viewed from the NPAC SMS GUI and are not available on the mechanized interface.

68

Message Flow Diagrams

6.Message Flow Diagrams

6.1.Overview

This chapter defines the message flow scenarios for the SOA to NPAC and the NPAC SMS to Local SMS interfaces.  Each of these definitions consists of a message flow diagram and a textual description of the diagram.

The following is an example message flow diagram and legend for elements shown in the diagram.

[Graphic Omitted:  example message flow diagram and legend]

6.2.Audit Scenarios

6.2.1.SOA Initiated Audit

In this scenario, the SOA initiates an audit to the NPAC SMS due to suspected subscription version discrepancies.

[Graphic Omitted: Process diagram for SOA initiated audit]

a.Action is taken by SOA personnel to start an audit due to suspected network discrepancies.

b.The SOA sends a M-CREATE request to the NPAC SMS, requesting an audit.  The SOA must specify the following attributes in the request:

serviceProvID - SOA service provider id
subscriptionAuditName - English audit name
subscriptionAuditServiceProvIdRange - which service provider or all service providers for audit
subscriptionAuditTN-Range - TNs to be audited

If these attributes are not specified, then the create will fail with a missingAttributesValue error.  The SOA may also specify the following attributes in the request:

subscriptionAuditAttributeList - subscription version attributes to be audited
subscriptionAuditTN-ActivationRange - time range of activation for subscription versions to be audited

The subscriptionAuditId and the subscriptionAuditStatus will be determined by the NPAC SMS.  If any values are deemed invalid, an invalidArgumentValue error will be returned. NOTE: The subscriptionAuditTN-Range will be limited based on the maximum range size specified in the NPAC SMS.  If the limit specified is exceeded, the create request will fail with an invalidAttributeValue error.

45

c.Once the NPAC SMS creates the audit request object, it sends an M-CREATE response back to the SOA that initiated the request.

d.NPAC SMS sends M-EVENT-REPORT to the service provider SOA for the subscriptionAudit creation.

e.The service provider SOA confirms the M-EVENT-REPORT.

f.NPAC SMS begins audit.

g.NPAC SMS issues a scoped and filtered M-GET for the subscription versions in the audit.

h.Local SMS returns M-GET query data.

i.NPAC SMS performs the necessary comparisons of each subscription version object.

j.If a discrepancy is found, NPAC SMS issues a subscriptionAuditDiscrepancyRpt M-EVENT-REPORT.

k.Service provider SOA confirms the M-EVENT-REPORT.

l.If a discrepancy is found, NPAC SMS issues the necessary operation to the Local SMS to correct the discrepancy (M-CREATE, M-DELETE, or
M-SET).

m.NPAC SMS has completed the audit comparisons and corrections.

n.NPAC SMS issues the subscriptionAuditResults M-EVENT-REPORT to the service provider SOA.

o.The Service provider SOA confirms the M-EVENT-REPORT.

p.The NPAC SMS then sends an objectDeletion M-EVENT-REPORT to the SOA for the subscriptionAudit object.

q.The service provider SOA confirms the M-EVENT-REPORT.

r.The NPAC SMS issues a local M-DELETE request for the subscriptionAudit object to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS.

s.The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.

6.2.2.SOA Initiated Audit Cancellation by the SOA

The SOA cancels an audit that it initiated.

[Graphic Omitted:  Process diagram for SOA cancelled audit]

a.Action is taken by SOA personnel to cancel an audit previously initiated by the SOA.

b.The SOA sends an M-DELETE request for the subscriptionAudit object to the NPAC SMS, requesting cancellation of an audit.  If the audit was not initiated by the SOA requesting cancellation, then the request will be rejected with an accessDenied error.

c.The NPAC SMS will respond by sending an objectDeletion M-EVENT-REPORT.

d.The SOA confirms the M-EVENT-REPORT.

e.The NPAC SMS sends an M-DELETE response to the SOA.

6.2.3.SOA Initiated Audit Cancellation by the NPAC

46

The NPAC cancels an audit that was initiated by an SOA.

[Graphic Omitted:  Process diagram for audit cancellation by NPAC]

a.Action is taken by NPAC personnel to cancel an audit previously initiated by an SOA.

b.The NPAC SMS sends an objectDeletion M-EVENT-REPORT to the SOA that initiated the audit request.

c.The SOA confirms the M-EVENT-REPORT

d.The NPAC SMS issues a local M-DELETE request to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS.

e.The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.

6.2.4.NPAC Initiated Audit

In this scenario, the NPAC SMS initiates an audit due to suspected subscription version discrepancies.

[Graphic Omitted: Process diagram for audit initiated for subscription version discrepancies]

a.Action is taken by NPAC personnel to start an audit due to suspected network discrepancies.

b.The NPAC SMS does a Local M-CREATE request to itself for the subscriptionAudit object requesting an audit.

c.The NPAC SMS responds with an M-CREATE response indicating that the subscriptionAudit object was created successfully.

d.The NPAC SMS sends an M-GET request to the Local SMSs to retrieve the subscription data to use for audit processing.  The request uses the CMIP scoping and filtering options to retrieve only the subscriptionVersion objects to be audited.

e.The Local SMS responds to the M-GET request by returning the subscription data that satisfies the scope and filter data.

f.NPAC SMS performs the comparisons. If any discrepancies are found, the NPAC SMS will perform the necessary fix to the Local SMS.

g.NPAC SMS completes the audit.

h.Issue a local M-DELETE request for the subscriptionAudit object to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS.

i.The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.

6.2.5.       NPAC Initiated Audit Cancellation by the NPAC

The NPAC SMS cancels an audit that it initiated.

[Graphic Omitted: Process diagram - The NPAC SMS cancels an audit that it initiated]

a.Action is taken by NPAC personnel to cancel an audit previously initiated by the NPAC SMS.

47

b.Issue a local M-DELETE request to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS.

c.The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.

6.2.6.Audit Query on the NPAC

This scenario shows a service provider query on an existing audit that it initiated.

[Graphic Omitted:  Process diagram of audit query]

a.The service provider SOA takes action to query an audit that it initiated.

b.Service provider SOA sends an M-GET request for a subscriptionAudit on the NPAC SMS.

c.NPAC SMS responds to an M-GET with the audit data or a failure and reason for failure. An accessDenied error will be returned to the service provider if they did not originate the audit queried.

48

6.3.Service Provider Scenarios

6.3.1.Service Provider Creation by the NPAC

In this scenario, the NPAC SMS creates data for a new LNP service provider. The addition of NPA-NXX and LRN data for a new service provider will be shown in flows that follow.

[Graphic Omitted: Process diagram for service provider creation]

a.Action is taken by NPAC SMS personnel to create a new service provider.

b.Issue a local M-CREATE request for the serviceProv object to/from the NPAC SMS. This will attempt to create the serviceProv object on the NPAC SMS. If the M-CREATE fails, the appropriate error will be returned.

c.The M-CREATE response is received on the NPAC SMS indicating whether the serviceProv object was created successfully. If a failure occurs, processing will stop.

d.Issue a local M-CREATE request for the serviceProvNetwork object to/from the NPAC SMS. This will attempt to create the serviceProvNetwork object on the NPAC SMS. If the M-CREATE fails, the appropriate error will be returned.

e.The M-CREATE response is received on the NPAC SMS indicating whether the serviceProvNetwork object was created successfully. If the object cannot be created, the serviceProv object is deleted and an error is returned.

f.The NPAC SMS sends an M-CREATE request for the serviceProvNetwork object to each of the Local SMSs.

g.The Local SMS(s) will respond by sending an M-CREATE response back to the NPAC SMS.

6.3.2.Service Provider Deletion by the NPAC

In this scenario, the NPAC SMS deletes data for an LNP service provider with no network data.

[Graphic Omitted: Process diagram for service provider deletion]

a.Action is taken by NPAC SMS personnel to delete an existing service provider.

b.Check the network database to see if the service provider has NPA-NXX data defined for it. If so, deny the request.

c.Issue a local M-DELETE request for the serviceProv object to/from the NPAC SMS. This will attempt to delete the serviceProv object on the NPAC SMS.

d.The M-DELETE response is received on the NPAC SMS indicating whether the serviceProv object was deleted successfully.

e.If the serviceProv object was deleted, issue a local M-DELETE request for the serviceProvNetwork object to/from the NPAC SMS. This will attempt to delete the serviceProvNetwork object on the NPAC SMS.

f.The M-DELETE response is received on the NPAC SMS indicating whether the serviceProvNetwork object was deleted successfully.

49

g.If the serviceProvNetwork object was deleted, the NPAC SMS sends an M-DELETE request for the serviceProvNetwork object to each of the Local SMS(s).

h.The Local SMS(s) will respond by sending an M-DELETE response back to the NPAC SMS.

6.3.3.Service Provider Modification by the NPAC

In this scenario, the NPAC SMS modifies the LNP service provider data.

[Graphic Omitted: Process diagram for service provider modification]

a.Action is taken by the NPAC personnel to modify data for an existing service provider.

b.Issue a local M-SET request for the serviceProv object to/from the NPAC SMS. This will attempt to set the specified information on the NPAC SMS.

c.Validate the data to be set in the M-SET request. An M-SET Error Response of invalidArgumentValue is returned if any data is deemed invalid.

d.The M-SET response is received on the NPAC SMS indicating whether the serviceProv object was modified successfully.

e.NPAC SMS performs an M-SET to the Local SMS if the service provider name changed.

f.The Local SMS responds.

6.3.4.Service Provider Modification by the Local SMS

In this scenario, the Local SMS modifies its own service provider data.

[Graphic Omitted: Process diagram for service provider modification by local SMS]

a.Action is taken by the Local SMS personnel to modify their own service provider data.

b.The Local SMS sends an M-SET request to the NPAC SMS to modify their service provider information.

c.The NPAC SMS verifies that the service provider to be modified is owned by the service provider that initiated the request. If not, an access denied M-SET Error Response of invalidArgumentValue is returned.

d.Validate the data to be set in the M-SET request. An invalidArgumentValue M-SET Error Response is returned if any data is deemed invalid.

e.The NPAC SMS sends an M-SET response back to the Local SMS that initiated the request.

50

6.3.5.Service Provider Modification by the SOA

In this scenario, the SOA modifies its own service provider data.

[Graphic Omitted: Process diagram for service provider modification by SOA]

a.Action is taken by the SOA to modify their own service provider data.

b.The SOA sends an M-SET request to the NPAC SMS to modify their service provider information.

c.The NPAC SMS verifies that the service provider to be modified is owned by the service provider that initiated the request. If not, an access denied M-SET Error Response of invalidArgumentValue is returned.

d.Validate the data to be set in the M-SET request. An invalidArgumentValue M-SET Error Response is returned if any data is deemed invalid.

e.The NPAC SMS sends an M-SET response back to the SOA that initiated the request.

6.3.6.Service Provider Query by the Local SMS

In this scenario, the Local SMS queries their own service provider data.

[Graphic Omitted: Process diagram for service provider query by local SMS]

a.Action is taken by the Local SMS personnel to query their own service provider data.

b.The Local SMS sends an M-GET request to the NPAC SMS requesting their own service provider information.

c.The NPAC SMS verifies that the service provider information to be retrieved is owned by the service provider that initiated the request. If not, an M-GET Error Response of accessDenied is returned if the two service providers do not match.

d.The NPAC SMS sends an M-GET response containing the requested service provider information back to the Local SMS or SOA that initiated the request.

6.3.7.Service Provider Query by the SOA

In this scenario, the SOA queries their own service provider data.

[Graphic Omitted: Process diagram for service provider query by SOA]

a.Action is taken by the SOA or SOA personnel to query their own service provider data.

b.The SOA sends an M-GET request to the NPAC SMS requesting their own service provider information.

c.The NPAC SMS verifies that the service provider information to be retrieved is owned by the service provider that initiated the request. If not, an M-GET error response of accessDenied is returned if the two service providers do not match.

d.The NPAC SMS sends an M-GET response containing the requested service provider information back to the SOA that initiated the request.

51

Service Provider Network Data Scenarios

6.3.8.NPA-NXX Scenarios

6.3.8.1.NPA-NXX Creation by the NPAC

In this scenario, NPAC SMS creates new NPA-NXX data for an LNP service provider.

[Graphic Omitted: Process diagram for NPA-NXX creation]

a.Action is taken by the NPAC Personnel to create an NPA-NXX for a specified service provider.

b.The NPAC SMS sends an M-CREATE request to itself in order to create a local serviceProvNPA-NXX object.

c.The NPAC SMS receives the M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.

d.If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to the Local SMS(s) for the serviceProvNPA-NXX object.

e.The Local SMS(s) respond by sending an M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.

52

6.3.8.2.NPA-NXX Deletion by the NPAC

In this scenario, NPAC SMS deletes an NPA-NXX for an LNP service provider.

[Graphic Omitted: Process diagram for NPA-NXX deletion]

a.Action is taken by NPAC SMS personnel to delete an NPA-NXX for a specified service provider.

b.Check the subscriptions database to see if subscriptions exist with this NPA-NXX that have a status other than “old” or “canceled.” If so, terminate processing at this point.

c.     The NPAC SMS sends an M-DELETE request to itself in order to delete the local serviceProvNPA-NXX object.

d.The NPAC SMS receives the M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

e.If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to the Local SMS(s) for the serviceProvNPA-NXX object.

f.The Local SMS(s) responds by sending an M-DELETE response to the NPAC SMS indicating whether the serviceProvNPA-NXX object was deleted successfully.

6.3.8.3.NPA-NXX Creation by the Local SMS

In this scenario, the Local SMS creates a new NPA-NXX for its own service provider network data.

[Graphic Omitted: Process diagram for NPA-NXX creation]

a.Action is taken by the Local SMS personnel to create an NPA-NXX available for porting in their own service provider network.

b.The Local SMS sends an M-CREATE request to the NPAC requesting that an NPA-NXX object be created for their own service provider network.

c.The NPAC SMS verifies that the service provider creating the NPA-NXX information is the same as the service provider that owns the network data. If not, then an access denied M-CREATE accessDenied Error Response is returned.

d.The NPAC SMS responds by sending an M-CREATE response to the Local SMS that initiated the request indicating whether the serviceProvNPA-NXX object was created successfully.

e.If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to the other Local SMS(s) for the serviceProvNPA-NXX object.

f.The Local SMS(s) responds by sending an M-CREATE Response indicating whether the serviceProvNPA-NXX object was created successfully.

53

6.3.8.4.NPA-NXX Creation by the SOA

In this scenario, the SOA creates a new NPA-NXX for its own service provider network data.

[Graphic Omitted: Process diagram for NPA-NXX creation]

a.Action is taken by the SOA personnel to create an NPA-NXX available for porting in their own service provider network.

b.The SOA sends an M-CREATE request to the NPAC requesting that an NPA-NXX object be created for their own service provider network.

c.The NPAC SMS verifies that the service provider creating the NPA-NXX information is the same as the service provider that owns the network data. If not, then an access denied M-CREATE response to the SOA that initiated the request indicating whether the serviceProvNPA-NXX object was created successfully.

d.The NPAC SMS sends an M-CREATE response back to the SOA for the serviceProvNPA-NXX object.

e.The NPAC SMS sends an M-CREATE request to the other Local SMS(s) for the serviceProvNPA-NXX object.

f.The Local SMS(s) responds by sending an M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.

6.3.8.5.NPA-NXX Deletion by the Local SMS

In this scenario, the Local SMS deletes an NPA-NXX in its own service provider network data.

[Graphic Omitted: Process diagram for NPA-NXX deletion]

a.Action is taken by the Local SMS personnel to delete an NPA-NXX for their own service provider network data.

b.The SMS sends an M-DELETE request to the NPAC SMS requesting that an NPA-NXX object be deleted for their own service provider.

c.The NPAC SMS verifies that the service provider that owns the NPAC-NXX information to be deleted is the same as the service provider that owns the network data. If not, then an M-DELETE accessDenied error response is returned.

d.Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” or canceled.” If so, terminate processing at this point.

e.The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

f.If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to the other Local SMS(s) for the serviceProvNPA-NXX object.

g.The Local SMS(s) responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

54

6.3.8.6.NPA-NXX Deletion by the SOA

In this scenario, the SOA deletes a new NPA-NXX for its own service provider network data.

[Graphic Omitted: Process diagram for NPA-NXX deletion by SOA]

a.Action is taken by the SOA personnel to delete an NPA-NXX for their own service provider network data.

b.The SOA sends an M-DELETE request to the NPAC SMS requesting that an NPA-NXX object be deleted for their own service provider.

c.The NPAC SMS verifies that the service provider that owns the NPAC-NXX information to be deleted is the same as the service provider that owns the network data. If not, then an M-DELETE accessDenied Error Response is returned.

d.Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” or “canceled.” If so, terminate processing at this point.

e.The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

f.The NPAC SMS sends an M-DELETE request to the Local SMS(s) for the serviceProvNPA-NXX object.

g.The Local SMS(s) respond by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

6.3.8.7.NPA-NXX Query by the Local SMS

In this scenario, the Local SMS queries for NPA-NXX data.

[Graphic Omitted: Process diagram for NPA-NXX Query by local SMS]

a.Action is taken by Local SMS personnel to query for a serviceProvNPA-NXX.

b.The Local SMS sends an M-GET request to the NPAC SMS for the serviceProvNPA-NXX object.

c.The NPAC SMS responds by sending an M-GET response containing the NPA-NXX data back to the Local SMS.

55

6.3.8.8.NPA-NXX Query by the SOA

In this scenario, the SOA queries for NPA-NXX updates.

[Graphic Omitted: Process diagram for NPA-NXX query for updates]

a.Action is taken by SOA personnel to query for a serviceProvNPA-NXX.

b.The SOA sends an M-GET request to the NPAC SMS for the serviceProvNPA-NXX object.

c.The NPAC SMS responds by sending an M-GET response containing the NPA-NXX data back to the Local SMS.

6.3.9.LRN Scenarios

6.3.9.1.LRN Creation by the NPAC

In this scenario, the NPAC SMS creates an LRN for an LNP serviceProvNPA-NXX.

[Graphic Omitted: Process diagram for LRN creation]

a.Action is taken by the NPAC personnel to create an LRN for an existing service provider.

b.The NPAC SMS sends an M-CREATE request to itself in order to create a local serviceProvLRN object.

c.     The NPAC SMS receives the M-CREATE response indicating whether the serviceProvLRN object was created successfully.

d.If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to the Local SMS(s) for the serviceProvLRN object.

e.The Local SMS(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.

6.3.9.2.LRN Creation by the SOA

In this scenario, the SOA creates an LRN for its own service provider network data.

[Graphic Omitted: Process diagram for LRN creation by SOA]

a.Action is taken by the SOA personnel to create an LRN for their own network data.

b.The SOA sends an M-CREATE request to the NPAC SMS requesting that an LRN object be created for their own network data.

c.The NPAC SMS verifies that the service provider creating the LRN information is the same as the service provider that owns the service provider network data. If not, then an accessDenied M-CREATE Error Response is returned.

d.The NPAC SMS responds by sending an M-CREATE response back to the SOA that initiated the request, indicating whether the serviceProvLRN object was created successfully.

56

e.The NPAC SMS sends an M-CREATE request to the Local SMS(s) for the serviceProvLRN object.

f.The Local SMS(s) respond by sending an M-CREATE response indicating whether the service provider LRN object was created successfully.

6.3.9.3.LRN Deletion by the SOA

In this scenario, the SOA deletes an LRN for their own service provider network data.

[Graphic Omitted: Process diagram for LRN deletion by SOA]

a.Action is taken by the SOA personnel to delete an LRN for their own network data.

b.The SOA sends an M-DELETE request to the NPA requesting that an LRN object be deleted.

c.The NPAC SMS verifies that the service provider deleting the LRN information is the same as the service provider that is associated with the network data. If not, then an accessDenied M-DELETE error response is returned.

d.Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” or “canceled.” If so, an M-SET error response complexity limitation is returned.

e.The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.

f.The NPAC SMS sends an M-DELETE request to the Local SMS(s) for the serviceProvLRN object.

g.The Local SMS(s) responds by sending a message indicating whether the serviceProvLRN object was deleted successfully.

6.3.9.4.LRN Query by the SOA

In this scenario, the SOA queries LRN data.

[Graphic Omitted: Process diagram for LRN query by SOA]

a.Action is taken by SOA personnel to an LRN for a specified service provider.

b.The SOA sends an M-GET request to the NPAC SMS for the serviceProvLRN object.

c.The NPAC SMS responds by sending an M-GET response containing the data back to the SOA.

57

6.3.9.5.LRN Deletion by the NPAC

In this scenario, the NPAC SMS deletes an LRN for an LNP serviceProvNPA-NXX.

[Graphic Omitted: Process diagram for LRN deletion by NPAC]

a.Action is taken by the NPAC SMS personnel to delete an LRN for a service provider.

b.Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” or “canceled.” If so, terminate processing at this point.

c.The NPAC SMS sends an M-DELETE request to itself in order to delete the local serviceProvLRN object.

d.The NPAC SMS receives the M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.

e.If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to the Local SMS(s) for the serviceProvLRN object.

f.The Local SMS(s) responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.

6.3.9.6.LRN Creation by the Local SMS

In this scenario, the Local SMS creates an LRN for its own service provider network data.

[Graphic Omitted: Process diagram for LRN creation by local SMS]

a.Action is taken by the Local SMS personnel to create an LRN for their own network data.

b.The SMS sends an M-CREATE request to the NPAC requesting that an LRN object be created for their own network data.

c.The NPAC verifies that the service provider creating the LRN information is the same as the service provider that owns the service provider network data. If not, then an accessDenied M-CREATE error response is returned.

d.The NPAC SMS responds by sending an M-CREATE response back to the Local SMS that initiated the request, indicating whether the serviceProvLRN object was created successfully.

e.If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to the other Local SMS(s) for the serviceProvLRN object.

f.The Local SMS(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.

58

6.3.9.7.LRN Deletion by the Local SMS

In this scenario, the Local SMS deletes an LRN for their own service provider network data.

[Graphic Omitted: Process diagram for LRN deletion by local SMS]

a.Action is taken by the Local SMS personnel to delete an LRN for their own network data.

b.The Local SMS sends an M-DELETE request to the NPAC requesting that an LRN object be deleted.

c.The NPAC SMS verifies that the service provider deleting the LRN information is the same as the service provider that is associated with the network data. If not, then an accessDenied M-DELETE Error Response is returned.

d.Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” or “canceled.” If so, an M-SET Error Response complexity limitation is returned.

e.The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.

f.If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to the other Local SMS(s) for the serviceProvLRN object.

g.The Local SMS(s) responds by sending a message indicating whether the serviceProvLRN object was deleted successfully.

6.3.9.8.LRN Query by the Local SMS

In this scenario, the Local SMS queries LRN data.

[Graphic Omitted: Process diagram for LRN query by local SMS]

a.Action is taken by Local SMS personnel to query an LRN for a specified service provider.

b.The Local SMS sends an M-GET request to the NPAC SMS for the serviceProvLRN object.

c.The NPAC SMS responds by sending an M-GET response containing the data back to the Local SMS.

59

6.3.9.9.Network Data Download

This scenario shows a Local SMS request for network data download in order to update their view of this data.

[Graphic Omitted: Process diagram for network data download]

a.Action is taken by the Local SMS personnel to request a network data download. The criteria to decide which network data is to be downloaded is specified by the Local SMS personnel.

b.The Local SMS sends an M-ACTION request to the NPAC SMS lnpNetwork object requesting a network data download.

c.The NPAC SMS looks up the network data in the network database as specified by the criteria in the M-ACTION request.

d.The NPAC SMS responds by sending an M-ACTION response to the Local SMS that initiated the request. The response includes the success/failure of the request along with the requested network data.

e.The Local SMS must take appropriate action to update their view of the data.

6.3.9.10.Scoped/Filtered GET of Network Data

This scenario shows a request for network data via a scoped/filtered M-GET. In this case, scoping is done from the lnpNetwork object. However, scoping and filtering can be done from serviceProvNetwork and serviceProvNPA-NXX objects.

[Graphic Omitted: Process diagram for get of network data]

a.Action is taken by the Local SMS personnel to request network data via a scoped/filtered M-GET request.

b.The Local SMS sends a scoped/filtered M-GET request to the NPAC SMS.

c.The NPAC SMS sends network data objects (serviceProvNetwork, serviceProvNPA-NXX, serviceProvLRN) that pass the scope/filter criteria to the Local SMS that initiated the request.

d.A final M-GET response is sent to the Local SMS that initiated the request once all scoped/filtered network objects have been returned.

60

6.4.SubscriptionVersion Flow Scenarios

6.4.1.SubscriptionVersion Create Scenarios

The subscriptionVersionNPAC object is created by either the new or old service provider SOA issuing an M-ACTION. Once one provider issues its M-ACTION create, the other service provider then responds with its own create.

6.4.1.1.SubscriptionVersion Create by the Initial SOA (Old Service Provider)

In this scenario, the old service provider is the first to send the M-ACTION to create the subscriptionVersion object.

[Graphic Omitted: Process diagram for subscription version creation]

a.Action is taken by the old service provider SOA to create a new version of a subscriber.

b.Old service provider SOA sends M-ACTION subscriptionVersionOldSP-Create to the NPAC SMS lnpSubscriptions object to create a new subscriptionVersionNPAC. The old service provider SOA must specify the following valid attributes:

subscriptionTN or a valid subscriptionVersionTN-Range

subscriptionNewCurrentSP

subscriptionOldSP

subscriptionOldSP-DueDate

subscriptionOldSP-Authorization

subscriptionLNPType

If the service provider were to give a range of TNs, this would result in an M-CREATE and M-EVENT-REPORT for each TN.

If an attribute value is invalid, an invalidArgumentValue will be returned, indicating invalid data values. Other appropriate errors will also be returned.

c.If the request is valid, the NPAC SMS will create the subscriptionVersionNPAC object. The status will be set to “pending” and the subscriptionOldSP-AuthorizationTimeStamp and subscriptionModifiedTimeStamp will be set.

d.NPAC SMS responds to M-CREATE.

e.NPAC SMS sends action reply with success or failure and reasons for failure.

f.If the M-ACTION was successful, the NPAC SMS issues an M-EVENT-REPORT to old service provider SOA of subscriptionVersionNPAC creation.

g.Old service provider SOA responds by sending an M-EVENT-REPORT confirmation back to the NPAC SMS.

h.If the M-ACTION was successful, the NPAC SMS issues an M- EVENT-REPORT to new service provider SOA of subscriptionVersionNPAC creation.

61

i.New service provider SOA issues an M-EVENT-REPORT confirmation to NPAC SMS.

The next scenario would be “SubscriptionVersion Create by the Second SOA (New Service Provider).”

6.4.1.2.SubscriptionVersion Create by the Initial SOA (New Service Provider)

In this scenario, the new service provider is the first to send the M-ACTION to create the subscriptionVersion object.

[Graphic Omitted: Process diagram for subscription version create]

a.Action is taken by the new service provider SOA to create a new version of a subscriber.

b.New service provider SOA sends M-ACTION subscriptionVersionNewSP-Create to the NPAC SMS lnpSubscriptions object to create a new subscriptionVersionNPAC. The new service provider SOA must specify the following valid attributes:

subscriptionTN or a valid subscriptionVersionTN-Range

subscriptionNewCurrentSP

subscriptionOldSP

subscriptionNewSP-DueDate

subscriptionLNPType

subscriptionPortingToOriginal-SP Switch

The following items must be provided unless subscriptionPortingToOriginal-SP is true:

subscriptionLRN

subscriptionCLASS-DPC

subscriptionCLASS-SSN

subscriptionLIDB-DPC

subscriptionLIDB-SSN

subscriptionCNAM-DPC

subscriptionCNAM-SSN

subscriptionISVM-DPC

subscriptionISVM-SSN

The following attributes are optional:

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

If the service provider were to give a range of TNs, this would result in an M-CREATE and M-EVENT-REPORT for each TN.

If any attribute is invalid, an action failure will be returned, indicating invalidArgumentValue. Other appropriate errors will also be returned.

c.If the request is valid, the NPAC SMS will create the subscriptionVersionNPAC object. The status will be set to “pending” and the subscriptionNewSP-AuthorizationTimeStamp,

62

subscriptionModifiedTimeStamp and subscriptionCreationTimeStamp will be set.

d.NPAC SMS responds to M-CREATE.

e.NPAC SMS sends action reply with success or failure and reasons for failure.

f.If the M-ACTION was successful, NPAC SMS issues an M-EVENT-REPORT to old service provider SOA of subscriptionVersionNPAC creation.

g.Old service provider SOA responds by sending an M-EVENT-REPORT confirmation back to the NPAC SMS.

h.If the M-ACTION was successful, NPAC SMS issues an M-EVENT-REPORT to new service provider SOA of subscriptionVersionNPAC creation.

i.New service provider SOA issues an M-EVENT-REPORT confirmation to NPAC SMS.

The next scenario would be “SubscriptionVersion Create by the Second SOA (Old Service Provider).”

6.4.1.3.SubscriptionVersion Create by Second SOA (New Service Provider)

In this scenario, the old service provider has already issued its request causing the subscriptionVersionNPAC to be created. The new service provider is now following with its own create action.

[Graphic Omitted: Process diagram for subscription version create by second soa]

a.New service provider SOA personnel take action to create a new subscription version.

b.New service provider SOA sends M-ACTION subscriptionVersionNewSP-Create to NPAC SMS lnpSubscriptions object to create a new subscriptionVersionNPAC. The new service provider SOA must specify the following valid attributes:

subscriptionTN or a valid subscriptionVersionTN-Range

subscriptionNewCurrentSP

subscriptionOldSP

subscriptionNewSP-DueDate

subscriptionLNPType

subscriptionPortingToOriginal-SP Switch

The following items must be provided unless subscriptionPortingToOriginal-SP is true:

subscriptionLRN

subscriptionCLASS-DPC

subscriptionCLASS-SSN

subscriptionLIDB-DPC

subscriptionLIDB-SSN

subscriptionCNAM-DPC

63

subscriptionCNAM-SSN

subscriptionISVM-DPC

subscriptionISVM-SSN

The following attributes are optional:

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

If a TN range is specified in the request, it would result in an M-SET request and M-EVENT-REPORT for each TN.

If the new service provider is not the new service provider specified in the initial create by the old service provider, an accessDenied error will be returned.

If any attribute is invalid, an action failure will be returned, indicating invalidArgumentValue. Other appropriate errors will be returned.

c.If successful, the NPAC SMS sets the subscriptionNewSP-AuthorizationTimeStamp, subscriptionModifiedTimeStamp, subscriptionCreationTimeStamp, and all data specified in the M-ACTION.

d.NPAC SMS responds to M-SET.

e.NPAC SMS sends M-ACTION reply with success or failure and reasons for failure.

f.NPAC SMS issues the M-EVENT-REPORT to the old service provider when the subscriptionNewSP-DueDate changes value.

g.Old service provider SOA issues M-EVENT-REPORT confirmation.

h.If the M-ACTION was successful, the NPAC SMS issues M-EVENT-REPORT to the new service provider for all attributes updated from the preceding list.

i.New service provider SOA issues M-EVENT-REPORT confirmation.

j.NPAC SMS decides if this subscription version is the first use or the NPA-NXX.

k.If this is the first use of the NPA-NXX, the NPAC SMS sends the subscriptionVersionNewNPA-NXX M-EVENT-REPORT to inform the Local SMS.

l.The Local SMS confirms the M-EVENT-REPORT.

The next scenario would be “SubscriptionVersion Activated by New Service Provider SOA.”

64

6.4.1.4.SubscriptionVersion Create by Second SOA (Old Service Provider)

In this scenario, the new service provider has already issued its request causing the subscriptionVersionNPAC to be created. The old service provider is now following with its own create action.

[Graphic Omitted: Process diagram for subscription version create by second soa]

a.Old service provider SOA personnel take action to create a old subscription version.

b.Old service provider SOA sends M-ACTION subscriptionVersionOldSP-Create to NPAC SMS lnpSubscriptions object to create an old subscriptionVersionNPAC.  The old service provider SOA must specify the following valid attributes:

subscriptionTN or a valid subscriptionVersionTN-Range

subscriptionOldCurrentSP

subscriptionOldSP

subscriptionOldSP-Authorization

subscriptionOldSP-DueDate

subscriptionLNPType

If a TN range is specified in the request, it would result in an M-SET request and M-EVENT-REPORT for each TN.

If the old service provider is not the old service provider specified in the initial create request by the new service provider, an accessDenied error will be returned.

If any attribute is invalid, an invalidArgumentValue will be returned, indicating invalid data values. Other appropriate errors will also be returned.

c.If the data is valid, the NPAC SMS sets the subscriptionOldSP-AuthorizationTimeStamp, subscriptionModifiedTimeStamp and all data specified in the M-ACTION.

d.NPAC SMS responds to M-SET.

e.NPAC SMS sends M-ACTION reply with success or failure and reasons for failure.

f.If the M-ACTION was successful, the NPAC SMS issues M-EVENT-REPORT attribute value change to the old service provider for all attributes updated from the following list:

subscriptionOldSP-DueDate

subscriptionOldSP-Authorization

g.Old service provider SOA issues M-EVENT-REPORT confirmation.

h.If the M-ACTION was successful, the NPAC SMS issues M-EVENT-REPORT attribute value change to the new service provider for all attributes updated from the preceding list.

i.New service provider issues M-EVENT-REPORT confirmation.

65

j.NPAC SMS decides if this subscription version is the first use or the NPA-NXX.

k.If this is the first use of the NPA-NXX, the NPAC SMS sends the subscriptionVersionNewNPA-NXX M-EVENT-REPORT to inform the Local SMS.

l.The Local SMS confirms the M-EVENT-REPORT.

The next scenario would be “SubscriptionVersion Activated by New Service Provider SOA.”

6.4.1.5.SubscriptionVersion Activated by New Service Provider SOA

In this scenario, both service providers have sent their create data updates for a new subscription version to the NPAC SMS. The new service provider now activates the subscriptionVersion.

[Graphic Omitted: Process diagram for subscription version activated]

a.The new service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version or range of subscription versions.

b.NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending,” subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC object.

c.NPAC SMS responds to the M-SET.

d.The NPAC SMS responds with the M-ACTION response. An error will be returned if the service provider is not the new service provider (accessDenied) or if there is no version to be activated (invalidArgumentValue) or if any other failures occur.

e.If the M-ACTION was successful, the NPAC SMS sends to the old SOA a subscriptionVersionStatusAttributeValueChange for the subscriptionVersionStatus being set to “sending”.

f.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

g.If the M-ACTION was successful, the NPAC SMS sends to the new service provider SOA a subscriptionVersionStatusAttributeValueChange for the subscriptionVersionStatus being set to “sending.”

h.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

For subscription versions that are not being ported to the original service provider’s switch, processing continues in the “Active SubscriptionVersion Create on Local SMSs” flow.

For ports to the original service provider’s switch, the flow follows an immediate disconnect scenario. The NPAC SMS sets the broadcast timestamp, notifies the service provider SOA of the status change and proceeds to issue M-DELETEs for the subscriptionVersion to the Local SMS.

66

6.4.1.6.Active SubscriptionVersion Create on Local SMS

This scenario and associated error scenarios reflect the message flow for all new object create requests from the NPAC SMS to the Local SMSs.

[Graphic Omitted: Process diagram for active subscription version create]

a.NPAC SMS has a new subscriptionVersion with a status of “sending.”

b.The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs.

c.Each Local SMS will reply to the M-CREATE.

d.NPAC SMS waits for Local SMSs to report successful objectCreation.

e.NPAC SMS issues an M-SET to update the subscriptionVersionStatus to “active” for the subscriptionVersionNPAC if all creates are successful, and sets the subscriptionActivationTimeStamp and subscriptionModifiedTimeStamp for the current version.

f.NPAC SMS responds to M-SET.

g.If the subscriptionVersion NPAC object was modified, the NPAC SMS will issue M-EVENT-REPORT notifications to the old service provider SOA of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.

h.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

i.If the subscriptionVersion NPAC object was modified, the NPAC SMS will issue M-EVENT-REPORT notifications to the new service provider SOA of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.

j.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

6.4.1.7.Active Subscription Version Create on Local SMS Using Create Action

This scenario reflects the message flow for all new object create requests from the NPAC SMS to the Local SMS Using Create Action.

[Graphic Omitted: Process diagram for all new object create requests from the NPAC SMS to the Local SMS Using Create Action]

a.NPAC SMS has one or more subscription versions with a status of “sending.”

b.NPAC SMS issues the subscriptionVersionLocalSMS-Create action to Local SMS. This action contains all data necessary to create the subscription version.

c.The Local SMS verifies the action is valid, but does not attempt to create the subscription version(s).

d.The Local SMS responds to the M-ACTION.

67

e.The Local SMS proceeds to execute all the creates specified by the action.

f.The Local SMS sends to the NPAC SMS the M-EVENT-REPORT specifying the success or failure of the creates.

g.NPAC SMS confirms the M-EVENT-REPORT.

h.NPAC SMS waits for all responses.

6.4.1.8.SubscriptionVersion Create: No Create Action from a SOA After Concurrence Window

This scenario shows no response within “Service Provider Concurrence Window” by one of the service provider SOAs.

In this case, the new service provider SOA issued the create request. The NPAC SMS has issued the ObjectCreation M-EVENT-REPORT back to both the old and new service provider SOAs. No response has yet been received by the old service provider SOA.

[Graphic Omitted: Process diagram for no create action from SOA]

a.NPAC SMS does not receive a response from the old service provider SOA within “Service Provider Concurrence Window”  for the pending subscriptionVersionNPAC created by the new service provider SOA.

b.NPAC SMS sends the old service provider SOA an M-EVENT-REPORT subscriptionVersionNoConcurrence.

c.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

d.Old service provider has up to “Service Provider Concurrence Failure Window” to respond to the request.

If the old service provider SOA responds with a valid M-ACTION or M-SET, processing resumes as a successful create.

6.4.1.9.Subscription Version Create: Failure to Receive Response from Old SOA

No response within “Service Provider Concurrence Failure Window” by one of the service provider SOA.

If the old service provider SOA does not respond, the status will become “conflict.” If the new service provider SOA does not respond, the status will become “cancel-pending.”

In this scenario, the old service provider SOA has not demonstrated concurrence to the new subscriptionVersion object create request.

[Graphic Omitted: Process diagram for failure to receive response]

a.NPAC SMS receives no response from the old service provider SOA in “Service Provider Concurrence Failure Window” after the concurrence notification was sent.

b.NPAC SMS issues an M-SET to update the subscriptionVersionStatus to “conflict” and set the subscriptionConflictTimeStamp and

68

subscriptionModifiedTimeStamp on the subscriptionVersionNPAC.

c.NPAC SMS issues an M-SET response.

d.If the subscriptionVersionNPAC was modified, the NPAC SMS issues an M-EVENT-REPORT for the subscriptionVersionStatus to the old service provider SOA of the status change.

e.The old service provider SOA returns an M-EVENT-REPORT confirmation to NPAC SMS.

f.If the subscriptionVersionNPAC was modified, the NPAC SMS issues an M-EVENT-REPORT for the subscriptionVersionStatus to the new service provider SOA of the status change.

g.The new service provider SOA returns an M-EVENT-REPORT confirmation to NPAC SMS.

6.4.1.10.Subscription Version Create: Failure to Receive Response from New SOA

This scenario shows action taken by the NPAC SMS after not receiving any concurrence from the new service provider after the “Service Provider Concurrence Failure Window.”

[Graphic Omitted: Process diagram for failure to receive response]

a.NPAC SMS receives no occurrence from the new service provider SOA in “Service Provider Concurrence Failure Window”  for the pending subscriptionVersionNPAC created by the old service provider SOA.

b.NPAC SMS issues M-SET for subscriptionVersionStatus to set it to “cancel-pending” and the subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.

c.NPAC SMS responds to M-SET.

d.If the subscriptionVersionNPAC object was modified, the NPAC SMS notifies the old service provider of the status change.

e.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

f.If the subscriptionVersionNPAC object was modified, the NPAC SMS notifies new service provider SOA of the status change.

g.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

69

6.4.1.11.SubscriptionVersionCreate M-CREATE Failure to Local SMS

This scenario shows a failure to all of the Local SMS on M-CREATE.

[Graphic Omitted: Process diagram for M-Create failure]

a.The new service provider SOA has activated the pending subscription.

b.The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs.

c.NPAC SMS waits for responses from each Local SMS.

d.NPAC SMS resends to each Local SMS up to a tunable number of retries at a tunable interval.

e.No responses occur from any Local SMS or all Local SMSs report a failure response to the M-CREATE.

f.NPAC SMS issues M-SET to update the subscriptionVersionStatus to “failed” in the subscriptionVersionNPAC object, the subscriptionFailed-SP-List, and the subscriptionModifiedTimeStamp.

g.NPAC SMS issues M-SET response.

h.If the subscriptionVersionNPAC was modified, the NPAC SMS will send M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change.

i.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

j.If the subscriptionVersionNPAC was modified, the NPAC SMS will send M-EVENT-REPORT to the new service provider SOA of the subscriptionVersionStatus change.

k.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

6.4.2.SubscriptionVersion M-CREATE: Partial Failure to Local SMS

This scenario shows a partial failure to a Local SMS on an M-CREATE.

[Graphic Omitted: Process diagram for M-create partial failure]

a.The new service provider SOA has activated the pending subscription.

b.The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs.

c.One or more Local SMSs respond to the M-CREATE.

d.NPAC SMS waits for responses from each Local SMS.

e.NPAC SMS resends, to each unresponsive Local SMS, up to a tunable number of retries at a tunable interval.

f.No responses occur from at least one Local SMS, or a Local SMS returns an M-CREATE failure.

70

g.NPAC SMS issues M-SET to the subscriptionVersionStatus to “partial-failure” in the subscriptionVersionNPAC object, subscriptionFailed-SP-List, and the subscriptionModifiedTimeStamp.

h.NPAC SMS issues M-SET response.

i.If the subscriptionVersionNPAC was modified, the NPAC SMS will send M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs.

j.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

k.If the subscriptionVersionNPAC was modified, the NPAC SMS will send M-EVENT-REPORT to the new service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs.

l.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

6.4.3.Modify Scenarios

6.4.3.1.SubscriptionVersion Modify Active Version Using M-ACTION by a Service Provider SOA

This scenario shows the modification of an active subscription. The modification of an active subscription version can only be performed by the current service provider SOA using M-ACTION.

[Graphic Omitted: Process diagram for subscription version modify activeversion]

a.Action is taken by current service provider to modify an active subscription version. The current service provider can only modify the following attributes:

subscriptionLRN

subscriptionCLASS-DPC

subscriptionCLASS-SSN

subscriptionLIDB-DPC

subscriptionLIDB-SSN

subscriptionCNAM-DPC

subscriptionCNAM-SSN

subscriptionISVM-DPC

subscriptionISVM-SSN

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

b.Current service provider SOA issues M-ACTION ModifySubscriptionVersion to the NPAC SMS lnpSubscriptions object to update the active version. The NPAC SMS validates the data.

c.If the M-ACTION data validates, NPAC SMS issues M-SET to the subscriptionVersionNPAC. The subscriptionVersionStatus is updated to “sending,” the subscriptionBroadcastTimeStamp and

71

subscriptionModifiedTimeStamp are set, and any other modified attributes are updated.

d.NPAC SMS issues M-SET response indicating success or failure.

e.NPAC SMS replies to the M-ACTION with success or failure and reasons for failure to the service provider SOA. If the action fails, no modifications are applied and processing stops. Failure reasons include accessDenied (not the current service provider) and invalidArgumentValue (validation problems).

f.NPAC SMS issues M-EVENT- REPORT subscriptionVersionStatusAttributeValueChange for the status change to “sending.”

g.Current service provider SOA responds with M-EVENT-REPORT confirmation.

h.NPAC SMS issues M-EVENT-REPORT for the rest of the modified attributes.

i.Current service provider SOA responds with M-EVENT-REPORT confirmation.

j.NPAC SMS issues M-SET to all Local SMSs for the updated attributes.

k.Local SMSs reply to M-SET.

l.All Local SMSs have reported the object modification.

Failure scenarios for this modification follow the same rules for an objectCreation failure to the Local SMS. The subscriptionVersionStatus will be set to “failed” or “partially-failed” as appropriate.

m.NPAC SMS issues M-SET to update the current subscriptionVersionNPAC object subscriptionVersionStatus to “active.”

n.NPAC SMS responds to M-SET.

o.NPAC SMS sends M-EVENT-REPORT to the current provider of the subscriptionVersionStatus update.

p.Service provider SOA issues M-EVENT-REPORT confirmation.

6.4.4.       SubscriptionVersion Modify Prior to Activate Using M-ACTION

This scenario can only be performed when the subscriptionVersionStatus is conflict, disconnect-pending, pending, cancel-pending, or conflict-resolution-pending.

[Graphic Omitted: Process diagram for SubscriptionVersion Modify Prior to Activate Using M-ACTION]

a.Action is taken by a service provider to modify the subscriptionVersion. The old service provider can only update the following attributes:

subscriptionOldSP-DueDate

subscriptionOldSP-Authorization

72

The new service provider can only update the attributes:

subscriptionLRN

subscriptionNewSP-DueDate

subscriptionCLASS-DPC

subscriptionCLASS-SSN

subscriptionLIDB-DPC

subscriptionLIDB-SSN

subscriptionCNAM-DPC

subscriptionCNAM-SSN

subscriptionISVM-DPC

subscriptionISVM-SSN

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

b.Service provider SOA issues M-ACTION subscriptionVersionModify to the NPAC SMS lnpSubscriptions object to update the version. The NPAC SMS validates the data.

c.If validation is successful, NPAC SMS will M-SET the attributes modified in the subscriptionVersionNPAC object and set the subscriptionModifiedTimeStamp.

d.The NPAC SMS will issue an M-SET response.

e.NPAC SMS replies to the M-ACTION with success or failure and reasons for failure.

f.NPAC SMS subscriptionVersionStatus reports subscriptionVersionStatusAttributeValueChange to the old service provider SOA, if appropriate.

g.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

h.NPAC SMS reports subscriptionVersionStatus AttributeValueChange to the new service provider SOA, if appropriate.

i.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

j.NPAC SMS issues M-EVENT-REPORT attributeValueChange to the old service provider SOA.

k.The old service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.

l.NPAC SMS issues M-EVENT-REPORT attributeValueChange to the new service provider SOA.

m.The new service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.

73

6.4.4.1.SubscriptionVersion Modify Prior to Activate Using M-SET

This scenario shows a modify using an M-SET. The M-SET can only be performed when the subscriptionVersionStatus is conflict, pending, cancel-pending, or conflict-resolution-pending.

[Graphic Omitted: Process diagram for subscription version modify prior to activate]

a.Action is taken by a service provider to modify the subscriptionVersion. The old service provider can only update the following attributes:

subscriptionOldSP-DueDate

subscriptionOldSP-Authorization

The new service provider can only update the attributes:

subscriptionLRN

subscriptionNewSP-DueDate

subscriptionCLASS-DPC

subscriptionCLASS-SSN

ubscriptionLIDB-DPC

subscriptionLIDB-SSN

subscriptionCNAM-DPC

subscriptionCNAM-SSN

subscriptionISVM-DPC

subscriptionISVM-SSN

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

b.The new or old service provider SOA will issue an M-SET request for the attributes to be updated in the subscriptionVersionNPAC object. The request will be validated for an authorized service provider and validation of the attributes and values.

c.The NPAC SMS will issue an M-SET response indicating success or failure and reasons for failure.

d.NPAC SMS reports subscriptionVersionStatus AttributeValueChange and/or an attributeValue change to the old and new service provider SOAs if applicable.

e.SOA issues M-EVENT-REPORT confirmation.

6.4.5.Cancel Scenarios

6.4.5.1.SubscriptionVersion Cancel by Service Provider SOA

A subscription version can be canceled when the current status is conflict, conflict-resolution-pending, disconnect-pending, or pending. This can be done by either the old or new service provider.

In this scenario, the old service provider initiates the cancel. Once the second cancellation acknowledgment is received, the version status is set to “canceled.”

[Graphic Omitted: Process diagram for subscription version cancel]

a.Action is initiated by the new or old service provider SOA to cancel a subscription version.

74

b.Service provider SOA issues an M-ACTION subscriptionVersionCancel to the NPAC SMS to the lnpSubscriptions object.

c.NPAC SMS issues M-SET to update subscriptionVersionStatus to “cancel-pending” in the subscriptionVersionNPAC object and the subscriptionModifiedTimeStamp.

d.NPAC SMS issues M-SET response.

e.NPAC SMS returns the M-ACTION reply. This either reflects a success or failure. Failure reasons are version in wrong state, no version to cancel, and authorization service provider.  If successful, the subscriptionPre-CancellationStatus is set to the current subscriptionVersionStatus and then the subscriptionVersionStatus is set to “cancel-pending.” If the action fails, no modifications are applied and processing stops.

f.An M-EVENT-REPORT for the subscriptionVersionStatus change is sent from the NPAC SMS to the old service provider SOA.

g.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

h.An M-EVENT-REPORT for the subscriptionVersionStatus change is sent from the NPAC SMS to the new service provider SOA.

i.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

j.The old service provider SOA sends an M-ACTION subscriptionVersionOldSP-CancellationAcknowledge to the NPAC SMS lnpSubscription object. This acknowledges the cancellation of the subscriptionVersionNPAC with a status of cancel-pending.

k.The NPAC SMS issues M-SET for the subscriptionOldSP-CancellationTimeStamp in the subscriptionVersionNPAC object and subscriptionModifiedTimeStamp.

l.NPAC SMS issues an M-SET response.

m.NPAC SMS responds to the M-ACTION with either a success or failure and failure reasons. If the action fails, no modifications are applied.

n.The new service provider SOA sends an M-ACTION subscriptionVersionNewSP-CancellationAcknowledge to the NPAC SMS lnpSubscriptions object.

o.The NPAC SMS issues M-SET for the subscriptionNewSP-CancellationTimeStamp, subscriptionModifiedTimeStamp, subscriptionCancellationTimeStamp, and subscriptionVersionStatus to “canceled.”

p.NPAC SMS issues M-SET response.

q.NPAC SMS replies to M-ACTION with success or failure and reasons for failure. If the action fails, no modifications are applied.

r.If the last M-ACTION was successful, the NPAC SMS sends the M-EVENT-REPORT for the subscriptionVersionStatus update to canceled to the old service provider SOA.

75

s.If the last M-ACTION was successful, the old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

t.NPAC SMS sends the M-EVENT-REPORT for the subscriptionVersionStatus update to canceled to the new service provider SOA.

u.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

6.4.5.2.SubscriptionVersionCancel: No Acknowledgment from a SOA

The NPAC SMS has set the status of the subscription version to “cancel-pending.” It is now waiting for the acknowledgments from both service provider SOAs. However one, in this scenario the new service provider, does not respond.

[Graphic Omitted: Process diagram for subscription version cancel]

a.NPAC SMS is waiting for the cancellation acknowledgments from both service provider SOAs.

b.The old service provider SOA sends a subscriptionVersionOldSP-CancellationAcknowledge M-ACTION to the NPAC SMS lnpSubscriptions object. This acknowledges the cancellation of the subscriptionVersionNPAC with a status of cancel-pending.

c.NPAC SMS issues M-SET for the subscriptionOldSP-CancellationTimeStamp and subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.

d.NPAC SMS responds to M-SET.

e.NPAC SMS replies to the M-ACTION with either a success or failure and failure reasons. If the action fails, no modifications are applied and processing stops.

f.The NPAC SMS waits for the cancellation acknowledgment from the new service provider SOA. No reply is received after a tunable period.

g.NPAC SMS issues M-EVENT-REPORT subscriptionVersionCancellationAcknowledgeRequest to the unresponsive new service provider SOA.

h.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

i.The “Service Provider Concurrence Cancellation Window” has expired and still no cancellation acknowledgment is received from the new service provider.

j.NPAC SMS issues M-SET to update the subscriptionVersionStatus to conflict and the subscriptionConflictTimeStamp and subscriptionModifiedTimeStamp are set.

k.NPAC SMS issues M-SET response.

l.The NPAC SMS M-EVENT-REPORT sends subscriptionVersionStatusAttributeValueChange to the old service provider SOA.

76

m.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

n.The NPAC SMS sends subscriptionVersionStatusAttributeValueChange to the new service provider SOA.

o.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

At this point, the flow follows the conflict resolution scenarios.

6.4.6.Disconnect Scenarios

6.4.6.1.SubscriptionVersion Immediate Disconnect

The current service provider can disconnect an active subscription version.  In this scenario, the disconnect is immediate.

[Graphic Omitted: Process diagram for subscription version immediate disconnect]

a.Current service provider SOA personnel take action to disconnect a subscription version.

b.Service provider SOA issues an M-ACTION to disconnect to the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId or subscriptionTN. The subscription version status must be active and no pending, failed, conflict, conflict-pending, cancel or cancel-pending versions can exist. The M-ACTION must also specify the subscriptionCustomerDisconnectDate.

c.NPAC SMS issues an M-SET to set the subscriptionCustomerDisconnectDate according to the disconnect action. The subscriptionVersionStatus goes to “disconnect-pending.”

d.NPAC SMS responds to M-SET.

e.NPAC SMS responds to the M-ACTION. If the action failed, an error will be returned and processing will stop on this flow.

f.NPAC SMS notifies service provider SOA of subscriptionVersionStatus being set to disconnect-pending.

g.Service provider SOA confirms M-EVENT-REPORT.

h.NPAC SMS sends the donor service provider SOA notification that the subscription version is being disconnected with the customer disconnect date.

i.The donor service provider SOA confirms the M-EVENT-REPORT.

j.NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” and set the subscriptionModifiedTimeStamp and the subscriptionBroadcastTimeStamp.

k.NPAC SMS responds to whether M-SET was successful.

l.NPAC SMS notifies service provider SOA of status change to “sending.”

m.Service provider SOA confirms event report.

77

n.NPAC SMS sends out an M-DELETE on the subscriptionVersion to all Local SMSs.

o.Each Local SMS responds with a successful M-DELETE reply.

p.All Local SMSs respond successfully.

q.NPAC SMS issues M-SET updating the subscriptionVersionStatus to old for subscriptionVersionNPAC objects. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.

r.NPAC SMS responds to M-SET.

s.NPAC SMS issues an M-EVENT-REPORT for the subscriptionVersionStatus equal to “old.” If a failure had occurred with the M-DELETE to one or more Local SMSs, this would be returned in an M-EVENT-REPORT for the subscriptionVersionStatus equal to “failure” or partial-failure.” If a “partial-failure” has occurred, a list of failed Local SMSs will be included.

t.Service provider SOA responds to M-EVENT-REPORT.

u.After a tunable amount of days, the subscription version is purged by the NPAC SMS housekeeping process.

6.4.6.2.SubscriptionVersion Disconnect With Effective Release Date

In this scenario, a future dated request is submitted to disconnect an active subscriptionVersion.

[Graphic Omitted: Process diagram for subscription version disconnect]

a.Service provider SOA personnel take action to disconnect a subscription version.

b.Service provider SOA issues an M-ACTION request to disconnect to the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId or subscriptionVersionLNPType and subscriptionTN, and also has future dated the subscriptionEffectiveReleaseDate and the subscriptionCustomerDisconnectDate. The subscription version status must be active and no pending, failed, conflict, conflict-pending, cancel or cancel-pending versions can exist.

c.NPAC SMS M-SETs the status to disconnect-pending, and sets the subscriptionEffectiveReleaseDate of the existing subscriptionVersionNPAC and also the subscriptionModifiedTimeStamp.

d.NPAC SMS responds to M-SET.

e.NPAC SMS responds to M-ACTION. If the action fails, no modifications are applied and the processing stops.

f.The NPAC SMS waits for the subscriptionEffectiveReleaseDate date to arrive.

At this point, the flow follows an immediate disconnect scenario. First the donor service provider’s Local SMS is notified of the impending disconnect. The NPAC SMS sets the subscriptionVersionStatus to sending the broadcast timestamp, notifies the service provider SOA of the status change, and

78

proceeds to issue M-DELETEs for the subscriptionVersion to the Local SMS.

6.4.7.Conflict Scenarios

A situation has arisen which causes the NPAC SMS or NPAC personnel to place the subscriptionVersion into conflict.

A subscription version can be removed from conflict by the NPAC personnel or the new service provider SOA.

6.4.7.1.SubscriptionVersion Conflict and Conflict Resolution Pending by the NPAC SMS

This scenario shows a version being placed into conflict and removed from conflict by the NPAC personnel.

[Graphic Omitted: Process diagram for subscription version conflict]

a.NPAC personnel or NPAC SMS take action to set the status of a subscription to “conflict.”

b.NPAC SMS issues M-SET request to update subscriptionVersionStatus to “conflict,” subscriptionConflictTimeStamp, and subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.

c.NPAC SMS issues an M-SET response. If the M-SET fails, processing for this scenario stops.

d.NPAC SMS issues an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange to old service provider SOA.

e.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

f.NPAC SMS issues subscriptionVersionStatusAttributeValueChange for status to new service provider SOA.

g.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

h.Once the conflict is resolved, NPAC personnel take action to remove the subscriptionVersion from conflict.

i.NPAC SMS issues an M-SET request to update the subscriptionModifiedTimeStamp and the subscriptionVersionStatus to “conflict-resolution-pending.”

j.NPAC SMS issues an M-SET response. If the M-SET fails, processing for this scenario stops.

k.NPAC SMS issues subscriptionVersionStatusAttributeValueChange for the new status to the old service provider SOA.

l.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

79

m.NPAC SMS issues subscriptionVersionStatusAttributeValueChange for the new status to the new service provider SOA.

n.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

o.Old service provider SOA issues an M-ACTION acknowledging the “conflict-resolution-pending” status to the lnpSubscriptions object.

p.NPAC SMS issues M-SET request for subscriptionOldSPConflictResolutionTimeStamp and the subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.

q.NPAC SMS issues M-SET response.

r.NPAC SMS responds with an M-ACTION reply. If the M-ACTION fails, no modifications are applied and the SOA must correct the problem and retry the action.

s.New service provider SOA issues an M-ACTION acknowledging the “conflict-resolution-pending” status to the lnpSubscriptions object.

t.NPAC SMS issues M-SET for the subscriptionNewSP-ConflictResolutionTimeStamp and the subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.

u.NPAC SMS responds to M-SET.

v.NPAC SMS replies with an M-ACTION response. If the M-ACTION fails, no modifications are applied and the SOA must correct the problem and retry.

w.NPAC SMS has received both acknowledgments.

x.NPAC SMS issues M-SET to update the subscriptionVersionStatus to “pending” in the subscriptionVersionNPAC object and sets the subscriptionModifiedTimeStamp.

y.NPAC SMS issues M-SET response. If the M-SET fails, processing stops for this scenario.

z.NPAC SMS sends a subscriptionVersionStatusAttributeValueChange to the old service provider SOA for the status update.

aa.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

bb.NPAC SMS sends a subscriptionVersionStatusAttributeValueChange to the new service provider SOA for the status update.

cc.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

6.4.7.2.Subscription Version Conflict Resolution Pending by the New Service Provider SOA

In this scenario, the new service provider elects to remove the subscription version from conflict.

80

[Graphic Omitted: Process diagram for subscription version conflict resolution pending]

a.A subscription version exists on the NPAC SMS with a status of conflict.

b.The new service provider SOA personnel take action to remove the subscription version from conflict.

c.The new service provider SOA sends the M-ACTION subscriptionVersionNewSP-conflictResolutionPending specifying the TN and Version ID of the subscription version in conflict.

d.If the request is valid, the NPAC SMS will set the status to “conflict-resolution-pending”.
The request will be denied and an error returned if the subscriptionOldSP-Authorization is not set to true.

e.The NPAC SMS responds to its own M-SET.

f.The NPAC SMS responds to the M-ACTION with success or failure and reason for failure.
The processing now continues with the subscriptionVersionStatusAttributeValueChange notices going out to the new and old service provider SOAs. Next, both service provider SOAs need to acknowledge the conflict-resolution-pending state and allow the subscription version to return to a pending state.

6.4.8.SubscriptionVersion Conflict: No Acknowledgment from SOA

This scenario shows a version being placed into conflict and resolved with one of the SOAs, the new service provider, not acknowledging conflict resolution.

[Graphic Omitted: Process diagram for subscription version conflict]

a.NPAC personnel or NPAC SMS sets the subscriptionVersionStatus to “conflict.”

b.NPAC SMS issues M-SET request to update subscriptionVersionStatus and the subscriptionConflictTimeStamp, and the subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.

c.NPAC SMS issues M-SET response. If the M-SET fails, processing stops for this scenario.

d.NPAC SMS issues M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange to old service provider SOA.

e.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

f.NPAC SMS issues subscriptionVersionStatusAttributeValueChange for status to new service provider SOA.

g.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

h.NPAC personnel resolve conflict. Status changes to “conflict-resolution-pending.”

81

i.NPAC SMS issues M-SET request to update subscriptionVersionStatus to “conflict-resolution-pending” in the subscriptionVersionNPAC object.

j.NPAC SMS issues M-SET response. If the M-SET fails, processing for this scenario stops.

k.NPAC SMS issues subscriptionVersionStatusAttributeValueChange for the new status to the old service provider SOA.

l.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

m.NPAC SMS issues subscriptionVersionStatusAttributeValueChange for the new status to the new service provider SOA.

n.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

o.Old service provider SOA issues an M-ACTION acknowledging the “conflict-resolution-pending” status to the lnpSubscriptions object. NPAC SMS updates subscriptionOldSP-ConflictResolutionTimeStamp.

p.NPAC SMS issues M-SET request to update subscriptionOldSP-ConflictResolutionTimeStamp and the subscriptionModifiedTimeStamp.

q.NPAC SMS issues M-SET response.

r.NPAC SMS responds with an M-ACTION reply. If the action fails, the old service provider should correct request and retry.

s.NPAC SMS does not get an acknowledgment from one service provider SOA.

t.NPAC SMS sends M-EVENT-REPORT subscriptionConflictResolutionAcknowledgeRequest to the unresponsive, new service provider SOA.

u.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

v.NPAC SMS still does not receive an acknowledgment from other service provider SOA.

w.NPAC SMS issues M-SET request to update subscriptionVersionStatus setting it to “conflict,” sets the subscriptionConflictTimeStamp and the subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.

x.NPAC SMS issues M-SET response.

y.If the subscriptionVersionNPAC object was modified, the NPAC SMS issues subscriptionVersionStatusAttributeValueChange for status to old service provider SOA.

z.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

aa.If the subscriptionVersionNPAC object was modified, the NPAC SMS issues subscriptionVersionStatusAttributeValueChange for status to new service provider SOA.

82

bb.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

6.4.9.SubscriptionVersion Conflict: No Conflict Resolution

This scenario shows the action taken at the NPAC SMS when service providers do not reach a conflict resolution.

[Graphic Omitted: Process diagram for no conflict resolution]

a.NPAC personnel or NPAC SMS take action to set a subscriptionVersionStatus to “conflict.”

b.NPAC SMS issues an M-SET request to set the subscriptionVersionStatus to “conflict,” the subscriptionConflictTimeStamp, and the subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.

c.NPAC SMS responds to M-SET. If the M-SET fails, processing stops for this scenario until the M-SET completes successfully.

d.NPAC SMS issues subscriptionVersionStatusAttributeValueChange to old service provider SOA for the new “conflict” status.

e.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

f.NPAC SMS issues subscriptionVersionStatusAttributeValueChange to new service provider SOA for the “conflict” status.

g.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

h.“Version Conflict Cancellation Window” expires without conflict resolution.

i.NPAC SMS issues an M-SET request to set the subscriptionVersionStatus to “cancel” in the subscriptionVersionNPAC object and sets the subscriptionCancellationTimeStamp and subscriptionModifiedTimeStamp.

j.NPAC SMS responds to M-SET. If the M-SET fails, processing stops for this scenario until the M-SET is successfully completed.

k.NPAC SMS issues attribute value change for status to old service provider SOA for the “cancel” status.

l.The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

m.NPAC SMS issues attribute value change for status to new service provider SOA for the “cancel” status.

n.The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

6.4.10.SubscriptionVersion Create for Intra-Service Provider Port

This scenario shows how an intra-service port is processed.

[Graphic Omitted: Process diagram for create for intra-service provider port]

83

a.Action is taken by the current provider SOA to create a new version of a subscriber.

b.Current provider SOA sends M-ACTION subscriptionVersionNewSP-Create to the NPAC SMS lnpSubscriptions object to create a new subscriptionVersionNPAC. The SOA must specify the following valid attributes:

subscriptionTN or a valid subscriptionVersionTN-Range

subscriptionNewCurrentSP

subscriptionOldSP

subscriptionNewSP-DueDate

subscriptionPortingToOriginal-SPSwitch

subscriptionLRN

subscriptionCLASS-DPC

subscriptionCLASS-SSN

subscriptionLIDB-DPC

subscriptionLIDB-SSN

subscriptionCNAM-DPC

subscriptionCNAM-SSN

subscriptionISVM-DPC

subscriptionISVM-SSN

subscriptionLNPType

The subscriptionNewCurrentServiceProv must be equal to the subscriptionOldServiceProv.

The following attributes are optional:

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

c.If the request is valid, the NPAC SMS will M-CREATE the subscriptionVersionNPAC object. The status will be set to “pending.” Also the subscriptionCreationTimeStamp, the subscriptionNewSP-AuthorizationTimeStamp, subscriptionOldSP-AuthorizationTimeStamp, and the subscriptionModifiedTimeStamp will be set.

d.NPAC SMS responds to M-CREATE.

e.NPAC SMS sends an action reply with success or failure and reasons for failure. If the action fails, no modifications are applied and processing stops for this scenario.

f.NPAC SMS notifies intra-service provider SOA of subscriptionVersionNPAC creation.

g.Service provider SOA sends M-EVENT-REPORT confirmation to NPAC SMS.

The intra-service subscriptionVersion now follows the same flow as an inter-service subscriptionVersionCreation to activate the subscriptionVersion on the NPAC SMS and create the subscriptionVersion on the Local SMSs.

84

The only difference is the M-EVENT-REPORT for the subscriptionVersionStatusAttributeValueChange is only sent to the new provider.

6.4.11.SubscriptionVersion Query

This scenario shows subscriptionVersion query from service provider systems to the NPAC SMS.

[Graphic Omitted: Process diagram for query]

a.Action is taken by either a service provider SOA or Local SMS for retrieving one or more versions of a subscription.

b.The service provider SOA or Local SMS issues a scoped filtered M-GET from the lnpSubscriptions object to retrieve a specific version for a TN or can request all subscription versions. However the service provider SOA is limited by a scope and filter in their search capabilities. The filter will currently support all the attributes on the subscriptionVersionNPAC.

c.The NPAC SMS replies with the requested subscriptionVersion data if the requested number of records is less than or equal to “Max Subscriber Query” specified in the NPAC SMS. Otherwise a resource Limitation Error will be returned.

The query return data includes:

subscriptionTN

subscriptionLRN

subscriptionNewCurrentSP

subscriptionOldSP

subscriptionNewSP-DueDate

subscriptionNewSP-CreationTimeStamp

subscriptionOldSP-DueDate

subscriptionOldSP-Authorization

subscriptionOldSP-AuthorizationTimeStamp

subscriptionActivationTimeStamp

subscriptionBroadcastTimeStamp

subscriptionConflictTimeStamp

subscriptionCustomerDisconnectDate

subscriptionDisconnectCompleteTimeStamp

subscriptionEffectiveReleaseDate

subscriptionVersionStatus

subscriptionCLASS-DPC

subscriptionCLASS-SSN

subscriptionLIDB-DPC

subscriptionLIDB-SSN

subscriptionCNAM-DPC

subscriptionCNAM-SSN

subscriptionISVM-DPC

subscriptionISVM-SSN

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

subscriptionLNPType

subscriptionPreCancellationStatus

subscriptionCancellationTimeStamp

85

subscriptionOldTimeStamp

subscriptionModifiedTimeStamp

subscriptionCreationTimeStamp

subscriptionOldSP-CancellationTimeStamp

subscriptionNewSP-CancellationTimeStamp

subscriptionOldSP-ConflictResolutionTimeStamp

subscriptionNewSP-ConflictResolutionTimeStamp

subscriptionPortingToOriginal-SPSwitch

subscriptionFailedSP-List

subscriptionDownloadReason

6.4.12.Subscription Data Download

This scenario shows a Local SMS request for subscription data download in order to update their view of this data.

[Graphic Omitted: Process diagram for data download]

a.Action is taken by the Local SMS personnel to request a subscription data download. The criteria to decide which subscription data is to be downloaded is specified by the Local SMS personnel.

b.The Local SMS sends an M-ACTION request to the NPAC SMS lnpSubscription object requesting a subscription data download.

c.The NPAC SMS looks up the subscription data in the subscription database as specified by the criteria in the M-ACTION request.

d.The NPAC SMS responds by sending an M-ACTION response to the Local SMS that initiated the request. The response includes the success/failure of the request along with the requested subscription data.

e.The Local SMS must take appropriate action to update their view of the data.

86

6.5.Miscellaneous

6.5.1.Sequencing of Events on Initialization/Resynchronization of Local SMS

If the resynchronization flag is TRUE upon association establishment, the NPAC SMS will hold updates to the Local SMS until the flag is turned off. At that time all updates issued since the association establishment will be sent.

If any of the requests in this scenario fail, the Local SMS must correct the problem - retry the action instead of continuing.

[Graphic Omitted: Process diagram for local SMS re-sync and re-init]

a.Local SMS establishes association with resynchronization flag on.

b.Local SMS sends M-ACTION to start network data download. The Local SMS specifies the start time.

c.NPAC SMS responds to M-ACTION with updates.

d.Local SMS sends M-ACTION to start subscription data download. The Local SMS specifies the start time.

e.NPAC SMS responds to M-ACTION with subscription version updates.

f.Local SMS sends M-ACTION to set resynchronization flag off.

g.NPAC SMS replies with data updates since association establishment.

h.Normal processing resumes.

6.6.SOA/Local SMS Notification of Scheduled NPAC Downtime

This scenario shows SOA/Local SMS notification of scheduled NPAC downtime.

[Graphic Omitted: Process diagram for notification of downtime]

a.Action is taken by NPAC SMS personnel to schedule downtime for the NPAC SMS system.

b.The NPAC SMS system recognizes that it is some tunable amount of time before a scheduled outage.

c.The NPAC SMS sends an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT to the Local SMSs.

d.The Local SMSs respond by sending an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT confirmation back to the NPAC SMS.

e.The NPAC SMS sends an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT to all SOAs.

f.The SOA(s) respond by sending an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT confirmation back to the NPAC SMS.

87

6.6.1.NPA-NXX Split

This scenario shows NPAC SMS personnel initiation of an NPA-NXX split.

[Graphic Omitted: Process diagram for NPA-NXX Split]

a.Action is taken by the NPAC SMS personnel to cause an NPA-NXX split.

b.The NPAC SMS updates all subscription version records in its local database that match the specified TN range. The TN field will be updated with the new NPA, and the other_TN field will be set to the previous TN (old NPA).

c.The permissive dialing period expires.

d.The NPAC SMS updates all subscription version records in its local database that match the specified TN range. The other_TN field will be set to Null.

6.7.Mass Update

NPAC SMS personnel can perform a mass update on subscription data.

[Graphic Omitted: Process diagram for mass update]

a.Action is taken by the NPAC SMS personnel to request that a mass update be performed on active subscription data.

b.Search the subscription database for subscription versions that match the specified mass update criteria. Perform steps c-f for the allowable range of subscription versions.

c.If LRN data was modified, check the LRN table to verify that it is defined for the serviceProv NPA-NXX found in the subscriptions. If not, terminate processing at this point.

d.The NPAC SMS sends an M-SET on the subscription versions to the Local SMS.

e.The Local SMS replies to the M-SET.

f.The NPAC SMS sends an attributeValueChange M-EVENT-REPORT to the current service provider SOA.

g.The service provider SOA sends a confirmation to the M-EVENT-REPORT.

88

GDMO Definitions

7.GDMO Definitions

7.1.Overview

The GDMO interface definitions provided below support the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.  Included in this chapterof the interface specification are object name bindings, attribute, package, action, and notification definitions.

7.2.Object Definitions

— 1.0 LNP Audits Managed Object

lnpAudits MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        lnpAuditsPkg;

    REGISTERED AS {lnp-objectClass 1};

lnpAuditsPkg PACKAGE

    BEHAVIOR

        lnpAuditsDefinition,

        lnpAuditsBehavior;

    ATTRIBUTES

        lnpAuditsName GET;

    ;

lnpAuditsDefinition BEHAVIOR

    DEFINED AS !

        The lnpAudits class is the managed object that is used as the container object for the subscriptionAudit objects on the NPAC SMS.  This object has been created for scoping efficiency.

    !;

lnpAuditsBehavior BEHAVIOR

    DEFINED AS !

        Local SMS and NPAC SMS Managed Object for the SOA to NPAC SMS and the Local SMS to NPAC SMS interface.

        The NPAC SMS can M-GET any lnpAudits object on the LSMS (Process Audit Association Function).

        The service provider SOA can M-GET any lnpAudits object on the NPAC SMS. (SOA Management Association Function).

        The Local SMS can not M-GET any lnpAudits object on the NPAC SMS.

        The lnpAuditsName attribute is read only and can not be changed via the Local SMS or SOA Interface once the object has been created.  The value of lnpAuditsName will always be “lnpAudits”.

        Only one of these objects will exist per agent and it will only be created at startup of the CMIP agent software

89

        on the Local SMS and the NPAC SMS.

    !;

— 2.0 LNP Local SMS Managed Object Class

lnpLocalSMS MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        lnpLocalSMS-Pkg,

        lnpRecoveryCompletePkg;

    REGISTERED AS {lnp-objectClass 2};

lnpLocalSMS-Pkg PACKAGE

    BEHAVIOR

        lnpLocalSMS-Definition,

        lnpLocalSMS-Behavior;

    ATTRIBUTES

        lnpLocal-SMS-Name GET;

    ;

lnpLocalSMS-Definition BEHAVIOR

    DEFINED AS !

        The lnpLocalSMS class is the managed object that is used as the container object for all Local SMS data in the NPAC SMS to Local SMS Interface.

    !;

lnpLocalSMS-Behavior BEHAVIOR

    DEFINED AS !

        Local SMS Managed Object.

        The NPAC SMS can M-GET any lnpLocalSMS object (Data Download Association Function).

        The lnp-LocalSMS-Name attribute is read only and can not be changed via the Local SMS Interface once the object has been created.  The value of lnpLocal-SMS-Name will always be a unique identifier for the Local SMS for the NPAC SMS to Local SMS Interface.

        The lnpRecoveryComplete-Pkg is used to used for indicating the recovery mode for the Local SMS is complete and to return all updates made since the recovery mode began.  (Data Download Functional Group).

        Only one of these objects will exist and it will only be created at startup of the CMIP agent software on the Local SMS.

    !;

— 3.0 LNP Log Record for the Subscription Audit Local SMS Discrepancy Report

lnpLogAudit-DiscrepancyRptRecord MANAGED OBJECT CLASS

    DERIVED FROM “Rec. X.721 | ISO/IEC 10165-2 : 1992”:eventLogRecord;

    CHARACTERIZED BY

        lnpLogAudit-DiscrepancyRptPkg;

    REGISTERED AS {lnp-objectClass 3};

lnpLogAudit-DiscrepancyRptPkg PACKAGE

    BEHAVIOR

        lnpLogAudit-DiscrepancyRptDefinition,

        lnpLogAudit-DiscrepancyRptBehavior;

    ATTRIBUTES

        auditDiscrepancyTn GET,

        auditDiscrepancyVersionId GET,

        auditDiscrepancyLSMS-SP-Id GET,

90

        auditDiscrepancyFailureReason GET,

        accessControl GET;

    ;

lnpLogAudit-DiscrepancyRptDefinition BEHAVIOR

    DEFINED AS !

        The lnpLogAudit-DiscrepancyRptRecord class is the managed object that is used to create log records for the subscriptionAudit-DiscrepancyRpt Notification.

    !;

lnpLogAudit-DiscrepancyRptBehavior BEHAVIOR

    DEFINED AS !

        This log record can be used by any CME wanting to log the subscriptionAudit-DiscrepancyRpt Notification.

    !;

— 4.0 LNP Log Record for the Subscription Audit Results

lnpLogAuditResultsRecord MANAGED OBJECT CLASS

    DERIVED FROM “Rec. X.721 | ISO/IEC 10165-2 : 1992”:eventLogRecord;

    CHARACTERIZED BY

        lnpLogAuditResultsPkg;

    REGISTERED AS {lnp-objectClass 4};

lnpLogAuditResultsPkg PACKAGE

    BEHAVIOR

        lnpLogAuditResultsDefinition,

        lnpLogAuditResultsBehavior;

    ATTRIBUTES

        auditResultStatus GET,

        auditResponseLevel GET,

        auditResultFailed-SP-List GET,

        auditResultNumberDiscrepancies GET,

        auditResultCompletionTime GET,

        accessControl GET;

    ;

lnpLogAuditResultsDefinition BEHAVIOR

    DEFINED AS !

        The lnpLogAuditResultsRecord class is the managed object that is used to create log records for the subscriptionAuditResults Notification.

    !;

lnpLogAuditResultsBehavior BEHAVIOR

    DEFINED AS !

        This log record can be used by any CME wanting to log the subscriptionAuditResults Notification.

    !;

— 5.0 LNP Log Record for the Subscription Version Cancellation

— Acknowledge Request Notification

lnpLogCancellationAcknowledgeRequestRecord MANAGED OBJECT CLASS

    DERIVED FROM “Rec. X.721 | ISO/IEC 10165-2 : 1992”:eventLogRecord;

    CHARACTERIZED BY

        lnpLogCancellationAcknowledgeRequestPkg;

    REGISTERED AS {lnp-objectClass 5};

lnpLogCancellationAcknowledgeRequestPkg PACKAGE

    BEHAVIOR

        lnpLogCancellationAcknowledgeRequestDefinition,

        lnpLogCancellationAcknowledgeRequestBehavior;

    ATTRIBUTES

        subscriptionTN GET,

        subscriptionVersionId GET,

91

        accessControl GET;

    ;

lnpLogCancellationAcknowledgeRequestDefinition BEHAVIOR

    DEFINED AS !

        The lnpLogCancellationAcknowledgeRequestRecord class is the managed object that is used to create log records for the subscriptionVersionCancellationAcknowledgeRequest Notification.

    !;

lnpLogCancellationAcknowledgeRequestBehavior BEHAVIOR

    DEFINED AS !

        This log record can be used by any CME wanting to log the subscriptionVersionCancellationAcknowledgeRequest Notification.

    !;

— 6.0 LNP Log Record for the Subscription Version Conflict Resolution

— Acknowledge Request Notification

lnpLogConflictResolutionAcknowledgeRequestRecord MANAGED OBJECT CLASS

    DERIVED FROM “Rec. X.721 | ISO/IEC 10165-2 : 1992”:eventLogRecord;

    CHARACTERIZED BY

        lnpLogConflictResolutionAcknowledgeRequestPkg;

    REGISTERED AS {lnp-objectClass 6};

lnpLogConflictResolutionAcknowledgeRequestPkg PACKAGE

    BEHAVIOR

        lnpLogConflictResolutionAcknowledgeRequestDefinition,

        lnpLogConflictResolutionAcknowledgeRequestBehavior;

    ATTRIBUTES

        subscriptionTN GET,

        subscriptionVersionId GET,

        accessControl GET;

    ;

lnpLogConflictResolutionAcknowledgeRequestDefinition BEHAVIOR

    DEFINED AS !

        The lnpLogConflictResolutionAcknowledgeRequestRecord class is the managed object that is used to create log records for the subscriptionVersionConflictResolutionAcknowledgeRequest Notification.

    !;

lnpLogConflictResolutionAcknowledgeRequestBehavior BEHAVIOR

    DEFINED AS !

        This log record can be used by any CME wanting to log the subscriptionVersionConflictResolutionAcknowledgeRequest Notification.

    !;

— 7.0 LNP Log Record for the Subscription Version New SP Create Request

—     Notification

lnpLogNewSP-CreateRequestRecord MANAGED OBJECT CLASS

    DERIVED FROM “Rec. X.721 | ISO/IEC 10165-2 : 1992”:eventLogRecord;

    CHARACTERIZED BY

        lnpLogNewSP-CreateRequestPkg;

    REGISTERED AS {lnp-objectClass 7};

lnpLogNewSP-CreateRequestPkg PACKAGE

    BEHAVIOR

        lnpLogNewSP-CreateRequestDefinition,

        lnpLogNewSP-CreateRequestBehavior;

    ATTRIBUTES

        subscriptionTN GET,

92

        subscriptionVersionId GET,

        subscriptionOldSP GET,

        subscriptionOldSP-DueDate GET,

        subscriptionOldSP-Authorization GET,

        subscriptionOldSP-AuthorizationTimeStamp GET,

        accessControl GET;

    ;

lnpLogNewSP-CreateRequestDefinition BEHAVIOR

    DEFINED AS !

        The lnpLogNewSP-CreateRequestRecord class is the managed object that is used to create log records for the subscriptionVersionNewSP-CreateRequest Notification.

    !;

lnpLogNewSP-CreateRequestBehavior BEHAVIOR

    DEFINED AS !

        This log record can be used by any CME wanting to log the subscriptionVersionNewSP-CreateRequest Notification.

    !;

— 8.0 LNP Log Record for the Subscription Version Old SP Concurrence Request

—     Notification

lnpLogOldSP-ConcurrenceRequestRecord MANAGED OBJECT CLASS

    DERIVED FROM “Rec. X.721 | ISO/IEC 10165-2 : 1992”:eventLogRecord;

    CHARACTERIZED BY

        lnpLogOldSP-ConcurrenceRequestPkg;

    REGISTERED AS {lnp-objectClass 8};

lnpLogOldSP-ConcurrenceRequestPkg PACKAGE

    BEHAVIOR

        lnpLogOldSP-ConcurrenceRequestDefinition,

        lnpLogOldSP-ConcurrenceRequestBehavior;

    ATTRIBUTES

        subscriptionTN GET,

        subscriptionVersionId GET,

        subscriptionNewCurrentSP GET,

        subscriptionNewSP-DueDate GET,

        subscriptionNewSP-CreationTimeStamp GET,

        accessControl GET;

    ;

lnpLogOldSP-ConcurrenceRequestDefinition BEHAVIOR

    DEFINED AS !

        The lnpLogOldSP-ConcurrenceRequestRecord class is the managed object that is used to create log records for the subscriptionVersionOldSP-ConcurrenceRequest Notification.

    !;

lnpLogOldSP-ConcurrenceRequestBehavior BEHAVIOR

    DEFINED AS !

        This log record can be used by any CME wanting to log the subscriptionVersionOldSP-ConcurrenceRequest Notification.

    !;

— 9.0 LNP Log Record for the NPAC SMS Operational Information Notification

lnpLogOperational-InformationRecord MANAGED OBJECT CLASS

    DERIVED FROM “Rec. X.721 | ISO/IEC 10165-2 : 1992”:eventLogRecord;

    CHARACTERIZED BY

        lnpLogOperational-InformationPkg;

    REGISTERED AS {lnp-objectClass 9};

93

lnpLogOperational-InformationPkg PACKAGE

    BEHAVIOR

        lnpLogOperational-InformationDefinition,

        lnpLogOperational-InformationBehavior;

    ATTRIBUTES

        downTime GET,

        npacContactNumber GET,

        additionalDownTimeInformation GET,

        accessControl GET;

    ;

lnpLogOperational-InformationDefinition BEHAVIOR

    DEFINED AS !

        The lnpLogOperational-InformationRecord class is the managed object that is used to create log records for the lnpNPAC-SMS-Operational-Information Notification.

    !;

lnpLogOperational-InformationBehavior BEHAVIOR

    DEFINED AS !

        This log record can be used by any CME wanting to log the lnpNPAC-SMS-Operational-Information Notification.

    !;

— 10.0 LNP Log Record for the Subscription Version Status Attribute Value

—     Change Notification

lnpLogStatusAttributeValueChangeRecord MANAGED OBJECT CLASS

    DERIVED FROM “Rec. X.721 | ISO/IEC 10165-2 : 1992”:eventLogRecord;

    CHARACTERIZED BY

        lnpLogStatusAttributeValueChangePkg;

    CONDITIONAL PACKAGES

        subscriptionVersionAttributeValueChangeFailed-SP-ListPkg PRESENT IF

            !the version status is failed or partially failed!;

    REGISTERED AS {lnp-objectClass 10};

lnpLogStatusAttributeValueChangePkg PACKAGE

    BEHAVIOR

        lnpLogStatusAttributeValueChangeDefinition,

        lnpLogStatusAttributeValueChangeBehavior;

    ATTRIBUTES

        subscriptionVersionAttributeValueChangeInfo GET,

        accessControl GET;

    ;

lnpLogStatusAttributeValueChangeDefinition BEHAVIOR

    DEFINED AS !

        The lnpLogStatusAttributeValueChangeRecord class is the managed object that is used to create log records for the subscriptionVersionStatusAttributeValueChange Notification.

    !;

lnpLogStatusAttributeValueChangeBehavior BEHAVIOR

    DEFINED AS !

        This log record can be used by any CME wanting to log the

        subscriptionVersionStatusAttributeValueChange Notification.

    !;

— 11.0 LNP Network Managed Object Class

lnpNetwork MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        lnpNetworkPkg;

    CONDITIONAL PACKAGES

94

    lnpDownloadPkg PRESENT IF

        !the object is instantiated on the NPAC SMS!;

    REGISTERED AS {lnp-objectClass 11};

lnpNetworkPkg PACKAGE

    BEHAVIOR

        lnpNetworkDefinition,

        lnpNetworkBehavior;

    ATTRIBUTES

        lnpNetworkName GET;

    ;

lnpNetworkDefinition BEHAVIOR

    DEFINED AS !

        The lnpNetwork class is the managed object that is used as the container object for the serviceProvNetwork objects. This object has been created primarily for scoping efficiency.

        The lnpDownloadPkg will only be used for lnpNetwork object instantiated on the NPAC SMS (Data Download Association Function). This package is used for initiating from the Local SMS downloading of serviceProvNetwork, serviceProvNPA-NXX, and serviceProvLRN object creation or deletion to the Local SMS from the NPAC SMS.

    !;

lnpNetworkBehavior BEHAVIOR

    DEFINED AS !

        Local SMS and NPAC SMS Managed Object used for the Local SMS to

        NPAC SMS interface.

        The Local SMS and the NPAC SMS can M-GET any lnpNetwork object (Data Download Association Function).  The lnpNetworkName attribute is read only and can not be changed via the NPAC SMS to Local SMS Interface once the object has been created.  The value of lnpNetworkName will always be “lnpNetwork”.

        Only one of these objects will exist and it will only be created at startup of the CMIP agent software on the NPAC SMS or the Local SMS.

    !;

— 12.0 LNP NPAC SMS Managed Object Class

lnpNPAC-SMS MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        lnpNPAC-SMS-Pkg,

        lnpRecoveryCompletePkg;

    REGISTERED AS {lnp-objectClass 12};

lnpNPAC-SMS-Pkg PACKAGE

    BEHAVIOR

        lnpNPAC-SMS-Definition,

        lnpNPAC-SMS-Behavior;

    ATTRIBUTES

        lnpNPAC-SMS-Name GET;

    NOTIFICATIONS

        lnpNPAC-SMS-Operational-Information;

    ;

lnpNPAC-SMS-Definition BEHAVIOR

    DEFINED AS !

        The lnpNPAC-SMS class is the managed object that is used as the container object for all NPAC SMS objects in the NPAC SMS to Local SMS Interface and the SOA to NPAC SMS interface.

    !;

95

lnpNPAC-SMS-Behavior BEHAVIOR

    DEFINED AS !

        NPAC SMS Managed Object for the SOA to NPAC SMS and the Local SMS

        to NPAC SMS interface.

        A Local SMS (Data Download Association Function) and service

        provider SOA (SOA Management Association Function) can M-GET

        any lnpNPAC-SMS object.

        The lnpNPAC-SMS-Name attribute is read only and can not be changed via either Interface once the object has been created.

        The value of lnpNPAC-SMS-Name will be set to “Illinois-NPAC-SMS” in Illinois.

        The lnpRecoveryComplete-Pkg is used to used for indicating the recovery mode for the Local SMS is complete and to return all updates made since the recovery mode began.  (Data Download Functional Group).

        Only one of these objects will exist and it will only be created at startup of the CMIP agent software on the NPAC SMS.

        The lnpNPAC-SMS-Operational-Information will be used to notify service provider SOA and Local SMS systems of planned outages.

    !;

— 13.0 LNP Service Providers Managed Object Class

lnpServiceProvs MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        lnpServiceProvsPkg;

    REGISTERED AS {lnp-objectClass 13};

lnpServiceProvsPkg PACKAGE

    BEHAVIOR

        lnpServiceProvsDefinition,

        lnpServiceProvsBehavior;

    ATTRIBUTES

        lnpServiceProvsName GET;

    ;

lnpServiceProvsDefinition BEHAVIOR

    DEFINED AS !

        The lnpServiceProvs class is the managed object that is

        used as the container object for the serviceProv

        objects on the NPAC SMS.  This object has been created

        for scoping efficiency.

    !;

lnpServiceProvsBehavior BEHAVIOR

    DEFINED AS !

        NPAC SMS Managed Object used for the Local SMS to NPAC

        SMS interface.

        A Local SMS and service provider SOA can M-GET any lnpServiceProvs object (Network Data Association Function). The lnpServiceProvsName attribute is read only and can not be changed via the Local SMS Interface once the object has been created.  The value of lnpServiceProvsName will always be “lnpServiceProvs”.

        Only one of these objects will exist and it will only be created at startup of the CMIP agent software on the NPAC SMS.

    !;

— 14.0 LNP Subscriptions Managed Object Class

96

lnpSubscriptions MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        lnpSubscriptionsPkg,

        subscriptionVersionLocalSMS-CreatePkg;

    CONDITIONAL PACKAGES

    lnpDownloadPkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionOldSP-CreatePkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionNewSP-CreatePkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionDisconnectPkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionModifyPkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionActivatePkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionCancelPkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionOldSP-CancellationPkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionNewSP-CancellationPkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionOldSP-ConflictResolutionPkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionNewSP-ConflictResolutionPkg PRESENT IF

        !the object is instantiated on the NPAC SMS!,

    subscriptionVersionNewSP-ConflictResolutionPendingPkg PRESENT IF

        !the object is instantiated on the NPAC SMS!;

    REGISTERED AS {lnp-objectClass 14};

lnpSubscriptionsPkg PACKAGE

    BEHAVIOR

        lnpSubscriptionsDefinition,

        lnpSubscriptionsBehavior;

    ATTRIBUTES

        lnpSubscriptionsName GET;

    NOTIFICATIONS

        subscriptionVersionLocalSMS-ActionResults;

    ;

lnpSubscriptionsDefinition BEHAVIOR

    DEFINED AS !

        Local SMS and NPAC SMS Managed Object for the SOA to NPAC SMS and the Local SMS to NPAC SMS interface.

        The lnpSubscriptions class is the managed object that is used as the container object for the subscription version objects on the NPAC SMS and the Local SMS.

        Local SMS interfaces must be able to support scope/filtered M-SETs and M-DELETEs with a TN range as the primary filter.

    !;

lnpSubscriptionsBehavior BEHAVIOR

    DEFINED AS !

        Local SMS and NPAC SMS Managed Object

        The Local SMS (Data Download Association Function) and the service provider SOA (SOA Management Association Function) can M-GET any lnpSubscriptions object.  The lnpSubscriptionsName attribute is read only and can not be changed via the Local SMS Interface once the object has been created.  The value of lnpSubscriptionsName will always be “lnpSubscriptions”.

97

        Only one of these objects will exist and it will only be created at startup of the CMIP agent software on the NPAC SMS or the Local SMS.

        The lnpDownloadPkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS.  This package is used to used for initiating downloading of subscriptionVersions object creation, deletion, or modifications to the Local SMS (Data Download Association Function).

        The subscriptionVersionOldSP-CreatePkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS.  This package is used for creation of subscription versions for porting TNs by the old service provider.

        The subscriptionVersionNewSP-CreatePkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS.  This package is used for creation of subscription versions for porting TNs by the new service provider.

        The subscriptionVersionDisconnectPkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS.  This package is used for disconnection of a ported TN by the current service provider.

        The subscriptionVersionModifyPkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS.  This package is used for modification of a ported TN by a service provider.

        The subscriptionVersionActivatePkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS.  This package is used for activation of a ported TN by a new service provider.

        The subscriptionVersionCancelPkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS.  This package is used for cancellation of a ported TN by a service provider.

        The subscriptionVersionOldSP-CancellationPkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS. This package is used for acknowledgment of subscription versions with status values of cancel-pending. Acknowledgments from both old and new service provider SOAs take a version from cancel-pending and to a canceled state.  This action is used by the old service provider SOA.

        The subscriptionVersionNewSP-CancellationPkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS. This package is used for acknowledgment of subscription versions with status values of cancel-pending. Acknowledgments from both old and new service provider SOAs take a version out of cancel-pending and to a canceled state.  This action is used by the new service provider SOA.

        The subscriptionVersionOldSP-ConflictResolutionPkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS. This package is used for acknowledgment of subscription versions with status values of conflict-resolution-pending. Acknowledgments from both old and new service provider SOAs take a version out of conflict-resolution-pending and to a pending state. This action is used by the old service provider SOA.

        The subscriptionVersionNewSP-ConflictResolutionPkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS. This package is used for acknowledgment of subscription versions

98

        with status values of conflict-resolution-pending. Acknowledgments from both old and new service provider SOAs take a version out of conflict-resolution-pending and to a pending state.  This action is used by the new service provider SOA.

        The subscriptionVersionNewSP-ConflictResolutionPendingPkg will only be used for a lnpSubscriptions object instantiated on the NPAC SMS. This package is used for setting the status of subscription versions with status values of conflict to conflict-resolution-pending. This action is used by the new service provider SOA.

    !;

— 15.0 LNP Service Provider Managed Object Class

serviceProv MANAGED OBJECT CLASS

    DERIVED FROM serviceProvNetwork;

    CHARACTERIZED BY

        serviceProvPkg;

    CONDITIONAL PACKAGES

        serviceProvBillingAddressPkg PRESENT IF

            !the service provider has billing address and contact

            information!,

        serviceProvSOA-AddressPkg PRESENT IF

            !the service provider has SOA address and contact information!,

        serviceProvLSMS-AddressPkg PRESENT IF

            !the service provider has LSMS address and contact information!,

        serviceProvWebAddressPkg PRESENT IF

            !the service provider has Web address and contact information!,

        serviceProvNetAddressPkg PRESENT IF

            !the service provider has network and communication facilities

            address and contact information!,

        serviceProvConflictAddressPkg PRESENT IF

            !the service provider has conflict resolution interface

            address and contact information!,

        serviceProvOperationsAddressPkg PRESENT IF

            !the service provider has operations address and contact

            information!,

        serviceProvRepairCenterInfoPkg PRESENT IF

            !the service provider has repair contact information!,

        serviceProvUserAdminAddressPkg PRESENT IF

            !the service provider has user administration interface address

            and contact information!;

    REGISTERED AS {lnp-objectClass 15};

serviceProvPkg PACKAGE

    BEHAVIOR

        serviceProvDefinition,

        serviceProvBehavior;

    ATTRIBUTES

        npacCustomerAllowableFunctions GET-REPLACE,

        serviceProvAddress GET-REPLACE,

        serviceProvSysLinkInfo GET-REPLACE,

        serviceProvTunables GET-REPLACE;

    ;

serviceProvDefinition BEHAVIOR

    DEFINED AS !

        The serviceProv class is the managed object used on the NPAC SMS to contain the data related to each LNP service provider.

    !;

serviceProvBehavior BEHAVIOR

    DEFINED AS !

        NPAC SMS Managed Object used for the Local SMS to NPAC

        SMS interface.

99

        A Local SMS and service provider SOA can M-GET their own serviceProv object (Network Data Association Function). Attempts to read any service provider information other than their own will be rejected as unauthorized.  All attributes in this object, except serviceProvID and npacCustomerAllowableFunctions can be M-SET by the Local SMS Interface once the object has been created on the NPAC SMS.

    !;

— 16.0 LNP Service Provider LRN Managed Object Class

serviceProvLRN MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        serviceProvLRN-Pkg;

    REGISTERED AS {lnp-objectClass 16};

serviceProvLRN-Pkg PACKAGE

    BEHAVIOR

        serviceProvLRN-Definition,

        serviceProvLRN-Behavior;

    ATTRIBUTES

        serviceProvLRN-ID GET,

        serviceProvLRN-Value GET,

        serviceProvDownloadReason GET,

                 serviceProvLRN-CreationTimeStamp GET;

    ;

serviceProvLRN-Definition BEHAVIOR

    DEFINED AS !

        The serviceProvLRN class is the managed object used to identify Service Provider LRN values open for porting.

    !;

serviceProvLRN-Behavior BEHAVIOR

    DEFINED AS !

        Local SMS and NPAC SMS Managed Object used for the Local SMS to

        NPAC SMS interface.

        All attributes are read only. Once created, the serviceProvLRN object can only be deleted via the Local SMS or SOA interface.

        The serviceProvLRN-ID is specified by the NPAC SMS. The serviceProvLRN-CreationTimeStamp will reflect the current system date and time when the object is created.

        NPAC SMS can M-GET, M-DELETE and M-CREATE any serviceProvLRN object on the Local SMS (Network Data Functional Unit).  The Local SMS only creates local copies of serviceProvLRN objects after receiving the objects from an NPAC SMS create request, reading them from the NPAC SMS for initial instantiation, or from a download request.

        A Local SMS can M-GET any serviceProvLRN object (Network Data Functional Unit).

        The Local SMS can M-DELETE and M-CREATE any serviceProvLRN object on the NPAC SMS for their own service provider id (Network Data Functional Unit).  Attempts to take actions on other service provider objects will be rejected as unauthorized.

        The creation or deletion of a serviceProvLRN object will be distributed to all Local SMSs.

        The serviceProvLRN-Value attributes on the NPAC SMS can

100

        not be modified by the Local SMS.  The service provider will have to add a new object and delete the old one to modify the data.

    !;

— 17.0 LNP Service Provider Network Managed Object Class

serviceProvNetwork MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        serviceProvNetworkPkg;

    REGISTERED AS {lnp-objectClass 17};

serviceProvNetworkPkg PACKAGE

    BEHAVIOR

        serviceProvNetworkDefinition,

        serviceProvNetworkBehavior;

    ATTRIBUTES

        serviceProvID GET,

        serviceProvName GET-REPLACE;

    ;

serviceProvNetworkDefinition BEHAVIOR

    DEFINED AS !

        The serviceProvNetwork class is the managed object used to contain the network data for a service provider.

    !;

serviceProvNetworkBehavior BEHAVIOR

    DEFINED AS !

        Local SMS and NPAC SMS Managed Object used for the Local SMS to NPAC SMS interface.

        Service providers and the NPAC SMS can M-GET, M-CREATE, and M-SET any serviceProvNetwork object (Network Data Association Function). The serviceProvId attribute is read only and can not be changed via the NPAC SMS to Local SMS Interface once the object has been created on the Local SMS or NPAC SMS.  The serviceProvName can be M-SET via the NPAC SMS to Local SMS Interface by the NPAC SMS.  The Local SMS only creates or modifies local copies of serviceProvNetwork objects after receiving the objects from an NPAC SMS M-CREATE or M-SET request or reading them from the NPAC SMS for initial instantiation.

    !;

— 18.0 LNP Service Provider NPA-NXX Managed Object Class

serviceProvNPA-NXX MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        serviceProvNPA-NXX-Pkg;

    REGISTERED AS {lnp-objectClass 18};

serviceProvNPA-NXX-Pkg PACKAGE

    BEHAVIOR

        serviceProvNPA-NXX-Definition,

        serviceProvNPA-NXX-Behavior;

    ATTRIBUTES

        serviceProvNPA-NXX-ID GET,

        serviceProvNPA-NXX-Value GET,

        serviceProvNPA-NXX-EffectiveTimeStamp GET,

        serviceProvDownloadReason GET,

                serviceProvNPA-NXX-CreationTimeStamp GET;

    ;

serviceProvNPA-NXX-Definition BEHAVIOR

101

    DEFINED AS !

        The serviceProvNPA-NXX class is the managed object used to identify Service Provider NPA-NXX values open for porting.

    !;

serviceProvNPA-NXX-Behavior BEHAVIOR

    DEFINED AS !

        Local SMS and NPAC SMS Managed Object used for the Local SMS to NPAC SMS interface.

        All attributes are read only. Once created, the serviceProvNPA-NXX object can only be deleted via the Local SMS or SOA interface.  The serviceProvNPA-NXX-ID is specified by the NPAC SMS. The serviceProvNPA-NXX-CreationTimeStamp will be set to the current system date and time when the object is created.

        NPAC SMS can M-GET, M-DELETE and M-CREATE any serviceProvNPA-NXX object on the Local SMS (Network Data Association Function).  The Local SMS only creates local copies of serviceProvNPA-NXX objects after receiving the objects from an NPAC SMS create, after reading them from the NPAC SMS for initial instantiation, or from a download.

        Service providers can M-GET any serviceProvNPA-NXX object.

        The Local SMS can M-DELETE and M-CREATE any serviceProvNPA-NXX object on the NPAC SMS for their own service provider id (Network Data Association Function).  Attempts to take actions on other service provider objects will be rejected as unauthorized.

        The Local SMS can not modify any of the attributes.

        To cause an NPA-NXX split to occur the service provider must contact the NPAC SMS operations personnel.

    !;

— 19.0 LNP Subscription Audit Managed Object

subscriptionAudit MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        subscriptionAuditPkg;

    REGISTERED AS {lnp-objectClass 19};

subscriptionAuditPkg PACKAGE

    BEHAVIOR

        subscriptionAuditDefinition,

        subscriptionAuditBehavior;

    ATTRIBUTES

        subscriptionAuditId GET,

        subscriptionAuditName GET,

        subscriptionAuditStatus GET-REPLACE,

        subscriptionAuditAttributeList GET,

        subscriptionAuditTN-Range GET,

        subscriptionAuditTN-ActivationRange GET,

        serviceProvID GET,

        subscriptionAuditServiceProvIdRange GET,

        subscriptionAuditTN-NotificationNumber GET,

        subscriptionAuditNumberOfTNs GET,

        subscriptionAuditNumberOfTNsComplete GET,

        subscriptionAuditRequestingSP GET;

    NOTIFICATIONS

        subscriptionAuditResults,

        subscriptionAudit-DiscrepancyRpt,

        “Rec. X.721 | ISO/IEC 10165-2 : 1992”:attributeValueChange

            accessControlParameter;

102

    ;

subscriptionAuditDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionAudit class is the managed object that represents a subscription audit request.  This object is only instantiated on the NPAC SMS.

    !;

subscriptionAuditBehavior BEHAVIOR

    DEFINED AS !

        When the subscriptionAuditStatus changes an attribute value change will be emitted to the audit requester.

        All attributes must be specified upon create with the exception of the subscriptionAuditAttributeList and the subscriptionAuditTN-ActivationRange.  If the subscriptionAuditAttributeList is not specified then a full audit is assumed. If the subscriptionAuditTN-ActivationRange then an audit of all TNs in the range specified in subscriptionAuditTN-Range will be audited.  The serviceAuditId is determined by the NPAC SMS.

        The SOA or NPAC SMS can M-SET the subscriptionAuditStatus to suspended in order suspend an audit.  The NPAC SMS can change the subscriptionAuditStatus from in-progress to suspended and from suspended to in-progress or canceled.  When the status is changed to suspended, the NPAC SMS will stop processing the audit until it is resumed by the NPAC SMS changing the status back to in-progress.  The subscriptionAuditRequestingSP is the id of the service provider who requested the audit.

        The NPAC SMS will be required to set the number of TNs that will be audited in the subscriptionAuditNumberOfTNs attribute based on the NPAC SMS audit request criteria.  An attribute value change notification will be emitted when the subscriptionAuditNumberOfTNs is set.  After every subscriptionAuditTN-NotificationNumber of TNs has been audited the subscriptionAuditNumberOfTNsComplete shall be updated and an attribute value change notification shall be sent to the NPAC SMS.

        The SOA or NPAC SMS can M-CREATE, M-GET subscriptionAudit managed objects on the NPAC SMS (Process Audit Association Function). When a subscriptionAudit object is created on the NPAC SMS the NPAC SMS will begin the audit for the service provider specified or all service providers.  The SOA can only M-GET subscriptionAudit that they created.

        The SOA will be required to set the service provider ID with their service provider id so that the origination of the audit request can be tracked and notifications can be sent to the requesting SOA.

        The subscriptionAuditTN-Range will be limited based on the maximum range size specified in the NPAC SMS.  If the limit specified is exceeded, the create request will fail with an invalidAttributeValue error.

        When this object is created and deleted, object creation and deletion notifications will be sent to the requester.  Object deletion indicates completion of an audit.  The audit results notification will be sent before the object is deleted by the entity performing the audit indicating how may discrepancies the audit found and reported during execution.

        If discrepancies are found during the audit, audit discrepancy

103

        notifications will be sent to the requester at the time they are found.  When audit discrepancy notifications are sent to the NPAC SMS by the Local SMS, create or modify requests will be sent to the Local SMS by the NPAC SMS to correct the discrepancies found.

        Deletion of an audit object cancels an audit request.

    !;

— 20.0 LNP subscription Version Managed Object Class

subscriptionVersion MANAGED OBJECT CLASS

    DERIVED FROM top;

    CHARACTERIZED BY

        subscriptionVersionPkg;

    REGISTERED AS {lnp-objectClass 20};

subscriptionVersionPkg PACKAGE

    BEHAVIOR

        subscriptionVersionDefinition,

        subscriptionVersionBehavior;

    ATTRIBUTES

        subscriptionVersionId GET,

        subscriptionTN GET-REPLACE,

        subscriptionLRN GET-REPLACE,

        subscriptionNewCurrentSP GET-REPLACE,

        subscriptionActivationTimeStamp GET-REPLACE,

        subscriptionCustomerDisconnectDate GET-REPLACE,

        subscriptionCLASS-DPC GET-REPLACE,

        subscriptionCLASS-SSN GET-REPLACE,

        subscriptionLIDB-DPC GET-REPLACE,

        subscriptionLIDB-SSN GET-REPLACE,

        subscriptionCNAM-DPC GET-REPLACE,

        subscriptionCNAM-SSN GET-REPLACE,

        subscriptionISVM-DPC GET-REPLACE,

        subscriptionISVM-SSN GET-REPLACE,

        subscriptionEndUserLocationValue GET-REPLACE,

        subscriptionEndUserLocationType GET-REPLACE,

        subscriptionBillingId GET-REPLACE,

        subscriptionLNPType GET-REPLACE,

        subscriptionDownloadReason GET-REPLACE;

    ;

subscriptionVersionDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersion class is the managed object that represents a subscription version on the Local SMS.

    !;

subscriptionVersionBehavior BEHAVIOR

    DEFINED AS !

        Local SMS Managed Object

        NPAC SMS can M-GET, M-SET, M-DELETE and M-CREATE any subscriptionVersion object on the Local SMS (Data Download Association Function).  The Local SMS only creates local copies of subscriptionVersion objects after receiving the objects from an NPAC SMS create request or reading them from the NPAC SMS for initial instantiation.

        The serviceProvVersionId is assigned upon creation by the NPAC SMS and is read only.

        The subscriptionTN, subscriptionLRN and associated routing information, are specified by the new service provider SOA upon creation of a new subscription version.

104

        When the subscription version is activated the subscriptionActivationTimeStamp is updated.

        When the subscription version is downloaded to the locals, the subscriptionDownloadReason is set to one of new, delete, modified, audit-discrepancy, or download-request. This field is not validated in audits.

        When the subscription version status is set to disconnect pending or old, the subscriptionVersionDonorSP-CustomerDisconnectDate is sent to the donor SOA informing the service provider of the actual customer disconnect date.

        The Local SMS can not modify any of the subscription version data locally unless changes were downloaded via a download request.

    !;

— 21.0 LNP NPAC Subscription Version Managed Object Class

subscriptionVersionNPAC MANAGED OBJECT CLASS

    DERIVED FROM subscriptionVersion;

    CHARACTERIZED BY

        subscriptionVersionNPAC-Pkg;

    REGISTERED AS {lnp-objectClass 21};

subscriptionVersionNPAC-Pkg PACKAGE

    BEHAVIOR

        subscriptionVersionNPAC-Definition,

        subscriptionVersionNPAC-Behavior;

    ATTRIBUTES

        subscriptionVersionStatus GET-REPLACE,

        subscriptionOldSP GET-REPLACE,

        subscriptionNewSP-DueDate GET-REPLACE,

        subscriptionNewSP-CreationTimeStamp GET-REPLACE,

        subscriptionOldSP-DueDate GET-REPLACE,

        subscriptionOldSP-Authorization GET-REPLACE,

        subscriptionOldSP-AuthorizationTimeStamp GET-REPLACE,

        subscriptionBroadcastTimeStamp GET-REPLACE,

        subscriptionConflictTimeStamp GET-REPLACE,

        subscriptionEffectiveReleaseDate GET-REPLACE,

        subscriptionDisconnectCompleteTimeStamp GET-REPLACE,

        subscriptionCancellationTimeStamp GET-REPLACE,

        subscriptionCreationTimeStamp GET-REPLACE,

        subscriptionFailed-SP-List GET-REPLACE,

        subscriptionModifiedTimeStamp GET-REPLACE,

        subscriptionOldTimeStamp GET-REPLACE,

        subscriptionOldSP-CancellationTimeStamp GET-REPLACE,

        subscriptionNewSP-CancellationTimeStamp GET-REPLACE,

        subscriptionOldSP-ConflictResolutionTimeStamp GET-REPLACE,

        subscriptionNewSP-ConflictResolutionTimeStamp GET-REPLACE,

        subscriptionPortingToOriginal-SPSwitch GET-REPLACE,

        subscriptionPreCancellationStatus GET-REPLACE;

    NOTIFICATIONS

        subscriptionVersionOldSP-ConcurrenceRequest,

        subscriptionVersionNewSP-CreateRequest,

        subscriptionVersionNewNPA-NXX,

        subscriptionVersionConflictResolutionAcknowledgeRequest,

        subscriptionVersionCancellationAcknowledgeRequest,

        subscriptionVersionDonorSP-CustomerDisconnectDate,

        subscriptionVersionStatusAttributeValueChange,

        “Rec. X.721 | ISO/IEC 10165-2 : 1992”:attributeValueChange

            accessControlParameter,

        “Rec. X.721 | ISO/IEC 10165-2 : 1992”:objectCreation

            accessControlParameter;

105

    ;

subscriptionVersionNPAC-Definition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionNPAC class is the managed object that represents a subscription version on the NPAC SMS.

    !;

subscriptionVersionNPAC-Behavior BEHAVIOR

    DEFINED AS !

        NPAC SMS Managed Object for the SOA to NPAC SMS and the Local SMS to NPAC SMS interface.

        A Local SMS can M-GET any subscriptionVersionNPAC objects from the NPAC SMS via the Local SMS Interface (Data Download Association Function).

        A Service Provider SOA can M-GET any subscriptionVersionNPAC objects from the NPAC SMS via the SOA Interface (SOA Management Association Function).

        If a Service Provider SOA or Local SMS does a scoped filtered M-GET for subscription versions, this request will only be successful if a the number of records to be returned is less than or equal to the NPAC SMS tunable parameter, “Max Subscriber Query”, in the Service Data table.

        When the status of an object is changed to “cancel-pending”, subscriptionPreCancellationStatus is first set to the current status.

        The subscriptionCreationTimeStamp is set to the current system time when the object is created.

        When the subscription version is modified for any reason, the subscriptionModifiedTimeStamp is updated with the current system time.

        When the subscription version is broadcast to Local SMSs via the NPAC to Local SMS interface, the subscriptionBroadcastTimeStamp is updated with the current system time.

        When the subscription version has its version status set to old, the subscriptionOldTimeStamp is updated with the current system time.

        When the subscription version has its version status set to cancel, the subscriptionCancellationTimeStamp is updated with the current system time.

        When the subscription version has its version status set to conflict, the subscriptionConflictTimeStamp is updated with the current system time.

        When the subscription version is disconnected and the version status is set to old, the subscriptionDisconnectCompleteTimeStamp is updated with the current system time.

        When the subscription version status is set to disconnect pending the subscriptionEffectiveReleaseDate is set to the date the disconnect should be broadcast.

        When the subscription version in a cancel-pending state is acknowledged by an old service provider SOA, the subscriptionOldSP-CancellationTimeStamp is updated with the current system time.

        When the subscription version in a cancel-pending state is acknowledged by a new service provider SOA, the

106

        subscriptionNewSP-CancellationTimeStamp is updated with the current system time.

        When the subscription version in a conflict-resolution-pending state is acknowledged by an old service provider SOA, the subscriptionOldSP-ConflictResolutionTimeStamp is updated with the current system time.

        When the subscription version in a conflict-resolution-pending state is acknowledged by a new service provider SOA, the subscriptionNewSP-ConflictResolutionTimeStamp is updated with the current system time.

        When the subscription version status is failed or partially-failed, the subscriptionFailed-SP-List is populated with a list of the failed service providers.

        The Service Provider SOA can M-GET and M-SET subscriptionVersionNPAC objects via the SOA to NPAC SMS interface (SOA Management Association Function).  Rules for M-SET are described below.

        For M-GET requests, the filter will support all attributes for a specified ported TN.

        Any service provider SOA can view any subscription version for any ported TN (SOA Management Association Function).

        Subscription versions are created on the NPAC SMS via actions over the SOA to NPAC SMS interface to the lnpSubscriptions object (SOA Management Association Function).  New service provider SOAs must use the subscriptionVersionNewSP-Create action and old service provider SOAs must use the subscriptionVersionOldSP-Create action. Creates can only be performed provided there is only one currently active subscription version for the TN.  If one service provider SOA has already done a create, the other service provider SOA may choose to M-SET that object directly to specify the create data information instead of using a create action.

        subscriptionPortingToOriginal-SPSwitch can only be specified as TRUE for a TN that is currently ported and is being ported back to the original service provider.   If the value of subscriptionPortingToOriginal-SPSwitch is TRUE, the LRN and GTT data should not be specified.  This data is not specified because when the activate occurs for the subscription version, the Local SMS will receive requests to delete the old subscription version routing data in their networks and they will not receive any new network routing data for the subscription. Concurrence from the old service provider is required.

        If the port of the subscription version is an intra-service provider port, the new service provider SOA can use the subscriptionVersionNewSP-Create action specifying the old service provider equal to the new service provider.  In this case, the old service provider create action is not required and processing proceeds after a valid pending version is created in the same manner as it does for inter-service provider porting.

        Once a version has been created that passes validation, the subscriptionVersionNPAC object subscriptionVersionStatus will be set to pending and an object creation notification will be sent to both old and new service provider SOAs.  If a version previously existed, attribute value change notifications will be sent to both old and new service provider SOAs.

        If there is a pending version that does not have concurrence during the “Service Provider Concurrence Window” specified in the Service Data table, a subscriptionVersionNoConcurrence notification will be

107

        sent to the service provider SOA that has not responded.  The subscriptionVersionStatus will be set to cancel-pending if the new service provider SOA has not responded or to conflict if the old service provider SOA has not responded after the “Service Provider Concurrence Failure Window” specified in the Service Data table. An attribute value change will be sent to the service provider SOA that sent the original create request.

        The Service Provider SOA can M-SET attributes associated with pending, cancel-pending, conflict-resolution-pending or conflict subscription versions (SOA Management Association Function). Attempts to modify an active, sending, failed, canceled, disconnect-pending or old version using M-SET will result in an access denied error.

        Modification of an active subscription can only be done by the current/new service provider SOA using the subscriptionVersionModify action.

        The modify action can be used by both old and new service provider SOAs to update pending, conflict-resolution-pending or conflict subscription versions.

        Old service provider SOAs can only modify the following attributes:

        subscriptionOldSP-DueDate

        subscriptionOldSP-Authorization

        New service provider SOAs can only modify the following attributes:

        subscriptionLRN

        subscriptionNewSP-DueDate

        subscriptionCLASS-DPC

        subscriptionCLASS-SSN

        subscriptionLIDB-DPC

        subscriptionLIDB-SSN

        subscriptionCNAM-DPC

        subscriptionCNAM-SSN

        subscriptionISVM-DPC

        subscriptionISVM-SSN

        subscriptionEndUserLocationValue

        subscriptionEndUserLocationType

        subscriptionBillingId

        Validation will be done for both old and new service provider data that is specified on an M-SET.  If validation fails, no changes will be made and a processing failure will be returned. If the version passes validation, the version status will be set to pending.  An error message will be returned to the service provider if the status is not pending when they attempt to change the version status to cancel-pending.

        Once a pending version has been created, the new service provider can activate the subscription version if authorization for the port has been received by the old service provider within the “Service Provider Concurrence Cancellation Window”.

        Once the version is activated, the version status is set to sending, the broadcast time stamp is updated, and creates are sent to the Local SMSs.

        If the create requests are successful for all Local SMSs, the version status will be marked as active and the previously active subscription version will have its version status set to old.

        If create requests fail for a subscription version after the retry periods have expired, the version status will be set

108

        to failed or partially-failed based on if the download failed in all or some of the Local SMSs respectively.

        A status version attribute value change will be sent to both old and new service providers when the subscriptionVersionStatus is modified.  If the version status is failed or partially-failed then a list of failed service providers is provided in the subscriptionVersionStatus notification.

        A service provider should acknowledge the conflict resolution pending state within a tunable time frame specified on the NPAC SMS with a conflict resolution acknowledgement action.

        If a service provider fails to acknowledge the conflict resolution pending state, a subscriptionVersionConflictResolutionAcknowledgeRequest is sent to the service provider.  If they do not respond to this acknowledgement in a tunable time frame specified on the NPAC SMS, the version status will be set to cancel-pending.

        A service provider should acknowledge the cancel pending state within a tunable time frame specified on the NPAC SMS with a cancel acknowledgement action.

        If a service provider SOA fails to acknowledge the cancel pending state, a subscriptionVersionCancellationAcknowledgeRequest is sent to the service provider SOA.  If they do not respond to this acknowledgement in a tunable time frame specified on the NPAC SMS, the version status will be set to conflict.

        No new subscription versions are created due to changes made via the M-SET command.  Only changes to an active version via the subscriptionVersionModify action cause new subscription versions to be created.

        Attribute value change notifications will be sent to both service provider SOAs when the following attribute values change for a pending, cancel-pending, conflict-resolution-pending, conflict or disconnect-pending subscription versions:

        subscriptionNewSP-DueDate

        subscriptionNewSP-CreationTimeStamp

        subscriptionOldSP-DueDate

        subscriptionOldSP-Authorization

        subscriptionOldSP-AuthorizationTimeStamp

        subscriptionVersionStatus

        Object creation notifications will be sent to both old and new service provider SOAs when a subscriptionVersionNPAC associated with their Service Provider id is created.  Object deletion notifications will not be used. Objects will only be deleted by the NPAC SMS as a result of housekeeping processing.

        When a subscription version is disconnected, the subscriptionVersionDonorSP-CustomerDisconnectDate is sent to the donor SOA informing the service provider of the actual customer disconnect date.

    !;

7.3.Name Binding Definitions

— 1.0 LNP Audits Managed Object Name Bindings

lnpAudits-lnpNPAC-SMS NAME BINDING

    SUBORDINATE OBJECT CLASS lnpAudits AND SUBCLASSES;

109

    NAMED BY

        SUPERIOR OBJECT CLASS lnpNPAC-SMS AND SUBCLASSES;

    WITH ATTRIBUTE lnpAuditsName;

    — Note: Create through interface is not supported.

    — Note: Delete through interface is not supported.

    REGISTERED AS {lnp-nameBinding 1};

lnpAudits-lnpLocalSMS NAME BINDING

    SUBORDINATE OBJECT CLASS lnpAudits AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS lnpLocalSMS AND SUBCLASSES;

    WITH ATTRIBUTE lnpAuditsName;

    — Note: Create through interface is not supported.

    — Note: Delete through interface is not supported.

    REGISTERED AS {lnp-nameBinding 2};

— 2.0 LNP Local SMS Managed Object Name Bindings

lnpLocalSMS-root NAME BINDING

    SUBORDINATE OBJECT CLASS lnpLocalSMS AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS “Rec. X.660 | ISO/IEC 9834-1 : 1992”:root;

    WITH ATTRIBUTE lnpLocal-SMS-Name;

    — Note: Create through interface is not supported.

    — Note: Delete through interface is not supported.

    REGISTERED AS {lnp-nameBinding 3};

— 3.0 LNP Network Managed Object Name Bindings

lnpNetwork-lnpNPAC-SMS NAME BINDING

    SUBORDINATE OBJECT CLASS lnpNetwork AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS lnpNPAC-SMS AND SUBCLASSES;

    WITH ATTRIBUTE lnpNetworkName;

    — Note: Create through interface is not supported.

    — Note: Delete through interface is not supported.

    REGISTERED AS {lnp-nameBinding 4};

lnpNetwork-lnpLocalSMS NAME BINDING

    SUBORDINATE OBJECT CLASS lnpNetwork AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS lnpLocalSMS AND SUBCLASSES;

    WITH ATTRIBUTE lnpNetworkName;

    — Note: Create through interface is not supported.

    — Note: Delete through interface is not supported.

    REGISTERED AS {lnp-nameBinding 5};

— 4.0 LNP NPAC SMS Managed Object Name Bindings

lnpNPAC-SMS-root NAME BINDING

    SUBORDINATE OBJECT CLASS lnpNPAC-SMS AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS “Rec. X.660 | ISO/IEC 9834-1 : 1992”:root;

    WITH ATTRIBUTE lnpNPAC-SMS-Name;

    — Note: Create through interface is not supported.

    — Note: Delete through interface is not supported.

    REGISTERED AS {lnp-nameBinding 6};

— 5.0 LNP Service Providers Managed Object Name Bindings

lnpServiceProvs-lnpNPAC-SMS NAME BINDING

    SUBORDINATE OBJECT CLASS lnpServiceProvs AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS lnpNPAC-SMS AND SUBCLASSES;

    WITH ATTRIBUTE lnpServiceProvsName;

    — Note: Create through interface is not supported.

    — Note: Delete through interface is not supported.

110

    REGISTERED AS {lnp-nameBinding 7};

— 6.0 LNP Subscriptions Managed Object Class Name Bindings

lnpSubscriptions-lnpNPAC-SMS NAME BINDING

    SUBORDINATE OBJECT CLASS lnpSubscriptions AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS lnpNPAC-SMS AND SUBCLASSES;

    WITH ATTRIBUTE lnpSubscriptionsName;

    — Note: Create through interface is not supported.

    — Note: Delete through interface is not supported.

    REGISTERED AS {lnp-nameBinding 8};

lnpSubscriptions-lnpLocalSMS NAME BINDING

    SUBORDINATE OBJECT CLASS lnpSubscriptions AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS lnpLocalSMS AND SUBCLASSES;

    WITH ATTRIBUTE lnpSubscriptionsName;

    — Note: Create through interface is not supported.

    — Note: Delete through interface is not supported.

    REGISTERED AS {lnp-nameBinding 9};

— 7.0 LNP Service Provider Managed Object Class Name Bindings

serviceProv-lnpServiceProvs NAME BINDING

    SUBORDINATE OBJECT CLASS serviceProv AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS lnpServiceProvs AND SUBCLASSES;

    WITH ATTRIBUTE serviceProvID;

    CREATE WITH-REFERENCE-OBJECT;

    DELETE ONLY-IF-NO-CONTAINED-OBJECTS;

    REGISTERED AS {lnp-nameBinding 10};

— 8.0 LNP Service Provider LRN Managed Object Class Name Bindings

serviceProvLRN-serviceProvNetwork NAME BINDING

    SUBORDINATE OBJECT CLASS serviceProvLRN AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS serviceProvNetwork AND SUBCLASSES;

    WITH ATTRIBUTE serviceProvLRN-ID;

    CREATE WITH-REFERENCE-OBJECT, WITH-AUTOMATIC-INSTANCE-NAMING;

    DELETE ONLY-IF-NO-CONTAINED-OBJECTS;

    REGISTERED AS {lnp-nameBinding 11};

— 9.0 LNP Service Provider Network Managed Object Class Name Bindings

serviceProvNetwork-lnpNetwork NAME BINDING

    SUBORDINATE OBJECT CLASS serviceProvNetwork AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS lnpNetwork AND SUBCLASSES;

    WITH ATTRIBUTE serviceProvID;

    CREATE WITH-REFERENCE-OBJECT;

    DELETE ONLY-IF-NO-CONTAINED-OBJECTS;

    REGISTERED AS {lnp-nameBinding 12};

— 10.0 LNP Service Provider NPA-NXX Managed Object Class Name Bindings

serviceProvNPA-NXX-serviceProvNetwork NAME BINDING

    SUBORDINATE OBJECT CLASS serviceProvNPA-NXX AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS serviceProvNetwork AND SUBCLASSES;

    WITH ATTRIBUTE serviceProvNPA-NXX-ID;

    CREATE WITH-REFERENCE-OBJECT, WITH-AUTOMATIC-INSTANCE-NAMING;

    DELETE ONLY-IF-NO-CONTAINED-OBJECTS;

    REGISTERED AS {lnp-nameBinding 13};

111

— 11.0 LNP Subscription Audit for the NPAC SMS Managed Object

subscriptionAudit-lnpAudits NAME BINDING

    SUBORDINATE OBJECT CLASS subscriptionAudit AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS lnpAudits AND SUBCLASSES;

    WITH ATTRIBUTE subscriptionAuditId;

    CREATE WITH-REFERENCE-OBJECT, WITH-AUTOMATIC-INSTANCE-NAMING;

    DELETE ONLY-IF-NO-CONTAINED-OBJECTS;

    REGISTERED AS {lnp-nameBinding 14};

— 12.0 LNP Subscription Version Managed Object Class

subscriptionVersion-lnpSubscriptions NAME BINDING

    SUBORDINATE OBJECT CLASS subscriptionVersion AND SUBCLASSES;

    NAMED BY

        SUPERIOR OBJECT CLASS lnpSubscriptions AND SUBCLASSES;

    WITH ATTRIBUTE subscriptionVersionId;

    CREATE WITH-REFERENCE-OBJECT, WITH-AUTOMATIC-INSTANCE-NAMING;

    DELETE ONLY-IF-NO-CONTAINED-OBJECTS;

    REGISTERED AS {lnp-nameBinding 15};

7.4.Attribute Definitions

— 1.0  LNP Access Control Attribute

accessControl ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpAccessControl;

    MATCHES FOR EQUALITY;

    BEHAVIOR accessControlBehavior;

    REGISTERED AS {lnp-attribute 1};

accessControlBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store/define access control information for security.

!;

— 2.0  LNP Action Id Attribute

actionId ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.Integer;

    MATCHES FOR EQUALITY;

    BEHAVIOR actionIdBehavior;

    REGISTERED AS {lnp-attribute 2};

actionIdBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the action id associated with an action that sends back an asynchronous notification.

!;

— 3.0  LNP Action Results Status Attribute

actionResultsStatus ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.ActionResultsStatus;

    MATCHES FOR EQUALITY;

    BEHAVIOR actionResultsStatusBehavior;

    REGISTERED AS {lnp-attribute 3};

actionResultsStatusBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the status of an action that sends back an asynchronous notification with the results.

!;

112

— 4.0  LNP Additional Down Time Information

additionalDownTimeInformation ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.GraphicString255;

    MATCHES FOR EQUALITY;

    BEHAVIOR additionalDownTimeInformationBehavior;

    REGISTERED AS {lnp-attribute 4};

additionalDownTimeInformationBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to provide additional information about planned NPAC SMS down time in an NPAC operations notification in a log record.

!;

— 5.0  LNP Audit Discrepancy Failure Reason

auditDiscrepancyFailureReason ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditFailureData;

    MATCHES FOR EQUALITY;

    BEHAVIOR auditDiscrepancyFailureReasonBehavior;

    REGISTERED AS {lnp-attribute 5};

auditDiscrepancyFailureReasonBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the audit discrepancy failure reason in an audit discrepancy notification in a log record.

!;

— 6.0  LNP Audit Discrepancy Local SMS Service Provider Id

auditDiscrepancyLSMS-SP-Id ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.ServiceProvId;

    MATCHES FOR EQUALITY;

    BEHAVIOR auditDiscrepancyLSMS-SP-Id-Behavior;

    REGISTERED AS {lnp-attribute 6};

auditDiscrepancyLSMS-SP-Id-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the service provider id associated with the Local SMS in an audit discrepancy notification in a log record.

!;

— 7.0  LNP Audit Discrepancy TN

auditDiscrepancyTn ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.PhoneNumber;

    MATCHES FOR EQUALITY;

    BEHAVIOR auditDiscrepancyTnBehavior;

    REGISTERED AS {lnp-attribute 7};

auditDiscrepancyTnBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the TN for which the discrepancy was found in an audit discrepancy notification in a log record.

!;

— 8.0  LNP Audit Discrepancy Version Id

auditDiscrepancyVersionId ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.SubscriptionVersionId;

    MATCHES FOR EQUALITY;

    BEHAVIOR auditDiscrepancyVersionId-Behavior;

    REGISTERED AS {lnp-attribute 8};

113

auditDiscrepancyVersionId-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the version id for the TN for which the discrepancy was found in an audit discrepancy notification in a log record.

!;

— 9.0  LNP Audit Response Level

auditResponseLevel ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditResponseLevel;

    MATCHES FOR EQUALITY;

    BEHAVIOR auditResponseLevelBehavior;

    REGISTERED AS {lnp-attribute 9};

auditResponseLevelBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the level to which an audit was performed (SCP, Local SMS).

!;

— 10.0  LNP Audit Results Audit Completion Time

auditResultCompletionTime ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR auditResultCompletionTimeBehavior;

    REGISTERED AS {lnp-attribute 10};

auditResultCompletionTimeBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the completion time of the audit in an audit results notification in a log record.

!;

— 11.0  LNP Audit Result Failed Service Provider List

auditResultFailed-SP-List ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.Failed-SP-List;

    MATCHES FOR EQUALITY;

    BEHAVIOR auditResultFailed-SP-ListBehavior;

    REGISTERED AS {lnp-attribute 11};

auditResultFailed-SP-ListBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store, in an audit results notification in a log record, the list of failed service providers for an audit that failed due to failures on Local SMSs.

!;

— 12.0 LNP Audit Results Number of Discrepancies

auditResultNumberDiscrepancies ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.Integer;

    MATCHES FOR EQUALITY;

    BEHAVIOR auditResultNumberDiscrepanciesBehavior;

    REGISTERED AS {lnp-attribute 12};

auditResultNumberDiscrepanciesBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the number of discrepancies found in an audit results notification in a log record.

!;

— 13.0 LNP Audit Result Status

114

auditResultStatus ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditResultStatus;

    MATCHES FOR EQUALITY;

    BEHAVIOR auditResultStatusBehavior;

    REGISTERED AS {lnp-attribute 13};

auditResultStatusBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the final status of the audit in an audit results notification in a log record.

!;

— 14.0 LNP Operational Notification Down Time

downTime ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.TimeRange;

    MATCHES FOR EQUALITY;

    BEHAVIOR downTimeBehavior;

    REGISTERED AS {lnp-attribute 14};

downTimeBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to indicate the down time in an NPAC operations notification in a log record.

!;

— 15.0 LNP Failed TN List

failedTN-List ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.FailedTN-List;

    MATCHES FOR EQUALITY;

    BEHAVIOR failedTN-ListBehavior;

    REGISTERED AS {lnp-attribute 15};

failedTN-ListBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to indicate the tn(s) and errors for a failed action in the return asynchronous notification.

!;

— 16.0 LNP Audits Name

lnpAuditsName ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpAuditsName;

    MATCHES FOR EQUALITY;

    BEHAVIOR lnpAuditsNameBehavior;

    REGISTERED AS {lnp-attribute 16};

lnpAuditsNameBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the lnpAudits managed object.  The value for this attribute is “lnpAudits”.

!;

— 17.0 LNP Local SMS Name

lnpLocal-SMS-Name ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpSMS-Name;

    MATCHES FOR EQUALITY;

    BEHAVIOR lnpLocal-SMS-NameBehavior;

    REGISTERED AS {lnp-attribute 17};

lnpLocal-SMS-NameBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the lnpNPAC-SMS object.  Valid values are service provider id of the Local

115

        SMS for the NPAC SMS to Local SMS Interface.

!;

— 18.0 LNP Network Name

lnpNetworkName ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpNetworkName;

    MATCHES FOR EQUALITY;

    BEHAVIOR lnpNetworkNameBehavior;

    REGISTERED AS {lnp-attribute 18};

lnpNetworkNameBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the lnpNetwork object.  Valid values are “lnpName” for the NPAC SMS to Local SMS Interface.

!;

— 19.0 LNP NPAC SMS Name

lnpNPAC-SMS-Name ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpSMS-Name;

    MATCHES FOR EQUALITY;

    BEHAVIOR lnpNPAC-SMS-NameBehavior;

    REGISTERED AS {lnp-attribute 19};

lnpNPAC-SMS-NameBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the lnpNPAC-SMS object.  The valid value for this attribute in Illinois is “Illinois-NPAC-SMS” for the NPAC SMS.

!;

— 20.0 LNP Service Providers Name

lnpServiceProvsName ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpServiceProvsName;

    MATCHES FOR EQUALITY;

    BEHAVIOR lnpServiceProvsNameBehavior;

    REGISTERED AS {lnp-attribute 20};

lnpServiceProvsNameBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the lnpServiceProvs object.   The value for this attribute will be “lnpServiceProvs” in the NPAC SMS to Local SMS Interface.

!;

— 21.0 LNP Specific Info

lnpSpecificInfo ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpSpecificInfo;

    MATCHES FOR EQUALITY;

    BEHAVIOR lnpSpecificInfoBehavior;

    REGISTERED AS {lnp-attribute 21};

lnpSpecificInfoBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to pass specific error information in the case of a cmip processing failure error.

!;

— 22.0 LNP Subscriptions Name

lnpSubscriptionsName ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpSubscriptionsName;

116

    MATCHES FOR EQUALITY;

    BEHAVIOR lnpSubscriptionsNameBehavior;

    REGISTERED AS {lnp-attribute 22};

lnpSubscriptionsNameBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the lnpSubscriptions object.   The value for this attribute will be “lnpSubscriptions” in the NPAC SMS to Local SMS Interface.

!;

— 23.0 LNP NPAC Contact Number

npacContactNumber ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.PhoneNumber;

    MATCHES FOR EQUALITY;

    BEHAVIOR npacContactNumberBehavior;

    REGISTERED AS {lnp-attribute 23};

 npacContactNumberBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to indicate the NPAC contact number to be called concerning an NPAC SMS outage in an NPAC operations notification in a log record.

!;

— 24.0 LNP NPAC Customer Allowable Functions

npacCustomerAllowableFunctions ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AssociationFunction;

    MATCHES FOR EQUALITY;

    BEHAVIOR npacCustomerAllowableFunctionsBehavior;

    REGISTERED AS {lnp-attribute 24};

npacCustomerAllowableFunctionsBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify what functions a service provider can perform on the SOA to NPAC SMS and NPAC SMS to Local SMS interfaces.

!;

— 25.0 LNP Results Completion Time

resultsCompletionTime ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR resultsCompletionTimeBehavior;

    REGISTERED AS {lnp-attribute 25};

resultsCompletionTimeBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the completion time of the action in the action results notification.

!;

— 26.0 LNP Service Provider Address

serviceProvAddress ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AddressInformation;

    MATCHES FOR EQUALITY;

    BEHAVIOR serviceProvAddressBehavior;

    REGISTERED AS {lnp-attribute 26};

serviceProvAddressBehavior BEHAVIOR

    DEFINED AS !

117

        This attribute is used to specify the address information for a service provider.

!;

— 27.0 LNP Service Provider Billing Address

serviceProvBillingAddress ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AddressInformation;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvBillingAddressBehavior;

    REGISTERED AS {lnp-attribute 27};

serviceProvBillingAddressBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the billing address information for a service provider.

!;

— 28.0 LNP Service Provider Conflict Resolution Contact Address

serviceProvConflictAddress ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AddressInformation;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvConflictAddressBehavior;

    REGISTERED AS {lnp-attribute 28};

serviceProvConflictAddressBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the service provider conflict resolution contact address and contact information.

!;

— 29.0 LNP Service Provider Data Download Reason

serviceProvDownloadReason ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.DownloadReason;

    MATCHES FOR EQUALITY;

    BEHAVIOR servicePriovderDownloadReasonBehavior;

    REGISTERED AS {lnp-attribute 29};

serviceProvDownloadReasonBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the reason the data was downloaded to the Local SMS from NPAC SMS.  This attribute only has meaning in objects instantiated on the Local SMS.

!;

— 30.0 LNP Service Provider ID

serviceProvID ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.ServiceProvId;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR serviceProvID-Behavior;

    REGISTERED AS {lnp-attribute 30};

serviceProvID-Behavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the serviceProvNetwork and serviceProv objects as well as an identifier for the service provider who has requested an audit on the NPAC SMS.  Valid values are the Facilities Id (or OCN) of the service provider.

!;

— 31.0 LNP Service Provider LRN Last Modified Time Stamp

serviceProvLRN-CreationTimeStamp ATTRIBUTE

118

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvLRN-CreationTimeStampBehavior;

    REGISTERED AS {lnp-attribute 31};

serviceProvLRN-CreationTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides the timestamp of the last time the serviceProvLRN object was created on the NPAC SMS.

!;

— 32.0 LNP Service Provider LRN ID

serviceProvLRN-ID ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LRN-ID;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvLRN-ID-Behavior;

    REGISTERED AS {lnp-attribute 32};

serviceProvLRN-ID-Behavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the serviceProvLRN object.  The NPAC SMS determines the value for this attribute.

!;

— 33.0 LNP Service Provider LRN Value

serviceProvLRN-Value ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LRN;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvLRN-Value-Behavior;

    REGISTERED AS {lnp-attribute 33};

serviceProvLRN-Value-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the value for a service provider LRN associated with an NPA-NXX.

!;

— 34.0 LNP Service Provider LSMS Address

serviceProvLSMS-Address ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AddressInformation;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvLSMS-AddressBehavior;

    REGISTERED AS {lnp-attribute 34};

serviceProvLSMS-AddressBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the service provider LSMS address and contact information.

!;

— 35.0 LNP Service Provider Name

serviceProvName ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.ServiceProvName;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR serviceProvNameBehavior;

    REGISTERED AS {lnp-attribute 35};

serviceProvNameBehavior BEHAVIOR

    DEFINED AS !

        This attribute is the English name for the service provider.

!;

— 36.0 LNP Service Provider Network and Communications Address

119

serviceProvNetAddress ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AddressInformation;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvNetAddressBehavior;

    REGISTERED AS {lnp-attribute 36};

serviceProvNetAddressBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the service provider network and communications facilities address and contact information.

!;

— 37.0 LNP Service Provider NPA-NXX Creation Time Stamp

serviceProvNPA-NXX-CreationTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvNPA-NXX-CreationTimeStampBehavior;

    REGISTERED AS {lnp-attribute 37};

serviceProvNPA-NXX-CreationTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides the timestamp of the creation of the serviceProvNPA-NXX object on the NPAC SMS.

!;

— 38.0 LNP Service Provider NPA-NXX Effective Time Stamp

serviceProvNPA-NXX-EffectiveTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvNPA-NXX-EffectiveTimeStampBehavior;

    REGISTERED AS {lnp-attribute 38};

serviceProvNPA-NXX-EffectiveTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides a timestamp as to when the NPA-NXX is available for LNP in the service provider networks.

!;

— 39.0 LNP Service Provider NPA-NXX ID

serviceProvNPA-NXX-ID ATTRIBUTE

    WITH ATTRIBUTE SYNTAX NPA-NXX-ID;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvNPA-NXX-ID-Behavior;

    REGISTERED AS {lnp-attribute 39};

serviceProvNPA-NXX-ID-Behavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the serviceProvNPA-NXX object. The NPAC SMS determines the value for this attribute.

!;

— 40.0 LNP Service Provider NPA-NXX Value

serviceProvNPA-NXX-Value ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.NPA-NXX;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvNPA-NXX-ValueBehavior;

    REGISTERED AS {lnp-attribute 40};

serviceProvNPA-NXX-ValueBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify a portable NPA-NXX value.

120

!;

— 41.0 LNP Service Provider Operations Address

serviceProvOperationsAddress ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AddressInformation;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvOperationsAddressBehavior;

    REGISTERED AS {lnp-attribute 41};

serviceProvOperationsAddressBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the service provider operations contact address and contact information.

!;

— 42.0 LNP Service Provider Repair Center Information

serviceProvRepairCenterInfo ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AddressInformation;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvRepairCenterInfoBehavior;

    REGISTERED AS {lnp-attribute 42};

serviceProvRepairCenterInfoBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the repair center information for a service provider.

!;

— 43.0 LNP Service Provider SOA Address

serviceProvSOA-Address ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AddressInformation;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvSOA-AddressBehavior;

    REGISTERED AS {lnp-attribute 43};

serviceProvSOA-AddressBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the service provider SOA address and contact information.

!;

— 44.0 LNP Service Provider System Link Information

serviceProvSysLinkInfo ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.NetworkAddressInformation;

    MATCHES FOR EQUALITY;

    BEHAVIOR serviceProvSysLinkInfoBehavior;

    REGISTERED AS {lnp-attribute 44};

serviceProvSysLinkInfoBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the system link address information for service provider for the SOA to NPAC SMS and NPAC SMS to Local SMS interfaces.

!;

— 45.0 LNP Service Provider Tunables

serviceProvTunables ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.Tunables;

    MATCHES FOR EQUALITY;

    BEHAVIOR serviceProvTunablesBehavior;

    REGISTERED AS {lnp-attribute 45};

121

serviceProvTunablesBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the service provider tunables for the NPAC SMS to Local SMS interface.

!;

— 46.0 LNP Service Provider User Administration Contact Address

serviceProvUserAdminAddress ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AddressInformation;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvUserAdminAddressBehavior;

    REGISTERED AS {lnp-attribute 46};

serviceProvUserAdminAddressBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the service provider user administration contact address and contact information.

!;

— 47.0 LNP Service Provider Web Address

serviceProvWebAddress ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AddressInformation;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR serviceProvWebAddressBehavior;

    REGISTERED AS {lnp-attribute 47};

serviceProvWebAddressBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the service provider Web interface address and contact information.

!;

— 48.0 LNP Subscription Activation Time Stamp

subscriptionActivationTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionActivationTimeStampBehavior;

    REGISTERED AS {lnp-attribute 48};

subscriptionActivationTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the time and date that the subscription version was activated.

!;

— 49.0 LNP Subscription Audit Attribute List

subscriptionAuditAttributeList ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditAttributes;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionAuditAttributeListBehavior;

    REGISTERED AS {lnp-attribute 49};

subscriptionAuditAttributeListBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the list of attributes in a subscription version that are to be audited.

!;

— 50.0 LNP Subscription Audit ID

subscriptionAuditId ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditId;

    MATCHES FOR EQUALITY, ORDERING;

122

    BEHAVIOR subscriptionAuditIdBehavior;

    REGISTERED AS {lnp-attribute 50};

subscriptionAuditIdBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the subscriptionAudit managed objects.  The value for this attribute is specified by the NPAC SMS.

!;

— 51.0 LNP Subscription Audit Name

subscriptionAuditName ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditName;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionAuditNameBehavior;

    REGISTERED AS {lnp-attribute 51};

subscriptionAuditNameBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the English name associated with an audit.

!;

— 52.0 LNP Subscription Audit Number of TNs to be Audited

subscriptionAuditNumberOfTNs ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditNumberOfTNs;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionAuditNumberOfTNsBehavior;

    REGISTERED AS {lnp-attribute 52};

subscriptionAuditNumberOfTNsBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the number of TNs that will be audited based on the audit request criteria.

!;

— 53.0 LNP Subscription Audit Number of TNs having Completed Audit

subscriptionAuditNumberOfTNsComplete ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditNumberOfTNsComplete;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionAuditNumberOfTNsCompleteBehavior;

    REGISTERED AS {lnp-attribute 53};

subscriptionAuditNumberOfTNsCompleteBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the number of TNs that have completed audit.  This attribute is only incremented by the amount specified in subscriptionAuditTN-NotificationNumber. will be audited based on the audit request criteria.

!;

— 54.0 LNP Subscription Audit Requesting Service Provider

subscriptionAuditRequestingSP ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.ServiceProvId;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionAuditRequestingSP-Behavior;

    REGISTERED AS {lnp-attribute 54};

subscriptionAuditRequestingSP-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the service provider who requested the audit.

!;

123

— 55.0 LNP Subscription Audit Service Provider Id Range

subscriptionAuditServiceProvIdRange ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditServiceProvIdRange;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionAuditServiceProvIdRangeBehavior;

    REGISTERED AS {lnp-attribute 55};

subscriptionAuditServiceProvIdRangeBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify a specific service provider or all service providers should be audited in the subscription audit.

!;

— 56.0 LNP Subscription Audit Status

subscriptionAuditStatus ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditStatus;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionAuditStatusBehavior;

    REGISTERED AS {lnp-attribute 56};

subscriptionAuditStatusBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the status of an audit.  Valid values are in-progress, suspended, canceled, and complete.

!;

— 57.0 LNP Subscription Audit TN Activation Range

subscriptionAuditTN-ActivationRange ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditTN-ActivationRange;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionAuditTN-ActivationRangeBehavior;

    REGISTERED AS {lnp-attribute 57};

subscriptionAuditTN-ActivationRangeBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the activation date and time range for which TNs should be audited in the subscription audit.

!;

— 58.0 LNP Subscription Audit TN Notification Number

subscriptionAuditTN-NotificationNumber ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.AuditTN-NotificationNumber;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionAuditTN-NotificationNumberBehavior;

    REGISTERED AS {lnp-attribute 58};

subscriptionAuditTN-NotificationNumberBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the number of TNs that have completed audit before the number of subscriptionAuditNumberOfTNsComplete gets incremented. This controls the frequency of attribute value notifications that gets sent to the audit requester when subscriptionAuditNumberOfTNsComplete completes.

!;

— 59.0 LNP Subscription Audit TN Range

subscriptionAuditTN-Range ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.TN-Range;

    MATCHES FOR EQUALITY;

124

    BEHAVIOR subscriptionAuditTN-RangeBehavior;

    REGISTERED AS {lnp-attribute 59};

subscriptionAuditTN-RangeBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the TN range to be used for the subscription audit.

!;

— 60.0 LNP Subscription Billing Id

subscriptionBillingId ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.BillingId;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionBillingIdBehavior;

    REGISTERED AS {lnp-attribute 60};

subscriptionBillingIdBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the Billing Id for the subscription version.

!;

— 61.0 LNP Subscription Broadcast Time Stamp

subscriptionBroadcastTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionBroadcastTimeStampBehavior;

    REGISTERED AS {lnp-attribute 61};

subscriptionBroadcastTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the time stamp of when the subscription version was broadcast to the service provider Local SMSs.

!;

— 62.0 LNP Subscription Cancellation Time Stamp

subscriptionCancellationTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionCancellationTimeStampBehavior;

    REGISTERED AS {lnp-attribute 62};

subscriptionCancellationTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the cancellation time stamp for the subscription version.  This field is only valid if the subscription version status is cancel.

!;

— 63.0 LNP Subscription Version Class Destination Point Code

subscriptionCLASS-DPC ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.DPC;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionCLASS-DPCBehavior;

    REGISTERED AS {lnp-attribute 63};

subscriptionCLASS-DPCBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription version CLASS Destination Point Code.

!;

125

— 64.0 LNP Subscription Version Class SSN

subscriptionCLASS-SSN ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.SSN;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionCLASS-SSN-Behavior;

    REGISTERED AS {lnp-attribute 64};

subscriptionCLASS-SSN-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription version CLASS SSN.

!;

— 65.0 LNP Subscription CNAM Destination Point Code

subscriptionCNAM-DPC ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.DPC;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionCNAM-DPC-Behavior;

    REGISTERED AS {lnp-attribute 65};

subscriptionCNAM-DPC-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the CNAM Destination Point value for the subscription version.

!;

— 66.0 LNP Subscription CNAM SSN

subscriptionCNAM-SSN ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.SSN;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionCNAM-SSN-Behavior;

    REGISTERED AS {lnp-attribute 66};

subscriptionCNAM-SSN-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the CNAM SSN value for the subscription version.

!;

— 67.0 LNP Subscription Conflict Time Stamp

subscriptionConflictTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionConflictTimeStampBehavior;

    REGISTERED AS {lnp-attribute 67};

subscriptionConflictTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the time stamp of when the subscription version was put into conflict.

!;

— 68.0 LNP Subscription Creation Time Stamp

subscriptionCreationTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionCreationTimeStampBehavior;

    REGISTERED AS {lnp-attribute 68};

subscriptionCreationTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the creation date for a

126

        subscription version.

!;

— 69.0 LNP Subscription Customer Disconnect Date

subscriptionCustomerDisconnectDate ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionCustomerDisconnectDateBehavior;

    REGISTERED AS {lnp-attribute 69};

subscriptionCustomerDisconnectDateBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the time stamp of when the customer was disconnected.

!;

— 70.0 LNP Subscription Disconnect Complete Date

subscriptionDisconnectCompleteTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionDisconnectCompleteTimeStampBehavior;

    REGISTERED AS {lnp-attribute 70};

subscriptionDisconnectCompleteTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the time stamp of when the subscription version was disconnected.

!;

— 71.0 LNP Subscription Download Reason

subscriptionDownloadReason ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.DownloadReason;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionDownloadReasonBehavior;

    REGISTERED AS {lnp-attribute 71};

subscriptionDownloadReasonBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the reason the data was downloaded to the Local SMS from NPAC SMS.  This attribute only has meaning in objects instantiated on the Local SMS and is not audited in subscription versions.

!;

— 72.0 LNP Subscription Effective Release Date

subscriptionEffectiveReleaseDate ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionEffectiveReleaseDateBehavior;

    REGISTERED AS {lnp-attribute 72};

subscriptionEffectiveReleaseDateBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the time stamp of when the subscription version is to be disconnected.  The status of the version must be disconnect pending.

!;

— 73.0 LNP Subscription End User Location Type

subscriptionEndUserLocationType ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.EndUserLocationType;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

127

    BEHAVIOR subscriptionEndUserLocationTypeBehavior;

    REGISTERED AS {lnp-attribute 73};

subscriptionEndUserLocationTypeBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the End User Location Type for the subscription version.  This field is included for future use.

!;

— 74.0 LNP Subscription End User Location Value

subscriptionEndUserLocationValue ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.EndUserLocationValue;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionEndUserLocationValueBehavior;

    REGISTERED AS {lnp-attribute 74};

subscriptionEndUserLocationValueBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the End User Location Value for the subscription version.  This field is included for future use.

!;

— 75.0 LNP Subscription Failed Service Provider List

subscriptionFailed-SP-List ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.Failed-SP-List;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionFailed-SP-ListBehavior;

    REGISTERED AS {lnp-attribute 75};

subscriptionFailed-SP-ListBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the failed service providers after a subscription version broadcast results in a failed or partially-failed subscription version status.

!;

— 76.0 LNP Subscription ISVM Destination Point Code

subscriptionISVM-DPC ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.DPC;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionISVM-DPC-Behavior;

    REGISTERED AS {lnp-attribute 76};

subscriptionISVM-DPC-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the ISVM Destination Point value for the subscription version.

!;

— 77.0 LNP Subscription ISVM SSN

subscriptionISVM-SSN ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.SSN;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionISVM-SSN-Behavior;

    REGISTERED AS {lnp-attribute 77};

subscriptionISVM-SSN-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the ISVM SSN value for the subscription version.

!;

128

— 78.0 LNP Subscription LIDB Destination Point Code

subscriptionLIDB-DPC ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.DPC;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionLIDB-DPC-Behavior;

    REGISTERED AS {lnp-attribute 78};

subscriptionLIDB-DPC-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the LIDB Destination Point value for the subscription version.

!;

— 79.0 LNP Subscription LIDB SSN

subscriptionLIDB-SSN ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.SSN;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionLIDB-SSN-Behavior;

    REGISTERED AS {lnp-attribute 79};

subscriptionLIDB-SSN-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the LIDB SSN value for the subscription version.

!;

— 80.0 LNP Subscription Local Number Portability Type

subscriptionLNPType ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LNPType;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionLNPTypeBehavior;

    REGISTERED AS {lnp-attribute 80};

subscriptionLNPTypeBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the Local Number Portability type for the subscription version.

        This attribute is also used to store the subscription version LNP Type for a new SP create request and a old service provider concurrence request notification in a log record.

!;

— 81.0 LNP Subscription LRN

subscriptionLRN ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.LRN;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionLRNBehavior;

    REGISTERED AS {lnp-attribute 81};

subscriptionLRNBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription LRN for a subscription version.

!;

— 82.0 LNP Subscription Modified Time Stamp

subscriptionModifiedTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionModifiedTimeStampBehavior;

129

    REGISTERED AS {lnp-attribute 82};

subscriptionModifiedTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the last modification date for a subscription version.

!;

— 83.0 LNP Subscription New or Current Service Provider

subscriptionNewCurrentSP ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.ServiceProvId;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionNewCurrentSPBehavior;

    REGISTERED AS {lnp-attribute 83};

subscriptionNewCurrentSPBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription New or Current Service Provider for a subscription version.

        This attribute is also used to store the new service provider for a new SP create request notification in a log record.

!;

— 84.0 LNP Subscription New Service Provider Cancellation Time Stamp

subscriptionNewSP-CancellationTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionNewSP-CancellationTimeStampBehavior;

    REGISTERED AS {lnp-attribute 84};

subscriptionNewSP-CancellationTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription cancellation concurrence time stamp for the subscription in a cancel-pending state.  This value is specified by the new service provider.

!;

— 85.0 LNP Subscription New Service Provider Conflict Resolution Time Stamp

subscriptionNewSP-ConflictResolutionTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionNewSP-ConflictResolutionTimeStampBehavior;

    REGISTERED AS {lnp-attribute 85};

subscriptionNewSP-ConflictResolutionTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription conflict resolution concurrence time stamp for the subscription in a conflict-resolution-pending state.  This value is specified by the new service provider.

!;

— 86.0 LNP Subscription New Service Provider Creation Time Stamp

subscriptionNewSP-CreationTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionNewSP-CreationTimeStampBehavior;

    REGISTERED AS {lnp-attribute 86};

subscriptionNewSP-CreationTimeStampBehavior BEHAVIOR

    DEFINED AS !

130

        This attribute is used to specify the time stamp of when the new service provider creates the cutover for the subscription from the old service provider.  This timestamp is set by the NPAC SMS when the new service provider sends its create request for activation.

        This attribute is also used to store the new service provider creation time stamp for a new SP create request notification in a log record.

!;

— 87.0 LNP Subscription New Service Provider Activation Due Date

subscriptionNewSP-DueDate ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionNewSP-DueDateBehavior;

    REGISTERED AS {lnp-attribute 87};

subscriptionNewSP-DueDateBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription due date for the subscription when they are being ported to a new service provider.  This value is specified by the new service provider.

!;

— 88.0 LNP Subscription Old Service Provider

subscriptionOldSP ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.ServiceProvId;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionOldSPBehavior;

    REGISTERED AS {lnp-attribute 88};

subscriptionOldSPBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription Old Service Provider for a subscription version.

        This attribute is also used to store the old service provider id for an old service provider concurrence request notification in a log record.

!;

— 89.0 LNP Subscription Old Service Provider Authorization

subscriptionOldSP-Authorization ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.ServiceProvAuthorization;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionOldSP-AuthorizationBehavior;

    REGISTERED AS {lnp-attribute 89};

subscriptionOldSP-AuthorizationBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to indicate the old service provider authorization or denial of cutover for the subscription to the new service provider.

        This attribute is also used to store the old service provider authorization for an old service provider concurrence request notification in a log record.

!;

— 90.0 LNP Subscription Old Service Provider Authorization Time Stamp

subscriptionOldSP-AuthorizationTimeStamp ATTRIBUTE

131

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionOldSP-AuthorizationTimeStampBehavior;

    REGISTERED AS {lnp-attribute 90};

subscriptionOldSP-AuthorizationTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the time stamp of when the old service provider authorizes or denies the cutover for the subscription to the new service provider.  This timestamp is set by the NPAC SMS when the old service provider sends its create request or modifies the authorization information for activation.

        This attribute is also used to store the old service provider authorization timestamp for an old service provider concurrence request notification in a log record.

!;

— 91.0 LNP Subscription Old Service Provider Cancellation Time Stamp

subscriptionOldSP-CancellationTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionOldSP-CancellationTimeStampBehavior;

    REGISTERED AS {lnp-attribute 91};

subscriptionOldSP-CancellationTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription cancellation concurrence time stamp for the subscription in a cancellation-pending state.  This value is specified by the old service provider.

!;

— 92.0 LNP Subscription Old Service Provider Conflict Resolution Time Stamp

subscriptionOldSP-ConflictResolutionTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionOldSP-ConflictResolutionTimeStampBehavior;

    REGISTERED AS {lnp-attribute 92};

subscriptionOldSP-ConflictResolutionTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription conflict resolution concurrence time stamp for the subscription in a conflict-resolution-pending state.  This value is specified by the old service provider.

!;

— 93.0 LNP Subscription Old Service Provider Cutover Due Date

subscriptionOldSP-DueDate ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionOldSP-DueDateBehavior;

    REGISTERED AS {lnp-attribute 93};

subscriptionOldSP-DueDateBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription due date for the subscription when they are being ported to a new service provider from an old service provider.  This value is specified by the old service provider.

!;

132

— 94.0 LNP Subscription Old Time Stamp

subscriptionOldTimeStamp ATTRIBUTE

    WITH ATTRIBUTE SYNTAX GeneralTime;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionOldTimeStampBehavior;

    REGISTERED AS {lnp-attribute 94};

subscriptionOldTimeStampBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the old time stamp for the subscription version.  This field is only valid if the subscription version status is old.

!;

— 95.0 LNP Subscription Porting To Original SP Switch

subscriptionPortingToOriginal-SPSwitch ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.SubscriptionPortingToOriginal-SPSwitch;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionPortingToOriginal-SPSwitchBehavior;

    REGISTERED AS {lnp-attribute 95};

subscriptionPortingToOriginal-SPSwitchBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify that the subscription version created is to be to ported back to the original service provider switch.

!;

— 96.0 LNP Subscription Pre-Cancellation Status

subscriptionPreCancellationStatus ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.SubscriptionPreCancellationStatus;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionPreCancellationStatusBehavior;

    REGISTERED AS {lnp-attribute 96};

subscriptionPreCancellationStatusBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the previous status of a cancel-pending subscription version.  Valid values are pending, conflict, sending, active, failed, failed-partial, conflict-resolution-pending, and disconnect-pending.

!;

— 97.0 LNP Subscription Version TN

subscriptionTN ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.PhoneNumber;

    MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;

    BEHAVIOR subscriptionTN-Behavior;

    REGISTERED AS {lnp-attribute 97};

subscriptionTN-Behavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the subscription version TN .

        This attribute is also used to store the subscription version TN for a new SP create request and a old service provider concurrence request notification in a log record.

!;

— 98.0 LNP Subscription Version Attribute Value Change Information

subscriptionVersionAttributeValueChangeInfo ATTRIBUTE

    WITH ATTRIBUTE SYNTAX Attribute-ASN1Module.AttributeValueChangeInfo;

133

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionVersionAttributeValueChangeInfoBehavior;

    REGISTERED AS {lnp-attribute 98};

subscriptionVersionAttributeValueChangeInfoBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to store the attribute value change information for a subscription version attribute value change notification in a log record.

!;

— 99.0 LNP Subscription Version Id

subscriptionVersionId ATTRIBUTE

    WITH ATTRIBUTE SYNTAX SubscriptionVersionId;

    MATCHES FOR EQUALITY, ORDERING;

    BEHAVIOR subscriptionVersionIdBehavior;

    REGISTERED AS {lnp-attribute 99};

subscriptionVersionIdBehavior BEHAVIOR

    DEFINED AS !

        This attribute provides an identifier for the lnpSubscriptions and subscriptionVersion objects.   The NPAC SMS determines the value for this attribute.

        This attribute is also used to store the subscription version Id in notification log records.

!;

— 100.0 LNP Subscription Version Status

subscriptionVersionStatus ATTRIBUTE

    WITH ATTRIBUTE SYNTAX LNP-ASN1.VersionStatus;

    MATCHES FOR EQUALITY;

    BEHAVIOR subscriptionVersionStatusBehavior;

    REGISTERED AS {lnp-attribute 100};

subscriptionVersionStatusBehavior BEHAVIOR

    DEFINED AS !

        This attribute is used to specify the status of the subscription version.  Valid values are pending, conflict, sending, active, failed, failed partial, old, canceled, conflict-resolution-pending, disconnect-pending, and cancel-pending.

!;

7.5.Package Definitions

— 1.0 LNP Download Package

lnpDownloadPkg PACKAGE

    BEHAVIOR lnpDownloadPkgBehavior;

    ACTIONS

         lnpDownload;

    REGISTERED AS {lnp-package 1};

lnpDownloadPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the lnpDownload action.

    !;

— 2.0 LNP Recovery Complete Package

lnpRecoveryCompletePkg PACKAGE

    BEHAVIOR lnpRecoveryCompletePkg;

134

    ACTIONS

         lnpRecoveryComplete;

    REGISTERED AS {lnp-package 2};

lnpRecoveryCompletePkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the lnpRecoveryCompletePkg action.

    !;

— 3.0 LNP Service Provider Billing Address Package

serviceProvBillingAddressPkg PACKAGE

    BEHAVIOR serviceProvBillingAddressPkgBehavior;

    ATTRIBUTES

         serviceProvBillingAddress GET-REPLACE;

    REGISTERED AS {lnp-package 3};

serviceProvBillingAddressPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the serviceProvBillingAddress attribute.

    !;

— 4.0 LNP Service Provider Conflict Address Package

serviceProvConflictAddressPkg PACKAGE

    BEHAVIOR serviceProvConflictAddressPkgBehavior;

    ATTRIBUTES

        serviceProvConflictAddress GET-REPLACE;

    REGISTERED AS {lnp-package 4};

serviceProvConflictAddressPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the serviceProvConflictAddress attribute.

    !;

— 5.0 LNP Service Provider LSMS Address Package

serviceProvLSMS-AddressPkg PACKAGE

    BEHAVIOR serviceProvLSMS-AddressPkgBehavior;

    ATTRIBUTES

        serviceProvLSMS-Address GET-REPLACE;

    REGISTERED AS {lnp-package 5};

serviceProvLSMS-AddressPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the serviceProvLSMS-Address attribute.

    !;

— 6.0 LNP Service Provider Net Address Package

serviceProvNetAddressPkg PACKAGE

    BEHAVIOR serviceProvNet-AddressPkgBehavior;

    ATTRIBUTES

        serviceProvNetAddress GET-REPLACE;

    REGISTERED AS {lnp-package 6};

serviceProvNetAddressPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the serviceProvNetAddress attribute.

    !;

135

— 7.0 LNP Service Provider Operations Address Package

serviceProvOperationsAddressPkg PACKAGE

    BEHAVIOR serviceProvOperationsAddressPkgBehavior;

    ATTRIBUTES

        serviceProvOperationsAddress GET-REPLACE;

    REGISTERED AS {lnp-package 7};

serviceProvOperationsAddressPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the serviceProvOperationsAddress attribute.

    !;

— 8.0 LNP Service Provider Repair Center Info Package

serviceProvRepairCenterInfoPkg PACKAGE

    BEHAVIOR serviceRepairCenterInfoPkgBehavior;

    ATTRIBUTES

        serviceProvRepairCenterInfo GET-REPLACE;

    REGISTERED AS {lnp-package 8};

serviceProvRepairCenterInfoPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the serviceProvRepairCenterInfo attribute.

    !;

— 9.0 LNP Service Provider SOA Address Package

serviceProvSOA-AddressPkg PACKAGE

    BEHAVIOR serviceProvSOA-AddressPkgBehavior;

    ATTRIBUTES

        serviceProvSOA-Address GET-REPLACE;

    REGISTERED AS {lnp-package 9};

serviceProvSOA-AddressPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the serviceProvSOA-Address attribute.

    !;

— 10.0 LNP Service Provider User Administration Address Package

serviceProvUserAdminAddressPkg PACKAGE

    BEHAVIOR serviceProvUserAdminAddressPkgBehavior;

    ATTRIBUTES

        serviceProvUserAdminAddress GET-REPLACE;

    REGISTERED AS {lnp-package 10};

serviceProvUserAdminAddressPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the serviceProvUserAdminAddress attribute.

    !;

— 11.0 LNP Service Provider Web Address Package

serviceProvWebAddressPkg PACKAGE

    BEHAVIOR serviceProvWebAddressPkgBehavior;

    ATTRIBUTES

        serviceProvWebAddress GET-REPLACE;

    REGISTERED AS {lnp-package 11};

serviceProvWebAddressPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the

136

        serviceProvWebAddress attribute.

    !;

— 12.0 LNP Subscription Version Activate Package

subscriptionVersionActivatePkg PACKAGE

    BEHAVIOR subscriptionVersionActivatePkgBehavior;

    ACTIONS

        subscriptionVersionActivate;

    REGISTERED AS {lnp-package 12};

subscriptionVersionActivatePkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionActivate action.

    !;

— 13.0 LNP Subscription Version Attribute Value Change Failed Service

—      Providers List

subscriptionVersionAttributeValueChangeFailed-SP-ListPkg PACKAGE

    BEHAVIOR subscriptionVersionAttributeValueChangeFailed-SP-ListPkg;

    ATTRIBUTES

        subscriptionFailed-SP-List GET;

    REGISTERED AS {lnp-package 13};

subscriptionVersionAttributeValueChangeFailed-SP-ListPkg BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionAttributeValueChangeFailed-SP-List attribute.

    !;

— 14.0 LNP Subscription Version Cancel Package

subscriptionVersionCancelPkg PACKAGE

    BEHAVIOR subscriptionVersionCancelPkgBehavior;

    ACTIONS

        subscriptionVersionCancel;

    REGISTERED AS {lnp-package 14};

subscriptionVersionCancelPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionCancel action.

    !;

— 15.0 LNP Subscription Version Disconnect Package

subscriptionVersionDisconnectPkg PACKAGE

    BEHAVIOR subscriptionVersionDisconnectPkgBehavior;

    ACTIONS

        subscriptionVersionDisconnect;

    REGISTERED AS {lnp-package 15};

subscriptionVersionDisconnectPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionDisconnect action.

    !;

— 16.0 LNP Subscription Version Local SMS Create Package

subscriptionVersionLocalSMS-CreatePkg PACKAGE

    BEHAVIOR subscriptionVersionLocalSMS-CreatePkgBehavior;

    ACTIONS

        subscriptionVersionLocalSMS-Create;

137

    REGISTERED AS {lnp-package 16};

subscriptionVersionLocalSMS-CreatePkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for including the subscriptionVersionLocalSMS-Create action.

    !;

— 17.0 LNP Subscription Version Modify Package

subscriptionVersionModifyPkg PACKAGE

    BEHAVIOR subscriptionVersionModifyPkgBehavior;

    ACTIONS

        subscriptionVersionModify;

    REGISTERED AS {lnp-package 17};

subscriptionVersionModifyPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionModify action.

    !;

— 18.0 LNP New Service Provider Subscription Version Cancellation

— Acknowledge Package

subscriptionVersionNewSP-CancellationPkg PACKAGE

    BEHAVIOR subscriptionVersionNewSP-CancellationPkgBehavior;

    ACTIONS

        subscriptionVersionNewSP-CancellationAcknowledge;

    REGISTERED AS {lnp-package 18};

subscriptionVersionNewSP-CancellationPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionNewSP-CancellationAcknowledge action.

    !;

— 19.0 LNP New Service Provider Subscription Version Conflict Resolution

— Acknowledge Package

subscriptionVersionNewSP-ConflictResolutionPkg PACKAGE

    BEHAVIOR subscriptionVersionNewSP-ConflictResolutionPkgBehavior;

    ACTIONS

        subscriptionVersionNewSP-ConflictResolutionAcknowledge;

    REGISTERED AS {lnp-package 19};

subscriptionVersionNewSP-ConflictResolutionPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionNewSP-ConflictResolutionAcknowledge action.

    !;

— 20.0 LNP New Service Provider Subscription Version Conflict Resolution

— Pending Package

subscriptionVersionNewSP-ConflictResolutionPendingPkg PACKAGE

    BEHAVIOR subscriptionVersionNewSP-ConflictResolutionPendingPkgBehavior;

    ACTIONS

        subscriptionVersionNewSP-ConflictResolutionPending;

    REGISTERED AS {lnp-package 20};

subscriptionVersionNewSP-ConflictResolutionPendingPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionNewSP-ConflictResolutionPending action.

    !;

138

— 21.0 LNP New Service Provider Subscription Version Create Package

subscriptionVersionNewSP-CreatePkg PACKAGE

    BEHAVIOR subscriptionVersionNewSP-CreatePkgBehavior;

    ACTIONS

        subscriptionVersionNewSP-Create;

    REGISTERED AS {lnp-package 21};

subscriptionVersionNewSP-CreatePkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionNewSP-Create action.

    !;

— 22.0 LNP Old Service Provider Subscription Version Cancellation

— Acknowledge Package

subscriptionVersionOldSP-CancellationPkg PACKAGE

    BEHAVIOR subscriptionVersionOldSP-CancellationPkgBehavior;

    ACTIONS

        subscriptionVersionOldSP-CancellationAcknowledge;

    REGISTERED AS {lnp-package 22};

subscriptionVersionOldSP-CancellationPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionOldSP-CancellationAcknowledge action.

    !;

— 23.0 LNP Old Service Provider Subscription Version Conflict Resolution

— Acknowledge Package

subscriptionVersionOldSP-ConflictResolutionPkg PACKAGE

    BEHAVIOR subscriptionVersionOldSP-ConflictResolutionPkgBehavior;

    ACTIONS

        subscriptionVersionOldSP-ConflictResolutionAcknowledge;

    REGISTERED AS {lnp-package 23};

subscriptionVersionOldSP-ConflictResolutionPkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionOldSP-ConflictResolutionAcknowledge action.

    !;

— 24.0 LNP Old Service Provider Subscription Version Create Package

subscriptionVersionOldSP-CreatePkg PACKAGE

    BEHAVIOR subscriptionVersionOldSP-CreatePkgBehavior;

    ACTIONS

        subscriptionVersionOldSP-Create;

    REGISTERED AS {lnp-package 24};

subscriptionVersionOldSP-CreatePkgBehavior BEHAVIOR

    DEFINED AS !

        This package provides for conditionally including the subscriptionVersionOldSP-Create action.

    !;

7.6.Parameter Definitions

— 1.0 Access Control Parameter

accessControlParameter PARAMETER

    CONTEXT EVENT-INFO;

    WITH SYNTAX LNP-ASN1-1.LnpAccessControl;

139

    REGISTERED AS {lnp-parameter 1};

7.7.Action Definitions

— 1.0 LNP Download Action

lnpDownload ACTION

    BEHAVIOR

        lnpDownloadDefinition,

        lnpDownloadBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.DownloadAction;

    WITH REPLY SYNTAX LNP-ASN1-1.DownloadReply;

    REGISTERED AS {lnp-action 1};

lnpDownloadDefinition BEHAVIOR

    DEFINED AS !

        The lnpDownload action is the action that is used by the Local SMS to specify the objects to be downloaded from the NPAC SMS.

    !;

lnpDownloadBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action is issued from an lnpSubscriptions or an lnpNetwork object and all objects to be downloaded are specified in the action request.

        Postconditions: After this action has been executed by the Local SMS specifying which objects to download, the NPAC SMS will determine which objects satisfy the download request and return them in the download action reply.

        Data to be downloaded can be specified by a time range of last modification/creation or by other criteria.  Time range requests will be limited to a tunable range specified in the NPAC SMS.  All data modified/created in the download time period, regardless of the amount of data, will be downloaded.  For download requests not specifying a time range, the amount of data downloaded will be limited to a tunable amount as specified in the NPAC SMS.

        Criteria for a subscription download is a time range or a TN or TN range and an optional local number portability type.

        Criteria for a network data download is a time range, service provider id or all service providers, an npa-nxx range or all npa-nxx data, an LRN range or all LRN data, or all network data.

        If a download requests fails in the NPAC SMS, the failure reason will be returned in the reply.

    !;

— 2.0 LNP Recovery Complete Action

lnpRecoveryComplete ACTION

    BEHAVIOR

        lnpRecoveryCompleteDefinition,

        lnpRecoveryCompleteBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.RecoveryCompleteAction;

    WITH REPLY SYNTAX LNP-ASN1-1.RecoveryCompleteReply;

    REGISTERED AS {lnp-action 2};

lnpRecoveryCompleteDefinition BEHAVIOR

    DEFINED AS !

        The lnpRecoveryComplete action is used by the Local SMS to specify the system has recovered from downtime and the

140

        transactions performed since the association establishment can now be sent from the NPAC SMS.

    !;

lnpRecoveryCompleteBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action is issued from an lnpLocalSMS object that specified the recovery mode flag in the access control as true at association establishment.

        Postconditions: After this action has been executed by the Local SMS specifying recovery is complete, the NPAC SMS will forward those updates which took place for the network and subscription data since the association was established in the action reply.

        If a recovery complete request fails in the NPAC SMS the failure reason will be returned in the reply.

    !;

— 3.0 LNP Subscription Version Activate Action

subscriptionVersionActivate ACTION

    BEHAVIOR

        subscriptionVersionActivateDefinition,

        subscriptionVersionActivateBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.ActivateAction;

    WITH REPLY SYNTAX LNP-ASN1-1.ActivateReply;

    REGISTERED AS {lnp-action 3};

subscriptionVersionActivateDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionActivate action is the action that can be used by the SOA of the new service provider to activate a subscription version id, tn or a range of tns via the SOA to NPAC SMS interface.

    !;

subscriptionVersionActivateBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action is issued from an lnpSubscriptions object specifying the object to be activated by either subscriptionVersionId or the subscriptionTN.

        Postconditions: The service provider has activated the subscription version.  An error will be returned to the service provider if there is no version that can be activated or if the activation fails due to the service provider not being the new service provider for the subscription version.

        Only pending subscription versions can be activated.  Attempts to port subscription that have not been authorized by both service providers will fail.

    !;

— 4.0 LNP Subscription Version Cancel Action

subscriptionVersionCancel ACTION

    BEHAVIOR

        subscriptionVersionCancelDefinition,

        subscriptionVersionCancelBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.CancelAction;

    WITH REPLY SYNTAX LNP-ASN1-1.CancelReply;

    REGISTERED AS {lnp-action 4};

141

subscriptionVersionCancelDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionCancel action is the action that can be used by the SOA to cancel a subscription version via the SOA to NPAC SMS interface.

    !;

subscriptionVersionCancelBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action is issued from an lnpSubscriptions object specifying the object to be canceled by either subscriptionVersionId or the subscriptionTN.

        Postconditions: The service provider has set the version status to cancel-pending in the subscription version.  An error will be returned to the service provider if there is no version that can be canceled (i.e. pending, conflict, conflict-resolution-pending or disconnect-pending) or if the cancellation fails due to authorization of the service provider.

    !;

— 5.0 LNP Subscription Version Disconnect Action

subscriptionVersionDisconnect ACTION

    BEHAVIOR

        subscriptionVersionDisconnectDefinition,

        subscriptionVersionDisconnectBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.DisconnectAction;

    WITH REPLY SYNTAX LNP-ASN1-1.DisconnectReply;

    REGISTERED AS {lnp-action 5};

subscriptionVersionDisconnectDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionDisconnect action is the action that is used by the SOA to disconnect a subscription version via the SOA to NPAC SMS interface.

    !;

subscriptionVersionDisconnectBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action is issued from an lnpSubscriptions object and specifies the object to be disconnected by either stating the subscriptionVersionId, the subscriptionTN or a range of TNs.  In addition, the customer’s disconnect date is specified. An optional effective release date can be specified for a time deferred disconnect.

        Postconditions: The new service provider can disconnect an active subscription version.  An error will be returned to the service provider if there is no active version. If there is a pending version and the old service provider has NOT authorized the pending subscription version, the disconnect would take place and the pending subscription version would go into conflict.  If the old service provider has authorized the pending subscription version, the NPAC SMS will fail the action back to the service provider.

        If the version is active, no outstanding versions exist, and the time stamp for disconnect has not been reached, the subscription version will be modified with a version status of disconnect-pending and the subscriptionEffectiveReleaseDate set to the effective release date specified in the action.

        If the version is active, there are no outstanding versions, and the time stamp for effective release has not been specified, the subscription version will be updated with a version status of

142

        sending.

        When the new subscription version status is set to sending either immediately or at the time the date and time specified in the subscriptionEffectiveReleaseDate, the broadcast time stamp is set to the current time when the disconnect version sending starts to the Local SMSs via the NPAC SMS to Local SMS interface.

        Before the broadcast of deletes begins, the subscriptionVersionDonorSP-CustomerDisconnectDate notification is sent to the donor SOA informing the service provider of the actual customer disconnect date.

        If the delete requests are successful for all Local SMSs, the current active version will have its version status marked as old and the subscriptionDisconnectCompleteTimeStamp is set to the current system date and time.

        If a delete request fails for the disconnect subscription version after the retry periods have expired, the version status will be set to failed or partially failed based on if the create failed in all or some of the Local SMSs respectively.  The current active version will remain active and an error will be returned for the action.

    !;

— 6.0 LNP Subscription Version Local SMS Create Action

subscriptionVersionLocalSMS-Create ACTION

    BEHAVIOR

        subscriptionVersionLocalSMS-CreateDefinition,

        subscriptionVersionLocalSMS-CreateBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.LocalSMS-CreateAction;

    WITH REPLY SYNTAX LNP-ASN1-1.LocalSMS-CreateReply;

    REGISTERED AS {lnp-action 6};

subscriptionVersionLocalSMS-CreateDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionLocalSMS-Create action is the action that can be used by the NPAC SMS to create multiple subscription versions via the Local SMS to NPAC SMS interface.

    !;

subscriptionVersionLocalSMS-CreateBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action is issued from an lnpSubscriptions object specifying the object(s) to be created by the subscriptionVersionId and the subscriptionTN.  All attribute values required for creation will be supplied.

        Postconditions: A successful reply indicates the Local SMS can decipher the subscription version create action. An error will be returned to the NPAC SMS if the Local SMS cannot recognize the action data.

        The Local SMS will attempt to create all the specified subscription versions. It will return the subscriptionVersionActionResults notification to the NPAC SMS informing it of the success or failure of the creation attempts.

    !;

— 7.0 LNP Subscription Version Modify Action

subscriptionVersionModify ACTION

    BEHAVIOR

        subscriptionVersionModifyDefinition,

143

        subscriptionVersionModifyBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.ModifyAction;

    WITH REPLY SYNTAX LNP-ASN1-1.ModifyReply;

    REGISTERED AS {lnp-action 7};

subscriptionVersionModifyDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionModify action is the action that can be used by the SOA to modify a subscription version via the SOA to NPAC SMS interface.

    !;

subscriptionVersionModifyBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action is issued from an lnpSubscriptions object specifying the object to be modified by either the subscriptionVersionId, the subscriptionTN or a range of TNs and optionally the status of the subscription version.  All attribute values to be modified shall also be specified.

        Postconditions: The service provider has modified the subscription version.  An error will be returned to the service provider if there is no version that is modifiable or if the modification fails due to authorization of the service provider or data validation.

        Service Providers can modify attributes associated with active, pending, cancel-pending, conflict-resolution-pending, disconnect-pending or conflict subscription versions.

        Old service providers can only modify the following attributes for pending, cancel-pending, conflict-resolution-pending, or conflict subscription versions:

        subscriptionOldSP-DueDate

        subscriptionOldSP-Authorization

        New service providers can only modify the following attributes for pending, cancel-pending, conflict-resolution-pending or conflict subscription versions:

        subscriptionLRN

        subscriptionNewSP-DueDate

        subscriptionCLASS-DPC

        subscriptionCLASS-SSN

        subscriptionLIDB-DPC

        subscriptionLIDB-SSN

        subscriptionCNAM-DPC

        subscriptionCNAM-SSN

        subscriptionISVM-DPC

        subscriptionISVM-SSN

        subscriptionEndUserLocationValue

        subscriptionEndUserLocationType

        subscriptionBillingId

        Validation will be done for both old and new service provider data that is specified for pending, cancel-pending, conflict-resolution-pending or conflict subscription versions. If validation fails no changes will be made and an error will be returned. If the version passes validation, the version status will be set to pending if the subscriptionVersionStatus was not the attribute modified.  A new service provider can modify the subscriptionVersionStatus for a pending or disconnect-pending subscription version to cancel-pending.  An error message will be returned to the service provider if the status is not pending when they attempt to change the version status to cancel-pending.

144

        New service providers can only modify the following attributes for active subscription versions:

        subscriptionLRN

        subscriptionCLASS-DPC

        subscriptionCLASS-SSN

        subscriptionLIDB-DPC

        subscriptionLIDB-SSN

        subscriptionCNAM-DPC

        subscriptionCNAM-SSN

        subscriptionISVM-DPC

        subscriptionISVM-SSN

        subscriptionEndUserLocationValue

        subscriptionEndUserLocationType

        subscriptionBillingId

        If the data specified passes validation, the modified version is immediately activated.  The modified subscription version will have a status of sending and broadcasts will begin.  If validation fails, no changes will be made and an error will be returned in the action reply.

    !;

— 8.0 LNP New Service Provider Cancellation Acknowledge Request

subscriptionVersionNewSP-CancellationAcknowledge ACTION

    BEHAVIOR

        subscriptionVersionNewSP-CancellationAcknowledgeDefinition,

        subscriptionVersionNewSP-CancellationAcknowledgeBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.CancellationAcknowledgeAction;

    WITH REPLY SYNTAX LNP-ASN1-1.CancellationAcknowledgeReply;

    REGISTERED AS {lnp-action 8};

subscriptionVersionNewSP-CancellationAcknowledgeDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionNewSP-CancellationAcknowledge action is the action that is used the on NPAC SMS via the SOA to NPAC SMS interface by the new service provider to acknowledge cancellation of a subscriptionVersionNPAC with a status of cancel-pending.

    !;

subscriptionVersionNewSP-CancellationAcknowledgeBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action was issued from an lnpSubscriptions object specifying the object to be acknowledged by either the subscriptionVersionId or the subscriptionTN.

        Postconditions: The service provider has acknowledged the subscription version.  An error will be returned to the service provider if no version exists that can have the cancellation acknowledged or if the acknowledgement fails due to the service provider not being authorized to perform the action.

        The subscriptionNewSP-CancellationTimeStamp will be updated to the current time if the action is successful and the version status will be changed to cancel if the old service provider has previously acknowledged the cancel.

    !;

— 9.0 LNP New Service Provider Conflict Resolution Acknowledge Request

subscriptionVersionNewSP-ConflictResolutionAcknowledge ACTION

    BEHAVIOR

145

        subscriptionVersionNewSP-ConflictResolutionAcknowledgeDefinition,

        subscriptionVersionNewSP-ConflictResolutionAcknowledgeBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.ConflictResolutionAcknowledgeAction;

    WITH REPLY SYNTAX LNP-ASN1-1.ConflictResolutionAcknowledgeReply;

    REGISTERED AS {lnp-action 9};

subscriptionVersionNewSP-ConflictResolutionAcknowledgeDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionNewSP-ConflictResolutionAcknowledge action is the action that is used the on NPAC SMS via the SOA to NPAC SMS interface by the new service provider to acknowledge conflict resolution of a subscriptionVersionNPAC with a status of conflict-resolution-pending.

    !;

subscriptionVersionNewSP-ConflictResolutionAcknowledgeBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action was issued from an lnpSubscriptions object specifying the object to be acknowledged by either the subscriptionVersionId or the subscriptionTN.

        Postconditions: The service provider has acknowledged the subscription version.  An error will be returned to the service provider if there is no version that can have conflict acknowledged or if the acknowledgement fails due to the service provider not being authorized to perform the action.

        The subscriptionNewSP-ConflictResolutionTimeStamp will be updated to the current time if the action is successful and the version status will be changed to pending if the old service provider has previously acknowledged the conflict.

    !;

— 10.0 LNP New Service Provider Conflict Pending

subscriptionVersionNewSP-ConflictResolutionPending ACTION

    BEHAVIOR

        subscriptionVersionNewSP-ConflictResolutionPendingDefinition,

        subscriptionVersionNewSP-ConflictResolutionPendingBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.ConflictResolutionPendingAction;

    WITH REPLY SYNTAX LNP-ASN1-1.ConflictResolutionPendingReply;

    REGISTERED AS {lnp-action 10};

subscriptionVersionNewSP-ConflictResolutionPendingDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionNewSP-ConflictResolutionPending action is the action that is used the on NPAC SMS via the SOA to NPAC SMS interface by the new service provider to set the subscription version status from conflict to conflict-resolution-pending.

    !;

subscriptionVersionNewSP-ConflictResolutionAcknowledgeBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action was issued from an lnpSubscriptions object specifying the object to be updated by either the subscriptionVersionId or the subscriptionTN.

        Postconditions: The NPAC SMS has acknowledged the subscription version.  An error will be returned to the service provider if there is no version that can have conflict resolution pending status set or if the acknowledgement fails due to the service provider not being the new service provider.

        The subscriptionNewSP-ConflictResolutionTimeStamp will be updated to the current time if the action is successful and the

146

        version status will be changed from conflict to conflict-resolution-pending.

    !;

— 11.0 LNP New Service Provider Subscription Version Create

subscriptionVersionNewSP-Create ACTION

    BEHAVIOR

        subscriptionVersionNewSP-CreateDefinition,

        subscriptionVersionSPNewSP-CreateBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.NewSP-CreateAction;

    WITH REPLY SYNTAX LNP-ASN1-1.NewSP-CreateReply;

    REGISTERED AS {lnp-action 11};

subscriptionVersionNewSP-CreateDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionNewSP-Create action is the action that is used the on NPAC SMS via the SOA to NPAC SMS interface by the new service provider to create a new subscriptionVersionNPAC.

    !;

subscriptionVersionNewSP-CreateBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action is issued from an lnpSubscriptions object.  Creates can only be performed provided there is only one currently active subscription or an action failure will be returned.

        The new service provider must specify valid values for the following attributes:

        subscriptionTN or a valid subscriptionVersionTN-Range

        subscriptionLRN

        subscriptionNewCurrentSP

        subscriptionOldSP

        subscriptionNewSP-DueDate

        subscriptionCLASS-DPC

        subscriptionCLASS-SSN

        subscriptionLIDB-DPC

        subscriptionLIDB-SSN

        subscriptionCNAM-DPC

        subscriptionCNAM-SSN

        subscriptionISVM-DPC

        subscriptionISVM-SSN

        subscriptionLNPType

        subscriptionPortingToOriginal-SPSwitch

        The new service provider may specify valid values for the following attributes:

        subscriptionEndUserLocationValue

        subscriptionEndUserLocationType

        subscriptionBillingId

        subscriptionPortingToOriginal-SPSwitch can only be specified as TRUE for a TN that is currently ported and is being ported back to the original service provider.   If the value of subscriptionPortingToOriginal-SPSwitch is TRUE, the LRN and GTT data should be specified as NULL.  If the variable is TRUE, when the activate occurs for the subscription version, the Local SMS’s will receive a request to delete the old subscription version routing data in their networks. They will not receive any new network routing data for the subscription. Concurrence from the old service provider is required.

        If the port of the subscription version is an intra-service provider port, the new service provider can use the

147

        subscriptionVersionNewSP-Create action specifying the old service provider equal to the new service provider.  In this case, the old service provider create action is not required.

        Postconditions: After this action has been executed, if the data specified passes validation, a pending subscription version will exist in the NPAC SMS.  These validations are done as follows:

        subscriptionTN or range of TNs are valid in a range open for porting by the old service provider.

        subscriptionLNPType is specified to be “LSPP” or “LISP”.

        subscriptionNewSP-DueDate is a future date.

        Old and New SP are valid service providers in the NPAC SMS.

        LRN data is associated with the New Service Provider.

        If a pre-existing version exists, validation will be done to insure that the new service provider previously specified is the same as the executor of the action.

        If the validations succeed and the subscription version does not exist, a new subscription version will be created with a status of pending.

        If the validations succeed and the subscription version already exists, the new service provider data will be applied to the subscription version.

        If the validations fail, a new subscription version will not be created if one does not exist.  If one already existed, it will be retained.

        The action success or failure and reasons for failure will be returned in the action reply.

    !;

— 12.0 LNP New Service Provider Cancellation Acknowledge Request

subscriptionVersionOldSP-CancellationAcknowledge ACTION

    BEHAVIOR

        subscriptionVersionOldSP-CancellationAcknowledgeDefinition,

        subscriptionVersionOldSP-CancellationAcknowledgeBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.CancellationAcknowledgeAction;

    WITH REPLY SYNTAX LNP-ASN1-1.CancellationAcknowledgeReply;

    REGISTERED AS {lnp-action 12};

subscriptionVersionOldSP-CancellationAcknowledgeDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionOldSP-CancellationAcknowledge action is the action that is used on the NPAC SMS via the SOA to NPAC SMS interface by the old service provider to acknowledge cancellation of a subscriptionVersionNPAC with a status of cancel-pending.

    !;

subscriptionVersionOldSP-CancellationAcknowledgeBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action was issued from an lnpSubscriptions object specifying the object to be acknowledged by either the subscriptionVersionId or the subscriptionTN.

        Postconditions: The service provider has acknowledged the subscription version.  An error will be returned to the service

148

        provider if there is no version that can have cancellation acknowledged or if the acknowledgement fails due to the service provider not being authorized to perform the action.

        The subscriptionOldSP-CancellationTimeStamp will be updated to the current time if the action is successful and the version status will be changed to cancel if the new service provider has previously acknowledged the cancel.

    !;

— 13.0 LNP Old Service Provider Conflict Resolution Acknowledge Request

subscriptionVersionOldSP-ConflictResolutionAcknowledge ACTION

    BEHAVIOR

        subscriptionVersionOldSP-ConflictResolutionAcknowledgeDefinition,

        subscriptionVersionOldSP-ConflictResolutionAcknowledgeBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.ConflictResolutionAcknowledgeAction;

    WITH REPLY SYNTAX LNP-ASN1-1.ConflictResolutionAcknowledgeReply;

    REGISTERED AS {lnp-action 13};

subscriptionVersionOldSP-ConflictResolutionAcknowledgeDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionOldSP-ConflictResolutionAcknowledge action is the action that is used the on NPAC SMS via the SOA to NPAC SMS interface by the old service provider to acknowledge conflict resolution of a subscriptionVersionNPAC with a status of conflict-resolution-pending.

    !;

subscriptionVersionOldSP-ConflictResolutionAcknowledgeBehavior BEHAVIOR

    DEFINED AS !

        Preconditions: This action was issued from an lnpSubscriptions object specifying the object to be acknowledged by either the subscriptionVersionId or the subscriptionTN.

        Postconditions: The service provider has acknowledged the subscription version.  An error will be returned to the service provider if there is no version that can have conflict acknowledged or if the acknowledgement fails due to the service provider not being authorized to perform the action.

        The subscriptionOldSP-ConflictResolutionTimeStamp will be updated to the current time if the action is successful and the version status will be changed to pending if the new service provider has previously acknowledged the conflict.

    !;

— 14.0 LNP Old Service Provider Subscription Version Create

subscriptionVersionOldSP-Create ACTION

    BEHAVIOR

        subscriptionVersionOldSP-CreateDefinition,

        subscriptionVersionOldSP-CreateBehavior;

    MODE CONFIRMED;

    WITH INFORMATION SYNTAX LNP-ASN1-1.OldSP-CreateAction;

    WITH REPLY SYNTAX LNP-ASN1-1.OldSP-CreateReply;

    REGISTERED AS {lnp-action 14};

subscriptionVersionOldSP-CreateDefinition BEHAVIOR

    DEFINED AS !

        The subscriptionVersionOldSP-Create action is the action that is used the on NPAC SMS via the SOA to NPAC SMS interface by the old service provider to create a new subscriptionVersionNPAC.

    !;

subscriptionVersionOldSP-CreateBehavior BEHAVIOR

149

    DEFINED AS !

        Preconditions: This action was issued from an lnpSubscriptions object.  Creates can be performed provided there is only one currently active subscription or action failure will be returned.

        The old service provider must specify valid values for the following attributes:

        subscriptionTN or a valid subscriptionVersionTN-Range

        subscriptionNewCurrentSP

        subscriptionOldSP

        subscriptionOldSP-DueDate

        subscriptionOldSP-Authorization

        subscriptionLNPType

        Postconditions: After this action has been executed if the data specified passes validation, a pending subscription version will exist in the NPAC SMS.  These validations are done as follows:

        subscriptionTN or range of TNs are valid in a range open for porting by the old service provider.

        subscriptionLNPType is specified as “LSPP” or “LISP”.

        subscriptionOldSP-DueDate is a future date.

        Old and New SP are valid service providers in the NPAC SMS and the new service provider is not equal to the old service provider.

        If a pre-existing version exists, validation will be done to insure that the new service provider previously specified is the same as the executor of the action.

        If the validations succeed and the subscription version does not exist, a new subscription version will be created with a status of pending.

        If the validations succeed and the subscription version already exists, the old service provider data will be applied to the existing subscription version.

        If the validations fail, a new subscription version will not be created if one does not exist.  If one already existed it will be retained and an error returned.

        The action success or failure and reasons for failure will be returned in the action reply.

    !;

7.8.Notification Definitions

— 1.0 LNP NPAC SMS Operational Information Notification

lnpNPAC-SMS-Operational-Information NOTIFICATION

    BEHAVIOR  lnpNPAC-SMS-Operational-InformationBehavior;

    WITH INFORMATION SYNTAX LNP-ASN1-1.NPAC-SMS-Operational-Information

    AND ATTRIBUTE IDS

        down-time downTime,

        npac-contact-number npacContactNumber,

        additional-down-time-information additionalDownTimeInformation,

        access-control accessControl;

    REGISTERED AS {lnp-notification 1};

lnpNPAC-SMS-Operational-InformationBehavior BEHAVIOR

    DEFINED AS !

        This notification contains information about the NPAC SMS’s

150

        scheduled down time.  This notification contains the start and stop date and time for the planned down time. It is sent to both the SOA and Local SMS systems.

    !;

— 2.0 LNP Subscription Audit Local SMS Discrepancy Report

subscriptionAudit-DiscrepancyRpt NOTIFICATION

    BEHAVIOR  subscriptionAudit-DiscrepancyRptBehavior;

    WITH INFORMATION SYNTAX LNP-ASN1-1.AuditDiscrepancyRpt

    AND ATTRIBUTE IDS

        tn auditDiscrepancyTn,

        version-id auditDiscrepancyVersionId,

        lsms-service-provider-id auditDiscrepancyLSMS-SP-Id,

        failure-reason auditDiscrepancyFailureReason,

        access-control accessControl;

    REGISTERED AS {lnp-notification 2};

subscriptionAudit-DiscrepancyRptBehavior BEHAVIOR

    DEFINED AS !

        This notification contains a report on a discrepancy found during an audit.  The discrepancy contains the subscription TN and Version ID for which the discrepancy was found and the error.  Valid errors are:

        fields mismatched between NPAC SMS and Local SMS

        record missing in Local SMS and associated Service Provider Id

        record missing in NPAC SMS

        If field mismatches are found then the attribute(s) for which the mismatch and the Local SMS value(s) and the NPAC SMS value(s) will be returned as well as the Service Provider Id associated with the Local SMS.

        When audit discrepancy notifications are sent to the NPAC SMS by the Local SMS create or modification requests to correct the discrepancy will be done by the NPAC SMS.

    !;

— 3.0 LNP Subscription Audit Results

subscriptionAuditResults NOTIFICATION

    BEHAVIOR  subscriptionAuditResultsBehavior;

    WITH INFORMATION SYNTAX LNP-ASN1-1.AuditResults

    AND ATTRIBUTE IDS

        status auditResultStatus,

        audit-response-level auditResponseLevel,

        failed-service-provider-list auditResultFailed-SP-List,

        number-of-discrepancies auditResultNumberDiscrepancies,

        time-of-completion auditResultCompletionTime,

        access-control accessControl;

    REGISTERED AS {lnp-notification 3};

subscriptionAuditResultsBehavior BEHAVIOR

    DEFINED AS !

        This notification contains the results of an audit.  It contains the name of the audit, the number of discrepancies found during the audit, the success or failure of the audit, and the time of audit completion or failure.

    !;

— 4.0 LNP Subscription Version Cancellation Resolution Request

— Notification

subscriptionVersionCancellationAcknowledgeRequest NOTIFICATION

    BEHAVIOR  subscriptionVersionCancellationAcknowledgeBehavior;

    WITH INFORMATION SYNTAX

151

        LNP-ASN1-1.VersionCancellationAcknowledgeRequest

    AND ATTRIBUTE IDS

        tn subscriptionTN,

        version-id subscriptionVersionId,

        access-control accessControl;

    REGISTERED AS {lnp-notification 4};

subscriptionVersionCancellationAcknowledgeBehavior BEHAVIOR

    DEFINED AS !

        This notification requests that a service provider send a cancellation acknowledgement for a subscription version.  The TN and the version id are sent.

    !;

— 5.0 LNP Subscription Version Conflict Resolution Acknowledge Request

— Notification

subscriptionVersionConflictResolutionAcknowledgeRequest NOTIFICATION

    BEHAVIOR  subscriptionVersionConflictResolutionAcknowledgeBehavior;

    WITH INFORMATION SYNTAX

        LNP-ASN1-1.VersionConflictResolutionAcknowledgeRequest

    AND ATTRIBUTE IDS

        tn subscriptionTN,

        version-id subscriptionVersionId,

        access-control accessControl;

    REGISTERED AS {lnp-notification 5};

subscriptionVersionConflictResolutionAcknowledgeBehavior BEHAVIOR

    DEFINED AS !

        This notification requests that a service provider send a conflict resolution acknowledgement for a subscription version. The TN and the version id are sent.

    !;

— 6.0 LNP Subscription Version Donor Service Provider Customer Disconnect Date

—       Notification

subscriptionVersionDonorSP-CustomerDisconnectDate NOTIFICATION

    BEHAVIOR  subscriptionVersionDonorSP-CustomerDisconnectDateBehavior;

    WITH INFORMATION SYNTAX LNP-ASN1-1.VersionCustomerDisconnectDate

    AND ATTRIBUTE IDS

        tn subscriptionTN,

        version-id subscriptionVersionId,

        service-prov-customer-disconnect-date

            subscriptionCustomerDisconnectDate,

        service-prov-effective-release-date

            subscriptionEffectiveReleaseDate,

        access-control accessControl;

    REGISTERED AS {lnp-notification 6};

subscriptionVersionDonorSP-CustomerDisconnectDateBehavior BEHAVIOR

    DEFINED AS !

        This notification informs the donor service provider SOA that a subscription version is being disconnected.

        The TN, the version id, customer disconnect date and effective release date values are sent.

    !;

— 7.0 LNP Subscription Version Local SMS Action Results

subscriptionVersionLocalSMS-ActionResults NOTIFICATION

    BEHAVIOR  subscriptionVersionLocalSMS-ActionResultsBehavior;

    WITH INFORMATION SYNTAX LNP-ASN1-1.LocalSMS-ActionResults

    AND ATTRIBUTE IDS

        action actionId,

        status actionResultsStatus,

152

        failed-tn-list failedTN-List,

        time-of-completion resultsCompletionTime,

        access-control accessControl;

    REGISTERED AS {lnp-notification 7};

subscriptionVersionLocalSMS-ActionResultsBehavior BEHAVIOR

    DEFINED AS !

        This notification contains the reuslts of a subscriptionVersionLocalSMS-Create action once all the create requests have been attempted. It contains the id of the action, the success or failure of the action, the completion time and an optional list of failed subscriptionTNs and error codes.

    !;

— 8.0 LNP Subscription Version New NPA-NXX Notification

subscriptionVersionNewNPA-NXX NOTIFICATION

    BEHAVIOR  subscriptionVersionNewNPA-NXXBehavior;

    WITH INFORMATION SYNTAX

        LNP-ASN1-1.VersionNewNPA-NXX

    AND ATTRIBUTE IDS

        service-prov-npa-nxx-id serviceProvNPA-NXX-ID,

        service-prov-npa-nxx-value serviceProvNPA-NXX-Value,

        access-control accessControl;

    REGISTERED AS {lnp-notification 8};

subscriptionVersionNewNPA-NXXBehavior BEHAVIOR

    DEFINED AS !

        This notification informs the Local SMS of a pending subscription version involving a new NPA-NXX.  The service-prov-npa-nxx-id and service-prov-npa-nxx-value are sent.

    !;

— 9.0 LNP Subscription Version New SP Create Request Notification

subscriptionVersionNewSP-CreateRequest NOTIFICATION

    BEHAVIOR  subscriptionVersionNewSP-CreateRequestBehavior;

    WITH INFORMATION SYNTAX LNP-ASN1-1.VersionNewSP-CreateRequest

    AND ATTRIBUTE IDS

        tn subscriptionTN,

        version-id subscriptionVersionId,

        service-provider-id subscriptionOldSP,

        service-provider-due-date subscriptionOldSP-DueDate,

        service-provider-authorization subscriptionOldSP-Authorization,

        service-provider-authorization-time-stamp

            subscriptionOldSP-AuthorizationTimeStamp,

        access-control accessControl;

    REGISTERED AS {lnp-notification 9};

subscriptionVersionNewSP-CreateRequestBehavior BEHAVIOR

    DEFINED AS !

        This notification requests that a new service provider send a create request for a subscription version for which concurrence for porting the number has not been received. The TN, the version id and the old service provider id, authorization flag and authorization timestamp values are sent.

    !;

— 10.0 LNP Subscription Version Old SP Concurrence Request Notification

subscriptionVersionOldSP-ConcurrenceRequest NOTIFICATION

    BEHAVIOR  subscriptionVersionOldSP-ConcurrenceRequestBehavior;

    WITH INFORMATION SYNTAX LNP-ASN1-1.VersionOldSP-ConcurrenceRequest

    AND ATTRIBUTE IDS

        tn subscriptionTN,

153

        version-id subscriptionVersionId,

        service-provider-id subscriptionNewCurrentSP,

        service-provider-due-date subscriptionNewSP-DueDate,

        service-provider-creation-time-stamp

            subscriptionNewSP-CreationTimeStamp,

        access-control accessControl;

    REGISTERED AS {lnp-notification 10};

subscriptionVersionOldSP-ConcurrenceRequestBehavior BEHAVIOR

    DEFINED AS !

        This notification requests that a old service provider send a create request for a subscription version for which concurrence for porting the number has not been received. The TN, the version id, and the new service provider id, authorization flag and creation timestamp values are sent.

    !;

— 11.0 LNP Subscription Version Status Attribute Value Change Notification

subscriptionVersionStatusAttributeValueChange NOTIFICATION

    BEHAVIOR  subscriptionVersionStatusAttributeValueChangeBehavior;

    WITH INFORMATION SYNTAX  LNP-ASN1-1.VersionStatusAttributeValueChange

    AND ATTRIBUTE IDS

        value-change-info subscriptionVersionAttributeValueChangeInfo,

        failed-service-providers subscriptionFailed-SP-List,

        access-control accessControl;

    REGISTERED AS {lnp-notification 11};

subscriptionVersionStatusAttributeValueChangeBehavior BEHAVIOR

    DEFINED  AS !

        This notification type is used to report changes to the subscriptionVersionStatus field.  It is identical to an attribute value change notification as defined in M.3100 except for the addition of the list of failed service providers in cases where the version status is active, failed or partially failed.

    !;

154

8.General ASN.1 Definitions

8.1.Overview

The ASN.1 definitions provided below support the GDMO definitions in Chapter 5.  Included below are the ASN.1 object identifier definitions and the syntax definitions for the interface attributes, notifications, and actions.

8.2.LNP ASN.1 Object Identifier Definitions

—#include           “smi.asn”

LNP-OIDS

  {joint-iso-ccitt(2) country(16) us(840) organization(1)

   lnp-net(4) oids(0)}

DEFINITIONS ::=

BEGIN

— EXPORTS all definitions

lnp-net OBJECT IDENTIFIER ::=

  {joint-iso-ccitt(2) country(16) us(840) organization(1)

   lnp-net(4) }

— LNP categories of interface information objects

lnp-attribute OBJECT IDENTIFIER ::= {lnp-net attribute(1) }

lnp-objectClass OBJECT IDENTIFIER ::= {lnp-net objectClass(2) }

lnp-nameBinding OBJECT IDENTIFIER ::= {lnp-net nameBinding(3) }

lnp-notification OBJECT IDENTIFIER ::= {lnp-net notification(4) }

lnp-action OBJECT IDENTIFIER ::= {lnp-net action(5) }

lnp-package OBJECT IDENTIFIER ::= {lnp-net package(6) }

lnp-parameter OBJECT IDENTIFIER ::= {lnp-net parameter(7) }

END — LNP-OIDS

8.3.LNP General ASN.1 Definitions

LNP-ASN1

  {joint-iso-ccitt(2) country(16) us(840) organization(1)

   lnp-net(4) asn1(1)}

DEFINITIONS IMPLICIT TAGS ::= BEGIN

— EXPORTS everything

155

IMPORTS

— CMIP

 ObjectClass, ObjectInstance

        FROM CMIP-1 {joint-iso-ccitt ms(9) cmip(1) modules(0) protocol(3)}

— DMI

 AttributeValueChangeInfo

        FROM Notification-ASN1Module {joint-iso-ccitt ms(9) smi(3) part2(2)

             asn1Module(2) 2};

ActionResultsStatus ::= ResultsStatus

ActivateAction ::= CHOICE {

        subscription-version-action [0] SubscriptionVersionAction,

        subscription-version-tn-range [1] TN-Range

    }

ActivateReply ::= SubscriptionVersionActionReply

AddressInformation ::= SEQUENCE {

    line1 GraphicString40,

    line2  GraphicString40,

    city   GraphicString20,

    state  GraphicString(SIZE(2)),

    zip  GraphicString40,

    province GraphicString(SIZE(2)),

    country GraphicString20,

    contactPhone  PhoneNumber,

    contact  GraphicString40,

    contactFax  PhoneNumber,

    contactPager  PhoneNumber,

    contactPagerPIN  DigitString,

    contactE-mail  GraphicString60

}

AssociationFunction ::= SEQUENCE {

    soaUnits SoaUnits,

    lsmsUnits LSMSUnits

}

AuditAttributes ::= CHOICE {

    specific-audit [0] SEQUENCE {

        lidb-data BOOLEAN,

        class-data BOOLEAN,

        cnam-data BOOLEAN,

        isvm-data BOOLEAN,

        lrn-data BOOLEAN

    },

    all-data [1] NULL

}

AuditDiscrepancyRpt ::= SEQUENCE {

    tn PhoneNumber,

    version-id SubscriptionVersionId,

    lsms-service-prov-id ServiceProvId,

    failure-reason AuditFailureData,

    access-control LnpAccessControl

}

AuditFailureData ::= CHOICE {

    tn-version-missing-NPAC [0] NULL,

    tn-version-missing-LSMS [1] NULL,

    mismatch-data [2] MismatchAttributes

}

156

AuditId ::= LnpKey

AuditName ::= GraphicString40

AuditNumberOfTNs ::= INTEGER

AuditNumberOfTNsComplete ::= INTEGER

AuditResponseLevel ::= ENUMERATED {

    audit-to-scp (0),

    audit-to-lsms (1)

}

AuditResults ::= SEQUENCE {

    status [0] AuditResultStatus,

    audit-response-level [1] AuditResponseLevel,

    failed-service-prov-list [2] Failed-SP-List OPTIONAL,

    number-of-discrepancies [3] INTEGER,

    time-of-completion [4] GeneralizedTime,

    access-control [5] LnpAccessControl

}

AuditResultStatus ::= ENUMERATED {

    success (0),

    failed-due-to-discrepancies (1),

    failed-on-local-sms (2),

    no-audit-performed (3)

}

AuditServiceProvIdRange ::= CHOICE {

    allServiceProvs [0] NULL,

    serviceProv [1] ServiceProvName

}

AuditStatus ::= ENUMERATED {

    in-progress (0),

    suspended (1),

    complete (2)

}

AuditTN-ActivationRange ::= TimeRange

AuditTN-NotificationNumber ::= INTEGER

BillingId ::= GraphicString4

Boolean ::= BOOLEAN

CancellationAcknowledgeAction ::= SubscriptionVersionAction

CancellationAcknowledgeReply ::= SubscriptionVersionActionReply

CancelAction::= SubscriptionVersionAction

CancelReply ::= SubscriptionVersionActionReply

ConflictResolutionAcknowledgeAction ::= SubscriptionVersionAction

ConflictResolutionAcknowledgeReply ::= SubscriptionVersionActionReply

ConflictResolutionPendingAction ::= SubscriptionVersionAction

ConflictResolutionPendingReply ::= SubscriptionVersionActionReply

DPC ::= CHOICE {

    dpc-value            [0] OCTET STRING (SIZE(3)),

    no-value-needed [1] NULL

157

}

DigitString ::= GraphicString (FROM (“0” | “1” | “2” | “3” | “4” | “5” |

                         “6” | “7” | “8” | “9” | “*” | “#” ))

DisconnectAction::= SEQUENCE {

    chc1 [0] CHOICE {

        subscription-version-action [0] SubscriptionVersionAction,

        subscription-version-tn-range [1] TN-Range

    },

    customer-disconnect-date [1] GeneralizedTime,

    effective-release-date [2] GeneralizedTime OPTIONAL

}

DisconnectReply ::= SEQUENCE {

    status SubscriptionVersionActionReply,

    version-id SET OF SubscriptionVersionId OPTIONAL

}

DownloadAction ::= CHOICE {

    subscriber-download [0] SubscriptionDownloadCriteria,

    network-download [1] NetworkDownloadCriteria

}

DownloadReason ::= ENUMERATED {

    new1 (0),

    delete1(1),

    modified (2),

    audit-discrepancy (3),

    download-request (4)

}

DownloadReply ::= SEQUENCE {

    status ENUMERATED {

        success (0),

        failed (1),

        time-range-invalid (2),

        criteria-to-large (3),

        no-data-selected (4)

    },

    CHOICE {

        subscriber-data [0] SubscriptionDownloadData,

        network-data [1] NetworkDownloadData

    } OPTIONAL

}

EndUserLocationType ::= NumberString(SIZE(2))

EndUserLocationValue ::= NumberString(SIZE(12))

Failed-SP-List  ::= SET OF SEQUENCE {

    service-prov-id ServiceProvId,

    service-prov-name ServiceProvName

}

FailedTN-List  ::= SET OF SEQUENCE {

    subscriptionVersionId SubscriptionVersionId,

    tn PhoneNumber,

    errorId INTEGER

}

GeneralTime ::= GeneralizedTime

GraphicStringBase ::= GraphicString

GraphicString4 ::= GraphicStringBase(SIZE(1..4))

158

GraphicString16 ::= GraphicStringBase(SIZE(1..16))

GraphicString20 ::= GraphicStringBase(SIZE(1..20))

GraphicString25 ::= GraphicStringBase(SIZE(1..25))

GraphicString28 ::= GraphicStringBase(SIZE(1..28))

GraphicString40 ::= GraphicStringBase(SIZE(1..40))

GraphicString60 ::= GraphicStringBase(SIZE(1..60))

GraphicString255 ::= GraphicStringBase(SIZE(1..255))

Integer ::= INTEGER

LnpAccessControl ::= [0] SEQUENCE {

    systemId [0] SystemID,

    systemType [1] SystemType,

    userId [2] GraphicString60 OPTIONAL,

    listId [3] INTEGER,

    keyId [4] INTEGER,

    cmipDepartureTime [5] GeneralizedTime,

    sequenceNumber [6] INTEGER(0..4294967295),

    function [7] AssociationFunction,

    recoveryMode [8] BOOLEAN,

    signature [9] BIT STRING

}

LnpAuditsName ::= GraphicString (“lnpAudits”)

LnpKey ::= INTEGER

LnpNetworkName ::= GraphicString (“lnpNetwork”)

LnpSMS-Name ::= GraphicString40

LnpServiceProvsName ::= GraphicString (“lnpServiceProvs”)

LnpSubscriptionsName ::= GraphicString (“lnpSubscriptions”)

LnpSpecificInfo ::= GraphicString255

LNPType ::= ENUMERATED {

    lspp (0),

    lisp (1)

}

LocalSMS-ActionResults ::= SEQUENCE {

    actionId [0] INTEGER,

    status [1] ActionResultsStatus,

    failed-tn-list [2] FailedTN-List OPTIONAL,

    time-of-completion [3] INTEGER,

    accessControl [4] LnpAccessControl

}

LocalSMS-CreateAction ::= SEQUENCE {

    actionId INTEGER,

    subscriptionVersionObjects SET OF SubscriptionVersionObject,

    accessControl LnpAccessControl

}

LocalSMS-CreateReply ::= ResultsStatus

LRN ::= OCTET STRING (SIZE(5))

LRN-ID ::= LnpKey

159

LRN-DownloadData ::= SET OF SEQUENCE {

    service-prov-lrn-id LRN-ID,

    service-prov-lrn-value LRN,

    service-prov-download-reason DownloadReason,

    service-prov-lrn-creation-timestamp GeneralizedTime OPTIONAL

}

LRN-Range ::= SEQUENCE {

  start-lrn LRN,

  stop-lrn LRN

}

LSMSUnits ::= SEQUENCE {

    dataDownload [0] NULL OPTIONAL,

    networkDataMgmt [1] NULL OPTIONAL,

    query [2] NULL OPTIONAL

}

MismatchAttributes ::= SEQUENCE {

    seq0 [0] SEQUENCE {

        lsms-subscriptionLRN LRN,

        npac-subscriptionLRN LRN

    } OPTIONAL,

    seq1 [1] SEQUENCE {

        lsms-subscriptionNewCurrentSP ServiceProvId,

        npac-subscriptionNewCurrentSP ServiceProvId

    } OPTIONAL,

    seq2 [2] SEQUENCE {

        lsms-subscriptionActivationTimeStamp GeneralizedTime,

        npac-subscriptionActivationTimeStamp GeneralizedTime

    } OPTIONAL,

    seq3 [3] SEQUENCE {

        lsms-subscriptionCustomerDisconnectDate GeneralizedTime,

        npac-subscriptionCustomerDisconnectDate GeneralizedTime

    } OPTIONAL,

    seq4 [4] SEQUENCE {

        lsms-subscriptionCLASS-DPC DPC,

        npac-subscriptionCLASS-DPC DPC

    } OPTIONAL,

    seq5 [5] SEQUENCE {

        lsms-subscriptionCLASS-SSN SSN,

        npac-subscriptionCLASS-SSN SSN

    } OPTIONAL,

    seq6 [6] SEQUENCE {

        lsms-subscriptionLIDB-DPC DPC,

        npac-subscriptionLIDB-DPC DPC

    } OPTIONAL,

    seq7 [7] SEQUENCE {

        lsms-subscriptionLIDB-SSN SSN,

        npac-subscriptionLIDB-SSN SSN

    } OPTIONAL,

    seq8 [8] SEQUENCE {

        lsms-subscriptionISVM-DPC DPC,

        npac-subscriptionISVM-DPC DPC

    } OPTIONAL,

    seq9 [9] SEQUENCE {

        lsms-subscriptionISVM-SSN SSN,

        npac-subscriptionISVM-SSN SSN

    } OPTIONAL,

    seq10 [10] SEQUENCE {

        lsms-subscriptionCNAM-DPC DPC,

        npac-subscriptionCNAM-DPC DPC

    } OPTIONAL,

    seq11 [11] SEQUENCE {

        lsms-subscriptionCNAM-SSN SSN,

        npac-subscriptionCNAM-SSN SSN

160

    } OPTIONAL,

    seq12 [12] SEQUENCE {

        lsms-subscriptionEndUserLocationValue EndUserLocationValue,

        npac-subscriptionEndUserLocationValue EndUserLocationValue

    } OPTIONAL,

    seq13 [13] SEQUENCE {

        lsms-subscriptionEndUserLocationType EndUserLocationType,

        npac-subscriptionEndUserLocationType EndUserLocationType

    } OPTIONAL,

    seq14 [14] SEQUENCE {

        lsms-subscriptionBillingId BillingId,

        npac-subscriptionBillingId BillingId

    } OPTIONAL,

    seq15 [15] SEQUENCE {

        lsms-subscriptionLNPType LNPType,

        npac-subscriptionLNPType LNPType

    } OPTIONAL

}

ModifyAction::= SEQUENCE {

    chc1 [0] CHOICE {

        subscription-version-action [0] SubscriptionVersionAction,

        subscription-version-tn-range [1] TN-Range

    },

    version-status [1] VersionStatus OPTIONAL,

    data-to-modify [2] SubscriptionModifyData

}

ModifyReply ::= SEQUENCE {

    status SubscriptionVersionActionReply,

    invalid-data SubscriptionModifyData

}

NetworkAddressInformation ::= SET OF SEQUENCE {

    interfaceAddress OSI-Address,

    systemType SystemType

}

NetworkDownloadCriteria ::= SEQUENCE {

    time-range [0] TimeRange OPTIONAL,

    chc1 [1] CHOICE {

        service-prov [0] ServiceProvId,

        all-service-provs [1] NULL

    },

    chc2 [2] CHOICE {

        npa-nxx-data [0] CHOICE {

            npa-nxx-range [0] NPA-NXX-Range,

            all-npa-nxx [1] NULL

        },

        lrn-data [1] CHOICE {

            lrn-range [0] LRN-Range,

            all-lrn [1] NULL

        },

        all-network-data [2] NULL

    }

}

NetworkDownloadData ::= SET OF SEQUENCE {

    service-prov-data [0] SEQUENCE {

        service-prov-id ServiceProvId,

        service-prov-name ServiceProvName OPTIONAL

    },

    service-prov-npa-nxx-data [1] NPA-NXX-DownloadData OPTIONAL,

    service-prov-lrn-data [2] LRN-DownloadData OPTIONAL

}

NewSP-CreateAction ::= NewSP-CreateData

161

NewSP-CreateData ::= SEQUENCE {

    chc1 [0] CHOICE {

        subscription-version-tn [0] PhoneNumber,

        subscription-version-tn-range [1] TN-Range

    },

    subscription-lrn [1] LRN OPTIONAL,

    subscription-new-current-sp [2] ServiceProvId,

    subscription-old-sp [3] ServiceProvId,

    subscription-new-sp-due-date [4] GeneralizedTime,

    subscription-class-dpc [6] DPC OPTIONAL,

    subscription-class-ssn [7] SSN OPTIONAL,

    subscription-lidb-dpc [8] DPC OPTIONAL,

    subscription-lidb-ssn [9] SSN OPTIONAL,

    subscription-isvm-dpc [10] DPC OPTIONAL,

    subscription-isvm-ssn [11] SSN OPTIONAL,

    subscription-cnam-dpc [12] DPC OPTIONAL,

    subscription-cnam-ssn [13] SSN OPTIONAL,

    subscription-end-user-location-value [14] EndUserLocationValue

        OPTIONAL,

    subscription-end-user-location-type [15] EndUserLocationType OPTIONAL,

    subscription-billing-id [16] BillingId OPTIONAL,

    subscription-lnp-type [20] LNPType,

    subscription-porting-to-original-sp-switch [21]

        SubscriptionPortingToOriginal-SPSwitch

}

NewSP-CreateReply ::= SEQUENCE {

    status SubscriptionVersionActionReply,

    invalid-data NewSP-CreateData

}

NPA ::= NumberString(SIZE(3))

NPA-NXX ::= SEQUENCE {

    npa-value NPA,

    nxx-value NumberString(SIZE(3))

}

NPA-NXX-DownloadData ::= SET OF SEQUENCE {

        service-prov-npa-nxx-id NPA-NXX-ID,

        service-prov-npa-nxx-value NPA-NXX OPTIONAL,

        service-prov-npa-nxx-effective-timestamp GeneralizedTime OPTIONAL,

        service-prov-download-reason DownloadReason,

        service-prov-npa-nxx-creation-timestamp GeneralizedTime OPTIONAL

}

NPA-NXX-ID ::= LnpKey

NPA-NXX-Range ::= SEQUENCE {

    start-npa-nxx NPA-NXX,

    stop-npa-nxx NPA-NXX

}

NPAC-SMS-Operational-Information ::= SEQUENCE {

    down-time TimeRange,

    npac-contact-number PhoneNumber,

    additional-down-time-information GraphicString255,

    access-control LnpAccessControl

}

NumberString ::= GraphicString (FROM (“0” | “1” | “2” | “3” | “4” | “5” |

                “6” | “7” | “8” | “9”))

OldSP-CreateAction ::= OldSP-CreateData

OldSP-CreateData ::= SEQUENCE {

162

    chc1 [0] CHOICE {

        subscription-version-tn [0] PhoneNumber,

        subscription-version-tn-range [1] TN-Range

    },

    subscription-new-current-sp [1] ServiceProvId,

    subscription-old-sp [2] ServiceProvId,

    subscription-old-sp-due-date [3] GeneralizedTime,

    subscription-old-sp-authorization [4] ServiceProvAuthorization

}

OldSP-CreateReply ::= SEQUENCE {

    status SubscriptionVersionActionReply,

    invalid-data OldSP-CreateData

}

OSI-Address ::= SEQUENCE {

    nsap            OCTET STRING(SIZE(20)),

    tsap            OCTET STRING(SIZE(1..4)),

    ssap            OCTET STRING(SIZE(1..4)),

    psap            OCTET STRING(SIZE(1..4))

}

PhoneNumber ::= NumberString(SIZE(10))

RecoveryCompleteAction ::= NULL

RecoveryCompleteReply ::= SEQUENCE {

    status ResultsStatus,

    subscriber-data [1] SubscriptionDownloadData OPTIONAL,

    network-data [2] NetworkDownloadData OPTIONAL

}

ServiceProvAuthorization ::= BOOLEAN

ServiceProvId ::= GraphicString4

ServiceProvName ::= GraphicString40

SoaUnits ::= SEQUENCE {

    soaMgmt [0] NULL OPTIONAL,

    networkDataMgmt [1] NULL OPTIONAL

}

ResultsStatus ::= ENUMERATED {

    success(0),

    failure(1)

}

SSN ::= CHOICE {

    ssn-value       [0] INTEGER(0..255),

    no-value-needed [1] NULL

}

SubscriptionData ::= SEQUENCE {

    subscription-lrn [1] LRN OPTIONAL,

    subscription-new-current-sp [2] ServiceProvId OPTIONAL,

    subscription-activation-timestamp [3] GeneralizedTime OPTIONAL,

    subscription-customer-disconnect-date [4] GeneralizedTime OPTIONAL,

    subscription-class-dpc [5] DPC,

    subscription-class-ssn [6] SSN,

    subscription-lidb-dpc [7] DPC,

    subscription-lidb-ssn [8] SSN,

    subscription-isvm-dpc [9] DPC,

    subscription-isvm-ssn [10] SSN,

    subscription-cnam-dpc [11] DPC,

    subscription-cnam-ssn [12] SSN,

    subscription-end-user-location-value [13] EndUserLocationValue

163

        OPTIONAL,

    subscription-end-user-location-type [14] EndUserLocationType OPTIONAL,

    subscription-billing-id [15] BillingId OPTIONAL,

    subscription-lnp-type [16] LNPType,

    subscription-download-reason [17] DownloadReason

}

SubscriptionDownloadCriteria ::= SEQUENCE {

    CHOICE {

        time-range [0] TimeRange,

        tn  [1] PhoneNumber,

        tn-range [2] TN-Range

    }

}

SubscriptionDownloadData ::= SET OF SEQUENCE {

    subscription-version-id [0] SubscriptionVersionId OPTIONAL,

    subscription-version-tn [1] PhoneNumber OPTIONAL,

    subscription-data SubscriptionData

}

SubscriptionModifyData ::= SEQUENCE {

    subscription-lrn [0] LRN OPTIONAL,

    subscription-new-sp-due-date [1] GeneralizedTime OPTIONAL,

    subscription-old-sp-due-date [2] GeneralizedTime OPTIONAL,

    subscription-old-sp-authorization [3] ServiceProvAuthorization OPTIONAL,

    subscription-class-dpc [4] DPC,

    subscription-class-ssn [5] SSN,

    subscription-lidb-dpc [6] DPC,

    subscription-lidb-ssn [7] SSN,

    subscription-isvm-dpc [8] DPC,

    subscription-isvm-ssn [9] SSN,

    subscription-cnam-dpc [10] DPC,

    subscription-cnam-ssn [11] SSN,

    subscription-end-user-location-value [12] EndUserLocationValue OPTIONAL,

    subscription-end-user-location-type [13] EndUserLocationType OPTIONAL,

    subscription-billing-id [14] BillingId OPTIONAL

}

SubscriptionPortingToOriginal-SPSwitch ::= BOOLEAN

SubscriptionPreCancellationStatus ::= ENUMERATED {

    conflict (0),

    pending (2),

    conflict-resolution-pending (6),

    disconnect-pending (7)

}

SubscriptionVersionAction ::= CHOICE {

    version-id [0] SubscriptionVersionId,

    tn [1] PhoneNumber

}

SubscriptionVersionActionReply ::= ENUMERATED {

    success (0),

    failed (1),

    soa-not-authorized (2),

    no-version-found (3),

    invalid-data-values (4),

    version-create-already-exists (5)

}

SubscriptionVersionId ::= LnpKey

SubscriptionVersionObject ::= SEQUENCE {

    tn-version-id SET OF TN-VersionId,

    subscription-data SubscriptionData

164

}

TimeRange ::= SEQUENCE {

    startTime [0] GeneralizedTime OPTIONAL,

    stopTime [1] GeneralizedTime OPTIONAL

}

Tunables ::= SET OF SEQUENCE {

    name GraphicString40,

    value GraphicString40

}

SystemID ::= CHOICE {

    serviceProvId [0] ServiceProvId,

    npac-sms [1] GraphicString60

}

SystemType ::= ENUMERATED {

    soa(0),

    local-sms(1),

    soa-and-local-sms(2),

    npac-sms(3)  — value is only valid for AccessControl definition

}

TN-Range ::= SEQUENCE {

    tn-start  NumberString(SIZE(1..10)),

    tn-stop   NumberString(SIZE(1..10))

}

TN-VersionId ::= SEQUENCE {

    tn PhoneNumber,

    version-id SubscriptionVersionId

}

VersionCancellationAcknowledgeRequest ::= SEQUENCE {

    tn PhoneNumber,

    version-id LnpKey,

    access-control LnpAccessControl

}

VersionConflictResolutionAcknowledgeRequest ::= SEQUENCE {

    tn PhoneNumber,

    version-id LnpKey,

    access-control LnpAccessControl

}

VersionCreateConcurrenceRequest ::= SEQUENCE {

    tn PhoneNumber,

    version-id LnpKey,

    service-prov-id ServiceProvId,

    service-prov-due-date GeneralizedTime,

    service-prov-authorization-time-stamp GeneralizedTime,

    access-control LnpAccessControl

}

VersionCustomerDisconnectDate ::= SEQUENCE {

    tn PhoneNumber,

    version-id LnpKey,

    service-prov-customer-disconnect-date GeneralizedTime,

    service-prov-effective-release-date GeneralizedTime,

    access-control LnpAccessControl

}

VersionNewNPA-NXX ::= SEQUENCE {

    service-prov-npa-nxx-id NPA-NXX-ID,

    service-prov-npa-nxx-value NPA-NXX OPTIONAL,

    access-control LnpAccessControl

165

}

VersionNewSP-CreateRequest ::= SEQUENCE {

    version-create-request VersionCreateConcurrenceRequest,

    service-prov-old-authorization ServiceProvAuthorization

}

VersionOldSP-ConcurrenceRequest ::= VersionCreateConcurrenceRequest

VersionStatus ::= ENUMERATED {

    conflict (0),

    active (1),

    pending (2),

    sending (3),

    download-failed (4),

    download-failed-partial (5),

    conflict-resolution-pending (6),

    disconnect-pending (7),

    old (8),

    canceled (9),

    cancel-pending (10)

}

VersionStatusAttributeValueChange ::= SEQUENCE {

    value-change-info [0] AttributeValueChangeInfo,

    failed-service-provs [1] Failed-SP-List OPTIONAL,

    access-control [2] LnpAccessControl

}

END — LNP-ASN1

166

9.Managed Object Conformance Statements

9.1.Overview

The Managed Object Conformance Statement (MOCS) that follow should be used by an implementation to identify which features and properties of each managed object class are supported. These tables have been prepared without regard to whether they are instantiated on the NPAC SMS, Local SMS, or the SOA.

The Base Status headings identify the base requirement, as stated in the GDMO templates. The valid values in the base status columns will be as follows:

m	for characteristics contained in mandatory packages or in conditional packages if the GDMO condition is always true
o	for characteristics of conditional packages with GDMO conditions that indicate static optionality (e.g., “if an instance supports it”)
cn	for all other conditions, where “n” is a unique integer and “cn” is a reference to a conditional status expression
x	for characteristics explicitly prohibited in the definition
-	for characteristics that are not mentions in the definition

9.2.lnpAudits Tables

9.2.1.lnpAudits Packages

Exhibit 9. lnpAudits Packages

Package Label	Object Identifier	Condition	Base Status	Additional Information
lnpAuditsPkg	(not registered)	Mandatory	m

9.2.2.lnpAudits Name Bindings

Exhibit 10. lnpAudits Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
lnpAudits-lnpNPAC-SMS	{lnp-nameBinding 1}	lnpNPAC-SMS and subclasses	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

167

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
lnpAudits-lnpLocalSMS	{lnp-nameBinding 2}	lnpLocalSMS and subclasses	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.2.3.lnpAudits Attributes

Exhibit 11. lnpAudits Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
objectClass	{9 3 2 7 65}
nameBinding	{9 3 2 7 63}
packages	{9 3 2 7 66}
allomorphs	{9 3 2 7 50}
lnpAuditsName	{lnp-attribute 16}		m

9.2.4.lnpAudits Actions

No actions supported for this object.

9.2.5.lnpAudits Notifications

No notifications supported for this object.

9.3.lnpLocalSMS Tables

9.3.1.lnpLocalSMS Packages

Exhibit 12. lnpLocalSMS Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpLocalSMS-Pkg	(not registered)	Mandatory	m
lnpRecoveryCompletePkg	{lnp-package 2}	Mandatory	m

168

9.3.2.lnpLocalSMS Name Bindings

Exhibit 13. lnpLocalSMS Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
lnpLocalSMS-root	lnp-nameBinding 3	“Rec. X.660 |ISO|IEC 9834 : 1992 : root	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.3.3.lnpLocalSMS Attributes

Exhibit 14. lnpLocalSMS Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
objectClass	{9 3 2 7 65}
nameBinding	{9 3 2 7 63}
packages	{9 3 2 7 66}
allomorphs	{9 3 2 7 50}
lnpLocal-SMS-Name	{lnp-attribute 17}	m	m

9.3.4.lnpLocalSMS Actions

Exhibit 15. lnpLocalSMS Actions

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
lnpRecoveryComplete	{lnp-action 2}	m	1.1	RecoveryCompleteAction	NULL	m
			1.2	RecoveryCompleteReply	SEQUENCE	m
			1.2.1	status	ENUMERATED	m
			1.2.2		SEQUENCE	o
			1.2.2.1	subscriber-data	SET OF SEQUENCE	m
			1.2.2.1.1	subscription-version-id	GraphicString	m
			1.2.2.1.2	subscription-version-tn	GraphicString	o
			1.2.2.1.3	subscription-data	SEQUENCE	m
			1.2.2.1.3.1	subscription-lrn	OCTET STRING	o
			1.2.2.1.3.2	subscription-new-current-sp	GraphicString	o
			1.2.2.1.3.3	subscription-activation-timestamp	GeneralizedTime	o
			1.2.2.1.3.4	subscription-customer-disconnect-date	GeneralizedTime	o
			1.2.2.1.3.5	subscription-class-dpc	CHOICE	m
			1.2.2.1.3.5.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.5.2	no-value-needed	NULL	o
			1.2.2.1.3.6	subscription-class-ssn	CHOICE	m
			1.2.2.1.3.6.1	ssn-value	INTEGER	o

169

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
			1.2.2.1.3.6.2	no-value-needed	NULL	o
			1.2.2.1.3.7	subscription-lidb-dpc	CHOICE	m
			1.2.2.1.3.7.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.7.2	no-value-needed	NULL	o
			1.2.2.1.3.8	subscription-lidb-ssn	CHOICE	m
			1.2.2.1.3.8.1	ssn-value	INTEGER	o
			1.2.2.1.3.8.2	no-value-needed	NULL	o
			1.2.2.1.3.9	subscription-isvm-dpc	CHOICE	m
			1.2.2.1.3.9.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.9.2	no-value-needed	NULL	o
			1.2.2.1.3.10	subscription-isvm-ssn	CHOICE	m
			1.2.2.1.3.10.1	ssn-value	INTEGER	o
			1.2.2.1.3.10.2	no-value-needed	NULL	o
			1.2.2.1.3.11	subscription-cnam-dpc	CHOICE	m
			1.2.2.1.3.11.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.11.2	no-value-needed	NULL	o
			1.2.2.1.3.12	subscription-cnam-ssn	CHOICE	m
			1.2.2.1.3.12.1	ssn-value	INTEGER	o
			1.2.2.1.3.12.2	no-value-needed	NULL	o
			1.2.2.1.3.13	subscription-end-user-location-value	NumberString	o
			1.2.2.1.3.14	subscription-end-user-location-type	NumberString	o
			1.2.2.1.3.15	subscription-billing-id	GraphicString	o
			1.2.2.1.3.16	subscription-lnp-type	ENUMERATED	m
			1.2.2.1.3.17	subscription-download-reason	ENUMERATED	m
			1.2.2.2	network-data	SEQUENCE	o
			1.2.2.2.1	service-prov-data	SET OF SEQUENCE	m
			1.2.2.2.1.1	service-prov-id	GraphicString	m
			1.2.2.2.1.2	service-prov-name	GraphicString	o
			1.2.2.2.2	service-prov-npa-nxx-data	SET OF SEQUENCE	o
			1.2.2.2.2.1	service-prov-npa-nxx-id	INTEGER	m
			1.2.2.2.2.2	service-prov-npa-nxx-value	NPA-NXX	o
			1.2.2.2.2.3	service-prov-npa-nxx-effective-timestamp	GeneralizedTime	o
			1.2.2.2.2.4	service-prov-download-reason	ENUMERATION	m
			1.2.2.2.2.5	service-prov-npa-nxx-creation-timestamp	GeneralizedTime	o
			1.2.2.2.3	service-prov-lrn-data	SET OF SEQUENCE	o
			1.2.2.2.3.1	service-prov-lrn-id	INTEGER	m
			1.2.2.2.3.2	service-prov-lrn-value	OCTET STRING	m
			1.2.2.2.3.3	service-prov-download-reason	ENUMERATION	m
			1.2.2.2.3.4	service-prov-lrn-creation-timestamp	GeneralizedTime	o

9.3.5.lnpLocalSMS Notifications

No notifications supported for this object.

9.4.lnpLogAudit-DiscrepancyRptRecord Tables

9.4.1.lnpLogAudit-DiscrepancyRptRecord Packages

Exhibit 16. lnpAudits Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpLogAudit-DiscrepancyRptPkg	(not registered)	Mandatory	m

170

9.4.2.lnpLogAudit-DiscrepancyRptRecord Name Bindings

Exhibit 17. lnpLogAudit-DiscrepancyRptRecord Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
logRecord-log	{9 3 2 6 3}	log and subclasses	1.1	Create support
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.4.3.lnpLogAudit-DiscrepancyRptRecord Attributes

Exhibit 18. lnpLogAudit-DiscrepancyRptRecord Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
auditDiscrepancyTn	{lnp-attribute 7}		m
auditDiscrepancyVersionId	{lnp-attribute 8}		m
auditDiscrepancyLSMS-SP-Id	{lnp-attribute 6}		m
auditDiscrepancyFailureReason	{lnp-attribute 5}		m
logRecordId	{9 3 2 8 3}	m	m
loggingTime	{9 3 2 8 59}		m
managedObject Class	{9 3 2 8 60}		m
managedObject Instance	{9 3 2 8 61}		m
eventType	{9 3 2 8 14}		m
accessControl	{lnp-attribute 1}		m

9.4.4.lnpLogAudit-DiscrepancyRptRecord Actions

No actions supported for this object.

9.4.5.lnpLogAudit-DiscrepancyRptRecord Notifications

No notifications supported for this object.

9.5.lnpLogAuditResultsRecord Tables

9.5.1.lnpLogAuditResultsRecord Packages

Exhibit 19. lnpLogAuditResultsRecord Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpLogAuditResults RecordPkg	(not Registered)	Mandatory	m

171

9.5.2.lnpLogAuditResultsRecord Name Bindings

Exhibit 20. lnpLogAuditResultsRecord Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
logRecord-log	{9 3 2 6 3}	log and subclasses	1.1	Create support
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.5.3.lnpLogAuditResultsRecord Attributes

Exhibit 21. lnpLogAuditResultsRecord Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
auditResultStatus	{lnp-attribute 13}		m
auditResultNumberDiscrepancies	{lnp-attribute 12}		m
auditResultCompletionTime	{lnp-attribute 10}		m
logRecordId	{9 3 2 8 3}	m	m
loggingTime	{9 3 2 8 59}		m
managedObject Class	{9 3 2 8 60}		m
managedObject Instance	{9 3 2 8 61}		m
eventType	{9 3 2 8 14}		m
accessControl	{lnp-attribute 1}		m
auditResultFailed-SP-List	{lnp-attribute 11}		m
auditResponseLevel	{lnp-attribute 9}		m

9.5.4.lnpLogAuditResultsRecord Actions

No actions supported for this object.

9.5.5.lnpLogAuditResultsRecord Notifications

No notifications supported for this object.

9.6.lnpLogCancellationAcknowledgeRequestRecord

9.6.1.lnpLogCancellationAcknowledgeRequest Packages

Exhibit 22. lnpLogCancellationAcknowledgeRequest Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpLogCancellation AcknowledgeRequestPkg	(not Registered)	Mandatory	m

172

9.6.2.lnpLogCancellationAcknowledgeRequest Name Bindings

Exhibit 23. lnpLogCancellationAcknowledgeRequest Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
logRecord-log	{9 3 2 6 3}	log and subclasses	1.1	Create support
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.6.3.lnpLogCancellationAcknowledgeRequest Attributes

Exhibit 24. lnpLogCancellationAcknowledgeRequest Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
subscriptionTN	{lnp-attribute 97}		m
subscriptionversionID	{lnp-attribute 99}		m
accessControl	{lnp-attribute 1}		m
SystemId
UserId
ListId
KeyId
cmipDepartureTime
SequenceNumber
Signature
logRecordId	{9 3 2 8 3}	m	m
loggingTime	{9 3 2 8 59}		m
managedObject Class	{9 3 2 8 60}		m
managedObject Instance	{9 3 2 8 61}		m
eventType	{9 3 2 8 14}		m

9.7.lnpLogConflictResolutionAcknowledgeRequestRecord

9.7.1.lnpLogConflictResolutionAcknowledgeRequest Packages

Exhibit 25. lnpLogConflictResolutionAcknowledgeRequest Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpLogConflictResolution AcknowledgeRequestPkg	(not registered)	Mandatory	m

173

9.7.2.lnpLogConflictResolutionAcknowledgeRequest Name Bindings

Exhibit 26. lnpLogConflictResolutionAcknowledgeRequest Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
logRecord-log	{9 3 2 6 3}	log and subclasses	1.1	Create support
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.7.3.lnpLogConflictResolutionAcknowledgeRequest Attributes

Exhibit 27. lnpLogConflictResolutionAcknowledgeRequest Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
subscriptionTN	{lnp-attribute 97}		m
subscriptionversionId	{lnp-attribute 99}		m
accessControl	{lnp-attribute 1}		m
SystemId
UserId
ListId
KeyId
cmipDepartureTIme
SequenceNumber
Signature
logRecordId	{9 3 2 8 3}	m	m
loggingTime	{9 3 2 8 59}		m
managedObject Class	{9 3 2 8 60}		m
managedObject Instance	{9 3 2 8 61}		m
eventType	{9 3 2 8 14}		m

9.8.lnpLogNewSP-CreateRequestRecord Tables

9.8.1.lnpLogNewSP-CreateRequestRecord Packages

Exhibit 28. lnpLogNewSP-CreateRequestRecord Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpLogNewSP-CreateRequestPkg	(not registered)	Mandatory	m

174

9.8.2.lnpLogNewSP-CreateRequestRecord Name Bindings

Exhibit 29. lnpLogNewSP-CreateRequestRecord Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
logRecord-log	{9 3 2 6 3}	log and subclasses	1.1	Create support
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.8.3.lnpLogNewSP-CreateRequestRecord Attributes

Exhibit 30. lnpLogNewSP-CreateRequestRecord Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
subscriptionTN	{lnp-attribute 97}		m
subscriptionVersionId	{lnp-attribute 99}		m
logRecordId	{9 3 2 8 3}	m	m
loggingTime	{9 3 2 8 59}		m
managedObject Class	{9 3 2 8 60}		m
managedObject Instance	{9 3 2 8 61}		m
eventType	{9 3 2 8 14}		m
accessControl	{lnp-attribute 1}		m
subscriptionOldSP	{lnp-attribute 88}		m
subscriptionOldSP-DueDate	{lnp-attribute 93}		m
subscriptionOldSP -Authorization	{lnp-attribute 89}		m
subscriptionOldSP -AuthorizationTimeStamp	{lnp-attribute 90}		m

9.8.4.lnpLogNewSP-CreateRequestRecord Actions

No actions supported for this object.

9.8.5.lnpLogNewSP-CreateRequestRecord Notifications

No actions supported for this object.

175

9.9.lnpLogOldSP-ConcurrenceRequestRecord Tables

9.9.1.lnpLogOldSP-ConcurrenceRequestRecord Packages

Exhibit 31. lnpLogOldSP-ConcurrenceRequestRecord Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpLogOldSP-ConcurrenceRequestPkg	(not registered)	Mandatory	m

9.9.2.lnpLogOldSP-ConcurrenceRequestRecord Name Bindings

Exhibit 32. lnpLogOldSP-ConcurrenceRequestRecord Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
logRecord-log	{9 3 2 6 3}	log and subclasses	1.1	Create support
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.9.3.lnpLogOldSP-ConcurrenceRequestRecord Attributes

Exhibit 33. lnpLogOldSP-ConcurrenceRequestRecord Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
subscriptionTN	{lnp-attribute 96}		m
subscriptionVersionId	{lnp-attribute 98}		m
logRecordId	{9 3 2 8 3}	m	m
loggingTime	{9 3 2 8 59}		m
managedObject Class	{9 3 2 8 60}		m
managedObject Instance	{9 3 2 8 61}		m
eventType	{9 3 2 8 14}		m
subscriptionNewCurrentSP	{lnp-attribute 83}		m
subscriptionNewSP-DueDate	{lnp-attribute 87}		m
accessControl	{lnp-attribute 1}		m

9.9.4.lnpLogOldSP-ConcurrenceRequestRecord Actions

No actions supported for this object.

9.9.5.lnpLogOldSP-ConcurrenceRequestRecord Notifications

No notifications supported for this object.

176

9.10.lnpLogOperational-InformationRecord Tables

9.10.1.lnpLogOperational-InformationRecord Packages

Exhibit 34. lnpLogOperational-InformationRecord Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpLogOperational-InformationRecordPkg	(not registered)	Mandatory	m

9.10.2.lnpLogOperational-InformationRecord Name Bindings

Exhibit 35. lnpLogOperational-InformationRecord Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
logRecord-log	{9 3 2 6 3}	log and subclasses	1.1	Create support
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.10.3.lnpLogOperational-InformationRecord Attributes

Exhibit 36. lnpLogOperational-InformationRecord Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
downTime	{lnp-attribute 14}		m
logRecordId	{9 3 2 8 3}	m	m
loggingTime	{9 3 2 8 59}		m
managedObject Class	{9 3 2 8 60}		m
managedObject Instance	{9 3 2 8 61}		m
eventType	{9 3 2 8 14}		m
npacContactNumber	{lnp-attribute 23}		m
additionalDownTimeInformation	{lnp-attribute 4}		m
accessControl	{lnp-attribute 1}		m

9.10.4.lnpLogOperational-InformationRecord Actions

No actions supported for this object.

9.10.5.lnpLogOperational-InformationRecord Notifications

No notifications supported for this object.

179

9.11.lnpLogStatusAttributeValueChangeRecord Tables

9.11.1.lnpLogStatusAttributeValueChangeRecord Packages

Exhibit 37. lnpLogOperational-InformationRecord Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpLogStatusAttributeValueChangePkg	(not registered)	Mandatory	m
subscriptionVersion Attribute ValueChangeFailed-SP-ListPkg	{lnp-package 13}	“if the version status is failed or partially failed”	o

9.11.2.lnpLogStatusAttributeValueChangeRecord Name Bindings

Exhibit 38. lnpLogStatusAttributeValueChangeRecord Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
logRecord-log	{9 3 2 6 3}	log and subclasses	1.1	Create support
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.11.3.lnpLogStatusAttributeValueChangeRecord Attributes

Exhibit 39. lnpLogStatusAttributeValueChangeRecord Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
subscriptionVersionAttributeValueChangeInfo	{lnp-attribute 98}		m
logRecordId	{9 3 2 8 3}	m	m
loggingTime	{9 3 2 8 59}		m
managedObject Class	{9 3 2 8 60}		m
managedObject Instance	{9 3 2 8 61}		m
eventType	{9 3 2 8 14}		m
accessControl	{lnp-attribute 1}		m

9.11.4.lnpLogStatusAttributeValueChangeRecord Actions

No actions supported for this object.

9.11.5.lnpLogStatusAttributeValueChangeRecord Notifications

No notifications supported for this object.

180

9.11.6.lnpNetwork Packages

Exhibit 40. lnpNetwork Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpNetworkPkg	(not registered)	Mandatory	m
lnpDownloadPkg	{lnp-package-1}	“if the object is instantiated on the NPAC SMS”	o

9.11.7.lnpNetwork Name Bindings

Exhibit 41. lnpNetwork Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
lnpNetwork-lnpNPAC-SMS	{lnp-nameBinding 4}	lnpNPAC-SMS and subclasses	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects
lnpNetwork-lnpLocalSMS	{lnp-nameBinding 5}	lnpLocal-SMS and subclasses	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.11.8.lnpNetwork Attributes

Exhibit 42. lnpNetwork Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
objectClass	{9  3  2  7  65}
nameBinding	{9  3  2  7  63}
packages	{9  3  2  7  66}
allomorphs	{9  3  2  7  50}
lnpNetworkName	{lnp-attribute 18}	m	m

9.11.9.lnpNetwork Actions

Exhibit 43. lnpNetwork Actions

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
lnpDownload	{lnp-action 1}	o	1.1	DownloadAction	CHOICE	m
			1.1.1	subscriber-download	SEQUENCE	o
			1.1.1.1		CHOICE	m
			1.1.1.1.1	time-range	SEQUENCE	m

181

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
			1.1.1.1.1.1	startTime	GeneralizedTime	m
			1.1.1.1.1.2	stopTime	GeneralizedTime	m
			1.1.1.1.2	tn	NumberString	m
			1.1.1.1.3	tn-range	SEQUENCE	m
			1.1.1.1.3.1	tn-start	NumberString	m
			1.1.1.1.3.2	tn-stop	NumberString	m
			1.1.1.2	lnp-type	ENUMERATED	o
			1.1.2	network-download	SEQUENCE	o
			1.1.2.1	time-range	SEQUENCE	o
			1.1.2.1.1	startTime	GeneralizedTime	m
			1.1.2.1.2	stopTime	GeneralizedTime	m
			1.1.2.2	chc1	CHOICE	m
			1.1.2.2.1	service-prov	NumberString	m
			1.1.2.2.1	all-serivce-provs		m
			1.1.2.3	chc2	CHOICE	m
			1.1.2.3.1	npa-nxx-data	CHOICE	m
			1.1.2.3.1.1	npa-nxx-range	SEQUENCE	m
			1.1.2.3.1.1.1	start-npa-nxx	SEQUENCE	m
			1.1.2.3.1.1.1.1	npa-value	NumberString	m
			1.1.2.3.1.1.1.2	nxx-value	NumberString	m
			1.1.2.3.1.1.2	stop-npa-nxx	SEQUENCE	m
			1.1.2.3.1.1.2.1	npa-value	NumberString	m
			1.1.2.3.1.1.2.2	nxx-value	NumberString	m
			1.1.2.3.1.2	all-npa-nxx		m
			1.1.2.3.2	lrn-data	CHOICE	m
			1.1.2.3.2.1	lrn-range	SEQUENCE	m
			1.1.2.3.2.1.1	start-lrn	OCTET STRING	m
			1.1.2.3.2.1.2	stop-lrn	OCTET STRING	m
			1.1.2.3.3	all-network-data	NULL	m
			1.2	DownloadReply	SEQUENCE	m
			1.2.1	status	ENUMERATED	m
			1.2.2		CHOICE
			1.2.2.1	subscriber-data	SET OF SEQUENCE	m
			1.2.2.1.1	subscription-version-id	GraphicString	m
			1.2.2.1.2	subscription-version-tn	GraphicString	o
			1.2.2.1.3	subscription-data	SEQUENCE	m
			1.2.2.1.3.1	subscription-lrn	OCTET STRING	o
			1.2.2.1.3.2	subscription-new-current-sp	GraphicString	o
			1.2.2.1.3.3	subscription-activation-timestamp	GeneralizedTime	o
			1.2.2.1.3.4	subscription-customer-disconnect-date	GeneralizedTime	o
			1.2.2.1.3.5	subscription-class-dpc	CHOICE	m
			1.2.2.1.3.5.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.5.2	no-value-needed	NULL	o
			1.2.2.1.3.6	subscription-class-ssn	CHOICE	m
			1.2.2.1.3.6.1	ssn-value	INTEGER	o
			1.2.2.1.3.6.2	no-value-needed	NULL	o
			1.2.2.1.3.7	subscription-lidb-dpc	CHOICE	m
			1.2.2.1.3.7.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.7.2	no-value-needed	NULL	o
			1.2.2.1.3.8	subscription-lidb-ssn	CHOICE	m
			1.2.2.1.3.8.1	ssn-value	INTEGER	o
			1.2.2.1.3.8.2	no-value-needed	NULL	o
			1.2.2.1.3.9	subscription-isvm-dpc	CHOICE	m
			1.2.2.1.3.9.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.9.2	no-value-needed	NULL	o
			1.2.2.1.3.10	subscription-isvm-ssn	CHOICE	m
			1.2.2.1.3.10.1	ssn-value	INTEGER	o
			1.2.2.1.3.10.2	no-value-needed	NULL	o
			1.2.2.1.3.11	subscription-cnam-dpc	CHOICE	m
			1.2.2.1.3.11.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.11.2	no-value-needed	NULL	o
			1.2.2.1.3.12	subscription-cnam-ssn	CHOICE	m
			1.2.2.1.3.12.1	ssn-value	INTEGER	o

182

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
			1.2.2.1.3.12.2	no-value-needed	NULL	o
			1.2.2.1.3.13	subscription-end-user-location-value	NumberString	o
			1.2.2.1.3.14	subscription-end-user-location-type	NumberString	o
			1.2.2.1.3.15	subscription-billing-id	GraphicString	o
			1.2.2.1.3.16	subscription-lnp-type	ENUMERATED	m
			1.2.2.1.3.17	subscription-download-reason	ENUMERATED	m
			1.2.2.2	network-data
			1.2.2.2.1	service-prov-data	SET OF SEQUENCE	m
			1.2.2.2.1.1	service-prov-id	GraphicString	m
			1.2.2.2.1.2	service-prov-name	GraphicString	o
			1.2.2.2.2	service-prov-npa-nxx-data	SET OF SEQUENCE	o
			1.2.2.2.2.1	service-prov-npa-nxx-id	INTEGER	m
			1.2.2.2.2.2	service-prov-npa-nxx-value	NPA-NXX	o
			1.2.2.2.2.3	service-prov-npa-nxx-effective-timestamp	GeneralizedTime	o
			1.2.2.2.2.4	service-prov-download-reason	ENUMERATION	m
			1.2.2.2.2.5	service-prov-npa-nxx-creation-timestamp	GeneralizedTime	o
			1.2.2.2.3	service-prov-lrn-data	SET OF SEQUENCE	o
			1.2.2.2.3.1	service-prov-lrn-id	INTEGER	m
			1.2.2.2.3.2	service-prov-lrn-value	OCTET STRING	m
			1.2.2.2.3.3	service-prov-download-reason	ENUMERATION	m
			1.2.2.2.3.4	service-prov-lrn-creation-timestamp	GeneralizedTime	o

9.11.10.lnpNetwork Notifications

No notifications supported for this object.

9.12.lnpNPAC-SMS Tables

9.12.1.lnpNPAC-SMS Packages

Exhibit 44. lnpNPAC-SMS Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpNPAC-SMSPkg	(not registered)	Mandatory	m
lnpRecoveryCompletePkg	lnp-package-2	Mandatory	m

9.12.2.lnpNPAC-SMS Name Bindings

Exhibit 45. lnpNPAC-SMS Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
lnpNPAC-SMS-root	{lnp-nameBinding 6}	“Rec. X.660 | ISO/IEC 9834-1 : 1992” : root	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

183

9.12.3.lnpNPAC-SMS Attributes

Exhibit 46. lnpNPAC-SMS Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
objectClass	{9  3  2  7  65}
nameBinding	{9  3  2  7  63}
packages	{9  3  2  7  66}
allomorphs	{9  3  2  7  50}
lnpNPAC-SMS-Name	{lnp-attribute 19}	m	m

9.12.4.lnpNPAC-SMS Actions

Exhibit 47. lnpNPAC-SMS Actions

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
lnpRecoveryComplete	{lnp-action 2}	m	1.1	RecoveryCompleteAction	NULL	m
			1.2	RecoveryCompleteReply	SEQUENCE	m
			1.2.1	status	ENUMERATED	m
			1.2.2		SEQUENCE	o
			1.2.2.1	subscriber-data	SET OF SEQUENCE	m
			1.2.2.1.1	subscription-version-id	GraphicString	m
			1.2.2.1.2	subscription-version-tn	GraphicString	o
			1.2.2.1.3	subscription-data	SEQUENCE	m
			1.2.2.1.3.1	subscription-lrn	OCTET STRING	o
			1.2.2.1.3.2	subscription-new-current-sp	GraphicString	o
			1.2.2.1.3.3	subscription-activation-timestamp	GeneralizedTime	o
			1.2.2.1.3.4	subscription-customer-disconnect-date	GeneralizedTime	o
			1.2.2.1.3.5	subscription-class-dpc	CHOICE	m
			1.2.2.1.3.5.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.5.2	no-value-needed	NULL	o
			1.2.2.1.3.6	subscription-class-ssn	CHOICE	m
			1.2.2.1.3.6.1	ssn-value	INTEGER	o
			1.2.2.1.3.6.2	no-value-needed	NULL	o
			1.2.2.1.3.7	subscription-lidb-dpc	CHOICE	m
			1.2.2.1.3.7.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.7.2	no-value-needed	NULL	o
			1.2.2.1.3.8	subscription-lidb-ssn	CHOICE	m
			1.2.2.1.3.8.1	ssn-value	INTEGER	o
			1.2.2.1.3.8.2	no-value-needed	NULL	o
			1.2.2.1.3.9	subscription-isvm-dpc	CHOICE	m
			1.2.2.1.3.9.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.9.2	no-value-needed	NULL	o
			1.2.2.1.3.10	subscription-isvm-ssn	CHOICE	m
			1.2.2.1.3.10.1	ssn-value	INTEGER	o
			1.2.2.1.3.10.2	no-value-needed	NULL	o
			1.2.2.1.3.11	subscription-cnam-dpc	CHOICE	m
			1.2.2.1.3.11.1	dpc-value	OCTET STRING	o

184

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
			1.2.2.1.3.11.2	no-value-needed	NULL	o
			1.2.2.1.3.12	subscription-cnam-ssn	CHOICE	m
			1.2.2.1.3.12.1	ssn-value	INTEGER	o
			1.2.2.1.3.12.2	no-value-needed	NULL	o
			1.2.2.1.3.13	subscription-end-user-location-value	NumberString	o
			1.2.2.1.3.14	subscription-end-user-location-type	NumberString	o
			1.2.2.1.3.15	subscription-billing-id	GraphicString	o
			1.2.2.1.3.16	subscription-lnp-type	ENUMERATED	m
			1.2.2.1.3.17	subscription-download-reason	ENUMERATED	m
			1.2.2.2	network-data
			1.2.2.2.1	service-prov-data	SET OF SEQUENCE	m
			1.2.2.2.1.1	service-prov-id	GraphicString	m
			1.2.2.2.1.2	service-prov-name	GraphicString	o
			1.2.2.2.2	service-prov-npa-nxx-data	SET OF SEQUENCE	o
			1.2.2.2.2.1	service-prov-npa-nxx-id	INTEGER	m
			1.2.2.2.2.2	service-prov-npa-nxx-value	NPA-NXX	o
			1.2.2.2.2.3	service-prov-npa-nxx-effective-timestamp	GeneralizedTime	o
			1.2.2.2.2.4	service-prov-download-reason	ENUMERATION	m
			1.2.2.2.2.5	service-prov-npa-nxx-creation-timestamp	GeneralizedTime	o
			1.2.2.2.3	service-prov-lrn-data	SET OF SEQUENCE	o
			1.2.2.2.3.1	service-prov-lrn-id	INTEGER	m
			1.2.2.2.3.2	service-prov-lrn-value	OCTET STRING	m
			1.2.2.2.3.3	service-prov-download-reason	ENUMERATION	m
			1.2.2.2.3.4	service-prov-lrn-creation-timestamp	GeneralizedTime	o

9.12.5.lnpNPAC-SMS Notifications

Exhibit 48. lnpNPAC-SMS Notifications

Notification Label	Object Identifier	Subindex	Notification Field	Value of object identifier of attribute type associated with field	Constraints and values	Base Status	Additional Information
lnpNPAC-SMS-Operational  -Information	{lnp-notification 1}	1.1	NPAC-SMS-Operational-Info		SEQUENCE	m
		1.1.1	downTime		timeRange	m
		1.1.1.1	timeRange		SEQUENCE	m
		1.1.1.1.1	startTime		GeneralizedTime	m	p. 108
		1.1.1.1.2	stopTime		GeneralizedTime	o
		1.1.2	npacContactNumber			m
		1.1.3	additionalDownTimeInformation		GraphicString	m
		1.1.4	accessControl		SEQUENCE	m

9.13.lnpServiceProvs Tables

9.13.1.lnpServiceProvs Packages

Exhibit 49. lnpServiceProvs Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpServiceProvsPkg	(not registered)	Mandatory	m

185

9.13.2.lnpServiceProvs Name Bindings

Exhibit 50. lnpServiceProvs Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
lnpServiceProvs-lnpNPAC-SMS	{lnp-nameBinding 7}	lnpNPAC-SMS and subclasses	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.13.3.lnpServiceProvs Attributes

Exhibit 51. lnpServiceProvs Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
objectClass	{9  3  2  7  65}
nameBinding	{9  3  2  7  63}
packages	{9  3  2  7  66}
allomorphs	{9  3  2  7  50}
lnpServiceProvsName	{lnp-attribute 20}	m	m

9.13.4.lnpServiceProvs Actions

No actions supported for this object.

9.13.5.lnpServiceProvs Notifications

No notifications supported for this object.

9.14.lnpSubscriptions Tables

9.14.1.lnpSubscriptions Packages

Exhibit 52. lnpSubscriptions Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
lnpSubscriptionsPkg	(not registered)	Mandatory	m
subscriptionVersionLocalSMS-CreatePkg	{lnp package 16}	Mandatory	m
lnpDownload Pkg	{lnp package 1}	“if the object is instantiated on the NPAC SMS”	o
subscriptionVersionOldSP-CreatePkg	{lnp package 24}	“if the object is instantiated on the NPAC SMS”	o
subscriptionVersionNewSP-CreatePkg	{lnp package 21}	“if the object is instantiated on the NPAC SMS”	o

186

Package Label	Object Identifier	Condition	Base Status	Addition Information
subscriptionVersionDisconnectPkg	{lnp package 15}	“if the object is instantiated on the NPAC SMS”	o
subscriptionVersionModifyPkg	{lnp package 17}	“if the object is instantiated on the NPAC SMS”	o
subscriptionVersionActivatePkg	{lnp package 12}	“if the object is instantiated on the NPAC SMS”	o
subscriptionVersionCancelPkg	{lnp package 14}	“if the object is instantiated on the NPAC SMS”	o
subscriptionVersionOldSP-CancellationPkg	{lnp package 22}	“if the object is instantiated on the NPAC SMS”	o
subscriptionVersionNewSP-CancellationPkg	{lnp package 18}	“if the object is instantiated on the NPAC SMS”	o
subscriptionVersionOldSP-ConflictResolutionPkg	{lnp package 23}	“if the object is instantiated on the NPAC SMS”	o
subscriptionVersionNewSP-ConflictResolutionPkg	{lnp package 19}	“if the object is instantiated on the NPAC SMS”	o
subscriptionVersionNewSP-ConfilictResolutionPendingPkg	{lnp package 20}	“if the object is instantiated on the NPAC SMS”	o

9.14.2.lnpSubscriptions Name Bindings

Exhibit 53. lnpSubscriptions Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
lnpSubscriptions-lnpNPAC-SMS	{lnp-nameBinding 8}	lnpNPAC-SMS and subclasses	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects
lnpSubscriptions-lnpLocalSMS	{lnp-nameBinding 9}	lnpLocalSMS and subclasses	2.1	Create support	m
			2.2	Create with reference object	m
			2.3	Create with automatic instance naming	m
			2.4	Delete support	m
			2.5	Delete only if no contained objects	m
			2.6	Delete contained objects

9.14.3.lnpSubscriptions Attributes

Exhibit 54. lnpSubscriptions Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
objectClass	{9  3  2  7  65}
nameBinding	{9  3  2  7  63}
packages	{9  3  2  7  66}
allomorphs	{9  3  2  7  50}
lnpSubscriptionsName	{lnp-attribute 22}	m	m

187

9.14.4.lnpSubscriptions Actions

Exhibit 55. lnpSubscriptions Actions

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
lnpDownload	{lnp-action 1}	o	1.1	DownloadAction	CHOICE	m
			1.1.1	subscriber-download	SEQUENCE	o
			1.1.1.1		CHOICE	m
			1.1.1.1.1	time-range	SEQUENCE	m
			1.1.1.1.1.1	startTime	GeneralizedTime	m
			1.1.1.1.1.2	stopTime	GeneralizedTime	m
			1.1.1.1.2	tn	NumberString	m
			1.1.1.1.3	tn-range	SEQUENCE	m
			1.1.1.1.3.1	tn-start	NumberString	m
			1.1.1.1.3.2	tn-stop	NumberString	m
			1.1.1.2	lnp-type	ENUMERATED	o
			1.1.2	network-download	SEQUENCE	o
			1.1.2.1	time-range	SEQUENCE	o
			1.1.2.1.1	startTime	GeneralizedTime	m
			1.1.2.1.2	stopTime	GeneralizedTime	m
			1.1.2.2	chc1	CHOICE	m
			1.1.2.2.1	service-prov	NumberString	m
			1.1.2.2.2	all-serivce-provs		m
			1.1.2.3	chc2	CHOICE	m
			1.1.2.3.1	npa-nxx-data	CHOICE	m
			1.1.2.3.1.1	npa-nxx-range	SEQUENCE	m
			1.1.2.3.1.1.1	start-npa-nxx	SEQUENCE	m
			1.1.2.3.1.1.1.1	npa-value	NumberString	m
			1.1.2.3.1.1.1.2	nxx-value	NumberString	m
			1.1.2.3.1.1.2	stop-npa-nxx	SEQUENCE	m
			1.1.2.3.1.1.2.1	npa-value	NumberString	m
			1.1.2.3.1.1.2.2	nxx-value	NumberString	m
			1.1.2.3.1.2	all-npa-nxx		m
			1.1.2.3.2	lrn-data	CHOICE	m
			1.1.2.3.2.1	lrn-range	SEQUENCE	m
			1.1.2.3.2.1.1	start-lrn	OCTET STRING	m
			1.1.2.3.2.1.2	stop-lrn	OCTET STRING	m
			1.1.2.3.3	all-network-data	NULL	m
			1.2	DownloadReply	SEQUENCE	m
			1.2.1	status	ENUMERATED	m
			1.2.2		CHOICE	o
			1.2.2.1	subscriber-data	SET OF SEQUENCE	m
			1.2.2.1.1	subscription-version-id	GraphicString	m
			1.2.2.1.2	subscription-version-tn	GraphicString	o
			1.2.2.1.3	subscription-data	SEQUENCE	m
			1.2.2.1.3.1	subscription-lrn	OCTET STRING	o
			1.2.2.1.3.2	subscription-new-current-sp	GraphicString	o
			1.2.2.1.3.3	subscription-activation-timestamp	GeneralizedTime	o
			1.2.2.1.3.4	subscription-customer-disconnect-date	GeneralizedTime	o
			1.2.2.1.3.5	subscription-class-dpc	CHOICE	m
			1.2.2.1.3.5.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.5.2	no-value-needed	NULL	o
			1.2.2.1.3.6	subscription-class-ssn	CHOICE	m
			1.2.2.1.3.6.1	ssn-value	INTEGER	o
			1.2.2.1.3.6.2	no-value-needed	NULL	o
			1.2.2.1.3.7	subscription-lidb-dpc	CHOICE	m
			1.2.2.1.3.7.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.7.2	no-value-needed	NULL	o
			1.2.2.1.3.8	subscription-lidb-ssn	CHOICE	m
			1.2.2.1.3.8.1	ssn-value	INTEGER	o
			1.2.2.1.3.8.2	no-value-needed	NULL	o
			1.2.2.1.3.9	subscription-isvm-dpc	CHOICE	m
			1.2.2.1.3.9.1	dpc-value	OCTET STRING	o

188

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
			1.2.2.1.3.9.2	no-value-needed	NULL	o
			1.2.2.1.3.10	subscription-isvm-ssn	CHOICE	m
			1.2.2.1.3.10.1	ssn-value	INTEGER	o
			1.2.2.1.3.10.2	no-value-needed	NULL	o
			1.2.2.1.3.11	subscription-cnam-dpc	CHOICE	m
			1.2.2.1.3.11.1	dpc-value	OCTET STRING	o
			1.2.2.1.3.11.2	no-value-needed	NULL	o
			1.2.2.1.3.12	subscription-cnam-ssn	CHOICE	m
			1.2.2.1.3.12.1	ssn-value	INTEGER	o
			1.2.2.1.3.12.2	no-value-needed	NULL	o
			1.2.2.1.3.13	subscription-end-user-location-value	NumberString	o
			1.2.2.1.3.14	subscription-end-user-location-type	NumberString	o
			1.2.2.1.3.15	subscription-billing-id	GraphicString	o
			1.2.2.1.3.16	subscription-lnp-type	ENUMERATED	m
			1.2.2.1.3.17	subscription-download-reason	ENUMERATED	m
			1.2.2.2	network-data
			1.2.2.2.1	service-prov-data	SET OF SEQUENCE	m
			1.2.2.2.1.1	service-prov-id	GraphicString	m
			1.2.2.2.1.2	service-prov-name	GraphicString	o
			1.2.2.2.2	service-prov-npa-nxx-data	SET OF SEQUENCE	o
			1.2.2.2.2.1	service-prov-npa-nxx-id	INTEGER	m
			1.2.2.2.2.2	service-prov-npa-nxx-value	NPA-NXX	o
			1.2.2.2.2.3	service-prov-npa-nxx-effective-timestamp	GeneralizedTime	o
			1.2.2.2.2.4	service-prov-download-reason	ENUMERATION	m
			1.2.2.2.2.5	service-prov-npa-nxx-creation-timestamp	GeneralizedTime	o
			1.2.2.2.3	service-prov-lrn-data	SET OF SEQUENCE	o
			1.2.2.2.3.1	service-prov-lrn-id	INTEGER	m
			1.2.2.2.3.2	service-prov-lrn-value	OCTET STRING	m
			1.2.2.2.3.3	service-prov-download-reason	ENUMERATION	m
			1.2.2.2.3.4	service-prov-lrn-creation-timestamp	GeneralizedTime	o
subscription VersionActivate	{lnp-action 3}	o	1.1	ActivateAction	CHOICE	m
			1.1.1	version-id	Integer	m
			1.1.2	tn	NumberString	m
			1.2	ActivateReply	ENUMERATED	m
subscription VersionCancel	{lnp-action 4}	o	1.1	CancelAction	CHOICE	m
			1.1.1	version-id	Integer	m
			1.1.2	tn	NumberString	m
			1.2	CancelReply	ENUMERATED	m
subscription Version Disconnect	{lnp-action 5}	o	1.1	DisconnectAction	SEQUENCE	m
			1.1.1	chc1	CHOICE	m
			1.1.1.1	subscription-version-action	GraphicString	o
			1.1.1.1.1	version-id	Integer	m
			1.1.1.1.2	tn	NumberString	m
			1.1.1.2	subscription-version-tn-range	SEQUENCE	o
			1.1.1.2.1	start-tn	NumberString	m
			1.1.1.2.2	stop-tn	NumberString	m
			1.1.2	customer-disconnect-date	GeneralizedTime	m
			1.1.3	effective-release-date	GeneralizedTime	m
			1.2	DisconnectReply	SEQUENCE	m
			1.2.1	status	ENUMERATED	m
			1.2.2	version-id	SET OF Integer	o
subscription VersionLocal SMS-Create	{lnp-action 6}	o	1.1	LocalSMS-CreateAction	SEQUENCE	m
			1.1.1	actionId	Integer	m
			1.1.2	subscriptionVersionObjects	SET OF SEQUENCE	m
			1.1.2.1	tn-version-id	SET OF SEQUENCE	m

189

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
			1.1.2.1.1	tn	NumberString	m
			1.1.2.1.2	version-id	Integer	m
			1.1.2.2	subscription-data	SEQUENCE	m
			1.1.2.2.1	subscription-lrn	OCTET STRING	o
			1.1.2.2.2	subscription-new-current-sp	GraphicString	o
			1.1.2.2.3	subscription-activation-timestamp	GeneralizedTime	o
			1.1.2.2.4	subscription-customer-disconnect-date	GeneralizedTime	o
			1.1.2.2.5	subscription-class-dpc	CHOICE	m
			1.1.2.2.5.1	dpc-value	OCTET STRING	o
			1.1.2.2.5.2	no-value-needed	NULL	o
			1.1.2.2.6	subscription-class-ssn	CHOICE	m
			1.1.2.2.6.1	ssn-value	INTEGER	o
			1.1.2.2.6.2	no-value-needed	NULL	o
			1.1.2.2.7	subscription-lidb-dpc	CHOICE	m
			1.1.2.2.7.1	dpc-value	OCTET STRING	o
			1.1.2.2.7.2	no-value-needed	NULL	o
			1.1.2.2.8	subscription-lidb-ssn	CHOICE	m
			1.1.2.2.8.1	ssn-value	INTEGER	o
			1.1.2.2.8.2	no-value-needed	NULL	o
			1.1.2.2.9	subscription-isvm-dpc	CHOICE	m
			1.1.2.2.9.1	dpc-value	OCTET STRING	o
			1.1.2.2.9.2	no-value-needed	NULL	o
			1.1.2.2.10	subscription-isvm-ssn	CHOICE	m
			1.1.2.2.10.1	ssn-value	INTEGER	o
			1.1.2.2.10.2	no-value-needed	NULL	o
			1.1.2.2.11	subscription-cnam-dpc	CHOICE	m
			1.1.2.2.11.1	dpc-value	OCTET STRING	o
			1.1.2.2.11.2	no-value-needed	NULL	o
			1.1.2.2.12	subscription-cnam-ssn	CHOICE	m
			1.1.2.2.12.1	ssn-value	INTEGER	o
			1.1.2.2.12.2	no-value-needed	NULL	o
			1.1.2.2.13	subscription-end-user-location-value	NumberString	o
			1.1.2.2.14	subscription-end-user-location-type	NumberString	o
			1.1.2.2.15	subscription-billing-id	GraphicString	o
			1.1.2.2.16	subscription-lnp-type	ENUMERATED	m
			1.1.2.2.17	subscription-download-reason	ENUMERATED	m
			1.1.3	accessControl	SEQUENCE	m
			1.1.3.1	systemId	SEQUENCE
			1.1.3.1.1	serviceProvId	GraphicString	m
			1.1.3.1.2	npac-sms	GraphicString	m
			1.1.3.2	systemType	ENUMERATED	m
			1.1.3.3	userId	GraphicString	o
			1.1.3.4	listId	Integer	m
			1.1.3.5	keyId	Integer	m
			1.1.3.6	cmipDepartureTime	GeneralizedTime	m
			1.1.3.7	sequenceNumber	Integer	m
			1.1.3.8	function	SEQUENCE	m
			1.1.3.8.1	soaUnits	SEQUENCE	m
			1.1.3.8.1.1	soaMgmt	NULL	o
			1.1.3.8.1.2	networkDataMgmt	NULL	o
			1.1.3.8.2	lsmsUnits	SEQUENCE	m
			1.1.3.8.2.1	dataDownload	NULL	o
			1.1.3.8.2.2	networkDataMgmt	NULL	o
			1.1.3.8.2.3	query	NULL	o
			1.1.3.9	recoveryMode	BOOLEAN	m
			1.1.3.10	signature	BIT STRING	m
			1.2	LocalSMS-CreateReply	SEQUENCE	m
			1.2.1	status	ENUMERATED	m
subscription VersionModify	{lnp-action 7}	o	1.1	ModifyAction	SEQUENCE	m
			1.1.1	chc1	CHOICE	m
			1.1.1.1	subscription-version-action	GraphicString	o

190

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
			1.1.1.1.1	version-id	Integer	m
			1.1.1.1.2	tn	NumberString	m
			1.1.1.2	subscription-verion-tn-range	SEQUENCE	o
			1.1.1.2.1	start-tn	NumberString	m
			1.1.1.2.2	stop-tn	NumberString	m
			1.1.2	version-status	ENUMERATED	o
			1.1.3	data-to-modify	SEQUENCE	m
			1.1.3.1	subscription-lrn	OCTET STRING	o
			1.1.3.2	subscription-new-sp-due-date	GeneralizedTime	o
			1.1.3.3	subscription-old-sp-due-date	GeneralizedTime	o
			1.1.3.4	subscription-old-sp-authorization	BOOLEAN	o
			1.1.3.5	subscription-class-dpc	CHOICE	m
			1.1.3.5.1	dpc-value	OCTET STRING	o
			1.1.3.5.2	no-value-needed	NULL	o
			1.1.3.6	subscription-class-ssn	CHOICE	m
			1.1.3.6.1	ssn-value	INTEGER	o
			1.1.3.6.2	no-value-needed	NULL	o
			1.1.3.7	subscription-lidb-dpc	CHOICE	m
			1.1.3.7.1	dpc-value	OCTET STRING	o
			1.1.3.7.2	no-value-needed	NULL	o
			1.1.3.8	subscription-lidb-ssn	CHOICE	m
			1.1.3.8.1	ssn-value	INTEGER	o
			1.1.3.8.2	no-value-needed	NULL	o
			1.1.3.9	subscription-isvm-dpc	CHOICE	m
			1.1.3.9.1	dpc-value	OCTET STRING	o
			1.1.3.9.2	no-value-needed	NULL	o
			1.1.3.10	subscription-isvm-ssn	CHOICE	m
			1.1.3.10.1	ssn-value	INTEGER	o
			1.1.3.10.2	no-value-needed	NULL	o
			1.1.3.11	subscription-cnam-dpc	CHOICE	m
			1.1.3.11.1	dpc-value	OCTET STRING	o
			1.1.3.11.2	no-value-needed	NULL	o
			1.1.3.12	subscription-cnam-ssn	CHOICE	m
			1.1.3.12.1	ssn-value	INTEGER	o
			1.1.3.12.2	no-value-needed	NULL	o
			1.1.3.13	subscription-end-user-location-value	NumberString	o
			1.1.3.14	subscription-end-user-location-type	NumberString	o
			1.1.3.15	subscription-billing-id	GraphicString	o
			1.2	ModifyReply	SEQUENCE	m
			1.2.1	status	ENUMERATED
			1.2.2	chc1	CHOICE	m
			1.2.2.1	subscription-version-action	GraphicString	o
			1.2.2.1.1	version-id	Integer	m
			1.2.2.1.2	tn	NumberString	m
			1.2.2.2	subscription-version-tn-range	SEQUENCE	o
			1.2.2.2.1	start-tn	NumberString	m
			1.2.2.2.2	stop-tn	NumberString	o
			1.2.3	version-status	ENUMERATED	o
			1.2.4	data-to-modify	SEQUENCE	m
			1.2.4.1	subscription-lrn	OCTET STRING	o
			1.2.4.2	subscription-new-sp-due-date	GeneralizedTime	o
			1.2.4.3	subscription-old-sp-due-date	GeneralizedTime	o
			1.2.4.4	subscription-old-sp-authorization	BOOLEAN	o
			1.2.4.5	subscription-class-dpc	CHOICE	m
			1.2.4.5.1	dpc-value	OCTET STRING	o
			1.2.4.5.2	no-value-needed	NULL	o
			1.2.4.6	subscription-class-ssn	CHOICE	m
			1.2.4.6.1	ssn-value	INTEGER	o
			1.2.4.6.2	no-value-needed	NULL	o
			1.2.4.7	subscription-lidb-dpc	CHOICE	m
			1.2.4.7.1	dpc-value	OCTET STRING	o
			1.2.4.7.2	no-value-needed	NULL	o

191

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
			1.2.4.8	subscription-lidb-ssn	CHOICE	m
			1.2.4.8.1	ssn-value	INTEGER	o
			1.2.4.8.2	no-value-needed	NULL	o
			1.2.4.9	subscription-isvm-dpc	CHOICE	m
			1.2.4.9.1	dpc-value	OCTET STRING	o
			1.2.4.9.2	no-value-needed	NULL	o
			1.2.4.10	subscription-isvm-ssn	CHOICE	m
			1.2.4.10.1	ssn-value	INTEGER	o
			1.2.4.10.2	no-value-needed	NULL	o
			1.2.4.11	subscription-cnam-dpc	CHOICE	m
			1.2.4.11.1	dpc-value	OCTET STRING	o
			1.2.4.11.2	no-value-needed	NULL	o
			1.2.4.12	subscription-cnam-ssn	CHOICE	m
			1.2.4.12.1	ssn-value	INTEGER	o
			1.2.4.12.2	no-value-needed	NULL	o
			1.2.4.13	subscription-end-user-location-value	NumberString	o
			1.2.4.14	subscription-end-user-location-type	NumberString	o
			1.2.4.15	subscription-billing-id	GraphicString	o
subscription VersionNewSP-Cancellation Acknowledge	{lnp-action 8}	o	1.1	CancellationAcknowledgeAction	CHOICE	m
			1.1.1	version-id	Integer	m
			1.1.2	tn	NumberString	m
			1.2	CancellationAcknowledgeReply	ENUMERATED	m
subscription VersionNewSP-Conflict Resolution Acknowledge	{lnp-action 9}	o	1.1	ConflictResolutionAcknowledgeAction	CHOICE	m
			1.1.1	version-id	Integer	m
			1.1.2	tn	NumberString	m
			1.2	ConflictResolutionAcknowledge-Reply	ENUMERATED	m
subscription VersionNewSP-Conflict Resolution Pending	{lnp-action 10}	o	1.1	ConflictResolutionPendingAction	CHOICE	m
			1.1.1	version-id	Integer	m
			1.1.2	tn	NumberString	m
			1.2	ConflictResolutionPendingReply	ENUMERATED	m
subscription VersionNewSP-Create	{lnp-action 11}	o	1.1	NewSP-CreateAction	SEQUENCE	m
			1.1.1	chc1	CHOICE	m
			1.1.1.1	subscription-version-tn	GraphicString	o
			1.1.1.2	subscription-version-tn-range	SEQUENCE	o
			1.1.1.2.1	start-tn	NumberString	m
			1.1.1.2.2	stop-tn	NumberString	m
			1.1.2	subscription-lrn	OCTET STRING	o
			1.1.3	subscription-new-current-sp	GraphicString	o
			1.1.4	subscription-new-old-sp	GraphicString	o
			1.1.5	subscription-new-sp-due-date	GeneralizedTime	o
			1.1.6	subscription-class-dpc	CHOICE	m
			1.1.6.1	dpc-value	OCTET STRING	o
			1.1.6.2	no-value-needed	NULL	o
			1.1.7	subscription-class-ssn	CHOICE	m
			1.1.7.1	ssn-value	INTEGER	o
			1.1.7.2	no-value-needed	NULL	o
			1.1.8	subscription-lidb-dpc	CHOICE	m
			1.1.8.1	dpc-value	OCTET STRING	o
			1.1.8.2	no-value-needed	NULL	o
			1.1.9	subscription-lidb-ssn	CHOICE	m

192

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
			1.1.9.1	ssn-value	INTEGER	o
			1.1.9.2	no-value-needed	NULL	o
			1.1.10	subscription-isvm-dpc	CHOICE	m
			1.1.10.1	dpc-value	OCTET STRING	o
			1.1.10.2	no-value-needed	NULL	o
			1.1.11	subscription-isvm-ssn	CHOICE	m
			1.1.11.1	ssn-value	INTEGER	o
			1.1.11.2	no-value-needed	NULL	o
			1.1.12	subscription-cnam-dpc	CHOICE	m
			1.1.12.1	dpc-value	OCTET STRING	o
			1.1.12.2	no-value-needed	NULL	o
			1.1.13	subscription-cnam-ssn	CHOICE	m
			1.1.13.1	ssn-value	INTEGER	o
			1.1.13.2	no-value-needed	NULL	o
			1.1.14	subscription-end-user-location-value	NumberString	o
			1.1.15	subscription-end-user-location-type	NumberString	o
			1.1.16	subscription-billing-id	GraphicString	o
			1.1.17	subscription-lnp-type	ENUMERATED	m
			1.1.18	subscription-porting-to-original-sp-switch	BOOLEAN	m
			1.2	NewSP-CreateReply	SEQUENCE	m
			1.2.1	status	ENUMERATED	m
			1.2.2	chc1	CHOICE	m
			1.2.2.1	subscription-version-tn	GraphicString	o
			1.2.2.2	subscription-version-tn-range	SEQUENCE	o
			1.2.2.2.1	start-tn	NumberString	m
			1.2.2.2.2	stop-tn	NumberString	m
			1.2.3	subscription-lrn	OCTET STRING	o
			1.2.4	subscription-new-current-sp	GraphicString	o
			1.2.5	subscription-new-old-sp	GraphicString	o
			1.2.6	subscription-new-sp-due-date	GeneralizedTime	o
			1.2.7	subscription-class-dpc	CHOICE	m
			1.2.7.1	dpc-value	OCTET STRING	o
			1.2.7.2	no-value-needed	NULL	o
			1.2.8	subscription-class-ssn	CHOICE	m
			1.2.8.1	ssn-value	INTEGER	o
			1.2.8.2	no-value-needed	NULL	o
			1.2.9	subscription-lidb-dpc	CHOICE	m
			1.2.9.1	dpc-value	OCTET STRING	o
			1.2.9.2	no-value-needed	NULL	o
			1.2.10	subscription-lidb-ssn	CHOICE	m
			1.2.10.1	ssn-value	INTEGER	o
			1.2.10.2	no-value-needed	NULL	o
			1.2.11	subscription-isvm-dpc	CHOICE	m
			1.2.11.1	dpc-value	OCTET STRING	o
			1.2.11.2	no-value-needed	NULL	o
			1.2.12	subscription-isvm-ssn	CHOICE	m
			1.2.12.1	ssn-value	INTEGER	o
			1.2.12.2	no-value-needed	NULL	o
			1.2.13	subscription-cnam-dpc	CHOICE	m
			1.2.13.1	dpc-value	OCTET STRING	o
			1.2.13.2	no-value-needed	NULL	o
			1.2.14	subscription-cnam-ssn	CHOICE	m
			1.2.14.1	ssn-value	INTEGER	o
			1.2.14.2	no-value-needed	NULL	o
			1.2.15	subscription-end-user-location-value	NumberString	o
			1.2.16	subscription-end-user-location-type	NumberString	o
			1.2.17	subscription-billing-id	GraphicString	o
			1.2.18	subscription-lnp-type	ENUMERATED	m
			1.2.19	subscription-porting-to-original-sp-switch	BOOLEAN	m
subscription VersionOldSP-Cancellation Acknowledge	{lnp-action 12}	o	1.1	CancellationAcknowledgeAction	CHOICE	m

193

Action Label	Object Identifier	Status	Subindex	Action Field	Constraints and Values	Base Status	Additional Information
			1.1.1	version-id	Integer	m
			1.1.2	tn	NumberString	m
			1.2	CancellationAcknowledgeReply	ENUMERATED	m
subscription VersionOldSP-Conflict Resolution Acknowledge	{lnp-action 13}	o	1.1	ConflictResolutionAcknowledge-Action	CHOICE	m
			1.1.1	version-id	Integer	m
			1.1.2	tn	NumberString	m
			1.2	ConflictResolutionAcknowledge-Reply	ENUMERATED	m
subscription VersionOldSP-Create	{lnp-action 14}	o	1.1	OldSP-CreateAction	SEQUENCE	m
			1.1.1	chc1	CHOICE	m
			1.1.1.1	subscription-version-tn	NumberString	m
			1.1.1.2	subscription-version-tn-range	SEQUENCE	m
			1.1.1.2.1	tn-start	NumberString	m
			1.1.1.2.2	tn-stop	NumberString	m
			1.1.2	subscription-new-current-sp	NumberString	m
			1.1.3	subscription-old-sp	NumberString	m
			1.1.4	subscription-old-sp-due-date	GeneralizedTime	m
			1.1.5	subscription-old-sp-authorization	BOOLEAN
			1.2	OldSP-CreationReply	SEQUENCE	m
			1.2.1	status	ENUMERATED	m
			1.2.2	invalid-data	SEQUENCE	m
			1.2.2.1	chc1	CHOICE	m
			1.2.2.1.1	subscription-version-tn	NumberString	m
			1.2.2.1.2	subscription-version-tn-range	SEQUENCE	m
			1.2.2.1.2.1	tn-start	NumberString	m
			1.2.2.1.2.2	tn-stop	NumberString	m
			1.2.2.2	subscription-new-current-sp	NumberString	m
			1.2.2.3	subscription-old-sp	NumberString	m
			1.2.2.4	subscription-old-sp-due-date	GeneralizedTime	m
			1.2.2.5	subscription-old-sp-authorization	BOOLEAN	m

9.14.5.lnpSubscriptions Notifications

Exhibit 56. lnpSubscriptions Notifications

Notification Label	Object Identifier	Subindex	Notification Field	Value of object identifier of attribute type associated with field	Constraints and values	Base Status
subscriptionVersionLocalSMS-ActionResults		1.1	LocalSMS-ActionResults		SEQUENCE	m
		1.1.1	actionId	{lnp-attribute 2}	Integer	m
		1.1.2	status	{lnp-attribute 3}	ENUMERATION	m
		1.1.3	failed-tn-list	{lnp-attribute 15}	SET OF SEQUENCE	o
		1.1.3.1	subscriptionVersionId		Integer	m
		1.1.3.2	tn		NumberString	m
		1.1.3.3	errorId		Integer	m
		1.1.4	time-of-completion	{lnp-attribute 25}	Integer	m
		1.1.5	accessControl	{lnp-attribute 1}	SEQUENCE	m
		1.1.5.1	systemId		SEQUENCE	m
		1.1.5.1.1	serviceProvId		GraphicString	m
		1.1.5.1.2	npac-sms		GraphicString	m
		1.1.5.2	systemType		ENUMERATED	m

194

Notification Label	Object Identifier	Subindex	Notification Field	Value of object identifier of attribute type associated with field	Constraints and values	Base Status
		1.1.5.3	userId		GraphicString	o
		1.1.5.4	listId		Integer	m
		1.1.5.5	keyId		Integer	m
		1.1.5.6	cmipDepartureTime		GeneralizedTime	m
		1.1.5.7	sequenceNumber		Integer	m
		1.1.5.8	function		SEQUENCE	m
		1.1.5.8.1	soaUnits		SEQUENCE	m
		1.1.5.8.1.1	soaMgmt		NULL	o
		1.1.5.8.1.2	networkDataMgmt		NULL	o
		1.1.5.8.2	lsmsUnits		SEQUENCE	m
		1.1.5.8.2.1	dataDownload		NULL	o
		1.1.5.8.2.2	networkDataMgmt		NULL	o
		1.1.5.8.2.3	query		NULL	o
		1.1.5.9	recoveryMode		BOOLEAN	m
		1.1.5.10	signature		BIT STRING	m

9.15.serviceProv Tables

9.15.1.serviceProv Packages

Exhibit 57. serviceProv Packages

Package Label	Object Identifier	Condition	Base Status	Additional– Information
serviceProvPkg	(not registered)	Mandatory	m
serviceProvNetworkPkg	(not registered)	Mandatory	m
serviceProvBillingAddressPkg	{lnp-package 3}	“if the service provider has billing address and contact information”	o
serviceProvSOA-AddressPkg	{lnp-package 9}	“if the service provider has SOA address and contact information”	o
serviceProvLSMS-AddressPkg	{lnp-package 5}	“if the service provider has LSMS address and contact information”	o
serviceProvWebAddressPkg	{lnp-package 11}	“if the service provider has Web address and contact information”	o
serviceProvNetAddressPkg	{lnp-package 6}	“if the service provider has network and communication facilities address and contact information”	o
serviceProvConflictAddressPkg	{lnp-package 4}	“if the service provider has conflict resolution interface address and contact information”	o
serviceProvOperationsAddressPkg	{lnp-package 7}	“if the service provider has operations address and contact information”	o
serviceProvUserAdminAddressPkg	{lnp-package 10}	“if the service provider has user administration and interface address and contact information”	o
serviceProvRepairCenterInfoPkg	{lnp-package 8}	“if the service provider has repair contact information”	o

9.15.2.serviceProv Name Bindings

Exhibit 58. serviceProv Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
serviceProv-lnpServiceProvs	{lnp-nameBinding 10}	lnpServiceProvs and subclasses	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

195

9.15.3.serviceProv Attributes

Exhibit 59. serviceProv Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
serviceProv Address	{lnp-attribute 26}	o	m	m
serviceProvSysLinkInfo	{lnp-attribute 44}	o	m	m
serviceProvTunables	{lnp-attribute 45}		m	m
npacCustomerAllowableFunctions	{lnp-attribute 24}		m	m

9.15.4.serviceProv Actions

No actions supported for this object.

9.15.5.serviceProv Notifications

No notifications supported for this object.

9.16.serviceProvLRN Tables

9.16.1.serviceProvLRN Packages

Exhibit 60. serviceProvLRN Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
serviceProvLRNPkg	(not registered)	Mandatory	m

9.16.2.serviceProvLRN Name Bindings

Exhibit 61. serviceProvLRN Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
serviceProvLRN-serviceProvNetwork	{lnp-nameBinding 11}		1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

196

9.16.3.serviceProvLRN Attributes

Exhibit 62. serviceProvLRN Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
objectClass	{9 3 2 7 65}
nameBinding	{9 3 2 7 63}
packages	{9 3 2 7 66}
allomorphs	{9 3 2 7 50}
serviceProv LRN-ID	{lnp-attribute 32}	m	m
serviceProv LRN-Value	{lnp-attribute 33}	o	m
serviceProv Download Reason	{lnp-attribute 29}	o	m
serviceProv LRNCreation TimeStamp	{lnp-attribute 31}		m

9.16.4.serviceProvLRN Actions

No actions supported for this object.

9.16.5.serviceProvLRN Notifications

No notifications supported for this object.

9.17.serviceProvNetwork Tables

9.17.1.serviceProvNetwork Packages

Exhibit 63. serviceProvNetwork Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
serviceProvNetworkPkg	(not registered)	Mandatory	m

9.17.2.serviceProvNetwork Name Bindings

Exhibit 64. serviceProvNetwork Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
serviceProvNetwork-lnpNetwork	{lnp-nameBinding 12}	lnpNetwork and subclasses	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

197

9.17.3.serviceProvNetwork Attributes

Exhibit 65. serviceProvNetwork Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
objectClass	{9 3 2 7 65}
nameBinding	{9 3 2 7 63}
packages	{9 3 2 7 66}
allomorphs	{9 3 2 7 50}
serviceProvID	{lnp-attribute 30}		m
serviceProvName	{lnp-attribute 35}		m	m

9.17.4.serviceProvNetwork Actions

No actions supported for this object.

9.17.5.serviceProvNetwork Notifications

No notifications supported for this object.

9.18.serviceProvNPA-NXX Tables

9.18.1.serviceProvNPA-NXX Packages

Exhibit 66. serviceProvNPA-NXX Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
serviceProvNPA-NXX-Pkg	(not registered)	Mandatory	m

9.18.2.serviceProvNPA-NXX Name Bindings

Exhibit 67. serviceProvNPA-NXX Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
serviceProvNPA-NXX-serviceProvNetwork	{lnp-nameBinding 13}		1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m

198

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
			1.6	Delete contained objects

9.18.3.serviceProvNPA-NXX Attributes

Exhibit 68. serviceProvNPA-NXX Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
objectClass	{9 3 2 7 65}
nameBinding	{9 3 2 7 63}
packages	{9 3 2 7 66}
allomorphs	{9 3 2 7 50}
serviceProv NPA-NXX-ID	{lnp-attribute 39}	m	m
serviceProv NPA-NXX-Value	{lnp-attribute 40}	o	m
serviceProvDownloadReason	{lnp-attribute 29}	o	m
serviceProvNPA-NXX-EffectiveTimeStamp	{lnp-attribute 38}	o	m
serviceProvNPA-NXX-CreationTimeStamp	{lnp-attribute 37}

9.18.4.serviceProvNPA-NXX Actions

No actions supported for this object.

9.18.5.serviceProvNPA-NXX Notifications

No notifications provided for this object.

9.19.subscriptionAudit Tables

9.19.1.subscriptionAudit Packages

Exhibit 69. subscriptionAudit Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
subscriptionAuditPkg	(not registered)	Mandatory	m
“Rec. M.3100 : 1992” :attributeValueChangeNotificationPackage	{0 0 12 3100 0 4 4}	Mandatory	m
“Rec. M.3100 : 1992” :createDeleteNotificationPackage	{0 0 12 3100 0 4 10}	Mandatory	m

199

9.19.2.subscriptionAudit Name Bindings

Exhibit 70. subscriptionAudit Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
subscriptionAudit-lnpAudits	{lnp-nameBindings 14}	lnpAudits and subclasses	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.19.3.subscriptionAudit Attributes

Exhibit 71. subscriptionAudit Attributes

		Base Status
Attribute Label	Object Identifier	set-by-create	get	replace	add	remove	set default	Additional Information
objectClass	{9 3 2 7 65}
nameBinding	{9 3 2 7 63}
packages	{9 3 2 7 66}
allomorphs	{9 3 2 7 50}
subscriptionAuditId	{lnp-attribute 50}	m	m
subscriptionAuditName	{lnp-attribute 51}	o	m
subscriptionAuditStatus	{lnp-attribute 56}	o	m
subscriptionAuditAttribute List	{lnp-attribute 49}	o	m
subscriptionAuditTN-Range	{lnp-attribute 59}	o	m
subscriptionAuditTN-ActivationRange	{lnp-attribute 57}	o	m
subscriptionAuditServiceProvIdRange	{lnp-attribute 55}	o	m
serviceProvId	{lnp-attribute 6}	o	m
subscription AuditTN-NotificationNumber	{lnp-attribute 58}		m
subscriptionAuditNumberof TNs	{lnp-attribute 52}		m
subscriptionAuditNumberof TNsComplete	{lnp-attribute 53}		m
subscriptionAuditRequestingSP	{lnp-attribute 54}		m

9.19.4.subscriptionAudit Actions

No actions supported for this object.

200

9.19.5.subscriptionAudit Notifications

Exhibit 72. subscriptionAudit Notifications

Notification Label	Object Identifier	Subindex	Notification Field	Value of object identifier of attribute type associated with field	Constraints and values	Base Status
subscriptionAuditResults	{lnp-notification 3}	1.1	AuditResults		SEQUENCE	m
		1.1.1	status	{lnp-attribute 13}	ENUMERATED	m
		1.1.2	audit-response-level	{lnp-attribute 9}	ENUMERATED	m
		1.1.3	failed-service-provider-list	{lnp-attribute 11}	GENERALIZED TIME	m
		1.1.3.1	service-prov-id	{lnp-attribute 6}	GRAPHICSTRING(4)	m
		1.1.3.2	service-prov-name	{lnp-attribute 35}	GRAPHICSTRING(40)	m
		1.1.4	number-of-discrepancies	{lnp-attribute 12}	INTEGER	m
		1.1.5	time-of-completion	{lnp-attribute 10}	GENERALIZEDTIME	m
		1.1.6	access-control	{lnp-attribute 1}	SEQUENCE	m
subscriptionAudit-DiscrepancyRpt	{lnp-notification 2}	2.1	AuditDiscrepancyRpt		SEQUENCE	m
		2.1.1	TN	{lnp-attribute 7}	NUMBERSTRING (10)	m
		2.1.2	Version-ID	{lnp-attribute 8}	INTEGER	m
		2.1.3	lsms-serviceProv-ID	{lnp-attribute 6}	NUMBERSTRING (8)	m
		2.1.4	failure-Reason	{lnp-attribute 5}	CHOICE	m
		2.1.4.1	TN-Version-Missing		NULL
		2.1.4.2	mismatchData		SEQUENCE
		2.1.4.2.1	SEQ0		SEQUENCE	c:0.1
		2.1.4.2.1.1	lsms-subscriptionLRN		OCTETSTRING (5)	c:0.1
		2.1.4.2.1.2	npac-subscriptionLRN		OCTETSTRING (5)	c:0.1
		2.1.4.2.2	SEQ1		SEQUENCE	c:0.2
		2.1.4.2.2.1	lsms-subscriptionNewCurrentSP		NUMBERSTRING (10)	c:0.2
		2.1.4.2.2.2	npac-subscriptionNewCurrentSP		NUMBERSTRING (10)	c:0.2
		2.1.4.2.3	SEQ2		SEQUENCE	c:0.3
		2.1.4.2.3.1	lsms-subscriptionNewCurrentSP-ActivationTimeStamp		GeneralizedTime	c:0.3
		2.1.4.2.3.2	npac-subscriptionNewCurrentSP-ActivationTimeStamp		GeneralizedTime	c:0.3
		2.1.4.2.3.3	lsms-subscriptionCustomerDisconnect-Date		GeneralizedTime
		2.1.4.2.3.4	npac- subscriptionCustomerDisconnect-Date		GeneralizedTime
		2.1.4.2.4	SEQ3		SEQUENCE	c:0.4
		2.1.4.2.4.1	lsms-subscriptionCLASS-DPC		DPC	c:0.4
		2.1.4.2.4.2	npac- subscriptionCLASS-DPC		DPC	c:0.4
		2.1.4.2.5	SEQ4		SEQUENCE	c:0.5
		2.1.4.2.5.1	lsms-subscriptionCLASS-SSN		SSN	c:0.5
		2.1.4.2.5.2	npac- subscriptionCLASS-SSN		SSN	c:0.5
		2.1.4.2.6	SEQ5		SEQUENCE	c:0.6
		2.1.4.2.6.1	lsms-subscriptionLIDB-DPC		DPC	c:0.6
		2.1.4.2.6.2	npac- subscriptionLIBD-DPC		DPC	c:0.6
		2.1.4.2.7	SEQ6		SEQUENCE	c:0.7
		2.1.4.2.7.1	lsms-subscriptionLIDB-SSN		SSN	c:0.7
		2.1.4.2.7.2	npac-subscriptionLIDB-SSN		SSN	c:0.7
		2.1.4.2.8	SEQ7		SEQUENCE	c:0.8
		2.1.4.2.8.1	lsms-subscriptionISVM-DPC		DPC	c:0.8
		2.1.4.2.8.2	npac-subscriptionISVM-DPC		DPC	c:0.8
		2.1.4.2.9	SEQ8		SEQUENCE	c:0.9
		2.1.4.2.9.1	lsms-subscriptionISVM-SSN-SSN		SSN	c:0.9
		2.1.4.2.9.2	npac-subscriptionISVM-SPC		DPC	c:0.9
		2.1.4.2.10.	SEQ9		SEQUENCE	c:0.10
		2.1.4.2.10.1	lsms-subscriptionCNAM-DPC		DPC	c:0.10
		2.1.4.2.10.2	npac-subscriptionCNAM-DPC		DPC	c:0.10
		2.1.4.2.11	SEQ10		SEQUENCE	c:0.11
		2.1.4.2.11.1	lsms-subscriptionCNAM-SSN		SSN	c:0.11
		2.1.4.2.11.2	npac-subscriptionCNAM-SSN		SSN	c:0.11
		2.1.4.2.12	SEQ11		SEQUENCE	c:0.12
		2.1.4.2.12.1	lsms-subscriptionEndUserLocationValue		EndUserLocationValue	c:0.12

201

Notification Label	Object Identifier	Subindex	Notification Field	Value of object identifier of attribute type associated with field	Constraints and values	Base Status
		2.1.4.2.12.2	npac-subscriptionEndUserLocationValue		EndUserLocationValue	c:0.12
		2.1.4.2.13	SEQ12		SEQUENCE	c:0.13
		2.1.4.2.13.1	lsms-subscriptionEndUserLocationType		EndUserLocation Type	c:0.13
		2.1.4.2.13.2	npac-subscriptionEndUserLocationType		EndUserLocation Type	c:0.13
		2.1.4.2.14	SEQ13		SEQUENCE	c:0.14
		2.1.4.2.14.1	lsms-subscriptionBillingId		BillingId	c:0.14
		2.1.4.2.14.2	npac-subscriptionBillingId		BillingId	c:0.14
		2.1.4.2.15.1	lsms-subscriptionLNPType		LNPType	c:0.30
		2.1.4.2.15.2	npac-subscriptionLNPType		LNPType	c:0.30
		2.1.5	access-control	{lnp-attribute 1}
Rec. X. 721 | ISO/IEC 10165-2 : 1992 attributeValueChange	{2 93 2 10 1}	3.1	AttributeValueChangeInfo		information Syntex SEQUENCE	m
		3.1.1	sourceIndicator	{2 9 3 2 7 26}	ENUMERATED	o
		3.1.2	attributeIdentifier List	{2 9 3 2 7 8}	SET OF AttributeId	o
		3.1.3	attributeValue ChangeDefinition	{2 9 3 2 7 10}	SET OF SEQUENCE	m
		3.13.1	attributeID	—	Attributed	m
		3.1.3.2	oldAttributeID	—	ANY DEFINED BY attributeID	o
		3.1.3.3	newAttributeID	—	ANY DEFINED BY attributeID	m
		3.1.4	notificationIdentifier	{2 9 3 2 7 19}	INTEGER	o
		3.1.5	correlatedNotifications	{2 9 3 2 7 12}	SET OF SEQUENCE	o
		3.1.5.1	correlatedNotifications	{2 9 3 2 7 12}	SET OF INTEGER	c:m
		3.1.5.2	sourceObjectInst	—	objectInstance	c:o
		3.1.6	additionalText	{2 9 3 2 7 7}	graphicString	o
		3.1.7	additionalInformation	{2 9 3 2 7 6}	SET OF SEQUENCE	o
		3.1.7.1	identifier	—	OBJECT IDENTIFIER	c:m
		3.1.7.2	significance	—	BOOLEAN	c:o
		3.1.7.3	information	—	ANY DEFINED BY identifier	c:m
Rec. X. 721 | ISO/IEC 10165-2 : 1992 objectCreation	{2 93 2 10 6}	4.1	Objectinfo		information Syntex SEQUENCE	m
		4.1.1	sourceIndicator	{2 9 3 2 7 26}	ENUMERATED	o
		4.1.2	attributeList	{2 9 3 2 7 9}	SET OF AttributeId	o
		4.1.3	notificationIdentifier	{2 9 3 2 7 16}	INTEGER	o
		4.1.4	correlatedNotifications	{2 9 3 2 7 12}	SET OF SEQUENCE	o
		4.1.4.1	correlatedNotifications	{2 9 3 2 7 12}	SET OF INTEGER	c:m
		4.1.4.2	sourceObjectInst	—	objectInstance	c:o
		4.1.5	additionalText	{2 9 3 2 7 7}	graphicString	o
		4.1.6	additionalInformation	{2 9 3 2 7 6}	SET OF SEQUENCE	o
		4.1.6.1	identifier	—	OBJECT IDENTIFIER	c:m
		4.1.6.2	significance	—	BOOLEAN	c:o
		4.1.6.3	information	—	ANY DEFINED BY identifier	c:m
Rec. X. 721 | ISO/IEC 10165-2 : 1992 objectDeletion	{2 93 2 10 6}	5.1	Objectinfo		information Syntex SEQUENCE	m
		5.1.1	sourceIndicator	{2 9 3 2 7 26}	ENUMERATED	o
		5.1.2	attributeList	{2 9 3 2 7 9}	SET OF Attribute	o
		5.1.3	notificationIdentifier	{2 9 3 2 7 16}	INTEGER	o
		5.1.4	correlatedNotifications	{2 9 3 2 7 12}	SET OF SEQUENCE	o
		5.1.4.1	correlatedNotifications	{2 9 3 2 7 12}	SET OF INTEGER	c:m
		5.1.4.2	sourceObjectInst	—	objectInstance	c:o
		5.1.5	additionalText	{2 9 3 2 7 7}	graphicString	o
		5.1.6	additionalInformation	{2 9 3 2 7 6}	SET OF SEQUENCE	o
		5.1.6.1	identifier	—	OBJECT IDENTIFIER	c:m
		5.1.6.2	significance	—	BOOLEAN	c:o
		5.1.6.3	information	—	ANY DEFINED BY identifier	c:m

202

9.20.subscriptionVersion Tables

9.20.1.subscriptionVersion Packages

Exhibit 73. subscriptionVersion Packages

Package Label	Object Identifier	Condition	Base Status	Addition Information
subscriptionVersionPkg	(not registered)	Mandatory	m

9.20.2.subscriptionVersion Name Bindings

Exhibit 74. subscriptionVersion Name Bindings

Name Bindings Label	Object Identifier	Superior Class	Subindex	Operation	Base Status	Additional Information
subscriptionVersion-lnpSubscriptions	{lnp-nameBinding 15}	lnpSubscriptions and subclasses	1.1	Create support	m
			1.2	Create with reference object	m
			1.3	Create with automatic instance naming	m
			1.4	Delete support	m
			1.5	Delete only if no contained objects	m
			1.6	Delete contained objects

9.20.3.subscriptionVersion Attributes

Exhibit 75. subscriptionVersion Attributes

		Base Status
Attribute Label	Object Identifier	set -by -create	get	replace	add	remove	set default	remove	set default	Additional Information
objectClass	{9 3 2 7 65}
nameBinding	{9 3 2 7 63}
packages	{9 3 2 7 66}
allomorphs	{9 3 2 7 50}
subscriptionVersionId	{lnp-attribute 99}	m	m
subscriptionTN	{lnp-attribute 97}	o	m	m
subscriptionNewCurrentSP	{lnp-attribute 83}	o	m	m
subscriptionActivationTimeStamp	{lnp-attribute 48}	o	m	m
subscriptionCLASS-DPC	{lnp-attribute 63}	o	m	m
subscriptionCLASS-SSN	{lnp-attribute 64}	o	m	m
subscriptionLIDB-DCP	{lnp-attribute 78}	o	m	m
subscriptionLIDB-SSN	{lnp-attribute 79}	o	m	m
subscriptionCNAM-DPC	{lnp-attribute 65}	o	m	m
subscriptionCNAM-SSN	{lnp-attribute 66}	o	m	m
subscriptionISVM-DPC	{lnp-attribute 76}	o	m	m
subscriptionISVM-SSN	{lnp-attribute 77}	o	m	m
subscriptionEndUserLocationValue	{lnp-attribute 73}	o	m	m
subscriptionEndUserLocationType	{lnp-attribute 74}	o	m	m
subscriptionBillingId	{lnp-attribute 60}	o	m	m

203

		Base Status
Attribute Label	Object Identifier	set -by -create	get	replace	add	remove	set default	remove	set default	Additional Information
subscriptionLNPType	{lnp-attribute 80}	o	m	m
subscriptionLRN	{lnp-attribute 81}	o	m	m
subscriptionDownLoadReason	{lnp-attribute 71}	o	m	m
subscriptionCustomerDisconnectDate	{lnp-attribute 69}	o	m	m

9.20.4.subscriptionVersion Actions

No actions are supported for this object.

9.20.5.subscriptionVersion Notifications

No notifications are supported for this object.

9.21.subscriptionVersionNPAC Tables

9.21.1.subscriptionVersionNPAC Packages

Exhibit 76. subscriptionVersionNPAC Packages

Package Label	Object Identifier	Condition	Base Status	Additional Information
subscriptionVersionNPAC-Pkg	(not registered)	Mandatory	m
“Rec. M. 3100 : 1992”:attributeValueChangeNotification Package	{0 0 13 3100 0 4 4}	Mandatory	m
“Rec. M. 3100 : 1992”:createDeleteNotificationPackage	{0 0 13 3100 0 4 10}	Mandatory	m

9.21.2.subscriptionVersionNPAC Name Bindings

No name binding are supported for this object

9.21.3.subscriptionVersionNPAC Attributes

204

Exhibit 77. subscriptionVersionNPAC Attributes

		Base Status
Attribute Label	Object Identifier	se t -by -create	ge t	re place	add	remove	setde fault	Additional Information
subscriptionVersion Status	{lnp-attribute 100}	m	m
subscriptionOldSP	{lnp-attribute 88}	m	m
subscriptionNewSP-DueDate	{lnp-attribute 87}	m	m
subscriptionOldSP-DueDate	{lnp-attribute 93}	m	m
subscriptionOldSP-Authorization	{lnp-attribute 89}	m	m
subscription OldSP-AuthorizationTimeStamp	{lnp-attribute 90}	m	m
subscriptionBroadcastTimeStamp	{lnp-attribute 61}	m	m
subscriptionConflictTimeStamp	{lnp-attribute 67}	m	m
subscriptionCancellationTimeStamp	{lnp-attribute 62}	m	m
subscriptionOldTimeStamp	{lnp-attribute 94}	m	m
subscriptionModifiedTimeStamp	{lnp-attribute 82}	m	m
subscriptionCreationTimeStamp	{lnp-attribute 68}	m	m
subscriptionOldSP-CancellationTimeStamp	{lnp-attribute 91}	m	m
subscriptionNewSP-CancellationTimeStamp	{lnp-attribute 84}	m	m
subscriptionOldSP-ConflictResolutionTimeStamp	{lnp-attribute 92}	m	m
subscriptionNewSP-ConflictResolutionTimeStamp	{lnp-attribute 85}	m	m
subscriptionPortingToOriginal-SPSwitch	{lnp-attribute 95}	m	m
subscriptionEffectiveReleaseDate	{lnp-attribute 72}	m	m
subscriptionDisconnectCompleteTimeStamp	{lnp-attribute 70}	m	m
subscriptionPreCancellationStatus	{lnp-attribute 96}	m	m
subscriptionFailed-SP-List	{lnp-attribute 75}	m	m

9.21.4.subscriptionVersionNPAC Actions

No actions are supported for this object.

9.21.5.subscriptionVersionNPAC Notifications

Exhibit 78. subscriptionVersionNPAC Notifications

Notification Label	Object Identifier	Subindex	Notification Field	Value of object identifier of attribute type associated with field	Constraints and values	Base Status
subscriptionVersionNewSP-CreateRequest	{lnp-notification 9}	1.1	VersionCreateConcurrenceRequest		SEQUENCE	m
		1.1.1	TN	{lnp-attribute 97}	NUMBERSTRING(10)	m
		1.1.2	VersionID	{lnp-attribute 99}	INTEGER	m
		1.1.3	lnpType	{lnp-attribute 80}	ENUMERATED	m
		1.1.4	serviceProvId	{lnp-attribute 83}	NUMBERSTRING(8)	m
		1.1.5	Authorization	{lnp-attribute 8}	Boolean	m
		1.1.6	serviceProvId-CreationTimeStamp	{lnp-attribute 86}	GeneralizedTime	m
subscriptionVersion OldSP-ConcurrenceRequest	{lnp-notification 10}	2.1	VersionCreateConcurrenceRequest		SEQUENCE	m
		2.1.1	TN	{lnp-attribute 97}	NUMBERSTRING(10)	m
		2.1.2	VersionID	{lnp-attribute 99}	INTEGER	m
		2.1.3	lnpType	{lnp-attribute 80}	ENUMERATED	m
		2.1.4	serviceProvId	{lnp-attribute 88}	NUMBERSTRING(8)	m
		2.1.5	serviceProvId-Authorization	{lnp-attribute 89}	Boolean	m
		2.1.6	serviceProvId-AuthorizationTimeStamp	{lnp-attribute 90}	GeneralizedTime	m
subscriptionVersion ConflictResolution AcknowledgeRequest	{lnp-notification 5}	3.1	VersionConflictResolutionAcknowledgeRequest		SEQUENCE	m
		3.1.1	Tn	{lnp-attribute 97}	NUMBERSTRING(10)	m
		3.1.2	version-ID	{lnp-attribute 99}	Integer	m
		3.1.3	lnp-type	{lnp-attribute 80}	enumerated	m
		3.1.4	access-Control	{lnp-attribute 1}	SEQUENCE	m
subscriptionVersionCancellation-AcknowlegeRequest	{lnp-notification 4}	4.1	VersionCancellationAcknowlegeRequest		SEQUENCE	m
		4.1.1	Tn	{lnp-attribute 97}	NUMBERSTRING(10)	m

205

Notification Label	Object Identifier	Subindex	Notification Field	Value of object identifier of attribute type associated with field	Constraints and values	Base Status
		4.1.2	version-ID	{lnp-attribute 99}	Integer	m
		4.1.3	lnp-type	{lnp-attribute 80}	enumerated	m
		4.1.4	access-Control	{lnp-attribute 1}	SEQUENCE	m
subscriptionVersion StatusAttributeValue Change	{lnp-notification 11}	5.1	VersionStatusAttributeValve Change		SEQUENCE	m
		5.1.1	valveChangeInfo		SEQUENCE	m
		5.1.2	failedServiceProvs		SET OF SEQUENCE	m
		5.1.2.1	serviceProvId	{lnp-attribute 30}	NUMBERSTRING(8)	m
		5.1.2.2	serviceProvName	{lnp-attribute 35}	GRAPHICSTRING(40)	m
Rec.X.721 | ISO/IEC 10165-2: 1992 attributeValue Change	(2 93 2 10 1)	6.1	AttributeValueChangeInfo		information Syntax SEQUENCE	m
		6.1.1	sourceIndicator	{2 9 3 2 7 26}	ENUMERATED	o
		6.1.2	attributeIdentifier List	{2 9 3 2 7 8}	SET OF AttributeId	o
		6.1.3	attributeValue ChangeDefinition	{2 9 3 2 7 10}	SET OF SEQUENCE	m
		6.13.1	attributeID	—	Attributed	m
		6.1.3.2	oldAttributeID	—	ANY DEFINED BY attributeID	o
		6.1.3.3	newAttributeID	—	ANY DEFINED BY attributeID	m
		6.1.4	notificationIdentifier	{2 9 3 2 7 19}	INTEGER	o
		6.1.5	correlatedNotifications	{2 9 3 2 7 12}	SET OF SEQUENCE	o
		6.1.5.1	correlatedNotifications	{2 9 3 2 7 12}	SET OF INTEGER	c:m
		6.1.5.2	sourceObjectInst	—	objectInstance	c:o
		6.1.6	additionalText	{2 9 3 2 7 7}	graphicString	o
		6.1.7	additionalInformation	{2 9 3 2 7 6}	SET OF SEQUENCE	o
		6.1.7.1	identifier	—	OBJECT IDENTIFIER	c:m
		6.1.7.2	significance	—	BOOLEAN	c:o
		6.1.7.3	information	—	ANY DEFINED BY identifier	c:m
Rec.X.721 | ISO/IEC 10165-2: 1992 objectCreation	(2 93 2 10 6)	7.1	Objectinfo		information Syntax SEQUENCE	m
		7.1.1	sourceIndicator	{2 9 3 2 7 26}	ENUMERATED	o
		7.1.2	attributeList	{2 9 3 2 7 9}	SET OF AttributeId	o
		7.1.3	notificationIdentifier	{2 9 3 2 7 16}	INTEGER	o
		7.1.4	correlatedNotifications	{2 9 3 2 7 12}	SET OF SEQUENCE	o
		7.1.4.1	correlatedNotifications	{2 9 3 2 7 12}	SET OF INTEGER	c:m
		7.1.4.2	sourceObjectInst	—	objectInstance	c:o
		7.1.5	additionalText	{2 9 3 2 7 7}	graphicString	o
		7.1.6	additionalInformation	{2 9 3 2 7 6}	SET OF SEQUENCE	o
		7.1.6.1	identifier	—	OBJECT IDENTIFIER	c:m
		7.1.6.2	significance	—	BOOLEAN	c:o
		7.1.6.3	information	—	ANY DEFINED BY identifier	c:m
Rec.X.721 | ISO/IEC 10165-2: 1992 objectDeletion	(2 93 2 10 6)	8.1	Objectinfo		information Syntax SEQUENCE	m
		8.1.1	sourceIndicator	{2 9 3 2 7 26}	ENUMERATED	o
		8.1.2	attributeList	{2 9 3 2 7 9}	SET OF Attribute	o
		8.1.3	notificationIdentifier	{2 9 3 2 7 16}	INTEGER	o
		8.1.4	correlatedNotifications	{2 9 3 2 7 12}	SET OF SEQUENCE	o
		8.1.4.1	correlatedNotifications	{2 9 3 2 7 12}	SET OF INTEGER	c:m
		8.1.4.2	sourceObjectInst	—	objectInstance	c:o
		8.1.5	additionalText	{2 9 3 2 7 7}	graphicString	o
		8.1.6	additionalInformation	{2 9 3 2 7 6}	SET OF SEQUENCE	o
		8.1.6.1	identifier	—	OBJECT IDENTIFIER	c:m
		8.1.6.2	significance	—	BOOLEAN	c:o
		8.1.6.3	information	—	ANY DEFINED BY identifier	c:m
subscriptionVersionDonorSP-CustomerDisconnectDate	{lnp-notification 6}	9.1	VersionCustomerDisconnectDate		SEQUENCE	m
		9.1.1	tn	{lnp-attribute 97}	NumberString	m
		9.1.2	version-id	{lnp-attribute 99}	Integer	m
		9.1.3	service-prov-customer-disconnect-date	{lnp-attribute 69}	GeneralizedTime	m

206

Notification Label	Object Identifier	Subindex	Notification Field	Value of object identifier of attribute type associated with field	Constraints and values	Base Status
		9.1.4	service-prov-effective-release-date	{lnp-attribute 72}	GeneralizedTime	m
		9.1.5	accessControl	{lnp-attribute 1}	SEQUENCE	m
subscriptionVersionNewNPA-NXX	{lnp-notification 8}	10.1	VersionNewNPA-NXX		SEQUENCE	m
		10.1.1	service-prov-npa-nxx-id	{lnp-attribute 39}	Integer	m
		10.1.2	service-prov-npa-nxx-value	{lnp-attribute 40}	SEQUENCE	m
		10.1.3	accessControl	{lnp-attribute 1}	SEQUENCE	m

207

Subscription Version Status

10.Subscription Version Status

[Graphic Omitted: State diagram for subscription version status]

1.Conflict to Cancel

A.NPAC SMS Internal

NPAC SMS automatically sets a subscription version in conflict directly to canceled after it has been in conflict for a tunable number of days.

2.Conflict to Cancel Pending

A.NPAC SMS OP GUI - NPAC Personnel

User cancels a subscription version with a status of conflict.

3.Cancel Pending to Conflict

A.NPAC SMS OP GUI - NPAC Personnel

User sets a subscription version with a status of cancel pending to conflict.

B.NPAC SMS Internal

NPAC SMS automatically sets a subscription version to conflict if cancel pending acknowledgment has not been received from the old and/or new service provider within a tunable timeframe.

4.Conflict Resolution Pending to Cancel Pending

A.NPAC SMS OP GUI - NPAC Personnel

User cancels a subscription version with a status of conflict resolution pending.

B.SOA to NPAC SMS Interface

User sends a cancellation request for a subscription version with a status of conflict resolution pending.

5.Conflict to Conflict Resolution Pending

A.NPAC SMS OP GUI - NPAC Personnel

User sets a subscription version with a status of conflict to conflict resolution pending.

6.Conflict Resolution Pending to Conflict

A.NPAC SMS OP GUI - NPAC Personnel

User sets a subscription version with a status of conflict resolution pending to conflict.

B.NPAC SMS Internal

NPAC SMS automatically sets a subscription version to conflict after conflict resolution pending acknowledgment has not been received from old and/or new service provider within a tunable timeframe.

C.SOA to NPAC SMS Interface - Old Service Provider

Old Service Provider sends a subscription version modification request for a subscription version with a status of conflict resolution pending, which revokes the Old Service Provider’s authorization for transfer of service.

7.Pending to Conflict

A.NPAC SMS OP GUI - NPAC Personnel

209

User sets a subscription version with a status of pending to conflict.

B.NPAC SMS Internal

NPAC SMS automatically sets a pending subscription version to conflict after authorization for transfer of service has not been received from the old service provider within a tunable timeframe.

C.SOA to NPAC SMS Interface - Old Service Provider

Old Service Provider sends a subscription version creation request for a subscription version with a status of pending, which revokes the old Service Provider’s authorization for transfer of service.

8.Conflict Resolution Pending to Pending

A.NPAC SMS Internal

NPAC SMS automatically sets a conflict resolution pending subscription version to pending after receiving conflict resolution pending acknowledgment from the old and/or new service provider.

9.Pending to Cancel Pending

A.NPAC SMS OP GUI - NPAC Personnel

User cancels a subscription version with a status of pending.

B.SOA to NPAC SMS Interface

User sends a cancellation request for a subscription version with a status of pending.

C.NPAC SMS Internal

1.NPAC SMS automatically sets a pending subscription version to cancel pending after authorization for the transfer of service has not been received from the new service provider within a tunable timeframe.

2.NPAC SMS automatically sets a pending subscription version to cancel pending if an activation request is not received a tunable amount of time after the most current due date (new or old).

10.Cancel Pending to Canceled

A.NPAC SMS Internal

NPAC SMS automatically sets a cancel pending subscription version to canceled after receiving cancel pending acknowledgment from the old an/or new service provider.

11.Creation - Set to Conflict

A.NPAC SMS OP GUI - NPAC Personnel

User creates a subscription version for the Old Service Provider and does not provide authorization for the transfer of service.

B.SOA to NPAC SMS Interface - Old Service Provider

User sends an Old Service Provider - subscription version creation request and does not provide authorization for the transfer of service.

12.Creation - Set to Pending

A.NPAC SMS OP GUI - NPAC Personnel

User creates a subscription version for either the new or old Service Provider. If the create is for the old Service Provider and authorization for the transfer of service is not provided, refer to step 11.

B.SOA to NPAC SMS Interface

User sends a subscription version creation request for either the new or old Service Provider. If the create is for the old Service Provider, and authorization for the transfer of service is not provided, refer to step 11.

13.Disconnect Pending to Cancel Pending

A.NPAC SMS OP GUI - NPAC Personnel

User cancels a subscription version with a disconnect pending status.

B.SOA to NPAC SMS Interface - New Service Provider

210

User sends a cancellation request for a disconnect pending subscription version.

14.Disconnect Pending to Sending

A.NPAC SMS Internal

NPAC SMS automatically sets a disconnect pending subscription version to sending after the effective release date is reached.

15.Pending to Sending

A.NPAC SMS OP GUI - NPAC Personnel

User activates a pending subscription version.

B.SOA to NPAC SMS Interface - New Service Provider

User sends an activation message for a pending subscription version.

16.Sending to Failed

A.NPAC SMS Internal

NPAC SMS automatically sets a subscription version from sending to failed after all Local SMSs fail subscription version activation, modification, or disconnect after the tunable retry period expires.

17.Failed to Sending

A.NPAC SMS OP GUI - NPAC Personnel

User resends a failed subscription version.

18.Partial Failure to Sending

A.NPAC SMS OP GUI - NPAC Personnel

User resends a partially failed subscription version.

19.Sending to Partial Failure

A.NPAC SMS Internal

NPAC SMS automatically sets a subscription version from sending to partial failure after some of the Local SMSs fail the subscription version activation, modification, or disconnect after the tunable retry period expires.

20.Sending to Old

A.NPAC SMS Internal

NPAC SMS automatically sets a sending subscription version to old after the disconnect to the Local SMSs successfully completes.

21.Sending to Active

A.NPAC SMS Internal

NPAC SMS automatically sets a sending subscription version to active after the subscription version activation or modification is successful in all of the Local SMSs.

22.Active to Old

A.NPAC SMS Internal

NPAC SMS automatically sets the previously active subscription version to old after an activation, modification, or disconnect to all of the Local SMSs successfully complete.

23.Immediate Disconnect to Sending

A.NPAC SMS OP GUI - NPAC Personnel

User disconnects an active subscription version and does not supply an effective release date.

B.SOA Current Service Provider

211

User sends a disconnect request for an active subscription version and does not supply an effective release date.

24.Deferred Disconnect - Set to Disconnect Pending

A.NPAC SMS OP GUI - NPAC Personnel

User disconnects an active subscription version and supplies an effective release date.

B.SOA to NPAC SMS Interface - Current Service Provider

User sends a disconnect request for an active subscription version and supplies an effective release date.

25.Modify Active to Sending

A.NPAC SMS OP GUI - NPAC Personnel

User modifies an active subscription version.

B.Mechanized SOA - Current Service Provider

User sends a modification request for an active subscription version.

212

Errors

Appendix A.Errors

CMISE Primitive Errors

The following exhibit contains the valid errors associated with CMISE confirmed primitives used in the interoperable interfaces definitions.  The situations under which these errors occur are documented in the message flow diagrams in Chapter 6.

Exhibit 79. Valid Errors Associated with CMISE-Confirmed Primitives Used by the NPAC SMS.

CMISE PRIMITIVE ERRORS

CMISE Primitive	Errors
M-EVENT-REPORT	invalidArgumentValue, noSuchArgument, noSuchObjectClass, noSuchObjectInstance, processingFailure
M-GET	accessDenied, classInstanceConflict, complexityLimitation, getListError, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, resourceLimitation, syncNotSupported
M-SET	accessDenied, class-InstanceConflict, complexityLimitation, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported
M-ACTION	accessDenied, class-InstanceConflict, complexityLimitation, invalidArgumentValue, invalidFilter, invalidScope, noSuchAction, noSuchArgument, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported
M-CREATE	accessDenied, class-InstanceConflict, duplicateManaged-ObjectInstance, invalidAttributeValue, invalidObjectInstance, missingAttributeValue, noSuchAttribute, noSuchObjectClass, noSuchObject-Instance, processingFailure
M-DELETE	accessDenied, class-InstanceConflict, complexityLimitation, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported
M-CANCEL-GET	mistypedOperation, noSuchInvokeID, processingFailure

CMISE Primitive Error Descriptions

accessDenied

The service provider does not have the authorization to do this operation.

Examples:

•The service provider is not authorized to perform this type of operation.

•The service provider is not the old or new service provider for the subscription version.

213

•The modify of the subscription version will cause a mass update.

•The version selected for a disconnect is not active.

duplicateManagedObjectInstance

For create operations, the requested object already exists.

Examples:

•Pending subscription version, NPA-NXX or LRN already exist on NPAC SMS.

classInstanceConflict

The object specified is not a member of the specified class.

complexityLimitation

A parameter was too complex to complete the operation.

invalidArgumentValue

A specified argument is not valid.

Examples:

•An argument value does not pass validation for an action or event report.

•A required parameter is missing for an action or event report.

•An argument value does not exist.

invalidAttributeValue

A specified attribute is not valid.

invalidFilter

A filter specified is not valid.

invalidScope

The scope specified is not valid.

noSuchAction

A specified action is not recognized.

noSuchArgument

A specified argument is not recognized.

noSuchAttribute

A specified attribute is not recognized.

noSuchObjectClass

A specified object class is not recognized.

noSuchObjectInstance

The requested object does not exist.

Examples:

•A query fails based on the search criteria.

•The referenced object (subscription version, NPA-NXX, LRN, etc.) does not exist.

processingFailure

A general failure has occurred in processing the operation or notification A text string is needed to qualify the error message.

214

Exhibit 80. processingFailure Errors.

processingFailure Errors

Error ID		Description
0	lnpSpecificInfo (GraphicString)	Number of records in query response, <#records>, exceeds the number of records that can be returned (<tunable>).

resourceLimitation

The operation was not processed due to a resource limitation.

synchronizationNotSupported

The type of synchronization specified is not supported.

215

EXHIBIT  D

RESPONSE TO RFP

NPAC/SMS SERVICES

[Due to its length, this document is not attached.
A copy of the Response to the RFP is
available upon request for the cost of copying and handling from
NECAC, by request made to the attention of Carville Collins]

[Information referred to in this exhibit immediately follows this page.]

CONFIDENTIAL

NYCAC NPAC/SMS PROPOSAL

October 25, 1996

Company

Address

City, State Zip Code

Re:New York Carrier Acquisition Company (NYCAC, LLC) NPAC/SMS Proposal

Dear Name:

Lockheed Martin Information Management Services Company (Lockheed Martin IMS) is pleased to submit our proposal to the New York Carrier Acquisition Company (NYCAC, LLC) for NPAC/SMS services.  Lockheed Martin IMS is a subsidiary of Lockheed Martin Corporation, one of the world’s most capable, diversified high technology companies, with $30 billion in annual sales and nearly 200,000 employees worldwide.

We are the only independent, neutral third-party number administrator and service center operator with success in administering number portability systems.  We are the operator of the 800 Number Administration and Service Center (NASC), providing reliable, evenhanded, secure, and responsive service every day for the last three years.  Also, we were recently selected as the primary vendor and system administrator for the Illinois Local Number Portability (LNP, LLC) NPAC/SMS.

As requested, we have provided each member of NYCAC’s Evaluation/Procurement Team with one hard copy and one diskette copy (IBM DOS format, Microsoft Word 6.0) of our proposal in a sealed package.

Our proposal is valid 180 days from this date (October 25, 1996).  Should you have any questions regarding our proposal, please contact Greg Roberts, Lockheed Martin’s official point of contact for this procurement, at (202) 414-3562 or via fax (202) 289-2690.

We look forward to our continued participation in NYCAC’s NPAC/SMS procurement process and working with NYCAC in the future, forging a productive partnership between us.

Sincerely,

Jeffrey E. Ganek

Sr. Vice President & Managing Director

Communications Industry Services

Enclosure

NYCAC NPAC/SMS PROPOSAL 1.0  Proposal Executive Summary

HIGHLIGHTS

•Lockheed Martin IMS is fully committed to supporting NPAC/ SMS deployment in the industry’s time-frames, and is backed by the vast resources of the $30 billion Lockheed Martin Corporation

•Demonstrated commitment to working cooperatively and inno-vatively with the industry as a team player for LNP deployment to satisfy FCC and industry deploy-ment timetables.

•Uniquely low-risk, low-cost, and high quality solution through leveraging effort and experience gained in the Illinois NPAC/SMS deployment and development activities

•Completely neutral team, sensitive to the demands, timetables, and ambiguities of the current regu-latory environment

•Commitment to develop and deploy cooperatively a first-of-its-kind cap-ability in the industry in a fully open, non-proprietary environment

1.0PROPOSAL EXECUTIVE SUMMARY (RFP Sect. 1.4.3.2)

The NYCAC has taken a leading role in the industry with its decision to move forward with regional local number portability at this time.  Portability will be facilitated by the accelerated development of the required technologies, processes, and procedures.  The Lockheed Martin Team has dedicated itself to the provision of an NPAC/SMS services solution that will provide the bedrock foundation from which the local service providers can address the marketplace dynamics while being confident that their NPAC/SMS infrastructure will be transparent to their customers and can accommodate fast paced change.

Lockheed Martin’s Solution Provides Added Value

The Lockheed Martin proposal meets or exceeds all the requirements of the New York Carrier Acquisition Company (NYCAC, LLC) Number Portability Administration Center and Service Management System (NPAC/SMS) RFP.  Specifically, our solution provides these significant benefits and features as discriminators:

1

Proposal Benefits and Features

•Completely neutral, experienced Lockheed Martin Team, with full backing and resources of $30 billion Lockheed Martin Corporation, has been working aggressively toward NPAC/SMS deployment, initially for Illinois.

•Demonstrated commitment of the Lockheed Martin Team to work cooperatively and innovatively with the industry as a team player for LNP to satisfy FCC and industry deployment timetables.

•Assured on-time delivery of NPAC/SMS on May 15, 1997, and start of “live” operations by October 1, 1997.

•Demonstrated leadership and competence, having developed open, non-proprietary NPAC/SMS technical standards: NPAC SMS Interoperable Interface Specification (IIS) and NPAC SMS Generic Functional Requirements Specification (G-FRS).

•Fully regionalized NPAC/SMS incorporating the latest industry business process flows and numerous enhancements, including support for location portability.

•NPAC SMS service scalability through distributed SMS service and software architecture engineered for full regional loads.

•Highest operational integrity, with service assurance capabilities including mutual-database integrity sampling, to ensure consistency of LNP routing data throughout New York and, when desired, the surrounding region.

2

•Highest possible NPAC/SMS service availability through network element-level availability and engineering standards using a diverse, fault-tolerant, real-time synchronized, mated-pair architecture.  Cut-over to the backup system is virtually instantaneous, without causing NPAC service disruption or outage.

•Hands-on experience of providing support for service-provider system (LSMS, SOA) vendors/implementers, including interoperability testing (lab-to-lab developer testing) as demonstrated in interface forums conducted to train vendors/developers in the implementation of the NPAC SMS interfaces.

•Harmonized NPAC/SMS service offerings across the industry providing technical operating efficiencies and cost-sharing across regions, including standard national NPAC/SMS service pricing for all regions the Lockheed Martin Team may be selected to serve.

Corporate Commitment

Lockheed Martin IMS (IMS), with the full backing and support of the Lockheed Martin Corporation, is fully committed to supporting the needs of the telecommunications industry.  Our Communications Industry Services (CIS) line of business is dedicated solely to providing neutral services, like LNP, required by communications services providers.  CIS is managed and staffed by experienced, dedicated individuals from within the telecommunications industry who are keenly aware of the sensitivities and needs of the industry at this significant time in the industry’s history.  Those needs include:

•Experienced neutral and evenhanded third parties;

•Guaranteed on-time, low-risk service delivery;

•Extremely highly-reliable and consistent service and systems;

3

•A partner sensitive to the demands, timetables, and ever-changing landscape of the current regulatory environment;

•Subject matter expertise in key technologies, such as LNP, SMS, and CMISE; and

•Commitment to develop and deploy cooperatively a first-of-its-kind capability in the industry in a fully open, non-proprietary environment.

Lockheed Martin understands the nature of number portability administration, as well as the challenges the industry faces relative to LNP deployment and deregulation in general.  In recognizing the spirit of the industry’s needs for its selected LNP administrator, we offer services and support that go beyond the letter of the requirements and that speak to our willingness and commitment to provide not just the services procured and contracted for but address the broader needs that really exist, as depicted in the chart that follows:

Industry Need	Lockheed Martin Response
Leadership in development of open, non-proprietary, NPAC/ SMS technical standards	•NPAC SMS interfaces (NPAC SMS Interoperable Interface Specification [IIS]) •NPAC SMS functional requirements (NPAC SMS Generic Functional Requirements Specification) •Design of functional enhancements in anticipation of regionalization of NPAC/SMS services
Flexibility, given the technical and operational uncertainties	•Have refined and adapted NPAC/SMS implementation to evolving industry needs •Incorporated numerous changes and process enhancements (109 new requirements) at service provider request in Illinois during five months of requirements definition, documentation, and review cycles •Latest industry business process flows incorporated •Scalability of NPAC/SMS solution, recognizing unpredictability of LNP penetration rates •A system and service capable of supporting: •     Wireless participation •     Number pooling (pooled number administration) •     Inter-NPAC and national LNP activities
	•Developed implementation enhancement (bulk download capability) to meet performance requirements to suit

4

Industry Need	Lockheed Martin Response
Creativity in engineering and recommending solutions that reflect an understanding of and address underlying bus-iness needs	LSMS constraints and scalability while still meeting the business requirements (to be able to download 25 numbers/second) •Moved real-time audit processing into NPAC/SMS to simplify LSMS implementation •Unsolicited enhancements: •     Surrogate SOA capability through direct user interface to NPAC SMS (OpGUI) •     Location portability •     Direct customer-manageable network and profile data on NPAC/SMS
Support for service-provider system (LSMS,SOA) vendors/ implementers	•Support of interoperability testing (lab-to-lab developer testing) •Leadership role in providing Interface Forums to train vendors/developers in implementation of the NPAC SMS interfaces •Provide NPAC SMS support for system vendors/developers •End-user graphical interface to NPAC SMS to provide surrogate SOA functions in NPAC in lieu of SOA system upgrades
Harmonize NPAC/SMS service offerings across the industry	•Development of standardized NPAC SMS generic software for consistency of NPAC/SMS services •Establishment of standard national NPAC/SMS service pricing for all regions Lockheed Martin IMS may be fortunate to serve •Common service element-based pricing provides for NPAC/SMS service cost parity across the country •No inter-regional pricing disparities or inequities for service providers (and their end-users) •Cost-sharing of economies of scale across regions •Usage sensitive pricing that links discount thresholds to higher transaction rates
Support aggressive LNP de-ployment schedules	•     Lockheed Martin has the scale, technical strength, and operating capability to implement and deliver NPAC/SMS services. Lockheed Martin is a $30 billion world class systems integration and services provider, operating very large, complex systems, with 200,000 employees •     Strict project schedule and risk management of ongoing development to ensure on-time delivery of NPAC/SMS to industry •     Willingness to initiate early start in New York with good-faith Letter of Intent to lock-in schedule  •     Initiated early start in Illinois, well ahead of formation of

5

Industry Need	Lockheed Martin Response
	Illinois LNP LLC and start of contract negotiations •     Incurred financial exposure in Illinois well above that covered by Letter of Intent, in order to safeguard the schedule
Economic and responsive provision of NPAC/SMS services	•     Lockheed Martin’s NPAC/SMS proposal and implementation program demonstrate our commitment to quality, responsiveness, and economic value •     Lockheed Martin will cooperate with NYCAC to establish processes and provisions ensuring NPAC/SMS services are highly responsive and economically priced •     Depth of Lockheed Martin Corporate resources ($30B, 200K employees, world-class systems integrator) and long experience in being entrusted with national strategic assets (e.g., 800 NASC, defense, aerospace) •     Have agreed to contractual protections in Illinois to ensure continued performance and responsiveness, and independent NPAC/SMS maintenance in case of default •     Active support of open, permanently non-proprietary, technical standards •     Long tradition of Lockheed Martin conducting business with highest of ethics, fairness, and evenhandedness
Flexibility given regulatory uncertainties	•     Willingness to incur substantial financial exposure (early start in Illinois) given these uncertainties •     Firm belief in eventuality of LNP deployment, need for NPAC/SMS services, and Lockheed Martin’s suitability as lead NPAC/SMS services provider •     Have recognized constraints on LLC authority and uncertainty regarding contract term and future events. Have requested reasonable commercial terms under circumstances of early termination without cause •     Willingness to actively support and cooperate, to the extent appropriate, with NANC LNPA standards and selection process •     Willingness to undertake advocacy role with regulators as subject matter experts in NPAC/SMS for the benefit of whole industry to the extent appropriate without jeopardizing strict neutrality (e.g., ex parte 95-116 presentation to FCC).

The Team

Lockheed Martin IMS, as the prime contractor for the NYCAC NPAC/SMS, has carefully selected a team of companies who possess the financial stability, proven performance, and complementary strengths

6

that will result in the provision of an NPAC/SMS that is on time, reliable, scalable, feature rich, competitively priced, and managed in an independent, evenhanded fashion.

The Lockheed Martin Team comprises the following companies:

Evolving Systems, Inc. (ESI):  An Englewood, Colorado company with a proven record of developing and delivering high quality software systems for the telecommunications industry.  As the lead NPAC SMS software developer for the Lockheed Martin Team, ESI is currently deeply into the design and development of the Lockheed Martin NPAC SMS generic software that forms the basis of NPAC/SMS services Lockheed Martin IMS will offer throughout the industry.  ESI has extensive experience in client server solutions, CMISE, GUI applications, network design, and on-time delivery.  With nine of every 10 employees involved in the development of software and their knowledge of requirements gleaned from their participation in the state portability workshops, ESI has the breadth and depth of talent to deliver a quality NPAC SMS application.

DSET:  A New Jersey company that is very prominent in the design and implementation of software tools that facilitate TMN system interfaces.  DSET’s tools, which are utilized by ESI, and their extensive experience in implementing and testing production-quality CMISE-based systems will ensure that the NPAC/SMS’ mechanized interface with the LSMS and SOA are impeccably implemented and validated.  DSET will build on its experience in conformance testing of CMISE interfaces to continue providing NPAC SMS interface interoperability testing, in support of service provider systems (LSMS and SOA) deployment serving both the Illinois LNP LLC and NYCAC jurisdictions, to the industry to ensure end-to-end interoperability of

7

service provider LSMS and SOA systems built to the IIS.  These services are essential to ensure timely and error-free turn-up testing in support of LNP deployment for NYCAC.

Stratus Computers, Inc.:  A Massachusetts company, Stratus’ fault tolerance and virtually continuous availability make it particularly well suited to the NPAC/SMS requirements.  Stratus platforms have been the linchpins of high transaction, mission critical applications in the telecommunications industry for years and were the logical choice for Lockheed Martin’s NPAC/SMS since the local service providers and their customers would be intolerant of any service outages resulting for NPAC SMS unavailability.

Lockheed Martin:  A corporation with a strong balance sheet and a proud record of growth and profitability.  We have the depth of resources ($30 billion revenues, and 200,000 people) and long experience in being entrusted with national strategic assets (e.g., 800 NASC, defense, aerospace) to support wide-scale deployment of NPAC/SMS services throughout the industry.

Lockheed Martin has designated its Information Management Services (IMS) company to lead the NYCAC NPAC/SMS initiative.  Lockheed Martin IMS will be fully responsible for system implementation, operations, and service delivery — repeating our demonstrated successes as a system integrator and service provider managing multi-disciplinary teams including major software systems developers.  In addition to Lockheed Martin IMS’ acknowledged leadership in the 800/888 toll free portability environment, we have augmented these substantial capabilities with the addition of experienced telecommunications consultants — Mark Foster (Principal of MDF Associates), Lisa Marie Maxson (Telecom Software Enterprises), and John Shea.  Sections 1.1 through 1.4 of our proposal fully describe the exact roles and responsibilities of each team member, and our team-wide qualifications and relevant experience.

8

The Solution

Lockheed Martin is convinced that our Team has designed a technical and operational solution that satisfies and exceeds all the requirements stipulated within the NYCAC RFP.  Furthermore, Lockheed Martin proposes NPAC/SMS performance metrics that reflect our willingness to accept accountability for the provisioning of high quality service to our customers.  Some significant aspects of the Lockheed Martin Team’s solution are as follows:

Neutrality

Lockheed Martin and all our team members are completely neutral in the light of the RFP requirements.  Furthermore, to foreclose any concerns regarding the NPAC/SMS application and its title, Lockheed Martin has acquired ownership of all intellectual property rights for this software and any modifications or enhancements that may be made while going forward.  Much like we demonstrate every day in the operation of the 800 NASC, Lockheed Martin takes our responsibilities to fairly represent the industry very seriously, and we have structured our business arrangements accordingly.

Implementation

Lockheed Martin has assembled a team that has the credentials, experience, and resources necessary to deliver the NPAC/SMS in accordance with the stated RFP requirements.  Our implementation schedule is realistic and attainable, especially in light of our early start on the design and development of the NPAC SMS applications software even prior to our selection as the NPAC/SMS provider in Illinois.  Furthermore, we believe that the level of detail and technical competency portrayed in this proposal is indicative of the Lockheed Martin Team’s commitment and capability to deliver the proposed solution on time.

9

NYCAC has aggressively driven the deployment schedule for local portability.  Lockheed Martin will facilitate that vision by delivering the NPAC/SMS on May 15, 1997, and ensuring that full operations are supported by October 1, 1997.

The Future

The Lockheed Martin NPAC/SMS is designed to grow as the needs of the competitive local service marketplace dictate.  The Lockheed Martin solution accommodates the addition of local service providers, geographic jurisdictions, or feature enrichments, such as:

•Broader location and service portability

•Wireless portability

•Direct support of resellers

•Pooled number administration.

In choosing Lockheed Martin, the NYCAC can be secure in the knowledge that the NPAC/SMS has been designed with the future in mind and that Lockheed Martin is committed to supporting ongoing New York LNP activities geared to initial LNP deployment in New York and future deployment throughout the surrounding region.

The Price

Lockheed Martin has made every effort to understand the evolving competitive local service marketplace.  We recognize the vagaries of cost recovery and the two year ramp-up of local service provider revenue.  With that in mind, we have designed an NPAC/SMS that is fairly and flexibly priced and sensitive to the service providers’ needs.

10

Conclusion

Given the national attention and visibility afforded the implementation of local number portability throughout the United States and the aggressive timetable mandated by the FCC, we believe that NYCAC must choose a qualified team that:

•Demonstrates a thorough understanding of the requirements, the marketplace, and the business issues

•Is knowledgeable and can begin immediately after contract award with a full understanding of the requirements

•Is credible and can unquestionably deliver the NPAC/SMS by May 15, 1997 for testing

•Is backed by the full faith and commitment of a neutral prime contractor with substantial financial and technical resources.

As our NPAC/SMS experience demonstrates and as this proposal validates, the Lockheed Martin Team is the best team for NYCAC, providing an honest and experienced partner, a fully compliant solution, and a competitive price.

11

This Page Intentionally Blank

12

NYCAC NPAC/SMS Proposal 1.1 Team Composition, Roles, & Responsibilities

HIGHLIGHTS

•Neutral position as a telecom-munications system administrator guarantees neutral, impartial service delivery

•As providers of continuously available computing platforms, NPAC SMS software, and TMN tools, the Team has all the requisite experience for a successful, on-time delivery

1.1TEAM COMPOSITION, ROLES, & RESPONSIBILITIES (RFP Sect. 1.3.3 and 1.3.5)

The Lockheed Martin Team has the proven capability to meet all responsibilities and contract obligations for a timely complete “turnkey” NPAC/SMS solution.

Lockheed Martin IMS—the “mission-critical” company in the Lockheed Martin Corporation having direct number portability administration expertise—has many years of experience in managing complex systems integration; a demonstrated record of neutral and evenhanded service delivery; and a long tradition of providing clients with reliable, flexible, and expandable systems and operations.  And, we have selected as teammates the software developers and hardware providers having the greatest expertise and experience required to deliver the best possible solution for NPAC/SMS services.

Our team—Evolving Systems, Inc. (ESI), DSET, and Stratus, Inc.—has prior SMS experience; uses a rigorous development process; is familiar with platform architectures, distributed databases, security facilities, LAN/WAN protocols and integration devices, and GDMO information modeling; and has the TMN-based system interface experience required to fully understand, design, and implement the requirements.  This same team of companies, led by Lockheed Martin, was unanimously selected to provide the NPAC/SMS for Chicago.  And, based on our collective work to date in Chicago, Lockheed Martin is convinced, more than ever, that we have assembled a solid team to provide complete “turnkey” NPAC/SMS services for NYCAC and the industry.

ESI is the team’s primary software designer;DSET provides a sophisticated development toolset for developing and testing TMN interfaces; and Stratus, Inc. will supply the system hardware and associated

13

software.  The Team also includes three consultants—Mark Foster of MDF Associates, John Shea, and Lisa Marie Maxson of Telecom Software Enterprises—all ofwhom bring specific industry and LNP experience to support Lockheed Martin in its role as prime contractor.

The general roles and responsibilities of the Lockheed Martin Team are depicted inExhibit 1.1-1 and summarized below.

Lockheed Martin IMS

As Primary Vendor/System Administrator, Lockheed Martin will assume all responsibilities and contract obligations for the NPAC/SMS.  In this regard, we will:

•Deliver the services and support required by NYCAC member carriers

•Manage all program components, team members, subcontractors, vendors, and consultants

•Provide overall quality assurance

•Purchase and provide NPAC SMS hardware and system components

•Oversee NPAC SMS functional definition, design, and testing

•Manage, oversee, and approve system implementation and acceptance testing

•Provide NPAC, NPAC SMS, and billing operations

•Design and install the NPAC SMS networking infrastructure and provide network management services

•Provide end user/industry training.

14

Evolving Systems, Inc. (ESI)

As a team member responsible for systems and support that meet RFP requirements, ESI will:

•Develop, test, and install NPAC SMS application software and support systems

•Support system integration and operational turn-up testing among the NPAC and the local SMSs and SOAs of NYCAC member carriers, and between the primary NPAC SMS and the back-up disaster recovery NPAC SMS

•Provide software documentation and application training.

DSET Corporation (DSET)

As a supporting NPAC SMS team member, DSET will:

•Review and support NPAC SMS system development and testing

•Support design, testing, and installation of TMN-type system interfaces

•Support interoperability testing between the NPAC SMS and the local SMSs and SOAs of NYCAC member carriers.

Stratus Computer, Inc. (Stratus)

Stratus Computer, Inc. will provide, install, and maintain system hardware and related software, and will work with others on the team to ensure system operability by the deadlines proposed in the RFP.

15

NYCAC NPAC/SMS Proposal 1.2 Financial Responsibility

HIGHLIGHTS

•Lockheed Martin, a financially stable and strong $30 billion corporation, as Prime Vendor ensures project success

•Financial strength to support NYCAC NPAC/SMS services for many years, including regional expansion outside the State of New York

•All team members are in good financial standing, enabling them to perform and complete con-tractual requirements

1.2FINANCIAL RESPONSIBILITY (RFP Sect. 1.3.1.1)

The audited financial statements for the Lockheed Martin Corporation and statements for each sub-contractor indicate the outstanding financial stability of the Lockheed Martin Team.

The Lockheed Martin Corporation is a diversified, financially stable, international corporation with $30 billion ($23 billion in 1995 plus the recent addition of the Loral Corporation) in annual revenues. 
The Corporation has a positive standing in the investment community, and a large ownership by its own employees.  Its success has grown from effective management of advanced technologies in complex systems that are responsive to customers’ requirements.

Lockheed Martin IMS, a member of the corporation’s $4.5 billion Information and Technology Services Sector, provides high-volume information management and processing services for a wide array of clients.  Projects include the operation of the 800 NASC and implementation of the NPAC/SMS for Chicago.  We have perfected the secure management of vital, private, and sensitive data for both private industry and government.  We are relied upon in critical and high-profile environments to manage information for competing interests in a credible and evenhanded manner. Few companies provide the range of technical and user support services in competitive and complex organizational arrangements as does Lockheed Martin IMS.

16

The success and sustained growth of Lockheed Martin IMS reflects the successful provision of information management and processing services.  Our company’s growth and innovation over the past 10 years has been facilitated by the Corporation’s sound financial backing.

Evolving Systems, Inc. (ESI) is a software developer engaged in the design, development, and implementation of distributed software systems and products—with emphasis on the UNIX operating system—for the telecommunications, cable, and entertainment industries. The Company is headquartered in Englewood, Colorado, a southern suburb of Denver, and employs more than 300 people.

Founded in 1985, ESI has grown to become one of the foremost UNIX development companies in the United States.  Revenues have increased from $4.8 million in 1991 to $45.3 million in 1995.  ESI is in the business of providing software solutions, not merely programming assistance, to its customers. As a result, ESI’s customers have typically been large corporations that require substantial systems design work, including Fortune 500 companies, most of the Regional Bell Operating Companies (RBOCs), large independent telephone companies, telephone research and development companies, major investment companies, and major software providers to the personal computer industry.

DSET is the premier vendor of TMN tools and solutions and an industry leader in distributed systems.  The company has a six-year history and has been engaged for hundreds of projects ranging in duration from two to 18 months.  Clients have included long distance carriers including AT&T; RBOCs; wireless vendors including Motorola and Hughes Network Systems; systems companies, including IBM and HP; switch manufacturers, including Ericsson; and international corporations, including Samsung, Hitachi, and Dae Woo.  DSET is a $10 million, internationally recognized telecommunications company headquartered in Bridgewater, New Jersey.

17

Stratus Computer, Inc. lends further financial strength and stability to the Lockheed Martin Team.  The firm is headquartered in Marlborough, Massachusetts, and has a 16-year history as a multi-system hardware vendor.  The company is publicly held and grossed nearly $600 million in sales in l995.  Its financial strength is highly rated by Dun & Bradstreet.  Stratus is a leading edge systems producer of international reputation and has sales offices throughout the world.  The company continues to grow and currently employs 2,400 people.

The last three year-end financial reports/statements of each team member are located in the Appendix G of our proposal.

This Page Intentionally Blank

18

HIGHLIGHTS

•Leading neutral third party administrator of databases and systems for the telecommuni-cations industry

•Third party administrator/agent for more than 140 jurisdictions

•Deep experience with NPAC type operations via our 800 NASC contract and recent Chicago NPAC/SMS work

•Strong telecommunications system development and system provision expertise

1.3BACKGROUND, QUALIFICATIONS, & RELEVANT EXPERIENCE (RFP Sect. 1.3.1.2)

The Lockheed Martin Corporation’s reputation as a leader in service and technological innovation has been demonstrated on many programs similar to the NPAC/SMS.

Lockheed Martin IMS is a wholly owned subsidiary of the Lockheed Martin Corporation, a broadly based $30 billion firm.  Headquartered in Bethesda, Maryland, Lockheed Martin employs nearly 200,000 workers and maintains a position as one of the most stable and financially secure firms in the world.  For more than 70 years, the companies forming Lockheed Martin have satisfied a range of clients in demanding high visibility projects with on-time and on-budget delivery of products that exceed client expectations.

Lockheed Martin is well known as a premier provider of advanced technologies in complex systems that deliver innovative and sophisticated solutions.  Lockheed Martin is a leader in space exploration, missile production, and systems management of complex projects.  It provides systems for space and military applications and has strong positions in expanding markets that demand high technology solutions and strict management control; integration and information management services; and system and management solutions for high volume transaction processing in time- and mission-critical environments.

Lockheed Martin IMS—a leading full-service provider of integrated systems solutions chosen by the Corporation to service LNP—has extensive and deep systems integration, data processing, and customer

19

service experience focused on specialized client needs in regulated and complex business environments that demand management expertise and sophisticated technical solutions.  As a service-oriented company, Lockheed Martin IMS draws on the product development assets and deep technical strengths of other Lockheed Martin companies to bring valuable expertise and experience to IMS’ customers.

Systems management, integration, and specialized technology services—provided by the Corporation’s Information and Technology Services Sector, shown in Exhibit 1.3-1—are Lockheed Martin’s fastest-growing lines of business.  The Corporation has made a strong commitment to these areas of business while placing an increased emphasis on product and business development.

1.3.1   Lockheed Martin IMS Background and Qualifications

Lockheed Martin IMS was founded in 1963 and has evolved into a highly diverse data processing firm.  Headquartered in Teaneck, New Jersey, we have more than 40 regional offices worldwide as shown in Exhibit 1.3-2, and currently employ more than 1,400 individuals.  We provide third party services and systems for more than 140 separate customers in a variety of applications.  We have developed extensive and deep systems integration, data processing, and customer service experience focused on specialized client needs.  Our role within Lockheed Martin is to provide full facility management services related to high volume automated transaction processing.  Our mission is to be the preeminent provider of high quality operational systems and third party services to government programs and public and private sector organizations.

Much of our business involves designing and delivering management and data processing services for complex, multifaceted customer entities with performance and service needs similar to the NPAC/SMS.  We have a state-of-the-art services facility at our data center in Tarrytown, New York, staffed by more than 150 experienced systems analysts, management personnel, and user support teams.  These

20

individuals and others offer expertise in operations and functions mirroring those proposed for the NPAC/SMS.

Lockheed Martin IMS and its key management staff are organized into the “lines of business” depicted in Exhibit 1.3-3.

•Communications Industry Services—This organization provides neutral third party services and supporting systems to the telecommunications industry, including two of particular relevance to the NYCAC NPAC/SMS.  Our operation of the 800 NASC and implementation of the NPAC/SMS for Chicago are performed by the organization.

•Children and Family Services—This organization focuses on privatization of systems development, operations, and associated services in support of programs concerned with the health and welfare of children and their families, including child support enforcement and electronic benefits transfer.  Children and Family Services has active contracts in New York, Maryland, California, Illinois, Minnesota, Virginia, Pennsylvania, and Colorado.  Service parallels with the NPAC/SMS include customer service, training, hardware and software maintenance, and facilities management.

•Municipal Services—This organization provides systems, large-scale database operations, and back-office services to more than 100 cities in support of high-volume parking management, traffic violations processing, and emergency medical services billing programs.  There are parallels between service offerings in this business line and NPAC/SMS requirements, including customer service, hardware and software maintenance, customer account maintenance, performance reporting, and training.  Operating in high demand, high scrutiny public environments, we manage enforcement

21

programs that dramatically improve client revenues and meet the customer’s need for responsive and sensitive service.

•Transportation Systems and Services—Established in 1986, this organization now serves toll authorities and more than 30 states, providing electronic toll collection systems and services; supporting the registration, taxation, and regulation of commercial motor vehicles with systems integration, software development and program management functions; and serving the motor carrier industry with “Intelligent Transportation” solutions.

•Criminal Justice Services—Our newest organization leverages core competencies of the company into the criminal justice field through the provision of court fine and fee collection services.

In each of these enterprises, we are called upon to provide solutions that require superior service and strict information security.  All of our lines of business are founded upon the right blend of people, facilities, systems, and process knowledge.  Our ability to support large, complex systems derives from our capacity to collect and place the appropriate resources: hardware, software, and personnel.  In addition, all of our services have the characteristics required of the NPAC/SMS and local number portability services:  high visibility, revenue sensitive, time sensitive, enhanced service to all clients within a customer-sensitive, complex environment.

1.3.1.1Lockheed Martin IMS Relevant Experience

Lockheed Martin IMS has been involved with number portability since responding to the initial Bellcore RFP for the 800 NASC in l988.  Marketplace dynamics, technical advances, and regulatory change drove the communications industry’s requirement that a neutral third party administrator provide local number portability.  Lockheed Martin committed to play a leadership role in the advent of number portability, supporting the industry’s resolution of regulatory, technical, and operating issues surrounding 800 and

22

local number portability.  This perseverance paid off in 1993, when Lockheed Martin IMS was selected to transition from Bellcore and operate the 800 NASC on a neutral, third party basis.

In November 1993, Lockheed Martin IMS completed successful transition from the Bellcore NASC, and has operated the 800 NASC to the satisfaction of our users and to Database Services Management, Incorporated (a subsidiary company of Bellcore) ever since.  Much of our experience over the past three years relates directly to the NPAC/SMS.  For example, in our operation of the 800 NASC, we provide the following categories of NPAC services, all of which are required by Section 12 of the NYCAC NPAC/SMS RFP:

System Administration

Exhibit 1.3-4 depicts the direct correlation between the NPAC/SMS requirements and our experience in performing the same functions.  Clearly, we have had significant exposure to all aspects of the RFP’s System Administration requirements, enabling us to provide carriers with solid, high quality NPAC service.

SYSTEM ADMINISTRATION

A Direct Correlation Between Our Experience and NPAC Needs

NPAC Functions	Lockheed Martin 800 NASC Experience (Through 1995)
Logon Administration	•     Processed over 2,100 logon requests •     Uses identical process as specified in RFP
Customer Record Security	•     Prepared Security Permissions Document •     Audit user ID usage •Stringent facility and LAN security •     Periodic reports
Scheduled System Unavailability Notification	•     Provide six months advance notice •     Provide a minimum of two weeks final notice via Bulletin Board and fax
Software Release Acceptance Testing	•     Created approximately 2000 new feature and regression test cases in support of three major releases

23

Service Administration	•     Performed thousands of transactions to update 800 portability tables.
Mass Change Administration	•     Have coordinated efforts between data center and site support on scores of NPA splits and changes. •     Good working relationships with NANPA and traffic routing administrators

Exhibit 1.3-4. We currently perform all NPAC System Administration tasks for the SMS/800 system.

User Support

Our 800 NASC User Support team knowledge is fully transferable to the NYCAC NPAC/SMS effort, providing the NYCAC with all the experiential benefits gained from the 800 NASC program.  Exhibit 1.3-5 shows, in a similar fashion, the strong foundation upon which we base our confidence in being able to perform the required user support functions within specified performance standards.

USER SUPPORT

A Direct Correlation Between Our Experience and NPAC Needs.

NPAC Functions	Lockheed Martin 800 NASC Experience (Through 1995)
User Problem Resolution	•     Processed over 30,000 user calls •     Developed trouble tracking system to accom-modate user queries •     Exceeded response performance objective •     93% of calls closed on initial contact
Software Release Acceptance Testing	•     Created approximately 2000 new features and regression test cases in support of three major releases
Software Modification Update	•     Provide a minimum of six months advanced notice •     Provide a minimum of two weeks confirming notification
Training Administration	•     Developed training updates in support of major releases •     Created training curricula brochure •     Scheduled training, billing, and collections for over 120 students

24

NPAC Functions	Lockheed Martin 800 NASC Experience (Through 1995)
Document Order Administration	•     Distribute application training student and instructor guides which we develop and maintain •     Work closely with Bellcore document distribution center •     Distribute industry guidelines
Training and Documentation User Feedback	•     All students are given post-training surveys •     Information shared with documentation preparers
Local SMS Download Problem Resolution	•     SCP Download exception reports reviewed daily •     SCP Download problem resolution coordinated with application support

Exhibit 1.3-5.The benefits to be derived from the transfer of comparable knowledge is readily apparent from the listing of our user support responsibilities in the 800 NASC.

25

System Support

We will provide technical support of the NPAC/SMS system operation, resolving communications and interface problems, administering scheduled report production, and notifying users of unscheduled unavailability of the system. In addition, we will administer, operate, and maintain the NPAC/SMS’ extensive, state-of-the-art infrastructure of redundant voice and data communications, WAN, Stratus NPAC SMS servers, LAN, PBX/ACD, etc.  Exhibit 1.3-6 demonstrates the relevancy of our 800 NASC role to the NPAC System Support requirements.

SYSTEM SUPPORT

A Direct Correlation Between Our Experience and NPAC Needs

NPAC Functions	Lockheed Martin 800 NASC Experience (Through 1995)
NPAC SMS Report Administration	•     Prepare and distribute regularly scheduled periodic reports to users •     Coordinate and negotiate ordering, scheduling and distribution of special request reports •     Explain report content to users
Failure recovery administration and user notification	•     Notify users via NASC recorded messages and fax •     Maintain close coordination with data center and site support •     Keep users updated every 30 minutes
NPAC SMS Interface Monitoring	•     Involved in the reporting and resolution of data link problems •     Assist users in accessing the system
Software Release Acceptance Testing	•     Created approximately 2000 new feature and regression test cases in support of three major releases

Exhibit 1.3-6.Lockheed Martin’s administrator responsibilities over the last 3 years have prepared us well for assuming the SMS system support functions.

In addition to our 800 NASC experience, Lockheed Martin IMS was selected by the Illinois Commerce Commission SMS/RFP Subcommittee to develop an NPAC SMS and provide supporting NPAC services

26

for Chicago LATA 358.  In Chicago, the six member carriers of the SMS/RFP Subcommittee—Ameritech, AT&T, MCI, Sprint, MFS Communications, and Teleport Communications Group—released the ICC NPAC/SMS RFP and unanimously selected Lockheed Martin IMS to develop and administer the NPAC/SMS.

The Lockheed Martin Team is currently implementing the NPAC/SMS and supporting operations for Chicago.  Just weeks ago, the Interoperable Interface Specification and the Functional Requirements Specification of the NPAC SMS developed by Lockheed Martin were approved by the Illinois LNP, L.L.C. members.  We have also begun an extraordinary amount of work on the external and internal NPAC SMS design.  The Chicago NPAC SMS (Release 1) and supporting NPAC operations are scheduled to be up and operational, ready for turn-up testing, in March 1997.

For the NYCAC NPAC/SMS, the Lockheed Martin Team will draw on our Chicago NPAC/SMS experience, as appropriate.  We will commit a group of experience professionals with directly relevant experience and provide them with the latest tools for accomplishing their mission, thus satisfying not only our performance metrics but carrier expectations. With our acknowledged NASC and Illinois NPAC/SMS background, we envision a smooth, timely, and problem-free implementation of the NPAC/SMS for the NYCAC.

Write-ups of additional Lockheed Martin projects that are similar in complexity and scope to the NYCAC NPAC/SMS are provided in Appendix A of our response.

27

1.3.2Evolving Systems Incorporated (ESI) Background, Qualifications, & Relevant Experience

Over its 10-year history, ESI has become one of the nation’s foremost UNIX development companies.  Its core competency includes developing telecommunications Operations Support Systems (OSS) and Business Support Systems (BSS) for many telecommunications providers.  Some of the particularly relevant systems and work they have accomplished include:

•Development of the NPAC/SMS application for Chicago.  Current work includes the development of the Interoperable Interface Specification for the NPAC SMS interfaces to carrier local SMSs and SOAs.  Additionally, ESI is assisting Lockheed Martin in the finalization of the NPAC SMS external design.  Work is well underway in the internal NPAC SMS system design, and code and unit testing has already started.

•Development of PilotPLUSä, a Business Support System (BSS) for CDPD. PilotPLUSä is a complete ready-to-install customer care, provisioning, rating, and billing system that supports the CDPD wireless industry. ESI is currently servicing the PilotPLUSä application for three CDPD carriers within the United States.

•Development of software for a 13,000-terminal, 600 UNIX computer, nationwide network for a major telecommunications company. They also provided the second tier of support for this network with more than 99% availability over a five-year period.

•Consulting services for a Regional Bell Operating Company (RBOC) to review the design of Bellcore’s Network Monitoring and Analysis (NMA) System. NMA is used by several of the RBOCs to monitor all of their trunks and network elements, such as central office switches and channel banks.

28

•Development of the Interactive Voice Response (IVR) systems, including screen synchronization of caller data with voice call arrival, and preview, progressive, and predictive dialing.

•Development of the Evolving Systems, Inc. Environment (ESIEâ). ESI developed an application layer that rides on top of UNIX to provide system operators and developers with a robust set of tools for remote reporting, analysis, and control. ESIEâ is used in virtually all ESI projects. ESI also developed an SNMP Management Information Base (MIB) that allows systems based on the ESIEâ to be remotely monitored and controlled.

•Development of the ESI Voice/Data Integration System (VDIS), an API based on ESIEâ.  VDIS combines the power of an Automatic Call Distributor (ACD), IVR, data communications with mainframes or other external systems, sophisticated agent interfaces, and a predictive dialing mechanism to produce significant efficiencies in both inbound and outbound call processing.

In addition, four projects particularly demonstrate ESI’s capabilities to support the NPAC/SMS effort.  In its Advanced Intelligent Network (AIN) Project for GTE, ESI is designing, implementing, and servicing a Local Service Management System (SMS) for a variety of Intelligent Network Services.  Both the system and software architecture for this Local SMS are parallel to that of a Regional SMS for LNP.  The GTE Local SMS consists of three major subcomponents: sales order entry, order processing, and system management.  System functions include customer number allocation, order validation, updating of customer information, and provisioning data on SCPs.

29

For another customer, ESI developed a CDPD MD-IS (Mobile Data Intermediate System) network infrastructure.  The firm designed, developed, implemented, and is servicing an application for transmission of advanced cellular digital data packets over existing phone channels.  Network management tasks performed here are directly applicable to regional SMS requirements.

GTE commissioned ESI to design a Provisioning Analysis and Control System (PACS).  These software modules were used to automate complex phone service provisioning. Phone service orders are programmed in the switch using an ESI-Developed Interface.

ESI designed a Benefits Eligibility Verification System utilizing a web server host and interface for US WEST.  The current pilot system will eventually provide the infrastructure necessary to support many health care transactions.  The user interface proposed for NYCAC NPAC/SMS is based on the design and development completed for this project.

Write-ups of other ESI projects that are similar in complexity and scope to the NYCAC NPAC/SMS are provided in Appendix A of our response.

1.3.3DSET Corporation Background, Qualifications, & Relevant Experience

DSET Corporation is a firm with extensive experience designing and implementing tools to effect TMN system interfaces.  They have developed and provided technology to both equipment manufacturers and end users and have worldwide experience with GDMO modeling.  DSET develops, licenses and services a suite of tools for building agent and manager functionality conforming to Open Systems Interconnect (OSI) network management standards.  These standards include CMIP (the Common Management Information Protocol), ASN.1 (Abstract Syntax Notation 1), and GDMO (the Guidelines for the Definition of Managed Objects).

30

In 1989 and 1990, DSET developed its own development platform, called DSG, the Distributed Systems Generator.  DSG provides: 1) a powerful object oriented development methodology, ideally suited to develop object oriented CMIP applications, and 2) a communications infrastructure critical to real-time embedded and distributed applications.

With its native support for ASN.1 and OSI, the DSG platform quickly became the backbone of the DSET TMN (Telecommunications Management Network) tools.  All of the DSET TMN tools are built on top of this platform.  Included are CMIP, TMN Agent Toolkit, TMN Manager Tools, CMIP Agent Tester, CMIP Agent Emulator, etc.  The platform architecture provides the DSET TMN tools with a number of industry competitive distinctions.  For example, cross platform development is facilitated.  Applications developed on a UNIX platform can be easily migrated to a real-time operating system platform.  An element manager comprising both TMN agent and manager roles is simplified in the DSET architecture because the DSG platform underlies both agent and manager components.  Communications between the agent and the manager are easily handled by the DSG platform.

With five years of development enhancements, the DSG platform is a heavy-duty, well-tested, industrial- strength platform effective for UNIX and real-time embedded systems applications.  DSET invests significantly in new development.  The DSET tools are regularly updated and enhanced to meet customers’ needs.

Currently, DSET and its tools play an important part in the development of the NPAC SMS for Chicago.  DSET has been used to review the NPAC SMS Interoperable Interface Specification.  DSET’s tools have been used to ensure that the GDMO object code and ASN.1 source compile.  As implementation proceeds in Chicago, DSET will assist in the interoperability testing of the NPAC SMS interfaces with the carriers’ local SMSs and SOAs.  Lockheed Martin will use the DSET suite of tools for the NPAC

31

SMS deployed in New York and in the surrounding region, and it is anticipated that DSET will also support interoperability testing.

DSET plays an active role in industry core standards committees to be aware of and influence new standards that impact the DSET software tools.  Some of the key standards committees are:

•The Network Management Forum

•OSE (Open Systems Environment) Implementors Workshop (OIW)

•The ANSI T1M1.5 Committees.

As shown in Exhibit 1.3-7, DSET’s experience spans many industry-related fields and applications, including:

•Electronic bonding

•AIN Service Management Systems

•TR-303

•Wireless CDPD

•Network traffic (GR-495).

32

Electronic Bonding

DSET’s CMIP tools are used extensively for electronic bonding.  Both local telephone companies (LECs) and interexchange carriers (IXCs), maintain trouble administration systems.  When telephone company customers call their local telephone company to report a problem on the telephone line, the LEC enters this as a trouble ticket into one of their database systems to manage resolution.  If, for example, the LEC dispatches a repair person to a customer’s location to work on the problem, this is recorded in the trouble administration system.  The status of the outstanding trouble ticket is updated regularly.  When the trouble is cleared, this is entered into the system as well.

Many troubles will also impact the IXC serving the customer.  To manage this, the IXC maintains its own trouble administration systems and manually enters information it obtains from the customer or from the LEC into their system.  In 1993, a better way to manage the resolution of problems across carrier domains was developed by an industry committee, which agreed to electronically bond the trouble administration system of the LECs to those of the IXCs utilizing a CMIP gateway architecture.  The IXC would build a CMIP manager functionality to send messages from its trouble administration systems to the LECs over a full 7-layer OSI stack.  The LECs would build a CMIP Agent functionality to connect messages from the IXC Manager to its trouble administration systems.  The carriers worked together in the TIM1.5 Committee of ANSI to build a managed object model, ultimately under the specifications T1.227 and T1.228, to handle the management functionality.

To date, four of the carriers have selected the DSET CMIP Agent and Manager tools to build their own CMIP Gateway.  This application provided DSET with a number of new challenges.  For example, the CMIP stack had to undergo full compliance testing under the CTS-3 Conformance Testing Suite provided under the auspices of the Corporation for Open Systems and the International Consortium for Conformance Testing.  In 1994, DSET completed this multi-month process on several UNIX platforms.

33

With stack conformance testing accomplished, the carriers integrated the CMIP Gateways into their trouble administration systems.  Once completed, their systems underwent comprehensive interoperability testing between carriers.  DSET assisted its customers through this rigorous effort, which was followed by managed object conformance testing for each of the carriers.  AT&T, BellSouth, Southwestern Bell, and Pacific Bell have utilized the DSET CMIP Agent and Manager tools to build their CMIP Gateways.  With DSET’s software and consulting support, all four have successfully implemented their systems and have had them in commercial service since late 1994.

A second electronic bonding application, for Preferred Interexchange Carrier (PIC), is under standardization and in early development at this point by some of the carriers.  All four of the carriers mentioned in the previous paragraph have selected the DSET tools for PIC.  Other telephone companies, including Ameritech, Bell Atlantic, NYNEX, Cincinnati Bell Telephone, and Southern New England Telephone, are exploring the use of the DSET CMIP tools for PIC.

SMS for AIN Services Interfacing to SCPs

Bellcore selected the DSET software for several aspects of its Integrated Service Control Point (ISCP).  The DSG software was used as the communications infrastructure internally to the ISCP, and DSET ASN.1 tools were used as the basis for two of the ISCP interfaces.  These are the provisioning interface called the Service Provisioning and Creation Environment (SPACE) Server, and the Billing interface.  Both of these interfaces use an RFC 1006 OSI stack from OSET and a message set and context definitions built with the DSET tools.  Bellcore delivered DSET software in its ISCP 3.0 and is now developing its third generation of ISCP (ISCP 5.0) based on the DSET software.  This has been successful both for Bellcore and DSET.  The interface work with Bellcore led DSET to many vendors and companies building service management systems (SMS) to communicate with service control point

34

(SCP) systems and service order systems.  Other companies using the DSET AIN Service Order software tools include:  DSC Communications for their SMS; Bell Atlantic for their SMS and billing systems; Southwestern Bell for their AIN interfaces; Pacific Bell for an intelligent peripheral processor to their Service Order systems; US West for their AIN billing systems interface; and Stentor in Canada for their SMS interface and the IBM SCP interface.

1.3.4Stratus Computer, Inc., Background, Qualifications, & Relevant Experience

Stratus Computer, Inc., a major hardware developer founded in 1980, designs, manufactures, services, and supports a broad line of systems, software, communications, and peripherals for critical on-line computing.  Stratus systems are designed to exceed fault tolerance, reaching “continuous availability.” The company began concentrating on the telecommunications industry in 1990, and today more than 33% of its current revenues are derived from servicing telecommunications.  By the end of 1997, that proportion should exceed 50%.

Stratus has made its systems the platforms of choice for long distance carriers, RBOCs, and independent companies in the United States, Asia, and Europe. Switch vendors, including Ericsson, Olivetti, NEC, and AT&T, have chosen Stratus computer platforms for remarket to the industry.  Traditional applications running on Stratus systems include network monitoring and analysis, network facilities testing, Video Dial Tone, 800-number operator services, directory assistance, E-911 services, enhanced billing, and mobile communications network control.  Recent applications include: the cellular management system, home locator register for cellular providers, and PCS.  Stratus Intelligent Network Applications Platform (SINAPTM) incorporates the SS7 protocol.

Stratus systems, using SS7 and X.25 protocols, function as service control points for defining subscriber services, running applications such as HLR.  They also serve as base platforms for a complete set of

35

UNIX-based software.  Stratus systems installed in OS environments help improve the efficiency of the operational infrastructure of the network, reducing operating costs.  Applications available on Stratus include real-time billing, voice response directory assistance, payphone management, and automated dispatch.  Network management applications and network monitoring operations are consolidated on Stratus systems to provide centralized surveillance and analysis of network elements, alarms, and trouble ticket operations for any size network.

36

This Page Intentionally Blank

37

NYCAC NPAC/SMS Proposal 1.3 Background, Quals., & Relevant Experience

HIGHLIGHTS

•Leading neutral third party administrator of databases and systems for the telecommuni-cations industry

•Third party administrator/agent for more than 140 jurisdictions

•Deep experience with NPAC type operations via our 800 NASC contract and recent Chicago NPAC/SMS work

•Strong telecommunications system development and system provision expertise

1.3BACKGROUND, QUALIFICATIONS, & RELEVANT EXPERIENCE (RFP Sect. 1.3.1.2)

The Lockheed Martin Corporation’s reputation as a leader in service and technological innovation has been demonstrated on many programs similar to the NPAC/SMS.

Lockheed Martin IMS is a wholly owned subsidiary of the Lockheed Martin Corporation, a broadly based $30 billion firm.  Headquartered in Bethesda, Maryland, Lockheed Martin employs nearly 200,000 workers and maintains a position as one of the most stable and financially secure firms in the world.  For more than 70 years, the companies forming Lockheed Martin have satisfied a range of clients in demanding high visibility projects with on-time and on-budget delivery of products that exceed client expectations.

Lockheed Martin is well known as a premier provider of advanced technologies in complex systems that deliver innovative and sophisticated solutions.  Lockheed Martin is a leader in space exploration, missile production, and systems management of complex projects.  It provides systems for space and military applications and has strong positions in expanding markets that demand high technology solutions and strict management control; integration and information management services; and system and management solutions for high volume transaction processing in time- and mission-critical environments.

Lockheed Martin IMS—a leading full-service provider of integrated systems solutions chosen by the Corporation to service LNP—has extensive and deep systems integration, data processing, and customer

38

service experience focused on specialized client needs in regulated and complex business environments that demand management expertise and sophisticated technical solutions.  As a service-oriented company, Lockheed Martin IMS draws on the product development assets and deep technical strengths of other Lockheed Martin companies to bring valuable expertise and experience to IMS’ customers.

Systems management, integration, and specialized technology services—provided by the Corporation’s Information and Technology Services Sector, shown in Exhibit 1.3-1—are Lockheed Martin’s fastest-growing lines of business.  The Corporation has made a strong commitment to these areas of business while placing an increased emphasis on product and business development.

1.3.1   Lockheed Martin IMS Background and Qualifications

Lockheed Martin IMS was founded in 1963 and has evolved into a highly diverse data processing firm.  Headquartered in Teaneck, New Jersey, we have more than 40 regional offices worldwide as shown in Exhibit 1.3-2, and currently employ more than 1,400 individuals.  We provide third party services and systems for more than 140 separate customers in a variety of applications.  We have developed extensive and deep systems integration, data processing, and customer service experience focused on specialized client needs.  Our role within Lockheed Martin is to provide full facility management services related to high volume automated transaction processing.  Our mission is to be the preeminent provider of high quality operational systems and third party services to government programs and public and private sector organizations.

Much of our business involves designing and delivering management and data processing services for complex, multifaceted customer entities with performance and service needs similar to the NPAC/SMS.  We have a state-of-the-art services facility at our data center in Tarrytown, New York, staffed by more than 150 experienced systems analysts, management personnel, and user support teams.  These

39

individuals and others offer expertise in operations and functions mirroring those proposed for the NPAC/SMS.

Lockheed Martin IMS and its key management staff are organized into the “lines of business” depicted in Exhibit 1.3-3.

•Communications Industry Services—This organization provides neutral third party services and supporting systems to the telecommunications industry, including two of particular relevance to the NYCAC NPAC/SMS.  Our operation of the 800 NASC and implementation of the NPAC/SMS for Chicago are performed by the organization.

•Children and Family Services—This organization focuses on privatization of systems development, operations, and associated services in support of programs concerned with the health and welfare of children and their families, including child support enforcement and electronic benefits transfer.  Children and Family Services has active contracts in New York, Maryland, California, Illinois, Minnesota, Virginia, Pennsylvania, and Colorado.  Service parallels with the NPAC/SMS include customer service, training, hardware and software maintenance, and facilities management.

•Municipal Services—This organization provides systems, large-scale database operations, and back-office services to more than 100 cities in support of high-volume parking management, traffic violations processing, and emergency medical services billing programs.  There are parallels between service offerings in this business line and NPAC/SMS requirements, including customer service, hardware and software maintenance, customer account maintenance, performance reporting, and training.  Operating in high demand, high scrutiny public environments, we manage enforcement programs that dramatically improve client revenues and meet the customer’s need for responsive and sensitive service.

40

•Transportation Systems and Services—Established in 1986, this organization now serves toll authorities and more than 30 states, providing electronic toll collection systems and services; supporting the registration, taxation, and regulation of commercial motor vehicles with systems integration, software development and program management functions; and serving the motor carrier industry with “Intelligent Transportation” solutions.

•Criminal Justice Services—Our newest organization leverages core competencies of the company into the criminal justice field through the provision of court fine and fee collection services.

In each of these enterprises, we are called upon to provide solutions that require superior service and strict information security.  All of our lines of business are founded upon the right blend of people, facilities, systems, and process knowledge.  Our ability to support large, complex systems derives from our capacity to collect and place the appropriate resources: hardware, software, and personnel.  In addition, all of our services have the characteristics required of the NPAC/SMS and local number portability services:  high visibility, revenue sensitive, time sensitive, enhanced service to all clients within a customer-sensitive, complex environment.

1.3.1.1Lockheed Martin IMS Relevant Experience

Lockheed Martin IMS has been involved with number portability since responding to the initial Bellcore RFP for the 800 NASC in l988.  Marketplace dynamics, technical advances, and regulatory change drove the communications industry’s requirement that a neutral third party administrator provide local number portability.  Lockheed Martin committed to play a leadership role in the advent of number portability, supporting the industry’s resolution of regulatory, technical, and operating issues surrounding 800 and local number portability.  This perseverance paid off in 1993, when Lockheed Martin IMS was selected to transition from Bellcore and operate the 800 NASC on a neutral, third party basis.

41

In November 1993, Lockheed Martin IMS completed successful transition from the Bellcore NASC, and has operated the 800 NASC to the satisfaction of our users and to Database Services Management, Incorporated (a subsidiary company of Bellcore) ever since.  Much of our experience over the past three years relates directly to the NPAC/SMS.  For example, in our operation of the 800 NASC, we provide the following categories of NPAC services, all of which are required by Section 12 of the NYCAC NPAC/SMS RFP:

System Administration

Exhibit 1.3-4 depicts the direct correlation between the NPAC/SMS requirements and our experience in performing the same functions.  Clearly, we have had significant exposure to all aspects of the RFP’s System Administration requirements, enabling us to provide carriers with solid, high quality NPAC service.

SYSTEM ADMINISTRATION

A Direct Correlation Between Our Experience and NPAC Needs

NPAC Functions	Lockheed Martin 800 NASC Experience (Through 1995)
Logon Administration	•     Processed over 2,100 logon requests •     Uses identical process as specified in RFP
Customer Record Security	•     Prepared Security Permissions Document •     Audit user ID usage •     Stringent facility and LAN security •     Periodic reports
Scheduled System Unavailability Notification	•     Provide six months advance notice •     Provide a minimum of two weeks final notice via Bulletin Board and fax
Software Release Acceptance Testing	•     Created approximately 2000 new feature and regression test cases in support of three major releases
Service Administration	•     Performed thousands of transactions to update 800 portability tables.

42

NPAC Functions	Lockheed Martin 800 NASC Experience (Through 1995)
Mass Change Administration	•     Have coordinated efforts between data center and site support on scores of NPA splits and changes. •     Good working relationships with NANPA and traffic routing administrators
Exhibit 1.3-4. We currently perform all NPAC System Administration tasks for the SMS/800 system.

User Support

Our 800 NASC User Support team knowledge is fully transferable to the NYCAC NPAC/SMS effort, providing the NYCAC with all the experiential benefits gained from the 800 NASC program.  Exhibit 1.3-5 shows, in a similar fashion, the strong foundation upon which we base our confidence in being able to perform the required user support functions within specified performance standards.

USER SUPPORT

A Direct Correlation Between Our Experience and NPAC Needs.

NPAC Functions	Lockheed Martin 800 NASC Experience (Through 1995)
User Problem Resolution	•     Processed over 30,000 user calls •     Developed trouble tracking system to accom-modate user queries •     Exceeded response performance objective •     93% of calls closed on initial contact
Software Release Acceptance Testing	•     Created approximately 2000 new features and regression test cases in support of three major releases
Software Modification Update	•     Provide a minimum of six months advanced notice •     Provide a minimum of two weeks confirming notification
Training Administration	•     Developed training updates in support of major releases •     Created training curricula brochure •     Scheduled training, billing, and collections for over 120 students
Document Order Administration	•     Distribute application training student and instructor guides which we develop and maintain •     Work closely with Bellcore document distribution center •     Distribute industry guidelines

43

NPAC Functions	Lockheed Martin 800 NASC Experience (Through 1995)
Training and Documentation User Feedback	•     All students are given post-training surveys •     Information shared with documentation preparers
Local SMS Download Problem Resolution	•     SCP Download exception reports reviewed daily •     SCP Download problem resolution coordinated with application support

Exhibit 1.3-5.The benefits to be derived from the transfer of comparable knowledge is readily apparent from the listing of our user support responsibilities in the 800 NASC.

44

System Support

We will provide technical support of the NPAC/SMS system operation, resolving communications and interface problems, administering scheduled report production, and notifying users of unscheduled unavailability of the system. In addition, we will administer, operate, and maintain the NPAC/SMS’ extensive, state-of-the-art infrastructure of redundant voice and data communications, WAN, Stratus NPAC SMS servers, LAN, PBX/ACD, etc.  Exhibit 1.3-6 demonstrates the relevancy of our 800 NASC role to the NPAC System Support requirements.

SYSTEM SUPPORT

A Direct Correlation Between Our Experience and NPAC Needs

NPAC Functions	Lockheed Martin 800 NASC Experience (Through 1995)
NPAC SMS Report Administration	•     Prepare and distribute regularly scheduled periodic reports to users •     Coordinate and negotiate ordering, scheduling and distribution of special request reports •     Explain report content to users
Failure recovery administration and user notification	•     Notify users via NASC recorded messages and fax •     Maintain close coordination with data center and site support •     Keep users updated every 30 minutes
NPAC SMS Interface Monitoring	•     Involved in the reporting and resolution of data link problems •     Assist users in accessing the system
Software Release Acceptance Testing	•     Created approximately 2000 new feature and regression test cases in support of three major releases

Exhibit 1.3-6.Lockheed Martin’s administrator responsibilities over the last 3 years have prepared us well for assuming the SMS system support functions.

In addition to our 800 NASC experience, Lockheed Martin IMS was selected by the Illinois Commerce Commission SMS/RFP Subcommittee to develop an NPAC SMS and provide supporting NPAC services

45

for Chicago LATA 358.  In Chicago, the six member carriers of the SMS/RFP Subcommittee—Ameritech, AT&T, MCI, Sprint, MFS Communications, and Teleport Communications Group—released the ICC NPAC/SMS RFP and unanimously selected Lockheed Martin IMS to develop and administer the NPAC/SMS.

The Lockheed Martin Team is currently implementing the NPAC/SMS and supporting operations for Chicago.  Just weeks ago, the Interoperable Interface Specification and the Functional Requirements Specification of the NPAC SMS developed by Lockheed Martin were approved by the Illinois LNP, L.L.C. members.  We have also begun an extraordinary amount of work on the external and internal NPAC SMS design.  The Chicago NPAC SMS (Release 1) and supporting NPAC operations are scheduled to be up and operational, ready for turn-up testing, in March 1997.

For the NYCAC NPAC/SMS, the Lockheed Martin Team will draw on our Chicago NPAC/SMS experience, as appropriate.  We will commit a group of experience professionals with directly relevant experience and provide them with the latest tools for accomplishing their mission, thus satisfying not only our performance metrics but carrier expectations. With our acknowledged NASC and Illinois NPAC/SMS background, we envision a smooth, timely, and problem-free implementation of the NPAC/SMS for the NYCAC.

Write-ups of additional Lockheed Martin projects that are similar in complexity and scope to the NYCAC NPAC/SMS are provided in Appendix A of our response.

46

1.3.2Evolving Systems Incorporated (ESI) Background, Qualifications, & Relevant Experience

Over its 10-year history, ESI has become one of the nation’s foremost UNIX development companies.  Its core competency includes developing telecommunications Operations Support Systems (OSS) and Business Support Systems (BSS) for many telecommunications providers.  Some of the particularly relevant systems and work they have accomplished include:

•Development of the NPAC/SMS application for Chicago.  Current work includes the development of the Interoperable Interface Specification for the NPAC SMS interfaces to carrier local SMSs and SOAs.  Additionally, ESI is assisting Lockheed Martin in the finalization of the NPAC SMS external design.  Work is well underway in the internal NPAC SMS system design, and code and unit testing has already started.

•Development of PilotPLUSä, a Business Support System (BSS) for CDPD. PilotPLUSä is a complete ready-to-install customer care, provisioning, rating, and billing system that supports the CDPD wireless industry. ESI is currently servicing the PilotPLUSä application for three CDPD carriers within the United States.

•Development of software for a 13,000-terminal, 600 UNIX computer, nationwide network for a major telecommunications company. They also provided the second tier of support for this network with more than 99% availability over a five-year period.

•Consulting services for a Regional Bell Operating Company (RBOC) to review the design of Bellcore’s Network Monitoring and Analysis (NMA) System. NMA is used by several of the RBOCs to monitor all of their trunks and network elements, such as central office switches and channel banks.

47

•Development of the Interactive Voice Response (IVR) systems, including screen synchronization of caller data with voice call arrival, and preview, progressive, and predictive dialing.

•Development of the Evolving Systems, Inc. Environment (ESIEâ). ESI developed an application layer that rides on top of UNIX to provide system operators and developers with a robust set of tools for remote reporting, analysis, and control. ESIEâ is used in virtually all ESI projects. ESI also developed an SNMP Management Information Base (MIB) that allows systems based on the ESIEâ to be remotely monitored and controlled.

•Development of the ESI Voice/Data Integration System (VDIS), an API based on ESIEâ.  VDIS combines the power of an Automatic Call Distributor (ACD), IVR, data communications with mainframes or other external systems, sophisticated agent interfaces, and a predictive dialing mechanism to produce significant efficiencies in both inbound and outbound call processing.

In addition, four projects particularly demonstrate ESI’s capabilities to support the NPAC/SMS effort.  In its Advanced Intelligent Network (AIN) Project for GTE, ESI is designing, implementing, and servicing a Local Service Management System (SMS) for a variety of Intelligent Network Services.  Both the system and software architecture for this Local SMS are parallel to that of a Regional SMS for LNP.  The GTE Local SMS consists of three major subcomponents: sales order entry, order processing, and system management.  System functions include customer number allocation, order validation, updating of customer information, and provisioning data on SCPs.

48

For another customer, ESI developed a CDPD MD-IS (Mobile Data Intermediate System) network infrastructure.  The firm designed, developed, implemented, and is servicing an application for transmission of advanced cellular digital data packets over existing phone channels.  Network management tasks performed here are directly applicable to regional SMS requirements.

GTE commissioned ESI to design a Provisioning Analysis and Control System (PACS).  These software modules were used to automate complex phone service provisioning. Phone service orders are programmed in the switch using an ESI-Developed Interface.

ESI designed a Benefits Eligibility Verification System utilizing a web server host and interface for US WEST.  The current pilot system will eventually provide the infrastructure necessary to support many health care transactions.  The user interface proposed for NYCAC NPAC/SMS is based on the design and development completed for this project.

Write-ups of other ESI projects that are similar in complexity and scope to the NYCAC NPAC/SMS are provided in Appendix A of our response.

1.3.3DSET Corporation Background, Qualifications, & Relevant Experience

DSET Corporation is a firm with extensive experience designing and implementing tools to effect TMN system interfaces.  They have developed and provided technology to both equipment manufacturers and end users and have worldwide experience with GDMO modeling.  DSET develops, licenses and services a suite of tools for building agent and manager functionality conforming to Open Systems Interconnect (OSI) network management standards.  These standards include CMIP (the Common Management Information Protocol), ASN.1 (Abstract Syntax Notation 1), and GDMO (the Guidelines for the Definition of Managed Objects).

49

In 1989 and 1990, DSET developed its own development platform, called DSG, the Distributed Systems Generator.  DSG provides: 1) a powerful object oriented development methodology, ideally suited to develop object oriented CMIP applications, and 2) a communications infrastructure critical to real-time embedded and distributed applications.

With its native support for ASN.1 and OSI, the DSG platform quickly became the backbone of the DSET TMN (Telecommunications Management Network) tools.  All of the DSET TMN tools are built on top of this platform.  Included are CMIP, TMN Agent Toolkit, TMN Manager Tools, CMIP Agent Tester, CMIP Agent Emulator, etc.  The platform architecture provides the DSET TMN tools with a number of industry competitive distinctions.  For example, cross platform development is facilitated.  Applications developed on a UNIX platform can be easily migrated to a real-time operating system platform.  An element manager comprising both TMN agent and manager roles is simplified in the DSET architecture because the DSG platform underlies both agent and manager components.  Communications between the agent and the manager are easily handled by the DSG platform.

With five years of development enhancements, the DSG platform is a heavy-duty, well-tested, industrial- strength platform effective for UNIX and real-time embedded systems applications.  DSET invests significantly in new development.  The DSET tools are regularly updated and enhanced to meet customers’ needs.

Currently, DSET and its tools play an important part in the development of the NPAC SMS for Chicago.  DSET has been used to review the NPAC SMS Interoperable Interface Specification.  DSET’s tools have been used to ensure that the GDMO object code and ASN.1 source compile.  As implementation proceeds in Chicago, DSET will assist in the interoperability testing of the NPAC SMS interfaces with the carriers’ local SMSs and SOAs.  Lockheed Martin will use the DSET suite of tools for the NPAC

265

SMS deployed in New York and in the surrounding region, and it is anticipated that DSET will also support interoperability testing.

DSET plays an active role in industry core standards committees to be aware of and influence new standards that impact the DSET software tools.  Some of the key standards committees are:

•The Network Management Forum

•OSE (Open Systems Environment) Implementors Workshop (OIW)

•The ANSI T1M1.5 Committees.

As shown in Exhibit 1.3-7, DSET’s experience spans many industry-related fields and applications, including:

•Electronic bonding

•AIN Service Management Systems

•TR-303

•Wireless CDPD

•Network traffic (GR-495).

Electronic Bonding

DSET’s CMIP tools are used extensively for electronic bonding.  Both local telephone companies (LECs) and interexchange carriers (IXCs), maintain trouble administration systems.  When telephone company customers call their local telephone company to report a problem on the telephone line, the LEC enters this as a trouble ticket into one of their database systems to manage resolution.  If, for example, the LEC dispatches a repair person to a customer’s location to work on the problem, this is

51

recorded in the trouble administration system.  The status of the outstanding trouble ticket is updated regularly.  When the trouble is cleared, this is entered into the system as well.

Many troubles will also impact the IXC serving the customer.  To manage this, the IXC maintains its own trouble administration systems and manually enters information it obtains from the customer or from the LEC into their system.  In 1993, a better way to manage the resolution of problems across carrier domains was developed by an industry committee, which agreed to electronically bond the trouble administration system of the LECs to those of the IXCs utilizing a CMIP gateway architecture.  The IXC would build a CMIP manager functionality to send messages from its trouble administration systems to the LECs over a full 7-layer OSI stack.  The LECs would build a CMIP Agent functionality to connect messages from the IXC Manager to its trouble administration systems.  The carriers worked together in the TIM1.5 Committee of ANSI to build a managed object model, ultimately under the specifications T1.227 and T1.228, to handle the management functionality.

To date, four of the carriers have selected the DSET CMIP Agent and Manager tools to build their own CMIP Gateway.  This application provided DSET with a number of new challenges.  For example, the CMIP stack had to undergo full compliance testing under the CTS-3 Conformance Testing Suite provided under the auspices of the Corporation for Open Systems and the International Consortium for Conformance Testing.  In 1994, DSET completed this multi-month process on several UNIX platforms.

With stack conformance testing accomplished, the carriers integrated the CMIP Gateways into their trouble administration systems.  Once completed, their systems underwent comprehensive interoperability testing between carriers.  DSET assisted its customers through this rigorous effort, which was followed by managed object conformance testing for each of the carriers.  AT&T, BellSouth, Southwestern Bell, and Pacific Bell have utilized the DSET CMIP Agent and Manager tools to build

52

their CMIP Gateways.  With DSET’s software and consulting support, all four have successfully implemented their systems and have had them in commercial service since late 1994.

A second electronic bonding application, for Preferred Interexchange Carrier (PIC), is under standardization and in early development at this point by some of the carriers.  All four of the carriers mentioned in the previous paragraph have selected the DSET tools for PIC.  Other telephone companies, including Ameritech, Bell Atlantic, NYNEX, Cincinnati Bell Telephone, and Southern New England Telephone, are exploring the use of the DSET CMIP tools for PIC.

SMS for AIN Services Interfacing to SCPs

Bellcore selected the DSET software for several aspects of its Integrated Service Control Point (ISCP).  The DSG software was used as the communications infrastructure internally to the ISCP, and DSET ASN.1 tools were used as the basis for two of the ISCP interfaces.  These are the provisioning interface called the Service Provisioning and Creation Environment (SPACE) Server, and the Billing interface.  Both of these interfaces use an RFC 1006 OSI stack from OSET and a message set and context definitions built with the DSET tools.  Bellcore delivered DSET software in its ISCP 3.0 and is now developing its third generation of ISCP (ISCP 5.0) based on the DSET software.  This has been successful both for Bellcore and DSET.  The interface work with Bellcore led DSET to many vendors and companies building service management systems (SMS) to communicate with service control point (SCP) systems and service order systems.  Other companies using the DSET AIN Service Order software tools include:  DSC Communications for their SMS; Bell Atlantic for their SMS and billing systems; Southwestern Bell for their AIN interfaces; Pacific Bell for an intelligent peripheral processor to their Service Order systems; US West for their AIN billing systems interface; and Stentor in Canada for their SMS interface and the IBM SCP interface.

53

1.3.4Stratus Computer, Inc., Background, Qualifications, & Relevant Experience

Stratus Computer, Inc., a major hardware developer founded in 1980, designs, manufactures, services, and supports a broad line of systems, software, communications, and peripherals for critical on-line computing.  Stratus systems are designed to exceed fault tolerance, reaching “continuous availability.” The company began concentrating on the telecommunications industry in 1990, and today more than 33% of its current revenues are derived from servicing telecommunications.  By the end of 1997, that proportion should exceed 50%.

Stratus has made its systems the platforms of choice for long distance carriers, RBOCs, and independent companies in the United States, Asia, and Europe. Switch vendors, including Ericsson, Olivetti, NEC, and AT&T, have chosen Stratus computer platforms for remarket to the industry.  Traditional applications running on Stratus systems include network monitoring and analysis, network facilities testing, Video Dial Tone, 800-number operator services, directory assistance, E-911 services, enhanced billing, and mobile communications network control.  Recent applications include: the cellular management system, home locator register for cellular providers, and PCS.  Stratus Intelligent Network Applications Platform (SINAPTM) incorporates the SS7 protocol.

Stratus systems, using SS7 and X.25 protocols, function as service control points for defining subscriber services, running applications such as HLR.  They also serve as base platforms for a complete set of UNIX-based software.  Stratus systems installed in OS environments help improve the efficiency of the operational infrastructure of the network, reducing operating costs.  Applications available on Stratus include real-time billing, voice response directory assistance, payphone management, and automated dispatch.  Network management applications and network monitoring operations are consolidated on Stratus systems to provide centralized surveillance and analysis of network elements, alarms, and trouble ticket operations for any size network.

54

This Page Intentionally Blank

55

NYCAC NPAC/SMS Proposal 1.4 Neutrality

HIGHLIGHTS

•Leading neutral third-party admin-istrator for the telecommunications industry

•Proven procedures and processes to guarantee neutral, impartial, and evenhanded operation of the NPAC

•All team members are 100% neutral, including the NPAC SMS hardware and software providers

1.4NEUTRALITY (RFP Sect. 1.3.1.3 and 1.3.4)

NYCAC can be assured of fair and impartial access of NPAC SMS data by selecting a neutral third party team to provide a complete “turnkey” NPAC SMS solution and operate the NPAC on a day-to-day basis.

As our experience demonstrates, Lockheed Martin understands precisely our role as a neutral third party.  Every day, we demonstrate our qualifications as a neutral third party in our implementation of the NPAC SMS for Chicago and our operation of the 800 NASC.  We understand that in our role as the NYCAC NPAC/SMS provider that neutrality, confidentiality, fairness, and impartially are paramount.  Over the years, we have perfected the procedures to support the neutral third party administration of databases.  Our employees are specifically trained on the definition of third party neutrality and to make management aware of any situations that could jeopardize fair and evenhanded service.

Specifically, Lockheed Martin IMS as the Primary Vendor/System Administrator meets all RFP mandated neutrality requirements:

A.We are a neutral third party that has no financial or market interest in providing local exchange services in the United States

B.1.)We do not have a direct material financial interest in the United States portion of the North American Numbering Plan (NANP), and number assignments pursuant to such Plan, including (but not limited to) telecommunications carriers

56

B.2.)We do not have a direct material financial interest in manufacturing telecommunications network switching or transmission equipment

B.3.)As required by RFP Section 1.3.4, Item B.3, we are not affiliated in other than a de minimis way in any entity described in statements (B.1.) or (B.2.) above

B.4.)We are not involved in a contractual relationship or other arrangement that would impair our ability to administer numbers fairly under the NANP and in accordance with the procedural delivery schedule established by NYCAC as set forth in RFP cover letter and further clarified in NYCAC’s answers to bidders’ questions.

The Lockheed Martin Team, including our subcontractors, certifies that we will abide by the neutrality provisions of Section 1.3.4 of the RFP, which were just itemized above, at all times.

As indicated in Section 1.1 above, neutrality was a major criteria in selecting our teaming partners.  All team members—Lockheed Martin IMS, ESI, DSET, and Stratus—are 100% neutral.  Our team partners, regardless of their project roles, are not predisposed to compromising neutrality by virtue of their own interests or those of their affiliates or owners.  Thus, the otherwise cumbersome “checks and balances” required to control a non-neutral, by definition, subcontractor or team member are eliminated.

Lockheed Martin IMS takes our responsibilities as a neutral third party very seriously, and we understand that supporting business arrangements, processes, and procedures must be in place to ensure evenhanded treatment of all carriers.  Not only do we understand the importance of neutrality, but we demonstrate it every day in our operation of the 800 NASC and implementation of the NPAC/SMS for Chicago.  Using this experience as a base, we will develop and implement policies and procedures to ensure

57

reliable, fair, and impartial access to the NPAC SMS database and evenhanded NPAC service for all NYCAC member carriers.

This Page Intentionally Blank

58

NYCAC NPAC/SMS PROPOSAL 1.5 Corporate Commitment

HIGHLIGHTS

•Full commitment of $30 billion Lockheed Martin Corporation to the telecommunications industry

•Dedicated LOB, Communications Industry Services (CIS), with unsurpassed technical and operating capabilities

•Fully committed to supporting service providers’ needs for neutral services, like LNP

•Fully committed to supporting LNP deployment in the spirit of the LNP workshops

1.5   CORPORATE COMMITMENT

Lockheed Martin IMS (IMS), with the full backing and support of the Lockheed Martin Corporation, is fully committed to supporting the needs of the telecommunications industry.  We have dedicated a line of business, Communications Industry Services (CIS), solely to offer services, like LNP, to the telecommunications industry.  CIS is managed and staffed by experienced, dedicated individuals from within the telecommunications industry who are keenly aware of the sensitivities and needs of the industry at this significant time in the industry’s history.  Those needs include:

•Strict neutrality and evenhandedness

•Guaranteed on-time, low-risk service delivery

•Extremely highly-reliable and consistent service and systems

•Sensitivity to the demands, time-tables, and ambiguities of the current regulatory environment

•Dedication of subject matter expertise in key technologies such as LNP, SMS, and CMISE

•Commitment to develop and deploy cooperatively a first-of-its-kind capability in the industry in a fully open, non-proprietary environment.

Lockheed Martin understands the nature of number portability administration, as well as the challenge the industry faces relative to LNP deployment and deregulation in general.  In recognizing the spirit of the industry’s needs for its selected LNP administrator, we offer services and support that go beyond the letter of the requirements and that speak to our willingness and commitment to provide not just the

59

services procured and contracted for, but address the broader needs that really exist, as depicted in the chart that follows:

Industry Need	Lockheed Martin Response
Leadership in development of open, non-proprietary, NPAC/ SMS technical standards	•     NPAC SMS interfaces (NPAC SMS Interoperable Interface Specification [IIS]) •     NPAC SMS functional requirements (NPAC SMS Generic Functional Requirements Specification) •     Design of functional enhancements in anticipation of regionalization of NPAC/SMS services
Flexibility, given the technical and operational uncertainties	•     Have refined and adapted NPAC/SMS implementation to evolving industry needs •     Incorporated numerous changes and process enhancements (109 new requirements) at service provider request in Illinois during five months of requirements definition, documentation, and review cycles •     Latest industry business process flows incorporated •     Scalability of NPAC/SMS solution, recognizing unpredictability of LNP penetration rates •     A system and service capable of supporting: •     Wireless participation •     Number pooling (pooled number administration) •     Inter-NPAC and national LNP activities
Creativity in engineering and recommending solutions that reflect an understanding of and address underlying business needs	•     Developed implementation enhancement (bulk download capability) to meet performance requirements to suit LSMS constraints and scalability while still meeting the business requirements (to be able to download 25 numbers/second) •     Moved real-time audit processing into NPAC/SMS to simplify LSMS implementation •     Unsolicited enhancements: •     Surrogate SOA capability through direct user interface to NPAC SMS (OpGUI) •     Location portability •     Direct customer-manageable network and profile data on NPAC/SMS

60

Industry Need	Lockheed Martin Response
Support for service-provider system (LSMS, SOA) vendors/ implementers	•     Support of interoperability testing (lab-to-lab developer testing) •     Leadership role in providing Interface Forums to train vendors/developers in implementation of the NPAC SMS interfaces •     Provide NPAC SMS support for system vendors/developers •     End-user graphical interface to NPAC SMS to provide surrogate SOA functions in NPAC in lieu of SOA system upgrades
Harmonize NPAC/SMS service offerings across the industry	•     Development of standardized NPAC SMS generic software for consistency of NPAC/SMS services •     Establishment of standard national NPAC/SMS service pricing for all regions Lockheed Martin IMS may be fortunate to serve •     Common service element-based pricing provides for NPAC/SMS service cost parity across the country •     No inter-regional pricing disparities or inequities for service providers (and their end-users) •     Cost-sharing of economies of scale across regions •     Usage sensitive pricing that links discount thresholds to higher transaction rates
Support aggressive LNP de-ployment schedules	•     Lockheed Martin has the scale, technical strength, and operating capability to implement and deliver NPAC/SMS services. Lockheed Martin is a $30 billion world class systems integration and services provider, operating very large, complex systems, with 200,000 employees •     Strict project schedule and risk management of ongoing development to ensure on-time delivery of NPAC/SMS to industry •     Willingness to initiate early start in New York with good-faith Letter of Intent to lock-in schedule •     Initiated early start in Illinois, well ahead of formation of Illinois LNP LLC and start of contract negotiations •     Incurred financial exposure in Illinois well above that covered by Letter of Intent, in order to safeguard the schedule

61

Industry Need	Lockheed Martin Response
Economic and responsive provision of NPAC/SMS services	•     Lockheed Martin’s NPAC/SMS proposal and implementation program demonstrate our commitment to quality, responsiveness, and economic value •     Lockheed Martin will cooperate with NYCAC to establish processes and provisions ensuring NPAC/SMS services are highly responsive and economically priced •     Depth of Lockheed Martin Corporate resources ($30B, 200K employees, world-class systems integrator) and long experience in being entrusted with national strategic assets (e.g., 800 NASC, defense, aerospace) •     Have agreed to contractual protections in Illinois to ensure continued performance and responsiveness, and independent NPAC/SMS maintenance in case of default •     Active support of open, permanently non-proprietary, technical standards •     Long tradition of Lockheed Martin conducting business with highest of ethics, fairness, and evenhandedness
Flexibility given regulatory uncertainties	•     Willingness to incur substantial financial exposure (early start in Illinois) given these uncertainties •     Firm belief in eventuality of LNP deployment, need for NPAC/SMS services, and Lockheed Martin’s suitability as lead NPAC/SMS services provider •     Have recognized constraints on LLC authority and uncertainty regarding contract term and future events. Have requested reasonable commercial terms under circumstances of early termination without cause •     Willingness to actively support and cooperate, to the extent appropriate, with NANC LNPA standards and selection process •     Willingness to undertake advocacy role with regulators as subject matter experts in NPAC/SMS for the benefit of whole industry to the extent appropriate without jeopardizing strict neutrality (e.g., ex parte 95-116 presentation to FCC).

In selecting Lockheed Martin IMS as the bidding entity for the Corporation, Lockheed Martin has, in fact, committed to perform these services in a reliable, responsive manner and to provide only the highest

62

quality services relative to the technical, management, and administrative demands of this opportunity.  This commitment extends to:

•Technical—All members of the management team and those assigned to key technical and administrative positions are highly experienced and capable of performing their duties in a manner that meets and exceeds the requirements

•Schedule—We will adhere to the NYCAC’s schedule, ensuring that all major milestones are met

•Quality—Our proposed technical solution to the NPAC/SMS is based on delivering a quality product that performs in total accordance with the RFP and industry requirements

•Responsiveness—We will adhere to all contract provisions

•Price and Cost—We will bid a realistic, honest price that reflects our understanding of the marketplace dynamics, is usage sensitive, and establishes a consistent cross regional pricing schedule.

This commitment, made at the highest levels of the Corporation, ensures that only highly qualified personnel are assigned to positions that affect the health or financial well-being of the program.  In designating IMS as the lead, single point of responsibility for this mission, the Corporation has committed the full support of its capabilities and resources to the mission.  As a demonstration of this, IMS established a Communications Industry Services (CIS) line of business and has committed to and is providing the necessary resources to ensure success.  Corporate strengths key to CIS’ success include:

63

•Systems integration—As a systems integrator of advanced information management systems, Lockheed Martin is unsurpassed in scale, scope, or complexity

•Telecommunications expertise—As a provider of advanced networking systems for defense applications, Lockheed Martin is a leader in large, advanced telecommunications technologies

•Information services management—As manager and operator of information management systems, Lockheed Martin is among the largest and most sophisticated in the world

•Financial stability—With $30 billion in annual revenues, Lockheed Martin has scale and financial stability in proportion to the telecommunications industry and to the criticality to the reliable functioning of the networks of inter-carrier services like LNP

•Reliability and quality—Lockheed Martin is frequently relied upon for mission critical roles where reliability and quality are of utmost importance.  Examples include its role in the NASA space program and in its provision of major defense systems

•Neutral and impartial—Lockheed Martin is a neutral, impartial administrator in the telecommunications market

•Integrity—Lockheed Martin operates according to the highest standards of ethics.

Within IMS, CIS is well positioned to apply Lockheed Martin’s full capabilities to the opportunity to serve.  IMS is a successful commercial provider of transactions and out-sourced information management services.  We are customer oriented and experienced in the fast-moving commercial market of information management services.  CIS has been structured to ensure delivery to the market of the best of

64

the Corporation’s large-scale strengths with the responsive effectiveness of Lockheed Martin IMS’ entrepreneurial management.

This Page Intentionally Blank

65

NYCAC NPAC/SMS PROPOSAL 1.6 NPAC/SMS Summary

HIGHLIGHTS

•Modular, rules-based NPAC SMS application software that supports complete NPAC regionalization, including functionality that ex-ceeds RFP requirements

•Diversified wide area network with multiple POPs and fully redundant data paths for access to the primary and backup/disaster recov-ery processors

•Fault tolerant, continuously avail-able, Stratus hardware platform ensures greater than 99.9% reli-ability and availability

•Proven NPAC operations based on SMS/800 administration exper-ience

1.6   NPAC/SMS SUMMARY

The Lockheed Martin Team proposes a superior NPAC/SMS solution that incorporates a highly robust data network, fault tolerant processors, proven suite of system software, modular application software supporting full regionalization, and proven number portability administration experience.

As shown in Exhibit 1.6-1, the NPAC/SMS comprises the following four distinct, yet integrated, components:

•A redundant, reliable WAN that allows LSPs to connect to the virtual point of presence (POP) within New York LATA 132 or to actual facilities-based POPs at the primary and backup/disaster recovery sites

•A proven, fault tolerant computing environment with a proven suite of system software

•Fully regionalized NPAC SMS application software that provides the required user and system functionality

•Supporting NPAC services including data center operations, system administration, user support, training and documentation services, and software support.

66

Without question, the NPAC/SMS implementation and deployment for NYCAC must be an unparalleled success.  Recognizing this, and understanding that each NPAC/SMS component requires state-of-the-art technology and the highest available quality, we are proposing a high quality, robust design that is also very cost effective. Our design is summarized in this section.

1.6.1   NPAC SMS System Network Summary

We propose a robust and reliable system network with multiple points-of-presence (POPs) for local service provider (LSP) access.

Lockheed Martin and ESI — our teammate and telecommunications software developer and network designer for the NPAC/SMS — propose a reliable, redundant wide area network (WAN) that connects LSPs to:  1) the NPAC and primary data center facility in Tarrytown, NY,  2) to the backup/disaster recovery data center in Chicago, IL, via a virtual POP in New York LATA 132 or actual POPs at each facility.  In addition,  ESI has switched-communications links to both data centers that support access to the Stratus processors.  The WAN architecture is shown in Exhibit 1.6-2.  Highlights include:

•A dedicated WAN using leased point-to-point DS-1 circuits, offering ample bandwidth and more reliability and better performance than a virtual private network

•Two facilities-based POPs (Tarrytown and Chicago) for LSP access to both the primary and backup/disaster recovery NPAC SMS computer systems

•Virtual POP located in New York LATA 132 connected via frame relay for LSP access to both the primary and backup/disaster recovery NPAC SMS computer systems

67

•Two DS-1 circuits between the Tarrytown POP and Chicago that are leased from separate carriers for maximum redundancy and diversity

•Enterprise packet switching hubs/routers for redundancy and fault tolerance

•Several supported WAN link types — T1, Fractional T1, Frame Relay, ISDN dial-up, V.34 dial-up (PPP) for flexibility

•Internet access using highly secure IP firewall/gateway/proxy servers for convenience and flexibility.

This architecture allows the LSPs to select their terminating NPAC POP and form a backup link (dedicated or dial-up) as well as provides dial-up user access.

1.6.2   NPAC SMS Architecture Summary

Because the NPAC SMS is so critical to the local number portability landscape, we incorporated within our design of the NPAC SMS maximum reliability, availability, cost-performance, expandability, connectivity, and security.

Our proposed NPAC architecture employs a state-of-the-art design that not only delivers the required reliability, availability, and functionality, but has the capability to meet current and future capacity and performance needs as well.  An overall view of the NPAC SMS architecture at the Tarrytown NPAC facility is presented in Exhibit 1.6-3.

Reliability and Availability

The RFP mandates very high levels of reliability and availability, including:

68

•99.9% reliability of NPAC SMS including all functionality and data integrity [R10-2]

•24-by-7 NPAC SMS and interface operations [R6-22, R10-1]

•99.9% availability of NPAC SMS interfaces [R6-23]

•Nine hours or less of NPAC SMS unscheduled downtime [R10-3]

•One hour or less NPAC SMS mean-time-to-repair [R10-4]

•Restoration of receiving, processing, and broadcasting updates within 24 hours after a disaster [R10-13]

•Full functionality within 48 hours after a disaster [R10-13].

By specifying such stringent requirements, it is evident that the NYCAC considers the reliability and availability of the NPAC/SMS to be extremely important.  We share the same view.  As such, we have designed the NPAC/SMS architecture to include multiple levels of redundancy and failover.  For example, we are proposing:

•Redundant WAN connecting redundant, geographically separate primary and backup/disaster recovery data centers as described in 1.6.1 above

•Multiple virtual and facilities-based POPs for diverse routing and LSP access to the NPAC SMS

•Enterprise packet switching hubs/routers for redundancy and fault tolerance

•Fault-tolerant, continuously-available Stratus hardware for the NPAC SMS server

•Redundant Virtual LAN at the NPAC

•Fault-resilient NPAC SMS application software.

Of particular interest is the proposed Stratus Continuum NPAC/SMS servers.  These servers are hardware fault-tolerant, offering immediate, on-board, automatic self-checking logic and duplexing of all major hardware components.  The Stratus platform provides continuous availability, greatly exceeding

69

the capability of high-availability systems as evidenced by a recent independent study made by the Standish Group International, Inc.  As shown in Exhibit 1.6-4, the Standish Group tested eight different

fault-tolerant/high availability solutions from leading computer vendors, including IBM and Hewlett-Packard.

The Standish Group tested each solution by measuring eight different types of availability — node, CPU, DASD, LAN, WAN, operating system, file system, and other — as well as compliance with Open System Standards.  As shown, Stratus Computer’s fault-tolerant, continuous availability solution beat the entire field with an overall grade of “A-.”  Competing “high availability” solutions from IBM, DEC, and HP graded substantially lower — C, C+, and D+, respectfully.

In addition, the NPAC/SMS operating system, Stratus UX, and layered platform products, such as Oracle RDBMS, provide an extremely reliable and proven base upon which the NPAC/SMS application layer operates.  The NPAC/SMS and interfaces are being developed using proven application support facilities, including ESI’s Basic Application Creation Environment (BACE).  BACE provides a robust, fault resilient environment, isolating software failures to specific processing steps and transactions, thereby safeguarding overall NPAC SMS availability.

Capacity and Performance

The RFP also mandates certain NPAC SMS capacity and performance.  Specifically, the NPAC/SMS must accommodate and process:

•Up to 50 Local Service Providers, 10 initially,  across the State of New York [R10-15]

•Up to and estimated 180,000,000 transactions in 2002 [R10-17]

•30% churn of accumulated records [R10-18]

•60 second or less response time for broadcasting updates to all LSPs [R10-19]

70

•Three second or less response time for sending an acknowledgment to user requests [R10-20]

•One CMISE TPS by each SOA to NPAC SMS interface association [R6-24]; however, standards in other jurisdictions call for two CMISE TPS for each association

•25 downloaded numbers per second (equates to approximately 5.2 CMISE TPS) by each NPAC SMS to Local SMS interface association [NYCAC Answer to Bidder Question # Q12].

We carefully analyzed these capacity and performance requirements and developed a preliminary sizing model.  Based on this model, we propose five (5) Stratus Continuum 400 Series Model 428H processors at each NPAC facility (primary and backup/disaster recovery).  Each 428H will have one pair of two-way SMP CPU boards that have 96mhz PA-8000 microprocessors and 1GB memory.  In addition, a total of 40GB hard disk storage will be available to the Stratus 428Hs at each NPAC facility.  To complement this Stratus platform, we also propose a 100-mbps fast ethernet virtual LAN at the NPAC.

Expandability

Our proposed architecture can readily grow to accommodate increased LSPs and expansion of NPAC SMS functionality.  This can easily occur by:

•Adding additional WAN POPs and links

•In-box scaling of the Stratus servers by adding a RAM and hard disk storage

•Adding additional Stratus Continuum Servers, if required

•Expanding the LAN infrastructure — servers, workstations, printers, etc.

•Expanding the PBX — trunks, lines, etc.

Connectivity and Security

Our proposed system architecture offers several secure methods of connecting and accessing the NPAC/SMS.  First, both the mechanized SOA and LOCAL SMS interface to the NPAC/SMS are

71

supported in complete compliance with Section 6 of the RFP by connecting to the New York LATA 132 virtual POP or either of the two facilities-based POPs (Tarrytown or Chicago).

Second, a substantial number of NPAC processes and operations may be performed manually by authorized service provider-based personnel (remote users) via a highly secure, fully authenticated, remote access facility.  At the service provider’s option, remote users may use the same IP-based communications links supporting the mechanized interfaces or use a separate access facility.  The facility may be dedicated (another IP-based link) or dial-up (ISDN or V.34 dialback) using the PPP protocol.  Over IP, remote user workstations use an authorized, secure web browser, e.g., Netscape, using the secure http protocol (https).

Third, and finally, our NPAC/SMS includes a highly robust, cost-effective, and proven firewall architecture that ensures security while enabling authorized Internet access.  This is accomplished by utilizing a perimeter sub-network within the NPAC/SMS LAN comprising two firewall routers and a Unix-based PC-server acting as a dedicated bastion host server that mediates services between the Internet and NPAC/SMS.

Conclusion

Our proposed NPAC SMS architecture is robust, providing high reliability and availability.  We have carefully designed the entire system with redundancy and automatic fail-over to minimize unscheduled downtime as much as possible.  With ample ways to expand, our architecture protects NYCAC’s investment in the NPAC/SMS.

72

1.6.3NPAC SMS Functional Summary

Our NPAC SMS is a highly reliable, highly functional, low maintenance, and low risk design based on existing, tested modular telecommunications software.

The basic function of the NPAC SMS is to facilitate changes of telephone routing information in the local service provider’s networks.  The NPAC SMS receives update notifications from the local service providers 24 hours a day, seven days a week.  Upon validation of the routing information, the NPAC SMS broadcasts the updated routing information to all local service providers.  Once configured, our NPAC SMS automates this basic functionality providing the local service providers with a reliable, transparent update mechanism.

Critical for NYCAC is how our NPAC SMS application supports regionalization.  Release 1 of our NPAC SMS is slated for delivery in March 1997 in Chicago.  Given the industry’s clear need for NPAC SMS regionalization, we have already begun design features within our NPAC SMS to support regionalization, creating a Release 2 of our NPAC SMS that will be delivered for NYCAC by May 15, 1997.  Our proposed NPAC SMS regional functionality includes:

•Filtering of broadcasts to service provider local SMS associations on an NPA-NXX basis.  This allow service providers, for a specific local SMS association, to specify NPA-NXXs for which they would like to receive downloads.  We will completely support this requirement by adding screening tables within the NPAC SMS for linking service providers to NPA-NXXs for downloading purposes.  Hence, using these tables, the NPAC SMS will only send/resend downloads for a given NPA-NXX to the proper service provider local SMS associations.

•Establishment of portability areas (NPA-NXX groupings, such as a LATA or MSA) to validate service provider access and arrangements to port numbers for a given NPA-NXX.

73

•Establishment of state-specific tunable parameters to allow timing and feature functionality to differ/vary by state within a regional NPAC to satisfy potential, if any, regulatory differences.

•Performance of cost reapportionment and billing on a state basis to allow for different cost recovery methods employed or mandated by state regulatory agencies, if applicable.

•Provision of screens and reports on portability area and state basis.

•Provision of administrative utilities, screens, and reports to establish and maintain portability area to NPA-NXX and NPA-NXX to service provider local SMS download association linkages.

In addition, our proposed NPAC SMS system supports all aspects of customer service.  The NPAC SMS customer service functions include the ability to determine the status of all system data and functions, ad hoc report generation, synchronization of routing information, and actions supporting conflict resolution.  Authorized NPAC users have easy access to the data and system capabilities required to support the local service providers.

Support of automated processes requires robust SMS administration and configuration capabilities.  Our NPAC SMS allows authorized NPAC users to easily monitor and manage every aspect of network configuration data, service data, local service provider data, and subscription data via graphical user interfaces.  The design of the graphical user interfaces expedite training and troubleshooting.  Service providers have the ability to view and manage their own service, network, and subscription data using graphical user interfaces similar to NPAC authorized users.

74

Because of the number of local service providers using the NPAC SMS, our design includes extensive event tracking capabilities.  The NPAC SMS timestamps and logs update events and system events.  The system also tracks performance and system utilization metrics.  Our NPAC SMS tracks all events and messages by entity.

Security is an important NPAC SMS design component.  The NPAC SMS controls access to and management of data and system functions with auditable, identification, and authentication mechanisms.  The strong authorization and data encryption security functions serve as the foundation for the users’ ability to administer their data and use the enhanced reporting functions.

Enhanced reporting capabilities allow NPAC users and service providers to access and understand system performance, system utilization, and billing.  The capabilities of the system include reports for all system and update events, system usage, and metrics by local service provider.  The reporting capabilities include generation of bills against resource accounting information.  The NPAC SMS features many predefined reports and supports ad hoc user queries.

ESI BACE Methodology

We are proposing to deliver the NPAC SMS application using ESI’s Basic Application Creation Environment (BACE) methodology.  ESI successfully uses this methodology to develop and implement on-time and on-budget solutions to the telecommunications industry.  These solutions include advanced services provisioning systems with high-volume and high-availability requirements.  The benefits of the BACE methodology include:

•Reduced development and lifecycle costs

•Reduced time to market

75

•Consistent, high quality solutions

•Open system standards compliant

•Solutions are created from readily available software components (building blocks).

Application Layers

Applications built according to the BACE methodology fit into the overall framework summarized in Exhibit 1.6-5.  The layers of this pyramid signify the following aspects of a project’s development:

A. NPAC SMS Application Code

The layer is those parts of the solution that are specific to the NPAC SMS product and are developed in C++.  This code has been specifically developed for our NPAC SMS product and is not reused by any other application.

B. Application Infrastructure

ESI-owned reusable components represent generic solutions to particular aspects of the telephony business, including domain-specific, but not client-specific, functionality. Telephone industry objects can often be shared by multiple applications.  The use of those objects may differ from application to application, or customer to customer.  In most cases, however, it is likely that there is a common foundation for each object that can be shared.  Differences in usage can be provided by differences in implementation or by different subsets of the available functionality.  Examples of such objects include:

•Objects representing the people involved in the application, such as customer objects, customer hierarchy objects, or personnel objects and management hierarchies (for a work flow administration)

•Objects representing hardware or other components in the switching network, such as switches, SCPs, LOCAL SMSs, etc.

76

•Objects representing records or messages, such as usage records, control messages, work orders.

C. Foundation Infrastructure

The foundation infrastructure comprises ESI-owned, low-level, reusable components that are not domain-specific.  These components, referred to as “tools,” support applications across a wide range of projects.  Tools are generic objects that can be used in variety of applications, for a variety of different purposes. The idea of a tool is that it is not specific to one task, but can be reused in many places by simply using a different set of data, a different configuration, etc.  Some examples include:

•A high level language, and associated compiler, run-time environment, etc., for defining customer-unique components behavior

•Tools supporting access to different types of data storage, including relational and object oriented data bases, file systems, shared memory, and so on, in a manner independent of the actual storage modality

•Tools providing common services such as security, object persistence and version control.

D.  COTS Components

The underlying foundation of the NPAC/SMS application software is a suite of proven Commercial Off-the-Shelf (COTS) components.  These components include the ORACLE RDBMS and the Stratus UX Operating system.  Wherever possible, we have selected COTS components to provide NPAC/SMS functionality to reduce NPAC application software development time frames and cost.

Implementation Overview

ESI mitigates the risk of new software development by building software applications in layers.  The foundation layers of the NPAC SMS application will consist of proven, tested commercially available

77

off-the-shelf (COTS) products.  The middle layers include existing telecommunications software components developed, owned, and implemented by ESI.  The upper layer consists of the custom software specifically designed for the NPAC SMS.  This methodology significantly reduces the amount of new, unproved code required to implement the project.  Software development risk and costs are greatly reduced when systems are implemented using a foundation of existing code.

1.6.4NPAC Operations Summary

As the only neutral third-party administrator of a number portability system (SMS/800), Lockheed Martin brings the requisite experience necessary to ensure that the NPAC SMS is an unquestioned success.

Lockheed Martin has more than three years of experience in providing fair, impartial, and evenhanded to service providers as the 800 NASC vendor.  We are intimately familiar with the role of the NPAC and possess the expertise and experience to implement and run the NPAC for NYCAC on a daily basis, offering a wide array of service components as outlined in Exhibit 1.6-6.

Highlights of our service components include:

•Proven NPAC operations approach using SMS/800 number administration expertise as a base

•Goal-oriented, streamlined organization that is staffed with experienced number portability administration and technical experts

•Established performance standards based on real-world operations, ensuring quality services for service providers

•Dedicated NPAC facility in Tarrytown, NY, providing focus and commitment

•Fully redundant backup/disaster recovery data center in Chicago, IL.

78

Based on our 800 NASC and current Illinois NPAC/SMS experience, we propose a streamlined organization, shown in Exhibit 1.6-7, that is designed for efficiency and providing timely, responsive service.  Staffed with experienced number portability administration and NPAC/SMS development personnel to operate the NPAC/SMS, this organization will provide the supporting NPAC services — software technical support, system administration, user support, quality control, and training and documentation support.

Highlights of our NPAC organization include:

•High level attention by a Management Review Committee to ensure rapid resolution of NPAC problems

•An NPAC director, Ms. Audrey Herrel, who is an experienced executive with extensive NASC management and operations experience

•Dedicated Quality Assurance and Control Group responsible for NPAC/SMS software acceptance testing, security, and performance standards establishment and attainment

•More than 30% of NPAC staff are computer and software engineers, who will ensure maximum uptime and reliability of the NPAC/SMS

•Dedicated Training and Documentation Services Group for providing user training and documentation to service provider users.

Guiding the NPAC will be written detailed operations plans as well as rigorous performance standards to ensure that all service providers receive timely, responsive, fair, and evenhanded service.  Currently, we meet or exceed more than 25 separate performance standards as the 800 NASC vendor, and we will bring this same customer-centered focus and drive to NPAC operations.

79

This Page Intentionally Blank

80

NYCAC NPAC/SMS PROPOSAL 1.7 NPAC/SMS Deployment

HIGHLIGHTS

•Regionalized NYCAC NPAC/SMS (released) ready for testing on May 15, 1997 with full live operations support on October 1, 1997

•Tremendous advantages of scale and reuse of common Illinois NPAC/SMS work guarantees on-time NPAC/SMS delivery

•Dedicated and experienced implementation team to ensure a smooth, trouble-free NPAC/SMS deployment

1.7   NPAC/SMS DEPLOYMENT

Realistic and attainable scheduling, detailed planning, technical excellence, and empowered and dedicated personnel ensure that the NPAC/SMS for NYCAC is deployed and operational on schedule.

Lockheed Martin, one of the world’s leading system integrators, has had demonstrated success in deploying and delivering technically and functionally complex systems for a wide array of applications.  Our background, financial strength, project management expertise, and technical knowledge of LNP were major reasons for our selection by the ICC to develop the NPAC/SMS for Chicago.  We will bring our current NPAC/SMS experience to bear on the implementation of an NPAC/SMS for NYCAC, providing tremendous advantages of scale, reducing risk, and ensuring on-time delivery of a fully compliant NPAC/SMS for testing by May 15, 1997.  Our project plan for implementing the NPAC/SMS for NYCAC is guided by the following:

•Strong corporate commitment, including active senior management involvement, to successfully satisfy NYCAC NPAC SMS requirements and objectives

•Placement of project responsibility within the Lockheed Martin company best suited to ensure success

•Careful selection of reliable, experienced, and technically qualified teaming partners and subcontractors with clearly defined project roles and responsibilities

81

•Fully regionalized NPAC SMS (Release 2) application software

•Reuse, refinement, and customization of operational procedures, training materials, and documentation from Illinois to streamline the NPAC/SMS implementation for NYCAC, reducing technical and schedule risk

•Thorough visibility of project progress at all management levels through project controls, reports, design reviews, and technical oversight reviews

•Assignment of qualified, dedicated, full-time NPAC management staff having highly effective management and technical skills as primary points of contact, and delegating to them full authority for project decisions and commitments

•Early identification of program risk areas and the establishment of contingency plans to migrate and address the risk areas to ensure NYCAC NPAC SMS success

•Total coordination and integration of the Lockheed Martin Team.

We have, in our belief and as evidenced by our selection and work in Illinois, assembled a team second to none.  Inherent in this team is the technical experience and know-how necessary to deliver the complex aspects of the NYCAC NPAC SMS.  In addition, our project management approach and its application ensure the successful deployment and operation of the NPAC SMS.

82

1.7.1  Project Workplan and Schedule

We are proposing a detailed and attainable workplan and schedule, which leverages our work in Illinois to the maximum extent possible, offering tremendous advantages to NYCAC and guaranteeing on-time delivery.  Details of the workplan and schedule are located in Section 2.0.2 of our response.

Highlights of our workplan include:

•Planned deployment of Release 2 of our NPAC SMS, which includes regional functionality that exceeds RFP requirements.  We are committed to delivering a NPAC/SMS solution for NYCAC on May 15, 1997 for system testing.

•Provision of NPAC/SMS Release 2 Functional Requirements Specification (FRS) and External Design by January 2, 1997 for review by NYCAC.  We are ready to hit the ground running and begin immediately on customizing our NPAC SMS software to meet NYCAC requirements as soon as possible after award.

•Full support of the NYCAC-recommended testing approach and timeframes.  In fact, because we will have established a standardized, dedicated test bed and infrastructure for testing our NPAC SMS interfaces.  Service providers can begin interoperability testing of their local SMSs and SOAs with our NPAC SMS in mid-December 1996.  In addition, those carrier local SMS and SOA systems that have undergone and successfully passed interoperability testing with our NPAC SMS system in Illinois will not have to redo their testing for New York.  This saves NYCAC member carriers and their selected local SMS and/or SOA vendors a tremendous amount of time and money.

•Full NPAC operational support by October 1, 1997 to live porting of numbers.

83

1.7.2   Experienced Implementation Team

Exhibit 1.7-1 depicts the Lockheed Martin Team proposed to implement and deploy the NYCAC NPAC/SMS.  All key positions have been identified and staffed.  We are committed to delivering a successful NPAC/SMS and fully understand the associated risks and concerns, especially those associated with schedule and quality delivery.  Accordingly, we are front-loading the staff to ensure a smooth project startup.  Highlights of our Implementation Team include:

•Direct senior management oversight of the project to ensure that schedules are met and all problems are rapidly resolved

•An experienced NPAC Director — Audrey Herrel — overseeing and managing all aspects of NPAC operations and deployment

•Proven and experienced system development manager — Richard Carter — overseeing and managing all NPAC SMS Release 2 product development for NYCAC

•Experienced application developer — ESI — designing and implementing the NPAC SMS Release 2

•Fully loaded NPAC System Acceptance Test “Tiger” Team led by the Quality Assurance Manager — John Varley — to thoroughly test the NPAC SMS application and interfaces to service provider systems

•Implementation support from team members DSET, Inc. and Stratus Computer, Inc., in conducting interoperability testing and installing and staging the Stratus computer system.

84

Many of our team members have been active in industry forums, have a firm grasp of the requirements, and possess the technical skills necessary to ensure a smooth and fluid deployment and implementation of the NYCAC NPAC SMS and supporting NPAC operations.

1.7.3   Deployment Summary

From the outset, the Lockheed Martin Team has made a quality, reliable, and trouble-free NPAC SMS implementation and deployment our number one goal.  Collectively, our team possesses the financial, NPAC/SMS experience, and technical resources to carry out and complete the required tasks and to guarantee a successful implementation of the NYCAC NPAC SMS and supporting NPAC operations.

85

NYCAC NPAC/SMS PROPOSAL 1.8 NPAC/SMS Evolution

HIGHLIGHTS

•Committed to supporting ongoing definition and evolution of LNP capabilities to ensure NPAC/SMS support of future LNP enhance-ments

•NPAC SMS Release 2 software supports full regionalization (state and jurisdictional expansion) and location portability

•Architecture is a permanent NPAC/SMS solution, offering unlimited growth in capacity with only incremental growth costs

•Use of database-resident, rules-based, definitions of transaction processing steps enables the enhancement of existing process flows and addition of new flows with minimal effort and cost

1.8   NPAC/SMS EVOLUTION

Our proposed NPAC/SMS is a permanent solution that offers unlimited growth in capacity and functionality with incremental growth costs.

A substantial amount of flexibility, expandability, and extensibility is essential to provide continuous NPAC/SMS services.  A primary design goal of the Lockheed Martin NPAC SMS is to design these attributes into every level of the NPAC SMS system, thus accommodating planned and unplanned future requirements with minimal cost and disruption.

The Lockheed Martin Team is firmly committed to support NYCAC and the industry in future growth and expansion of NPAC/SMS services by: 1) performing enhancements of the NPAC SMS on a timely, cost efficient, and non-disruptive basis, and 2) expanding the NPAC infrastructure — facilities and staff — as well.  To accommodate both planned and unplanned increases in system growth due to functional and/or geographic jurisdiction expansion, it is essential that the NPAC SMS be extremely scalable.  The Lockheed Martin NPAC SMS achieves this, providing for processing capacity expansion in three dimensions:

1.NPAC SMS server expansion.  Our proposed Stratus Continuum fault tolerant platform may be smoothly scaled up to two logical RISC SMP CPUs, 2GB of duplex RAM, 178 GB of duplex disk, and 84 I/O adapters, allowing up to 1,344 direct connect communications lines.  Upgrading the

86

NPAC SMS may be performed on-line while the system is live, thus ensuring no disruption to operations due to unanticipated system upgrades.

Exhibit 1.8-1 illustrates the performance increases of new planned processor technologies being developed by HP (PA-RISC) and HP/Intel (Merced).  Availability of new processor technologies from the two strongest technology companies, with continuing performance enhancements and binary software compatibility, ensures longevity of NPAC/SMS facilities and continued scalability

Exhibit 1.8-1.  Explosive growth in future processor technology guarantees server scalability.

[Graphic Omitted:  Chart depicting increasing processor performance]

through the future of LNP deployment.  The HP (PA-RISC) technology will be used by the Stratus Continuum I family and the HP/Intel (Merced) technology will be used by the Stratus Continuum II family.

Exhibit 1.8-2 illustrates the performance growth curve for Stratus systems based on the Stratus Continuum I (HP PA-RISC) and Continuum II (HP/Intel Merced) technologies.  This growth curve does not include performance enhancements due to additional distribution or clustering technologies (such as load sharing, parallel database servers, and shared-efficient message queuing) that will increase the effective performance of multi-system configurations.

Exhibit 1.8-2.  Performance roadmap for future Continuum I and II systems

[Graphic Omitted:  System performance roadmap chart]

2.NPAC SMS software distribution.  The NPAC SMS software processes are configured to operate in a distributed fashion across multiple servers, as illustrated in Exhibit 1.8-3.  The system configuration dictated by the capacity requirements in R10-15 and R10-17 calls for five (5) Stratus Continuum Model 428H systems operating cooperatively in a distributed fashion.  There are several

87

functional boundaries across which software distribution may be performed — front-end communications processing, database storage, rules-based process execution out to one or more additional servers — depending upon the nature of the NPAC/SMS system growth and the need for increased system bandwidth.  This advanced architecture enables unprecedented flexibility and cost savings in future system growth, while retaining complete use and re-deployment of existing software and hardware.

Exhibit 1.8-3.  NPAC SMS Scalability Through Software Distribution

[Graphic Omitted:  Chart depicting system scalability]

3.NPAC network expansion.  The NPAC network design is capable of significant functional, load, and geographic expansion while incrementally building on the existing infrastructure.  Use of cell-based fast hub (ATM-supportable) switching technologies ensures no upper limit on NPAC network capabilities and LAN/WAN technologies to support — in a highly cost effective yet fully available manner — expansion in POPs, data centers, NPAC personnel, service providers, and NPAC SMS servers.  Exhibit 1.8-4 illustrates the potential to expand NPAC/SMS services through the addition of NPAC/SMS service centers networked to accommodate the future increased capacity (e.g., location portability and number pooling) and functional requirements (trans-regional data interchange).

Exhibit 1.8-4.   NPAC SMS Scalability Through NPAC Network Expansion

[Graphic Omitted:  Map showing network expansion locations]

88

To accommodate future changes in NPAC SMS functionality with minimal/or no re-engineering impact to existing functionality, it is necessary to build flexibility into the software design and implementation.  We are achieving this flexibility goal by employing the following strategy:

•CMIP-mechanized interface processing using automated CMIP agent interface development tools, e.g., DSET GDMO compiler and agent toolkit.  Changes in the mechanized interface information model can be accommodated by re-compiling the revised GDMO information model definition of the interfaces, and revising the process flows rules set accordingly.

•Object-oriented design methodologies and language (C++).

•Use of ESI’s BACE product for flexible rules-based process implementation.  SMS process flows are executed by rules-based processing engines, where process steps may be readily changed or re-sequenced by modifying database-resident rules.  Lower-level processing steps are coded in C++ in the form of operations against object instances.

•Distributed protocol stack processing for SMP-scalability.  The Stratus UX operating system supports a redundant network interface (RNI) feature that enables multiple LAN (fast-ethernet) ports to operate as a single logical entity at the IP level of the protocol stack.  Further, the Unix streams-based implementation of the IP stack supports high levels of parallelism (and therefore scalability) in addition to that achieved by RNI.  Also, the upper layers of the OSI stack (for ROSE, ACSE, and CMISE layers) are implemented within DSET’s Distributed Systems Generator (DSG) product, which employs a multi-task, multi-process execution model for further parallelism.

89

•Web-browser oriented generic GUI with Java provides a standard, secure, robust, and highly extensible GUI environment for all user support across arbitrary access and network methods and a wide variety of client workstation environments.  Screens and menus are ‘published’ using HTML editors and stored independently of any software.  Object embedding technology enables ease of extensibility with minimal impact to existing software.

•Use of Oracle for the RDBMS engine provides a highly extensible and robust DBMS environment with proven advanced replication and distribution capabilities.  It also helps to ensure scalability of back-end database server functions.  If future functionality and capacity needs should dictate, the database could be transparently distributed across more than one server using the Oracle Distributed Processing module.  Also, the Oracle Parallel Query module can be used to optimize queries, reports, audits, etc., in a distributed database implementation.  Consequently, even the back-end RDBMS engine provides cost effective functionality for initial requirements while enabling incremental enhancement to support future requirements without application software impacts.

1.8.1Expansion of Service Providers

Expansion of the number of service providers is readily supported by NPAC/SMS with only incremental capacity and network communications upgrades required.

1.8.2Expansion to Other States (Regionalization)

Expansion of NPAC/SMS to other states is readily supported via capacity and service provider interface expansion, as well as functional extensibility (for regulatory state-specific process flow variations) and load firewalling.  We are proposing an NPAC SMS system and NPAC operations that are fully

90

expandable and scalable (additional NPAC office space, staff, Stratus server hardware, communications infrastructure, etc.) to handle higher transaction volumes and additional service providers and jurisdictions.

In addition, our NPAC SMS Release 2 supports full regionalization.  Our NPAC SMS will filter broadcasts to service provider LSMS associations on an NPA-NXX basis.  This allows service providers, for a specific LSMS association, to specify the NPA-NXXs for which they would like to receive downloads.  We will completely support this requirement by adding screening tables within the NPAC SMS for linking service providers to NPA-NXXs for downloading purposes.  Using these tables, the NPAC SMS will only send/resend downloads for a given NPA-NXX to the proper service provider LSMS associations.

Additionally, through our participation in LNP activities throughout the country, we will also offer the following enhancements to support regional NPAC services as a part of our base NPAC SMS Release 2 product that will be initially used for NYCAC:

•Establishment of portability areas (NPA-NXX groupings, such as a LATA or MSA) to validate service provider access and arrangements to port numbers for a given NPA-NXX

•Establishment of state-specific tunable parameters to allow timing and, if desired,  feature functionality to differ/vary by state, within a regional NPAC to satisfy potential regulatory differences

•Performance of cost reapportionment and billing on a state basis to allow for different cost recovery methods employed or mandated by state regulatory agencies, if applicable

•Provision of screens and reports on portability area and state basis

91

•Provision of administrative utilities, screens, and reports to establish and maintain portability area to NPA-NXX and NPA-NXX to service provider local SMS download association linkages

•Inter-active voice response system (IVR) for 7x24 automated telephone access to service provider associations for ported numbers.

1.8.3   Geographic Number Portability

The NPAC/SMS design will support multiple forms for number portability beyond the initial rate center-coincident service provider number portability (SPNP) specified for the initial release.  NPAC SMS functionality and IIS support both SPNP and location portability (intra-provider portability), which is presumed to be intra-rate center location portability.  Within the definition of SPNP functionality for the NPAC SMS is full life-cycle support for ported numbers, including: initial port, additional ports, port back to original switch, and disconnect.  Additional types or variations of LNP that can be supported in the future include:

•Non-coincident rate center SPNP.  When competing LSPs are no longer required to use rate centers coincident with each other or historical rating boundaries, additional parameters may be required in the NPAC/SMS database to allow service providers to support switch or SCP-based call recording of these additional parameters.  While NYCAC clearly anticipates these additional fields, the exact format and treatment of these parameters is not required until implementation of this functionality in the network is specified.  The eventual participation in LNP of service providers using non-wireline network technologies, such as wireless and cable-telco for example, will increase the need to revisit existing rate center concepts.

•Inter-rate center, intra-LATA, location portability.  Similar to the above without changing service providers.

92

•Inter-LATA, intra-NPAC administrator, location portability.  Location portability outside of the LATA but within the jurisdiction of a common NPAC administrator might require only minor additional call recording parameters to be provided, if any, from the general case of rate-center portability within the LATA.

•Inter-NPAC location portability.  Location portability, with or without an accompanying change in service provider where the new serving location is administered under the jurisdiction of another NPAC SMS or NPAC administrator, requires inter-NPAC coordination.  We anticipate that an additional CMIP-based mechanized interface to support NPAC-to-NPAC operations will be developed and standardized.  The choice of CMIP for mechanized interface technology will enable upward expandability within the framework of the initial NPAC/SMS deployed.  Given the criticality of building on appropriate technologies for both the short and long-term, one member of the Lockheed Martin team was the first to propose — at INC 14 in March 1995 — that CMIP-based TMN signaling technology be standardized for use in mechanized interfaces for LNP administration, both between service providers and their NPAC and among NPACs serving different jurisdictions.(1)  The new NPAC-to-NPAC interface will be modeled primarily on the SOA-to-NPAC SMS interface with extensions.  The addition of inter-NPAC functionality between two NPACs does not necessarily impact their service providers, since the inter-NPAC operations are transparent to the involved service providers.

(1)INC contribution PORT-59 by Stratus Computer, Inc.

93

1.8.4   Service Portability

From an NPAC perspective, the various forms of service portability as they affect serving switch location and rate-center boundaries are addressed in one of the above types of location portability.  However, the processing for a change in serving switch location, where the customer’s service location is the same, does not necessarily imply the same impacts, e.g., rating, that result from the customer physically changing geographic locations.

1.8.5   Wireline-Wireless and Wireless-Wireless SPNP

Wireless service providers of all types, including those affiliated with currently participating wireline service providers, have a keen interest in participating in LNP.  Their network and switch technology, billing and rating, regulatory governance, and nature of services offered, e.g., terminal and subscriber mobility, add significant complexity to implementing LNP.  The ultimate solution to implementing LNP with and between wireless service providers is likely to require enhancements to the mechanized interface information model and database, which can be readily supported.

Many of the above forms of portability have implications for service provider billing and settlement systems requiring enhancements to support the rating, billing, and inter-company settlement flows resulting from de-coupling the customer’s TN from its historical rate center and RAO.  The NPAC may be called upon to provide database information to service providers and other involved parties to enable their billing and settlement systems to properly bill and rate calls and route billing messages.

94

1.8.6  Overlays of NPA-NXXs

Overlays can readily be supported by the NPAC/SMS through a minor enhancement to provide the overlay information, if any, associated with a subscription to the NPAC SMS via the SOA interface.  This information would also be included in the routing update broadcast to the LSMS interfaces so that SCPs could create any appropriate additional routing records required.  Impacts due to newly created overlays affecting existing subscriptions would be processed as mass changes.

1.8.7   Expansion for Use by Wireless Service Providers

Expansion to wireless service providers and the additional database fields potentially required can be accommodated by the NPAC/SMS.  Wireless service provider participation may require additional database fields and associated mechanized interface attributes, especially to support wireless-to-wireless SPNP.  These can be supported as minor functional enhancements, in addition to any required incremental capacity upgrades.  Additional routing attributes that may be required for wireless service providers includes: DPC and SSN for IS-41 messaging, and a non-dialable 10-15 digit MSID.  With the planned participation in LNP by wireless providers, any additional attributes that may need to be supported within the NPAC SMS can readily be provided through a minor enhancement to the IIS and database schema tables.

1.8.8   Expansion to Include Data Related to Resellers

The NPAC/SMS can be expanded to support both resale and direct resellers as a new class of directly or indirectly connected service providers, where appropriate. We recognize the importance of resale in enabling new LSPs to offer ubiquitous service coverage without massively over-building their network infrastructure and to support resellers of their network services.  The NYCAC has anticipated this need

95

by including a Billing ID field in the subscription data, defined in Section 2.3.  The service provider data tables and initial processing logic developed by the Lockheed Martin Team further anticipate requirements for identifying resellers and independently tracking the facilities-based service provider from the billing service provider (non-facilities based service provider, i.e., reseller).  Additionally, rules for authorizing get/modify/create/delete privileges for both facilities and non-facilities based service providers will need to be developed and agreed to by the service providers to specify the required functionality.  Minor enhancements to the SOA interface could be considered to distinguish transactions where the SOA is the facilities — or non-facilities-based service provider and to support the appropriate semantics for operations and notifications across both types of service providers.  These enhancements would enable authorized resellers to directly interface to the NPAC, and permit facilities-based service providers to offer indirect access to the NPAC on their reseller’s behalf.

1.8.9  Pooled NXXs

Although the topic of pooled NXXs or “number pooling” is not specifically identified as an potential future consideration in the NYCAC NPAC/SMS RFP, is has been identified as such in other states’ activities and NPAC/SMS RFPs, as well as being of great interest to the FCC.  Thus, we thought it appropriate to discuss it as a possible area of evolution for the NYCAC NPAC/SMS.  Number pooling aids number resource conservation by potentially improving fill rates of portable NXXs through shared use and allocation of numbers among all service providers in an area.  Number pooling requires the same call processing functionality as inter-rate center location portability, since number pooling within a rate center does not provide for additional number resources (borrowed from across the service area) within high demand areas.

Number pooling requires significant functional and capacity enhancements to the NPAC/SMS, which can be accommodated within the NPAC/SMS architecture through incremental NPAC SMS upgrades,

96

enhanced mechanized interface specifications (to support number administration operations), and supporting software enhancements.  The NPAC SMS database size will increase significantly since subscription records will be created for newly allocated numbers out of pooled NXXs for new non-LNP related service requests, in addition to the subscription storage for actual ported numbers.

Transaction loads will likely increase even more so than the database size, due primarily to the added volumes of transactions required to perform the lifecycle state transitions of pooled numbers, such as vacant number search, allocation, assignment, activation, and disconnect.  Operationally, NPAC will be involved in the administration of the 10-digit numbers in the designated portable NXXs that are to be pooled.  Consequently, the capacity growth, functional extensibility, and direct operating experience in number administration offered by the Lockheed Martin NPAC/SMS are unique values in safeguarding the initial investment in the NPAC and ensuring a smooth, reduced cost transition to new LNP capabilities in the future.

97

NYCAC NPAC/SMS PROPOSAL 1.9 Compliance Summary

HIGHLIGHTS

•100 percent compliance with RFP requirements

•No exceptions or deviations to RFP requirements

•Technical alternatives to improve NYCAC NPAC/SMS operations and reduce cost

1.9COMPLIANCE SUMMARY (RFP Sect. 1.4.3.1)

The Lockheed Martin Team’s NYCAC NPAC/SMS solution meets or exceeds all RFP requirements, without exception.

To aid the NYCAC Evaluation/Procurement Team in reviewing our proposal, we prepared and placed a Requirements Matrix in a separately tabbed section at the beginning of the proposal.  The matrix lists all requirements of the RFP and identifies the proposal paragraph of our corresponding response.

In addition, to assist the Evaluation/Procurement Team in the evaluation of our proposal, we have placed requirement numbers in brackets at the end of sentences/paragraphs throughout our proposal — example: [R9-99] — to indicate exactly where our NPAC/SMS solution satisfies the corresponding “R labeled” requirements.

We take no exceptions to the RFP, and have prepared a fully compliant solution.  We have, however, proposed for the Evaluation/Procurement Team’s consideration a number of alternatives/options designed to improve NPAC/SMS operations or reduce cost without sacrificing performance, reliability, or security.  Our proposed alternatives are summarized in Section 2.1.5.3 and detailed in the relevant sections throughout our response.

98

This Page Intentionally Blank

99

NYCAC NPAC/SMS PROPOSAL 2.0 Functional and Technical Requirements

HIGHLIGHTS

•Our NPAC SMS is in complete compliance with all functional and technical requirements

•Minimal schedule risk through leverage of common Illinois NPAC/SMS work guarantees on-time delivery

•Preliminary implementation plan-ning ensures an on-time NPAC SMS delivery and operations

•Qualified and experienced staff ensures reliable and quality NPAC operations

•Risk management with reduction planning addresses areas of high risk and responsiveness

2.0FUNCTIONAL AND TECHNICAL REQUIREMENTS (RFP Sect. 1.4.3.2)

Our proposed NPAC SMS and supporting NPAC operations meets and exceeds all RFP requirements.

Delivery and deployment of a complex, mission critical system, such as the NPAC SMS, requires more than simply understanding the RFP requirements.  In addition, and far more important, the selected contractor must have a firm grasp and understanding of the planning and management practices required to accomplish the work on-time and within budgetary allocations. Even then, to ensure success of the project, a sound management approach, detailed implementation planning, and experienced staff are of critical importance.

The Lockheed Martin Team — Lockheed Martin IMS, Evolving Systems, Inc. (ESI), DSET Corporation, and Stratus Computers, Inc. — are prepared through experience and commitment to meet and exceed the requirements and objectives of the NYCAC in their implementation of Local Number Portability in the State of New York and, when desired, throughout the surrounding region.  The remainder of this section demonstrates our understanding of the management practices required and outlines our management approach, including the following vital areas:

•Project Management Approach and Staffing (Section 2.0.1)

100

•Implementation Approach and Staffing (Section 2.0.2)

•Project Controls (Section 2.0.3).

2.0.1PROJECT MANAGEMENT APPROACH AND STAFFING

Lockheed Martin’s mission and philosophy are to attract and retain customers by providing high quality, reliable, responsive, and cost effective services.  To achieve this level of service — the company’s highest priority — we apply whatever resources are needed to meet and, where possible, exceed established performance standards.  Five characteristics of our management philosophy are especially appropriate to meet NYCAC’s needs.  These are:

•Experienced, Motivated Staff —For all of our projects, we assemble the “best team” to accomplish the work, relying heavily on people who are recognized experts in their fields (“Subject Matter Experts”).  We search hard for the right mix of talent and experience and, whenever possible, draw from the entire Lockheed Martin Corporation to ensure unparalleled service to our clients.  Our company culture includes active commitment to the well-being of our employees.  We encourage optimal performance by facilitating communication between and among all levels of the company.  Our personnel are encouraged to seek continuous education through provision of company tuition support.  We also use incentive programs to reward superior performance by managers and supervisors.  The results of these programs are high morale, good performance, general personal well-being, and an exceptionally low rate of turnover of personnel.  This translates directly into stable, high quality, and responsive operation on all projects throughout the company.

•Subcontractor Management — In addition to selecting the right people inside Lockheed Martin to provide the “best team,” we also seek to augment our expertise with qualified, reliable,

101

subcontractors who are the best in their fields.  For the NPAC/SMS, we have selected three subcontractors—Evolving Systems Incorporated (ESI), DSET, and Stratus—as integral members of our team.  Each is an unquestioned leader in their field of specialty.  The specific tasks performed by these team members are listed in Exhibit 2.0-1.  In addition, we have chosen three of the industry’s leading consultants — Mark Foster, Lisa Marie Maxson, and John Shea — as members of the team.  Their expertise and constant involvement in the implementation of the Illinois NPAC/SMS and attendance in New York and other states’ Steering Committee Meetings have been instrumental in shaping our NPAC/SMS offering for NYCAC.

As a leading systems integrator and provider of complex, mission-critical systems, we understand that managing team members, subcontractors, and vendors is essential to ensure on-time project delivery and deployment.  Accordingly, we employ sound project management principles to oversee and monitor all subcontractor operations, starting with a firm subcontract that details all required deliverables, milestones, and activities.  In addition, we consider subcontractors to be team members and subject them to all internal project controls.

Lockheed Martin has a heritage of successfully employing and managing subcontractors.  We will apply this expertise on the NYCAC NPAC/SMS program throughout the life of the project.

•Quality Control and Continuous Improvement — Our commitment to quality and continuous improvement, which has been nationally recognized, ensures the successful implementation,

102

deployment, and operation of the NPAC/SMS.  We emphasize quality and continuous improvement in all of our operations. Beyond the traditional approach of simply monitoring compliance with specifications, we believe that quality assurance improves all stages of product and service delivery and, therefore, permeate it throughout all areas of our company.

A corporate-wide Continuous Quality Improvement program was initiated in 1989, including guidelines and training for continuous improvement.  The goal behind this program was and is to ensure that work is performed properly the first time, thereby reducing the overhead and cost of downstream rework caused by inability to pass quality inspections.  The results of this program have been outstanding.  Lockheed Martin has received national recognition in quality service, including receiving NASA’s prestigious Excellence Award for Quality and Productivity, the Air Force’s Blue Ribbon Contractor Award, and the Malcom Baldridge Award for quality.

We will bring the same vigor and our pursuit of quality to the implementation and operation of the NPAC SMS for New York.

Risk Management –Lockheed Martin’s risk management approach is disciplined, consistent, and iterative.  We anticipate potential risks and take preventive action (eliminating or mitigating the risk) to ensure no significant project impact.  Once a risk is identified and a risk reduction plan is in place, progress is monitored in all management review activities.  Exhibit 2.0-2depicts our risk management process, which we propose to apply to the NPAC/SMS project.  This constant reassessment of risk throughout the life of the project will ensure that Lockheed Martin’s NPAC Director has the information needed to provide timely decisions on risk reduction actions.

103

As required, we analyzed the major design aspects of the NPAC SMS to determine areas that: 1) possess a high degree of risk, 2) require a high degree of responsiveness, and 3) are potentially deficient and require improvement.  Our analysis is provided in Section 2.1.5 below.

•Business Conduct — We conduct all business in an open, ethical, and evenhanded manner, respecting the needs of all stakeholders. We maintain this high ethical standard for both business and interpersonal relations.  All business is conducted in an open and professional manner.  Every employee receives a copy of “Setting the Standard — Code of Ethics” when they join the company and two hours of ethics training annually.  Many of our contracts require regular operational and financial audits.  In addition, we are audited by Arthur Young & Company and by internal corporate auditors.

2.0.2IMPLEMENTATION APPROACH AND STAFFING

A comprehensive plan guides our overall NPAC SMS implementation, ensuring that the NPAC SMS will be fully operational on schedule.

Our implementation of the NPAC/SMS will be guided by a thorough, comprehensive, and detailed plan.  Tasks are defined and resourced to address every aspect of the implementation, including NPAC/SMS system deployment, facilities, personnel, training, and implementation management.  The success of our proposed implementation is fully dependent on a thoughtful strategy, experienced personnel, cooperation and participation of “stakeholders,” and resources and management expertise.  The Team’s experience derived from implementing several large telecommunications systems, including the Illinois NPAC/SMS and local SMSs, and in performing comparable operations (800 NASC), will be of great value to ensuring a smooth NPAC/SMS startup and trouble-free operations.

104

Our implementation approach is founded on several key ingredients, including:

•A step-by-step project plan that is our “road map” for implementation.  We employ automated project management tools for planning and monitoring progress, and have established procedures for “mid-course” corrections to the plan, as required.

•Implementation teams staffed with experienced, qualified personnel who have implemented complex systems and possess a broad range of technical, operations, and telecommunications skills.

•Specific project responsibilities for each member of the Lockheed Martin Team under the auspices of the NYCAC.

•In-depth training in NPAC operations provided to all staff members, instilling customer service and service quality orientation throughout the organization.

These ingredients, combined with the tremendous advantages of our work on the Illinois NPAC/SMS plus our unwavering commitment to the NYCAC project, ensure the on-time delivery of the NPAC/SMS for NYCAC.

105

2.0.2.1Preliminary NPAC SMS Implementation Plan

We are providing a Preliminary NPAC SMS Implementation Plan for NYCAC’s review.  This plan: 1) outlines the major project activities that must be performed; 2) outlines the corresponding projected timeframes for each activity; and 3) is based on our experience with the activities performed and planned for the Illinois NPAC/SMS, providing a realistic and attainable schedule that is success oriented.  Shortly after contract award, this plan will be updated, refined, and used to guide the Team’s implementation and deployment of the NPAC SMS and supporting NPAC operations.

We are committed to delivering the NPAC SMS for live production system-to-system testing on May 15, 1997 and for full-scale NPAC/SMS deployment (live operations) on October 1, 1997.  We are also committed to meeting the schedule for all agreed-upon deliverables, including NPAC SMS design documents, test plans, and methods and procedures manuals.  To meet this commitment, the NYCAC must also be actively involved, receiving, reviewing, and approving all agreed-upon deliverables in a timely fashion after submittal.

Our Preliminary NPAC SMS Implementation Plan, shown in Exhibit 2.0-3 addresses 10 major areas of activity, including:

•Proposal Submission and Contracts

•Project Planning

•Staffing

•Facility Preparation

•Communications

•Administrative Systems

106

•Operations Procedures

•Service Provider and NPAC Training

•NPAC SMS Release 2 Deployment for NYCAC

•Testing.

Upon completion of testing, the NPAC/SMS will be fully operational.  A discussion of each of the major activities is presented below.

2.0.2.1.1   Proposal Submission and Contracts

NPAC SMS implementation activities will commence upon notice of award.  We anticipate agreement on the following contractual areas in the NYCAC Master Contract and Service Agreements:

•Implementation activities, milestones, and deliverables

•Timeframes for approving agreed-upon milestones and deliverables

•NPAC SMS and service performance levels

•NPAC SMS and NPAC service acceptance requirements

•Confidentiality and security procedures

•Limitations of liability

•Insurance and indemnity

•Payment terms and conditions.

Upon notice of selection, scheduled for December 18, 1996, our implementation team will initiate implementation planning and staffing activities, and begin NPAC facilities management activities.  In order to establish an NPAC operation, Lockheed Martin will have to spend considerable resources (time

107

and money) while the Master Contract and Service Agreements are being negotiated and finalized.  To facilitate the expenditure of capital and resources, we are asking the NYCAC to issue a Letter of Intent (LOI) that states that NYCAC has selected Lockheed Martin and plans on entering into good faith contractual negotiations.

Also, during this phase of the project, we will provide the NYCAC with a Functional Requirements Specification (FRS) and External Design of the NPAC SMS for NYCAC approval.  We anticipate that these documents will be included, by reference, as a part of the Master Contract and Service Agreements.  The FRS defines the functionality of the NPAC SMS, including requirements for Regional Expansion, and the External Design provides the formats of NPAC SMS screens, reports, and error messages.  For Illinois, the Lockheed Martin Team and the Illinois Workshop Carriers (Ameritech, AT&T, GTE, MFS Communications, MCI Metro, Sprint, and TCG) spent approximately four months on developing these documents, excluding regionalization.  Because the technical requirements of the Illinois NPAC SMS are nearly identical, excluding regionalization, to the requirements for the NYCAC NPAC/SMS, the Lockheed Martin Team and the NYCAC can hit-the-ground running, quickly verifying the base NPAC SMS system design and fine-tuning the technical requirements needed.  We envision that Master Contract and Service Agreement negotiations will conclude on the February 13, 1997 target date.

2.0.2.1.2   Project Planning

The NPAC director is responsible for coordinating the personnel and resources necessary to ensure a successful and timely implementation.  In conjunction with NYCAC, we will clarify responsibilities,

108

develop a technical implementation strategy and plan, and coordinate implementation activities. We also will refine our preliminary implementation plan to form a final detailed implementation plan that all parties agree to.  In addition, several other plans will be developed as indicated in Exhibit 2.0-3, including a detailed staffing plan, facility plan, equipment plan, software development plan, etc., which are all designed to ensure on-time delivery and operation of the NPAC SMS.

2.0.2.1.3   Staffing

The primary objective of the staffing activity is to provide a well-trained and operationally-effective staff that is capable of performing ongoing NPAC operations. The staffing activity must also mobilize the implementation team.  The NPAC director and the Management Review Committee are responsible for all project staffing activities, including assuring that all staff positions are filled and that the specific needs of NPAC SMS implementation and ongoing NPAC operations are met.  We will provide highly qualified staff for all positions, ensuring that our team is able to meet and, in most cases, exceed the requirements for skills, competence, and experience.  In addition to technical skills, we are selecting individuals with “customer first” attitudes.

2.0.2.1.4   Facility Preparation

We plan to utilize our existing Tarrytown Data Center in Tarrytown, New York to serve as the primary NPAC location.  Within this facility, the primary NPAC SMS system will reside in a data center area, with controlled access, raised flooring, chillers, and an Uninterruptible Power Source (UPS). The tasks required to prepare and equip both sites for NPAC SMS operations will be defined in our Facility Plan.  The Plan will detail how the Lockheed Martin Team will:

109

•Finalize the NPAC office layout

•Define the site preparation and leasehold improvements required

•Bid and contract for leasehold improvements

•Prepare both Tarrytown and Chicago sites

•Order furnishings and fixtures

•Receive and install office furnishings and fixtures

•Acquire all computing equipment (Stratus servers, LAN servers, workstations, printers, etc.)

•Acquire office equipment and supplies

•Acquire and install the security system

•Arrange for off-site document storage

•Acquire and install site voice communications facilities.

Lockheed Martin has extensive experience in establishing new office operations comparable to the NPAC, including the current establishment of an NPAC facility in downtown Chicago for the Illinois LNP LLC and starting up the SMS/800 NASC approximately 40 months ago.

110

2.0.2.1.5   Communications

Our Network, Engineering, and Infrastructure Group will perform all network related tasks, including:

•Installing all WAN and LAN components — routers, hubs, interface ports, etc.

•Procuring and overseeing installation of all telco circuits (T1 & PRI)

•Overseeing installation and testing of PBX and phone system

•Testing all circuits

•Testing the entire communications infrastructure

•Installing and testing all network management software.

2.0.2.1.6   Administrative Systems

During implementation, we will acquire and implement the PC LAN-based NPAC SMS administrative systems, including systems for Problem Tracking and Resolution (LINCSS), Order Entry Inventory, and third party COTS software for word processing, spreadsheets, presentations, accounting, etc.  We will also acquire a toll-free (800/888) number for user access to the NPAC.

2.0.2.1.7   Operations Procedures

Another area of tremendous reuse is in the area of operating procedures.  We understand the industry’s goal of trying to create consistent NPAC services nationwide.  In addition to the development and standardization of Interoperable Interface Specifications, the standardization of operating procedures and performance criteria is another logical choice.  We currently are in the process of refining our SMS/800 NASC procedures for use by the Illinois NPAC and likewise plan to leverage our Illinois NPAC procedures for NYCAC NPAC operations.  These Lockheed Martin-developed procedures will form a

111

firm foundation for implementing and operating the NYCAC NPAC SMS.  Potential areas of customization will be reviewed, verified, and incorporated into our NPAC SMS operating procedures, where appropriate.  We will also incorporate the operating procedures for the PC LAN environment and administrative systems into the overall NPAC SMS operating procedures.  In addition, our NPAC director and quality assurance and control manager will incorporate performance standards and security procedures and controls into NPAC SMS operating procedures.

2.0.2.1.8   Service Provider and NPAC Training

We consider an effective training program to be an essential component of our implementation plan.  Initial training activities will include:

•Developing end-user and NPAC staff training materials

•Developing a staff training plan specific to the NPAC SMS

•Scheduling NPAC SMS management and supervisory personnel to attend training classes

•Training service provider users during turn-up and software acceptance testing.

2.0.2.1.9   NPAC SMS Release 2 Deployment for NYCAC

Under the direction of the NPAC SMS product development manager and supporting Lockheed Martin system engineers, ESI will tailor the our NPAC SMS software to meet NYCAC-specific requirements and enhance it for NPAC SMS regionalization.  Through our attendance in New York and other states’ LNP meetings, we understand that, in the final analysis, “Regionalization” of the NPAC SMS could be more than just filtering broadcasts/downloads to the local SMSs on an NPA-NXX basis.  There is a strong possibility that:

112

•Reporting on a state-by-state basis for regulatory oversight may have to be provided

•Different cost recovery mechanisms on a state-by-state basis may have to be supported

•Validation of service providers may have to be done on a portability-area basis ( i.e., LATA or MSA).

As previously mentioned, we are already addressing these functions, the filtering of downloads on NPA-NXXs, and the other functions needed to support regional NPAC services in our current NPAC SMS Release 2 system design.

Because: 1) the technical requirements of the initial Illinois NPAC/SMS and the NYCAC NPAC SMS are nearly identical, except for regionalization, and 2) the Lockheed Martin Team will have an NPAC SMS system design already in place and approved in Illinois by contract award, the NYCAC and the Lockheed Martin Team can concentrate on verifying the NPAC SMS functional requirements and NPAC SMS system design, including the those requirements needed for regional expansion.  We will not be confronted with the time-and resource-consuming task of completely developing functional requirements and a system design from scratch.

Thus, rather than having to perform a complete, ground-zero, NPAC SMS software development effort, the Lockheed Martin Team will employ a streamlined software development approach to deploy the NPAC SMS for the NYCAC.  This approach includes the following phases:

•Functional Requirements Verification. Using the RFP, our Illinois NPAC SMS Functional Requirements Specification the NPAC SMS Generic Functional Requirements Specification (G-FRS), and our Release 2 Functional Requirements as a base, NPAC SMS functionality for the

113

NYCAC will be further defined and verified during contract negotiations, yielding a revised Functional Requirements Specification (FRS) for NYCAC approval.  The revised FRS could be a “delta” document from the base FRS if allowed by NYCAC.  Also, a Requirements Traceability Matrix will be developed.

•High-level Design. Using the NYCAC NPAC SMS FRS, we will revise our existing NPAC SMS External Design (ED), which includes NPAC SMS screen and report formats as well as error messages, to meet NYCAC NPAC SMS requirements during the contract negotiation period, thereby creating a revised External Design (ED) for NYCAC.

•Detailed System Design. During this phase, we will revise our existing internal NPAC SMS system design to accommodate NYCAC-specific functional requirements as well as regionalization.

•Code and Unit Test.  During this phase, individual developers will develop, code, and unit test their individual code modules to implement NYCAC-specific NPAC SMS functionality, if any.

2.0.2.1.10   Testing

We view testing as the most critical phase of the deployment cycle.  Also, this is another area where NYCAC receives tremendous benefits from our selection as the NPAC SMS developer for Illinois.  We do not have to develop test plans from scratch; instead, we will just revise our existing plans to test NYCAC-specific changes, if any, to NPAC SMS functionality.  In addition, as explained below, NYCAC member carriers that have already tested the interoperability of their SOA and Local SMS systems with our Illinois NPAC SMS will not have to re-perform these tests with our NYCAC NPAC SMS.  Thus, a significant amount of testing is reusable, and the internal costs born by the carriers to test their systems

114

with the regional NPAC SMS is reduced by selecting Lockheed Martin.  We will perform and support the following testing activities:

•Test Plan Development — During this phase, NPAC SMS Integration, Interoperability (Application Level only), and System Acceptance test plans are revised to test the NYCAC-specific changes, if any, to our NPAC SMS product.

•Integration Testing — According to test scenarios detailed in the Integration/System Test Plan, unit modules of the NPAC SMS software are tested together at the subsystem/total system level.

•Mechanized Interface Interoperability/Certification Testing — Interoperability testing is a critical step in testing carrier SOA and local SMS systems with the NPAC SMS, validating the interoperability of their applications and their stacks.  Interoperability testing has three levels:

•Stack-to-Stack

•Object-to-Object

•Application-to-Application.

In a lab environment, each carrier or its vendor will have to test their SOA and local SMS systems with the NPAC SMS test system, verifying all levels of the CMISE NPAC SMS interfaces in accordance with the standard Interoperable Interface Specification (IIS), which Lockheed Martin developed for the industry and placed in the public domain.  After successfully completing interoperability testing, and thus certifying their system with the NPAC SMS, carriers can then begin turn-up testing.  Those

115

LSMS or SOA systems having passing interoperability testing for Illinois will not need to be retested for New York.

•LM Internal System Acceptance Testing — Acceptance testing is key to the successful implementation of the NPAC SMS. The NPAC SMS software acceptance testing is founded on specific test scenarios with predictive results and regression test scripts.  Additionally during this phase, all NPAC SMS network facilities and NPAC SMS disaster recovery procedures will be tested to ensure a smooth implementation.  The acceptance test provides the opportunity to examine all parts of the NPAC SMS in operation and to verify response as well as functionality.

During the acceptance test, results are formally matched to stated expectations using a sign-off process.  For areas not meeting requirements, a statement of deficiency is created.  These statements of deficiency are tracked via the Problem Tracking and Resolution system (LINCSS).  When deficiencies have been rectified, the appropriate elements of the acceptance test are repeated. This process continues until all system functions are approved.  All test results are gathered and preserved as part of the project documentation.  The test input is also preserved, making it possible to recreate the acceptance test, if necessary.

•Turn-up Testing.  After completing interoperability testing,  LSPs will begin interfacing, connecting, and testing to the “live” NPAC SMS system.  We envision that LSPs will first wish to test both the NPAC SMS to SOA interface and the NPAC SMS to Local SMS interfaces.  Next, they will port selected lab numbers and administrative numbers, and finally, selected customer numbers.  Once satisfied, the LSPs will begin porting “live” numbers.

116

2.0.2.2   Implementation Staff

Our proposed NPAC/SMS implementation organization is shown in Exhibit 2.0-4.  Our implementation team comprises qualified and experienced personnel from several different disciplines–each of whom is a specialist in their areas of expertise.

The NPAC SMS implementation will be led by Ms. Audrey Herrel, our proposed NPAC director.  Ms. Herrel has more than 20 years of experience in the telecommunications, data processing, and customer service industries, and brings the background and experience that is especially well-suited to lead the development and deployment of the NPAC SMS and manage ongoing NPAC operations.

As NPAC SMS product development manager, Mr. Richard Carter, will be responsible for the entire NPAC SMS system, including the supporting Stratus computing environment and communications network.  Mr. Carter is an experienced application development manager of complex telecommunications systems.  Supporting Mr. Carter in developing the NPAC SMS are Ms. Deborah Gay and Mr. Michael Savino from ESI.  Ms. Gay is an experienced system development manager from ESI with several years of system development expertise in complex applications on numerous hardware platforms, operating systems, and programming languages.  Mr. Savino is a telecommunications network specialist with more than 15 years of experience in telecommunications system specification and programming.

117

Other key positions include Mr. Lou Gammone as Network, Engineering and Infrastructure Manager, and Mr. John Varley as Quality Assurance and Control Manager.  In addition to these key staff positions, the Lockheed Martin Team has furnished resumes of other staff members, including resumes of the Management Review Committee.  These appear in Appendix B of our response.

2.0.3   PROJECT CONTROLS

Our project controls, consisting of quality assurance, performance standards, and configuration management, are staffed to ensure that high levels of service are consistently delivered to our clients.

All Lockheed Martin projects employ various program controls to ensure that the services provided to our customers meet or exceed their needs.  Each program is staffed with highly qualified personnel who are responsible for assuring overall quality and improving service delivery.  Our quality assurance approach for the NPAC/SMS is based on this philosophy.

To measure contract performance and service delivery, quality assurance and control, configuration management, and performance monitoring standards are established and adhered to by our project implementation teams. These standards are fine-tuned over the course of the project for continuously improving service.

The depth and breadth of the performance measures established by Quality Assurance and Control facilitate system and operations monitoring, thereby assuring that the highest levels of service are provided. Performance parameters include software quality, system availability and performance, and operations responsiveness to user needs.

118

Configuration management is an integral part of our software development process.  ESI manages all documentation, software, and development tools using a third party configuration management system appropriate for the hardware and operating system platform for the project.  Our configuration management systems are capable of managing multiple software product branches, including third party software.  Each software branch may contain multiple software releases.  ESI packages software that has completed all phases of the development cycle into a release kit that includes executables, tools, user documentation, load files and installation notes.  ESI coordinates the delivery and installation of the release kit with the customer.

Finally, we always institute monitoring and control standards to measure our project performance. Our records are reviewed and audited by internal groups and are always available for client auditing.

2.0.3.1   Quality Assurance and Continuous Improvement

Our commitment to total quality assurance and continuous improvement has been nationally recognized; this commitment ensures the successful provision of NPAC/SMS services for NYCAC.

Lockheed Martin emphasizes quality assurance in all of its operations.  Beyond the traditional approach of simply monitoring compliance with specifications, quality assurance improves all stages of product and service delivery and permeates all areas. We propose to extend this philosophy to the NPAC SMS.

ESI’s largest customer recently reviewed the performance and quality of their software development vendors via an audit conducted by the Software Engineering Institute (SEI) using their Software Maturity Model (SMM).  ESI received the highest rating of all vendors developing software for this customer -  the top 15% of software developers nationally.

119

Quality Assurance and Control Approach

At Lockheed Martin, quality assurance is of the utmost importance and a primary component within our operations.  It is not an afterthought.

Our philosophy is that the attainment and measurement of quality is the responsibility of the entire team assigned to and working on a project.  A separate program or issue is not simply relegated to the Quality Assurance and Control Group.  It must instead be the central theme and focus of the management group.  The culture and attitude of a company are formed at the top and permeate the organization.  The work force quickly picks up these attitudes and incorporates them into its work habits.  The best way to instill the quality ethic into an organization is to demonstrate that management cares about it and that it is the fiber and fabric from which the business is woven.  In essence, quality is our team’s lifeline.

Instilling the philosophy that customer satisfaction is the overriding concern of the NPAC/SMS organization will be an ongoing mission of the management team.  It will be emphasized during initial and ongoing training and in continuous quality improvement initiatives, and will be reinforced at staff meetings and performance reviews.

Evaluations of personnel will encompass both quality of service and customer satisfaction.  Compensation will be based on the individual’s performance as well as that of his/her group and the overall NPAC/SMS organization.  In this manner, the team concept is reinforced and quality becomes everyone’s business.  Our intent is to reward performance that supports the long-term goals of the NPAC/SMS and its users.

120

At Lockheed Martin, we strive to design quality into the product or process whenever we set up a new operation.  We then seek to improve upon our original design through our Continuous Quality Improvement Process. Continuous quality improvement for the NPAC SMS is the responsibility of the quality assurance and control manager, who will identify critical elements in a process and develop or eliminate procedures to improve the process.  He will spearhead and facilitate a team effort, involving members from the affected NPAC operations unit as well as outside staff with relevant expertise.

To design quality into the work process and continually improve upon it, we: (1) identify the purpose and the critical elements of the process; (2) organize an improvement team; (3) review the current process; (4) analyze the current process and develop process measures; (5) identify improvement opportunities; (6) develop an improvement plan; (7) establish measures of improvement; (8) implement the process change; (9) validate the process-improvement effectiveness; (10) establish and maintain controls; and (11) begin the improvement cycle again.

Thus, the pursuit of quality and its improvement are continuous processes and have measurable objectives.  We also recognize the interrelationship between quality and cost.  To that end, we always consider quality the more critical component.

In setting up the operating procedures and performance standards we are proposing for NPAC SMS, we have emphasized consistency, reliability, and responsiveness.  There must be consistency of service within each member of the group, the user must receive the same quality of service regardless of who answers the phone, and calls must be directed to the first available phone.

121

In addition, we are assuring consistency among the NPAC groups.  One group will not provide superior service while another offers only average service.  Any such variations, either on an individual or group basis, will be identified and corrected so that all groups supply the same level of superior service.

To further facilitate service, only one customer representative will interface with a user on a given transaction.  Hence, if a transaction cannot be resolved immediately and requires additional research, that same individual will be responsible for tracking it through to completion and reporting back to the user.  We utilize this single point of interface and ownership approach for logon administration, user problem resolution, system updates, training, report administration, and communications link requirements.  Reliability will be provided in terms of equipment and staff availability.  Redundancy of terminal, lines, and workstations is being designed into the system to ensure open lines of communication.

The Lockheed Martin Team’s staff level is designed to meet anticipated volume forecasts.  In addition, we are proposing to cross-train staff members to perform other functions in their group as well as in other NPAC SMS disciplines.  Hence, staff can be temporarily re-allocated to respond to unanticipated workloads or staff shortages.

The location of the NPAC/SMS in Tarrytown, New York uniquely positions it to be readily available to NYCAC, thereby assuring a capability to closely coordinate activities while maintaining a physical presence.

Responsiveness is another major component of quality service.  The staff will perform each procedure within — or better than — the time constraints specified in the performance standards.  Deviations from these standards will be tracked, and corrective action will be initiated.

122

2.0.3.2   Performance Monitoring

Performance is measured against a set of standards that are refined over time, allowing us to continuously improve our service to our clients.

The Quality Assurance and Control Group performs a major function in the development, implementation, and monitoring of performance measures, thus ensuring that the highest level of quality service is delivered to the NPAC/SMS user community in an evenhanded manner.  This team, reporting to the NPAC director, will establish processes and procedures to ensure that both the system and the operations functions conform fully to the terms of the contract while performing at levels that meet or exceed defined performance thresholds and standards.  Our performance will be measured through internal and external mechanisms.

Within our NPAC/SMS business unit, which comprises service center operations and the NPAC SMS, self-monitoring includes:

•Ongoing performance assessment through:

•System performance against defined standards

•Administration center performance against defined standards.

•Supervisory monitoring of staff on a daily basis to enable anticipation of potential problems in service delivery.  Supervisors counsel employees to cement what goes right in operations and provide guidance in those areas that require improvement.

123

•Daily meetings among managers to provide a formal and regular format to identify areas in NPAC/SMS operations requiring attention and resources.

•Staff performance reviews conducted regularly.

•Status report meetings held on a weekly basis during implementation and monthly thereafter.

External means of providing quality control and monitoring performance include:

•Monthly meetings between the Lockheed Martin Team and the NYCAC to provide status and progress reports as well as providing a forum to address new issues as they may arise.

•Management Review Committee reviews to ensure overall contract compliance and make suggestions on performance issues.

•NYCAC evaluations of NPAC/SMS performance.  NYCAC is provided a copy of our performance standards specifications, quality assurance and control guidelines, self-monitoring procedures, and performance data gathered by our Quality Assurance and Control Group.

•Interviews conducted with user representatives and groups.

In addition, customer surveys are conducted, and users are periodically surveyed regarding their assessment of the performance of NPAC/SMS.

124

This Page Intentionally Blank

125

NYCAC NPAC/SMS PROPOSAL 2.1  NPAC/SMS Overview

HIGHLIGHTS

•Redundant NPAC service centers, each with fully redundant high-speed LAN and WAN backbones, provide for guaranteed availability of primary or backup site for transparent NPAC operations and diversity of service provider access to the NPAC

•Minimal deployment and schedule risks due to use of standard Lockheed Martin NPAC SMS applications software already being deployed in support of the Illinois LNP LLC region

•NPAC SMS based on continuously available, fully hardware fault tolerant, Stratus computer plat-form in each service center to provide the highest possible availability and reliability

•Modular NPAC/SMS software and hardware architecture enables the development of future capabilities while retaining existing investment in NPAC functionality

2.1   NPAC/SMS OVERVIEW

2.1.1  NPAC/SMS System

Redundant wide area network (WAN) facilities provide reliable, diverse, data communications access for service providers and for real-time backup/disaster recovery.

The NPAC/SMS designed by the Lockheed Martin Team provides a highly cost effective solution without compromising the highest availability, flexibility, and expandability objectives.  Exhibit 2.1-1, NPAC/SMS WAN architecture, illustrates the top-level view of the network topology comprising the NPAC/SMS.  Dual wide area networks (WAN) comprising leased, dedicated, point-to-point DS-1 circuits and enterprise IP switching hubs provide a fully redundant data communications network infrastructure.  A dedicated dual WAN architecture, with fully diverse facilities, provides guaranteed communications access to the NPAC/SMS for service providers’ mechanized interfaces and authorized remote users.  The dedicated inter-site backbones links are complemented with switched (frame relay) links at up to DS-3 speed for overflow inter-site communications.  A dedicated WAN architecture was selected for use in the NPAC/SMS, vis-à-vis a virtual private network arrangement, due to its cost savings, guaranteed performance, availability, and physical network security.

126

2.1.1.1   NPAC/SMS Network POPs and Service Centers

Diverse, fully redundant, NPAC/SMS service centers provide complete backup and disaster recovery capability, and provides for backup cut-over in seconds with virtually no NPAC/SMS service disruption, far exceeding requirements in RFP Section 10 for availability.

The primary NPAC/SMS service center serving NYCAC is located at the Lockheed Martin Data Center in Tarrytown, NY.  This facility is located at: 777 Old Saw Mill River Road, Tarrytown, NY 10591.

127

Initially, to serve New York, two facilities-based points-of-presence (POPs) are provided off of the NPAC/SMS WAN for service provider interconnect.  These POPs are located at the two  Lockheed Martin NPAC/SMS service centers: Tarrytown, NY and Chicago, IL.  An additional virtual POP will be provided in New York LATA 132 as required, and will be interconnected to the NPAC WAN via frame relay to one of the NPAC/SMS facility POPs.

The backup and disaster recovery site for the Tarrytown NPAC/SMS service center is located at Lockheed Martin’s Chicago, IL NPAC  facility.  This facility also is the primary site for the Chicago NPAC/SMS service center, serving the Illinois LNP LLC region.  However, the backup NPAC/SMS system in the Chicago center will be dedicated for the NYCAC NPAC/SMS and not be shared.

A maintenance and support POP is deployed at the ESI development facility in Denver, CO, to facilitate software and system support and maintenance.  The ESI facility also houses a dedicated testbed, replicating the production environment at the two production service centers.

The two production NPAC/SMS service centers for NYCAC, in Tarrytown and Chicago, are fully replicated to enable continuation of NPAC operations in case of catastrophic site failure.  Diverse service provider access facilities (dedicated and dial-up) provide continued access to NPAC/SMS mechanized interfaces in such a case, enabling the NPAC/SMS to satisfy availability and backup cut-over time requirements.  Both NPAC SMS systems are fully accessible from any of the POPs, so any cut-over to backup does not rely on a separate set of communications links.  Consequently, NPAC/SMS operations are fully safeguarded.

The Lockheed Martin team selected a diverse, redundant, service center architecture in order to responsibly meet the requirements of the service providers in New York and deploy a cost effective solution that can readily support additional jurisdictions and functionality without the significant

128

incremental costs resulting from replicating non-redundant state-by-state solutions that do not provide for scalability and assured reliability.

2.1.1.2   Service Provider Interfaces to NPAC/SMS

Both mechanized interfaces (LSMS and SOA) and remote service provider- based users are supported to enable service providers to efficiently conduct both mechanized and manual operations with the NPAC.

The Lockheed Martin NPAC/SMS provides three forms of external interfaces with the NPAC/SMS system directly:

1.LSMS

2.SOA

3.Remote (authorized service provider-based) users.

Both mechanized SOA and LSMS interfaces (interfaces one and two, above) to the NPAC/SMS are supported in complete compliance with Section 6 of the RFP, as described in Section 2.6 below.  Since both of these interfaces are CMISE+IP based, they are both instances of a common type of mechanized interface to service providers, as defined in the NPAC SMS Interoperable Interface Specification (IIS) developed by the Lockheed Martin Team in conjunction with the members of the Illinois NPAC SMS committee.

In addition, a substantial number of NPAC processes and operations may be performed manually by authorized service provider-based personnel (remote users) over the third interface.  This interface provides a web-based GUI environment to access SOA-like functions directly on the NPAC SMS.  Consequently, the NPAC SMS may be used as a surrogate SOA for service providers on a permanent,

129

temporary, or emergency basis.  This enables service providers to optimize the automation level of certain functions (e.g., maintenance of service provider network data in the NPAC SMS) that may be initiated via service provider-based operational support systems (OSSs) across the mechanized interfaces versus direct remote user interaction with the NPAC/SMS.  Certain support and maintenance related functions may not justify the development expense in service provider OSSs to use the mechanized interface to the NPAC SMS.

For this reason, remote user support is provided via a highly secure, fully authenticated remote access facility, occasionally referred to as a low-tech interface (versus the “high-tech” CMISE interface).  At the service provider is option, remote users may use the same IP-based communications links interconnecting the service provider with the NPAC WAN (also supporting the mechanized interfaces), or use a separate access facility.  This facility may be dedicated (another IP-based link) or dial-up (ISDN or V.34 dialback) using PPP protocol.  Over IP, remote users’ workstations use an authorized secure web browser (e.g., Netscape Navigator or Microsoft Explorer) as the client application supporting the secure http protocol (HTTPS), thereby providing full encryption and authentication (via key certification and smart card).  In addition, full user, session, and application security facilities within the NPAC SMS control access to screens and data in a way that is consistent with the data access rules defined in the mechanized interfaces.

Functions that might be performed across this interface include:

1.Performing ad hoc queries of authorized database tables and fields for data auditing and trouble-shooting.

2.Maintaining (querying, viewing, reporting, modifying) service provider-related data, such as network data.

130

3.Performing manual service order, subscription, and activation functions in lieu of mechanized interfaces, e.g., in case of service provider SOA unavailability.

4.Requesting reports, re-transmits, or audits (if service provider on-demand audits are to be allowed through the NPAC SMS).

Remote users are authorized to perform a subset of the functions that internal NPAC users may perform using the same NPAC SMS operational graphical user interface (OpGUI).  All mechanized interface operations may also be performed by the appropriately authorized remote user personnel, thereby providing a manual fallback mode of operation in case of service provider SOA interface unavailability.  This ensures that time-critical activation and trouble-shooting operations can be performed by craft personnel even where access via the service provider SOA is not available.

2.1.1.3   NPAC/SMS Network Technology

The NPAC/SMS network is based on fault-tolerant, fast-packet, enterprise-switching hubs with routing and gateway screening capabilities, supporting a wide variety of dedicated and switched/dial-up WAN links to service providers.

The primary network-level communications technology underlying the NPAC/SMS network is the IP protocol.  A wide variety of physical link types and MAC layer protocols may be utilized to gain secure, fully authenticated access to the NPAC/SMS network, but the primary network layer remains IP for consistency in administration, security, performance, and switching technology.  Each NPAC service center has its own InterNIC assigned Class C IP network address and sub-domain name within the NPAC/SMS network domain (npac.com).  Publicly addressable systems within each of the Lockheed Martin NPAC/SMS service centers may be addressed by prefixing the location name (Tarrytown and Chicago) in front of the “npac.com” domain name, e.g., tarrytown.npac.com.  Public NPAC/SMS

131

information will be available for the NYCAC region via a web-based electronic bulletin board at www.tarrytown.npac.com, or www.nycac.npac.com.

Exhibit 2.1-2 illustrates the three primary interface types that are employed in the NPAC/SMS.  The first two interface types, mechanized and user, are external interfaces that are available to service providers.  Either dedicated or switched (ISDN or V.34) facilities may be used to access either type of interface.

Layer	Mechanized Interface	Local & Remote Users	NPAC System Support (Internal Only)	Function
	CMIP Agent Server	Secure Web Server (Open Market Web Server)	UNIX daemons, Oracle, Net mgmt	User
7	CMISE, ACSE, ROSE	HTTPS	Oracle, ftp, smtp, telnet, X, DNS,	Application
6	ANSI T.224		TACACS+, NFS, X.400, lpr,	Presentation
5	ANSI T.224	SSL	SNMP	Session
4	TCP, RFC1006, TP0	TCP	TCP/UDP	Transport
3	IP	IP	IP	Network
2	PPP, FR, MAC, ATM	PPP, FR, MAC, ATM	PPP, MAC, ATM	Link
1	DS-1/3, DS-0 x n, ISDN, V.34	DS-1/3, DS-0 x n, ISDN, V.34	DS-1/3, DS-0 x n, ISDN (backup)	Physical

Exhibit 2.1-2. NPAC/SMS Primary Network Protocol Stacks:  This exhibit illustrates the three primary interfaces types (two external, one internal only) and the underlying protocol stack technologies that are employed.  Shaded areas represent where primary security management (below application layer) is provided for each of the three interface types.

To enforce security for dial-up facilities, only PPP protocol is supported.  The first-level authentication scheme for dial-up PPP control is the Challenge Handshake Authentication Protocol (CHAP), an excellent authentication scheme for dial situations.  CHAP forces any remote device attempting a PPP connection to give the device name, a random value, and a secret, encrypted password that only the NPAC WAN can recognize.  Consequently, the NPAC WAN enforces strict link-level access security and authentication prior to granting a dial-up connection access to the NPAC network.  Additionally, per

132

requirement R7-43, dial-up access requires use of a smart card (the SecureID), validated by the NPAC/SMS.  Full usage/accounting information is collected for both dial-up and dedicated connection links using the TACACS+ protocol between the NPAC WAN network access servers and one of NPAC SMS servers, which is also used to provide for authorization and authentication of the remote terminal, using a RADIUS server.

The interface specifications for the mechanized interface are fully compliant with the RFP, and may be found in the IIS.  Please see Section 2.7 below for a discussion of security features across this interface.

To provide an equivalently secure environment for both local (NPAC) and remote (service provider) users, the HTTPS protocol (secure web) was selected.  This protocol uses the SSL (Secure Sockets Layer) protocol standard for encryption and authentication.  Readily available web browser client software supporting HTTPS (e.g., Netscape Navigator or Microsoft Explorer) significantly reduces the user workstation requirements and cost without reducing security.  Secondly, standardizing on a common internal and external user interface technology also significantly reduces development and maintenance costs, while offering service providers greater flexibility and redundancy in invoking NPAC services.

The third interface type (NPAC system support) is solely for internal use by NPAC system support personnel and system support software.  Consequently, physical link/network access is the primary access control security mechanism used.  Certain of these protocols (e.g., ftp, smtp) are used to provide standard network services (e.g., file transfer, E-mail) in support of NPAC operations.  These facilities are accessible external to the NPAC only through a dedicated firewall/gateway/proxy server at each NPAC service center to ensure the highest level of security and auditability.

133

2.1.1.4   Service Provider Access to NPAC/SMS

Access facilities into the NPAC/SMS are engineered in conjunction with each service provider to optimize their communications requirements and minimize costs without sacrificing availability and security.

Lockheed Martin will work in conjunction with each service provider to engineer, within a defined set of options, the communications facilities that best meet their needs, considering, for example: cost, diversity, bandwidth, dedicated vs. dial-up primary links, and dial-up vs. dedicated backup links.  Service providers may choose their terminating NPAC POP using any of the POPs available throughout any of Lockheed Martin’s NPAC service regions, including Tarrytown and Chicago, or the virtual POP in New York LATA 132 for each primary mechanized interface link and form of backup link (dedicated vs. dial-up).  Also, link types for user support (via HTTPS, the secure web protocol) may be separately engineered (dedicated vs. dial-up) or engineered to share common links with either mechanized interface or may be authorized to access via the Internet.

Supported WAN link types, are

1.DS-1

2.Fractional DS-1 (DS-0 x n)

3.Frame Relay (DS-0 x n as the CIR)

4.DS-3 (unlikely to be required in the near future)

5.ATM

6.ISDN dial-up (DS-0 x n circuit switched data [PPP] only)

7.dial-up (PPP only).

134

Supported routing protocols include:

1.OSPF

2.BGP-4

3.RIP, RIP2

4.BCP bridging

5.IGMP multicast forwarding.

Network routers within the service providers’ and users’ networks will be required to comply with one or more of these industry standard protocols to enable effective link and route management.  A failure of any one communications link will not cause inaccessibility of any NPAC/SMS-related system by providing sufficient link redundancy and diversity.  The routing protocols will affect the necessary re-routing to manage around isolated link failures, rendering most of these transparent to the service provider and NPAC/SMS systems.

Access to the NPAC/SMS is available via the Internet using a highly secure, dedicated IP firewall/gateway/proxy facility, further discussed in Section 2.1.2 below, on the NPAC/SMS network to ensure security.  The primary function for the Internet access facility is for E-mail access to service providers.  However, remote user support using HTTPS (secure web access) via the Internet is possible.  For security purposes, non-SMS network services (e.g., E-mail, ftp) will not be supported on the primary NPAC SMS servers, but on separate servers.  These services include: E-mail, ftp (for report and bulk data transfers), X.400/X.500, DNS (domain name service).

2.1.2   NPAC/SMS Architecture

Cost effective, yet highly reliable and scalable service center architecture ensures NPAC/SMS availability and expandability.

135

Each of the two production NPAC sites (Tarrytown and Chicago) for the NYCAC are redundant.  Exhibit 2.1-3illustrates the architecture within the primary  NPAC site.

2.1.2.1   NPAC Service Center LAN

Redundant NPAC service center LAN architecture guarantees availability of NPAC/SMS servers to local users and to service providers via the NPAC WAN, thereby providing diverse access to and within each service center.

Each NPAC service center has fully fault-tolerant enterprise-switching routers, performing fast packet switching and routing.  Multiple virtual local area networks (VLANs) are logically formed within the NPAC LAN using LAN microsegmentation to route traffic only to the intended segments, thus providing for scalability without sacrificing security.  The backbone routers at the two service centers are connected via two dedicated facilities (DS-1s) to provide for seamless LAN/WAN connectivity, with switched inter-site frame relay services for overflow traffic capacity.  No single point of failure can render the NPAC/SMS unavailable to local users and service providers.

The Lockheed Martin Team felt that it would be irresponsible to propose less than this architecture given the availability, scalability, and investment retention requirements.  The judicious use of network element-level design principles was employed to ensure that no brick walls would be encountered in the future that would require a complete change-out of network infrastructure, facilities, or software.  Furthermore, from the Team’s extensive operating experience, non-redundant LAN backbones are less than 99.7% available, rendering overall NPAC/SMS availability below required levels.

136

In case of a cut-over to the backup service center for any reason, this redundant LAN/WAN architecture enables the mechanized and user interfaces to be re-routed virtually instantaneously via logic in the router switches and via remote management.  A planned cut-over could occur virtually transparently to service providers.  They would be requested to logoff and immediately log back in, at which point the mechanized and user interfaces would be established with the alternate service center.  Near real-time database replication, performed autonomously, ensures that both service centers have consistent and current data, preventing virtually all cut-overs from causing costly service disruption due to stale data.  Mechanized transaction recovery facilities in the CMISE interfaces ensures full re-synchronization in case of either NPAC SMS or individual service provider failure.

The NPAC service center LAN is a virtual, packet-switched network for security, reliability, and scalability.  Local loop (intra-NPAC) types include: fast ethernet (100 Mbps), ethernet (10 Mbps), FDDI, and ATM.  Only packets destined to host on a loop are routed to that loop.  The NPAC WAN routers are fault tolerant with hot-swappable field replaceable units (FRUs), and complete instrumentation via SNMP for remote management and monitoring from the NPAC network operations group.  Gateway screening functionality in the packet switches safeguards against attempts to access improper network services by unauthorized WAN/dial-up link or internal user.

To maximize accessibility to the NPAC SMS server, the server has two fast ethernet or FDDI loops, each connected to one of the separate modules within the NPAC service center hub.

2.1.2.2   NPAC SMS Server

The NPAC SMS, based on a continuously available, fully hardware- fault- tolerant Stratus computer platform in each service center, will provide the highest possible and most cost-effective availability and reliability.

137

Lockheed Martin IMS selected Stratus Computer, Inc., to provide the NPAC SMS server platform and to participate as a team member after an extensive analysis of the availability and scalability requirements and a determination of the most cost-effective solution to those requirements.  A comparison of the three basic types of availability levels is illustrated in Exhibit 2.1-4.

Type	Method	Availability	Downtime (per yr)	System Cost Ratio
Continuous Availability (CA)	Transparent hardware fault tolerance.	99.99%	0.876 hrs. 52.6 min.	2.7
High Availability (HA)	Hardware/software fail-over to backup: no continuous checking, some disruption during fail-over.	99.5%	43.8 hrs. 1.83 days	2.1
Simplex	Non-hardened, non-auto fail-over.	98%	175.2 hrs. 7.3 days	1.0

Exhibit 2.1-4.   Types of Computer System Availability Architectures.

The NPAC SMS is based on the Stratus Continuum series of fault tolerant computers.  The initial server configuration can readily expand to handle traffic volumes well in excess of those predicted for year 5 traffic.  A Stratus Continuum 400 Series Model 428H processor configuration, consisting of two logical 180MHz HP PA-RISC PA-8000 processors in a symmetrical multiprocessing (SMP) configuration, is proposed to support the initial NPAC/SMS deployment.  To support the volume projections stated in R10-15 and R10-17, five (5) Stratus Continuum 400 Series Model 428Hs would be required to support the estimated capacity requirements.  This configuration is illustrated in Exhibit 2.1-5.  The Lockheed Martin NPAC SMS software is designed to run in a highly parallel fashion to enable NPAC SMS scalability through increased distribution and addition Stratus Continuum processor modules.  The Stratus-based NPAC SMS provides cost effective on-line transaction processing capability, with software- and performance-transparent fault tolerance and significant expandability.

The NPAC SMS directly services both external NPAC interfaces – the CMISE-based mechanized interfaces and the secure-web based interface.  Security and key management, access control, and

138

authentication (CHAP for PPP) are performed on the Stratus-based NPAC SMS server.  The NPAC SMS databases, history files, audit files, etc., are also maintained on the NPAC SMS server.  Please see Section 2.1.3 below on NPAC SMS application software architecture.

[Graphic Omitted:  chart of high-level configuration]

Exhibit 2.1-5: Fully Configured NYCAC NPAC SMS Configuration Consisting of five (5)Stratus Continuum 400 Series Model 428H.

The Stratus-based NPAC SMS server also provides full network management instrumentation for centralized control and monitoring by the NPAC network management group.  The Stratus hardware, Stratus UX operating system, communications stacks (OTS/9000), application software, and Oracle RDBMS all support either SNMP or CMIP-based remote management.  The Stratus UX operating system is Stratus UX 10.10, a port of HP’s HP-UX 10.10, which ensures binary compatibility of applications and layered software.

2.1.2.2.1   Stratus Hardware Architecture

The Stratus-based NPAC SMS delivers consistent, full performance even with a hardware failure, making NPAC/SMS operations immune to such failures.

Introduction

The Stratus® Continuum™ Series, Stratus’ latest and most advanced family of application platforms, delivers the availability, features, and performance needed for large mission-critical OLTP applications.  The Continuum product family, which uses Hewlett-Packard’s PA-RISC 7100 and 8000 microprocessor technology to deliver exceptional levels of processing power, was specifically designed to incorporate a completely new system architecture to keep pace with the advances being made in CPU performance.

139

With Continuum, Stratus delivers substantial improvements in performance and price/performance.  Comparisons with the prior Stratus XA/R™ series show that the high-end of the Continuum Series delivers three times the system level performance of high-end XA/R systems.  From a price/performance standpoint, Continuum models deliver up to four times the performance for a given price point.

Such improvements now allow customers within Stratus’ key markets to afford the fault tolerance they require to bring more critical applications on-line, thereby enhancing their own competitive advantages.  This is particularly true of the telecommunications and financial services markets that look to Stratus for a broad range of hardware and software platforms.

Stratus Continuous Processing

Stratus originated a unique, automatic, hardware-based, fault-tolerant architecture and continues to enhance its implementation.  No technology other than Stratus combines trouble-free setup and robust processing with transaction availability.

Stratus Continuous Processing is based on the premise that all aspects of the system design must be addressed to create a continuously available system.  Stratus provides features such as duplex self-checking hardware, operating system kernel hardening, on-line upgrades, on-line service, and on-line system administration, thus avoiding potential sources of downtime. In addition, Stratus’ fully integrated approach keeps the application, data, and processing available and free of corruption.

Stratus fault tolerance begins with power-up diagnostics that spot potential problems before they occur.  During operation, all computation, storage, and I/O proceed in parallel on duplex hardware.  Each circuit board checks itself for hardware errors at every machine clock cycle. If a logic fault is detected, the system stops the faulty board instantly while the duplex partner board continues to execute the program

140

in a normal manner and at normal speed. Thus, if a board should fail, there is no need for intervention by the operating system.  The failed board simply drops out of service and is automatically reported to a Stratus Customer Assistance Center.  This approach has the added advantage of catching transient errors as well as “hard” failures, resulting in higher availability and increased assurance of data integrity.  Memory is duplicated and ECC-protected, and memory controller logic is self-checking.  Advanced “sniffing” circuitry checks memory for errors, ensuring that seldom-used memory locations do not develop non-correctable errors. “Sniffing” does not affect the performance of ongoing work.

Disks and disk controllers are also duplicated to prevent a failure from corrupting data or interrupting the system’s operation.  Whenever a write operation is requested, the operating system writes the data to both parallel disks.  When a read operation is required, it comes from the disk whose read-write heads are closest to the data, thereby minimizing access time and offering performance benefits in read-heavy environments. If a disk failure occurs, all disk I/O operations continue on the good drive until the malfunction is repaired.  When the failure is repaired, the system automatically restores the disk.  Here again, the application software is unaware of the failure or the redundant hardware architecture.

Continuum Models

For distributed and departmental environments, the Continuum family offers the 400-, 600-, and 1200-series models.  These high performance systems provide open, continuously available computing.  The performance of the systems in each of these series is roughly equivalent; the primary difference is the amount of communications links and disk storage expandability.  Since the Stratus systems in the Lockheed Martin NPAC/SMS architecture do not directly terminate individual communications links to service providers, the I/O expandability of the model 600 and 1200-series systems is not required.  Instead, common high-speed communications facilities (fast ethernet, FDDI, and ATM) are used to

141

interconnect each Stratus system into the NPAC LAN at each service center, through which access to NPAC users is provided.

Hands-Off Availability

Because Stratus has designed continuous availability directly into the Continuum architecture, customers get the highest possible uptime with virtually no additional configuration, reprogramming, or administration costs.  On-line service and system administration let both the customer and Stratus monitor the status of the system and the application.  In the event of a component failure, the Stratus architecture ensures that the system continues to function uninterrupted at peak performance, while Stratus’ around-the-clock customer assistance center is automatically alerted to ship a user-installable replacement.

By addressing all aspects of system design needed for continuous availability, Continuum makes the world’s highest degree of reliability effortless and transparent to the user.  Duplexed, self-checking hardware and self-checking logic checking minimize the chances of application or operating system downtime.  In addition, Stratus’ design eliminates routine planned downtime by allowing on-line service, upgrades, and systems administration.

Combined CPU and Memory on a Single Board

Stratus Continuum Series systems combine processor, cache, and main memory on a single board for greatly enhanced system throughput.  The CPU-Memory Board is a combined processor/memory board containing up to two logical (four physical) Hewlett-Packard PA-RISC 7100, or two logical HP PA-8000 processors.

The Stratus Continuum Series Family is illustrated in Exhibit 2.1-6.  Continuum Series models 410, 610, and 1210 feature one pair of duplex CPU boards incorporating the 72MHz PA-7100 microprocessor.  Models 425, 620, 625, 1220, and 1225 feature one pair of two-way SMP CPU boards.  The xx20 models

142

incorporate the same PA-7100 microprocessor with up to 512MB memory.  The xx25 models utilize two 96MHz PA-7100s microprocessors with up to 512 MB of memory.  Disks are expandable up to 82GB.  Model 1245 features two duplex pair of two-way SMP CPU boards (comprising four logical CPUs) with the 96MHz PA-7100s microprocessor and up to 1GB memory and up to 178GB disk.

The Continuum Series models xx18H and xx28H (e.g., 418H, 428H, 818H, 828H, etc.) are the latest addition to the Continuum Family, and feature the 180MHz PA-8000 microprocessor, representing a 4x increase in CPU performance over the 96 MHz PA-7100 processor.  In addition, a 4x increase memory capacity is available, up to 2GB of RAM can be supported.  The xx18H models feature one pair of duplex 180MHz PA-8000 CPU boards (one logical CPU), and the xx28H models feature two pairs of duplex 180MHz PA-8000 CPUs (two logical CPUs).  For a comparison of the specifications and relative performance of the Continuum Series Family, see Exhibits 2.1-7 and 2.1-8.  Note the Lockheed Martin NPAC SMS platform is based on the Continuum 428H system (2 x PA-8000).

[Graphic Omitted:  graphic of Stratus family]

Exhibit 2.1-6: Stratus Continuum Series I Family

Model	CPU & Clock	Number of SMP CPUs	Max Memory	Relative Perf.
610S, 610, 1210	72 MHz PA-7100, 512KB Cache	1	512 MB	1.0
412	96 MHz PA-7100, 512KB Cache	1	512 MB	1.2
415, 1215	96 MHz PA-7100, 2MB Cache	1	512 MB	1.5
620, 1220	72 MHz PA-7100, 512KB Cache	2	512 MB	1.6
422	96 MHz PA-7100, 512KB Cache	2	512 MB	1.8
425, 625, 1225	96 MHz PA-7100, 2MB Cache	2	512 MB	2.7
1245	96 MHz PA-7100, 2MB Cache	4	1 GB	4.5
418H, 818H, 1218H	180 MHz PA-8000, 2MB Cache	1	2 GB	5.9

143

Model	CPU & Clock	Number of SMP CPUs	Max Memory	Relative Perf.
428H, 828H, 1228H	180 MHz PA-8000, 2MB Cache	2	2 GB	10.0
Exhibit 2.1-7: Stratus Continuum I Series Specifications Summary

[Graphic Omitted: Stratus performance comparison chart]

Exhibit 2.1-8: Stratus Continuum I Performance Comparison

NPAC SMS
Platform (428H)

As in earlier Stratus designs, each CPU-memory board contains a C side and a D side, which are compared side-to-side to detect on-board errors.  A partner board runs in lockstep, and a detected failure on either board causes the board to go off-line while its twin continues to support the application unabated.  The CPU subsystem and system bus interface are fully duplicated and compared in the same manner, as illustrated in Exhibit 2.1-9. The memory subsystem uses ECC detection and correction to handle recoverable faults.

144

System Bus

Duplicated to provide fault tolerance, the Continuum system bus is a single logical split transaction multiplexed address/data type bus, as illustrated in Exhibit 2.1-10.  Major features include the ability to support 32- and 64-bit bus interface widths, completely synchronous operation, cache consistency support, a single logical ASIC interface, and a 192MB/second CPU to CPU speed.

[Graphic Omitted:  architecture diagram]

Exhibit 2.1-10: Dual Bus Architecture of the Stratus Continuum family illustrates its fault-tolerant design.

Power Fail Ride-Through Enhancements

The Continuum architecture features two major improvements in how it handles power failures to prevent any memory loss: a very robust power subsystem and DC-powered disk drives.  The NPAC service centers employ UPS systems or backup generators to maintain power during blackouts.  Yet, to ensure against data loss, the power fail ride-through for Continuum Series systems has been expanded to 45 seconds (over the 6-second ride-through available with prior Stratus models), including full disk read/write operations.  This is significant, because more than 80 percent of power failures are of a duration of less than 10 seconds.

If power has not been restored after 45 seconds, application processing is suspended.  The operating system then copies all volatile data to disk, ensuring against data loss while keeping data in memory.  After the data is written to disk, the system then completes its shutdown.  When power is restored, a normal system restart occurs, minimizing application downtime and ensuring 100 percent data integrity.

145

Expandability

The Continuum architecture makes it very easy to expand a system incrementally as system needs increase.  All models within the 6xx and 12xx Continuum are on-line upgradable simply by swapping processor boards or by adding additional processor boards.

The design of the memory, disk, and I/O subsystems also makes incremental, on-line growth very easy.  The Continuum family supports up to three I/O communications processors, four logical RISC processors, 2GB of duplex memory, 178 GB of duplex disk, and 84 I/O adapters, allowing up to 1,344 direct connect communications lines.

Future Stratus Continuum systems will incorporate newer processor technologies, from both HP (PA-RISC) and the HP/Intel joint venture (Merced), resulting in significant performance improvements, as illustrated in Exhibit 2.1-11, to ensure continued scalability of the NPAC SMS capability.

Exhibit 2.1-11: Performance Roadmap for Future HP and HP/Intel-based Systems

[Graphic Omitted:  Chart of future system performance]

Communications

The Stratus Continuum Series supports a broad range of industry-standard local and wide-area communications technologies, including OSI, X.25, X.400, TCP/IP, ethernet, fast ethernet, FDDI, ISDN, and ATM.  To accomplish this, the Continuum Series supports a wide range of I/O adapters, including 16-line asynchronous adapters, universal communications adapters, ethernet adapters, Token Ring adapters, X.21 communications adapters, and Channel Attach I/O adapters.

146

2.1.2.1.2   Stratus Software

Mission-critical, hardened SMP UNIX operating system provides software/OS reliability consistent with transparent hardware fault tolerance.

The Stratus Continuum-based NPAC SMS is UNIX-based, using the Stratus UX operating system. The Stratus UX operating system is Stratus UX 10.10, a port of HP’s HP-UX 10.10, that ensures binary compatibility of applications and layered software.  The layering of Stratus UX facilities is illustrated in Exhibit 2.1-12.

Stratus UX on the Stratus Continuum Hardware Family:

•Supports full range of Continuum packages

•Improved power-fail ride-through

•Local memory-pool allocation

•Support of virtually addressed caches

The following sections discuss the benefits of the Stratus UX operating system due to its being a port of HP’s HP-UX operating system for use in the HP PA-RISC based environment of the Stratus Continuum Family.

HP-UX Version 10.10 Operating System

Hewlett-Packard’s HP-UX is the industry’s leading UNIX operating system, providing a highly reliable, standards-based foundation for companies to run and manage business-critical solutions. The demands of the enterprise-computing environment today require both adherence to industry standards and a solution set that meets ever more exacting needs as businesses react to their changing competitive environments. HP knows that customers need a foundation that can support their business today as well as meet their future needs. With its outstanding software scalability and value-added features, HP-UX is designed

147

to run in environments ranging from the enterprise desktop, engineering workstations, departmental- and branch-size servers, to mainframe-class systems within the data centers of large enterprises.

HP-UX is the only UNIX operating system on the market that offers customers full enterprise-class functionality. From the kernel up, HP-UX is designed to support enterprise requirements such as:

•Broad scalability

•Mainframe-class performance

•Maximized system up-time

•Broad, best-in-class business solution availability

•Robust and easy-to-use integrated system- and network-management solutions

•Application investment protection

•HP-VISUALIZE high-speed 3D graphics.

Furthermore, because HP-UX incorporates the leading standards, customers are well positioned for superior inter-operability in a mixed vendor environment.

Investment Protection

HP-UX offers application investment protection unmatched by any other UNIX system vendor.  Since its commercial debut on PA-RISC in 1986, HP-UX has provided customers application binary compatibility when upgrading to new HP-UX versions. This translates directly to increased productivity for development and administrative staff who can devote their time to planning for future business requirements rather than managing migrations. With HP-UX version 10.10, HP continues to provide application investment protection so customers can quickly and easily take advantage of the new features of the operating environment.

148

Scalability and Performance

HP-UX is completely scalable from the desktop to the data center.  Applications can be developed on an entry-level HP 9000 server or workstation and placed into production on a data center-class system, such as the Stratus Continuum Model 428H or other Stratus/HP production systems—systems that feature symmetrical multiprocessing (SMP) for parallelism.  HP-UX is designed to provide high performance in on-line transaction processing (OLTP), graphics, file serving, and batch processing, and to do so when a blend of applications are using the system environment.  Additionally, HP-UX has been tuned to provide superior NFS (network file system) performance on both SMP and uni-processor servers.

HP Process Resource Manager offers additional flexibility to manage the system’s performance according to business priorities by allowing an administrator to dynamically allocate a desired minimum percentage of available CPU cycles to defined groups of users or processes.  Mission-critical applications can now be guaranteed access to the required level of processing power on a shared system.

The Foundation for Enterprise-Wide Network and System Management

HP-UX serves as an ideal platform for system and network management of both centralized and enterprise-wide replicated sites. The system and network management facilities supported by HP-UX provide a comprehensive set of products and procedures that manage all aspects of the system and network. Available on HP-UX, HP OpenView is the industry-standard modular solution for managing distributed networks of multi-vendor systems. It forms the backbone of HP’s enterprise-wide network and system management strategy.

149

Industry-Leading Performance and Scalability

Feature	Benefits
Scaling across the entire HP 9000 product line	Offers flexibility to accommodate future growth with full application binary compatibility.
Symmetric Multiprocessing (SMP)	Provides excellent scaling of application performance across multiple processors using a single version of the operating system.
Large-Scale Functionality * Maximum Large File System Size (128GB) * Large Addressable RAM (3.75GB)	Enables processing of high-end OLTP, decision support, and technical applications.
Memory Mapped Files (MMF)	Offers faster file access for applications using POSIX and OSFAES compliant MMF calls.
Shared libraries	Allows applications to share libraries during run-time, reducing RAM usage and making it easier to update applications.
User-space threads based on POSIX 1003.1 c, draft 4 and thread-safe libraries for C++, Pascal dynamic loader allowing development of multi-threaded applications	Supports high-performance, enterprise-scalable client/server, math/vector, networking, and applications based on industry-standard technology.
Logical Volume Manager (LVM) * Software Disk Striping	Transparently implements virtual disks that span multiple physical drives to improve disk access management and performance.
HP Process Resource Manager/9000	Gives the system manager the ability to dynamically match the system’s CPU resources with business priorities.
Dynamic Buffer Cache	Adjusts dynamically to deliver optimal application performance.
ANSI-standard compilers optimized for PA-RISC	Deliver optimized performance for applications.

Core System Management with HP-UX Made Even Easier

The system management facilities supported by HP-UX are designed to easily manage both single-server and complex networked systems, increasing the productivity of the operational staff.

Core system configuration is conducted with the HP-UX System Administration Manager (SAM). SAM allows the administrator to perform all major administrative functions using an intuitive graphical user

150

interface that leads the administrator through the choices in a given task. SAM is designed to take a potentially complex task, such as adding and configuring a disk to a system, and simplify it to a short sequence of guided steps so fewer errors occur and greater productivity in core systems management is achieved.

SAM also supports system administration for large enterprises where there are multiple administrators, each performing different tasks to maintain the environment. SAM can be used by the lead system administrator (a superuser) to create specialized subsets of tasks that other non-root administrators can use to accomplish their administration duties. System security is improved by reducing the number of administrators requiring superuser capability while supporting administrative roles that fit the organizational structure.

The same graphical interface and object/task design (applied with SAM) is used for software management through HP Software Distributor/UX, as well as for enterprise-wide management of client/server applications based on HP DCE/9000, CICS® for HP 9000, and Encina/9000. HP is the only vendor that provides this consistent methodology for managing different elements of the environment.

To address the complex task of managing software, HP-UX includes a standards-based utility called HP Software Distributor/UX.  This tool, based on the submission for the POSIX 1387.2 standard, offers packaging, distribution, management, and software installation services.

Integration with Existing Environments

In the open systems world, one important requirement is to provide enterprise-wide connectivity into all major environments. Included with HP-UX are several key networking features that provide customers cost-effective networking with heterogeneous systems.

151

All licenses of HP-UX version 10.10 include TCP/IP, Internet services, ONC/NFS, DCE/9000 Executive, XTI over TCP/IP, Streams/9000, and NCS. Additionally, HP offers a complete networking product line for integration with local- or wide-area multi-vendor environments.

#1 in Reliability for Business-Critical Computing

In both the commercial and technical markets, business-critical computing requires environments that provide the highest possible up- time for production environments. The reliability of HP-UX has historically ranked highest in the industry in comparison to other UNIX operating systems. This focus on reliability of HP-UX is key to the high availability of the operating system’s services for business-critical computing. Additionally, HP-UX supports kernel features designed to maximize system up-time.

HP-UX System Administration

System Administration Manager (SAM):

•Terminal and motif-based object/task oriented interface

•Superuser can define subset of tasks for non-root administration

•SAM designed to minimize administrator inputs while optimizing configuration on behalf of system administrator. Provides increased accuracy, productivity, and ease-of-use for configuration and management

•SAM logging activities viewable in window

•Extensible and customizable

•Integrated with HP OpenView for enterprise scalability.

152

HP Software Distributor/UX for standards-based packaging, distribution, installation, and management of all software in the environment:

•Ability to pull software from a central software depot with the capability to easily enable push capability with HP Software Distributor/UX.  Provides a common software distribution and packaging, leading to increased administrative efficiency in a multi-vendor systems environment

•Supports multiple architectures.  Run-time version of iFOR/LS software license compliance tool to manage software usage.  De facto industry-standard makes licensing administration more effective

•Disk quotas. Allow the system manager to control the amount of disk space available to users.

System Security

Feature	Benefits
Compliance with Dept. of Defense C2 security requirements	Provides the basis for server security.
System Auditing, which maintains a log of security-related events	Improves user accountability and deters unauthorized activities.
Access Control Lists (ACL)	Provides increased flexibility to control file access above standard C2 discretionary access control.
Extended Password Management Facility	Password Management Guidelines. Provides superuser-only encrypted password database, system generated passwords, user generated password screening, and enforced password aging.
Logon Restriction Facility	Allows administrator to control times/dates that specific users can access the system and locations from where logins will be accepted.
System Administration Roles	With SAM, the lead system administrator can partition tasks to others on the team without relinquishing superuser capabilities. Allows maximum utilization of system administration resources while maintaining system security.
Boot Authentication	Prevents unauthorized users from booting-up a system.
Coexistence with DCE Security	HP-UX server security and distributed application security provide a robust environment for enterprise needs including integrated security login.

153

To meet the needs of today’s business processing environments, HP-UX 10.10 complies with U. S. Department of Defense C2-Level standards, with selected additional features from the B-Level security specifications.

Standards Leadership for Competitive Advantage

HP-UX 10.10 is an X/Open UNIX 95-branded product, meaning that it conforms with X/Open’s Single UNIX Specification (SPEC1170). In addition, HP-UX 10.10 complies with such standards as XPG4, SVID3 level 1 APIs, OSF AES, as well as all major de facto APIs such as BSD. Through its adherence to standards, HP-UX reflects HP’s strong commitment to interoperability and portability.

Third-Party Software Availability

More than 5,000 HP Channel Partners offer 10,000 solutions that run on HP-UX. More vendors of leading engineering, mainframe-based and priority operating environment solutions have ported their software to HP-UX than to any other UNIX operating system.

Further, the industry’s leading relational database software vendors, including Oracle, Informix, Computer Associates (CA-OpenIngres), Progress, and Sybase, have optimized their databases for the HP-UX operating environment.

In support of customers’ next-generation client/server applications, HP-UX includes the industry-leading HP DCE/9000 Executive license-to-use. This makes it easier for customers to deploy standards-based Distributed Computing Environment (DCE) applications across the enterprise.

Business-Critical High Availability

Feature	Benefits
Journaled File System included with HP-UX	Guarantees file system integrity through a fast recovery process in the event of a system failure

154

Feature	Benefits
Dynamic management of the Journaled File System with HPOnline JFS: • On-line disk defragmentation • On-line disk resizing • On-line backup	Allows on-line file system management for the Journaled File System, providing even greater system availability
Automatic restart after power failure	Supports “lights-out” recovery.
Auto-configuration of I/O systems and device drivers at system boot-up	Enables fast system startup
Additional capabilities designed into OSF-defined Logical Volume Manager for increased system availability and performance: • LVM on root disk as well as data disk • Maintains consistency between multiple-mirrored logical volumes, which is vital for database applications that access multiple file systems • Supports dual I/O paths between disks and the system, with automatic fail-over to second I/O path • Ability to back-up a mirrored logical volume from a second system, thereby increasing system availability.	Ensures high availability and data consistency for large, data-intensive applications
Supports a variety of diagnostics that reduce the likelihood of system-interfering events such as RAM, disk, or other component failure: • Detection of potential system failures with proactive diagnostics and services through Stratus Support Services • Dynamic de-allocation of bad memory pages before a serious memory failure occurs.	Keeps unplanned downtime to a minimum with tools and services designed to detect problems before they can interfere with the system.

155

Standards

Feature	Benefit
Conformance to all major standards: • X/Open UNIX 95 (conforming with the Single UNIX Specification, SPEC 1170) • X/Open Portability Guide Issue 4 Base Profile (XPG4) • OSF AES • AT&T System V Interface Definition (SVID3 base and kernel extensions subset) Level 1 API support • Federal Information Processing Specification (FIPS) 151-2 • UC Berkeley Software Distribution 4.3 (BSD4.3) including features such as job control, fast file system, symbolic links, longfile names and the C shell • System V.4 File System Directory Layout • IEEE POSIX 1003.1 and 1003.2 • IEEE POSIX 1003.1b Real-time API support (Phase 1) • NFS Diskless and ONC/NFS Version 4.2.	Ensures highest degree of portability in a multi-vendor environment. HP-UX is among the first UNIX operating systems to be UNIX 95-branded, offering users greater investment protection and flexibility.
User Interface: • Common Desktop Environment (CDE) 1.0 • Run-time support for XWindow System Server Version 11 Release 6 • HP Visual User Environment 3.0 • OSF/Motif 1.2.5.	Industry-standard interfaces for increased developer, as well as end-user, productivity.
HP DCE/9000 Executive including the following services are included with HP-UX: • Remote Procedure Call (RPC) • User-space threads based on POSIX 1003.1c, draft 4 • Timing services • Client services for the DCE Cell Directory Service, Security Service, and Distributed File Service.	Deployment-ready for distributed client/server applications.

156

2.1.2.3   NPAC Internal Users and Work Group Support

NPAC internal users are housed on PC workstations support by a Microsoft NT-based server for office automation/support to provide a fully automated NPAC operation.

NPAC internal users access the NPAC SMS similar to external users, using a secure web browser as the client workstation application.  These workstations also provide the NPAC staff with access to office automation services provided by a separate workgroup server.  These functions include:

•E-mail

•File sharing and transfer (ftp, NFS)

•Centralized fax document transmission, retrieval, and storage

•Network printing

•Document/report archival on optical WORM drive.

•Ad hoc NPAC SMS database querying and reporting capabilities via DBACCESS.

NPAC support staff may be located in any NPAC service center and, via the NPAC/SMS WAN, establish a virtual presence within a required workgroup.  This enables significant flexibility regarding NPAC staffing functions, with corresponding operational cost savings for the benefit of service providers.

2.1.2.4   NPAC Network Management

Centralized management of all NPAC/SMS network, facilities, hardware, and software enables quick fault detection and resolution and minimal service provider disruption.

NPAC network management personnel monitor the health of all NPAC facilities through a centralized network management facility.  An integrated network management environment using HP OpenView

157

enables network operations staff to monitor all NPAC facilities and systems, including: network communications facilities, hubs, NPAC SMS server (hardware, UX operating system, communications stacks, application software, and RDBMS).

Configuration changes and backup fail-over/restore processes may be initiated by the network management group centrally with direct control over all required resources.

2.1.2.5   NPAC Internet Firewall

Highly robust, cost effective, and proven firewall architecture ensures NPAC/SMS security while enabling authorized Internet access to facilitate efficient communications with service providers.

The NPAC/SMS LAN architecture utilizes a perimeter sub-network as a logical gateway network between the unsecure Internet and the fully secure NPAC/SMS network.  The perimeter network is formed using two firewall routers which employ IP packet filtering and other mechanisms to control the types of allowed traffic into and out of the perimeter network.  The sole node on the perimeter network is a UNIX-based server acting as a dedicated bastion host server to mediate services between the Internet and NPAC/SMS.  The bastion host is treated as a semi-secure host, acting as a mail gateway, ftp server, public web server, and proxy server for explicitly allowed services.  The use of a bastion host to eliminate direct TCP/IP communications with any host within the NPAC/SMS network, in addition to controls on the perimeter sub-network, ensures full security within the NPAC/SMS by eliminating all known security threats.

The public web server operating on the bastion host can be used to electronically publish NPAC/SMS related information to service providers regarding upcoming NPAC/SMS events, schedules, operating status, changes to network data (e.g., new NXXs opened for porting), and any other broadcast data

158

desired.  This, in addition to faxes and E-mail, enable the NPAC/SMS to cost effectively provide timely information to service providers.

159

HIGHLIGHTS

•Standardized, fully regionalized, Lockheed Martin NPAC SMS application software offers the highest level of deployment credibility and the lowest risk of functional/performance deficiencies

•NPAC SMS solution is readily extensible due to its building-block structure using available com-ponents

•Key layered software components (CMIP tools) and technologies sourced from within the Lockheed Martin Team for assured support and ongoing enhancement

•Proven third party COTS software products: e.g., Oracle RDBMS

•Standards-based, open architecture facilitates cost effective application expansion

2.1.3NPAC Service Management System Application Software

Planning for the potential growth associated with number portability and number administration requires vision and a flexible design.  The Lockheed Martin Team’s vision is to successfully perform at the leading edge of business and technology.  The Lockheed Martin Team’s proven track record of successful, leading-edge telecommunications project implementation is the foundation of the vision.  The Team’s vision for the NPAC SMS application is detailed in this section.

The NPAC SMS functional design consists of two primary components: NPAC SMS application and the NPAC Operational GUI (OpGUI) available to authorize internal and external users.  The two NPAC SMS components represent a blend of:

•Proven, tested, and deployed commercially available off-the-shelf (COTS) telecommunications software products developed by Lockheed Martin Team members (ESI, DSET).

160

•Proven, mission-critical grade, third-party software products to complement the Team-sourced platform software products.  Some of these include:

•Oracle RDBMS

•Open Market secure web server product

•HP OpenView network management product

•PowerLogin Security Management software

•V-One’s SmartWall smartcard authenticator and Internet firewall product

•Security Dynamics ACE/Server smartcard authentication server

•RSA Certificate Issuing System (CIS) integrated security management system

•RSA BSAFE Development Toolkit security application development product.

•NPAC SMS-specific application software and process rules to be developed by ESI.

Implementing the NPAC SMS on a foundation of existing software minimizes overall cost, lowers project risk, and decreases implementation time.

2.1.3.1  NPAC SMS Application Architecture

The following components, illustrated in Exhibit 2.1-13, deliver the NPAC SMS application functionality:

•Protocol Adapters

•Processing Environment:

161

•Work Flow Manager

•Timer Manager

•PDEs

•Datastore (Oracle)

These components and their inter-workings are detailed in the sections below.

2.1.3.1.1 Protocol Adapters

Protocol adapters provide an open interface between the NPAC SMS application external systems and the transaction processing back-end implemented within ESI’s BACE environment.  The NPAC SMS supports three primary protocols:

•CMIP for communication between the NPAC SMS application and the service provider’s Local SMS (LSMS) and Service Order Administration (SOA) systems.  CMIP is also used to manage the NPAC SMS application itself, along with those WAN and LAN nodes with instrumentation that requires CMIP to communicate with the Network Management System (NMS).

•HTTPS (HyperText Transfer Protocol Secure) is also supported to provide a secure user interface for both internal and external NPAC users that leverages a common, readily extensible GUI environment for all non-mechanized interfaces.

•SNMP for the management of WAN and LAN nodes with instrumentation that requires SNMP to communicate with the Network Management System (NMS).

The BACE Protocol Adapters receive secure, encrypted data from external systems.  The protocol adapters convert the external message into the BACE standard internal message format, which is

162

delivered to the work flow manager for processing.  When processing is complete, the work flow manager sends the BACE standard internal message back to the protocol adapters for conversion to the protocol appropriate for communicating with the external systems.

2.1.3.1.2  Basic Application Creation Environment (BACE)

Use of BACE enables the Lockheed Martin Team to leverage existing, proven, standards-based software to provide a state-of-the-art NPAC SMS within the timeframes requested by NYCAC.

The key component of the proposed NPAC SMS is ESI’s Basic Application Creation Environment (BACE) software.  BACE is a library of telecommunications-specific software developed and implemented for the telecommunications industry.  ESI has a proven track record of implementing high-availability, high-capacity telecommunications systems using BACE.

Through years of developing telecommunications-specific software, ESI discovered that software components for the industry are often shared between multiple applications.  Even though the use of those components varied slightly from application to application and customer to customer, there was a common foundation for each component.  ESI developed BACE as a means to leverage the commonality of the components and define the rules used to implement the variations of the components on a case-by-case basis.  Examples of these components are:

•Telecommunications components in the switching network, such as Service Management Systems (SMSs), Service Switching Points (SSPs), Service Control Points (SCPs), Service Transfer Points (STPs), and Intelligent Peripherals (IPS).

163

•Components representing records or messages, such as usage records, control messages, and work orders.

ESI also uses BACE as a means to leverage the use of development and run-time tools.  BACE includes generic tools that can be used in a wide variety of applications, serving many different purposes.  The idea of a tool is that it is not specific to one task, but can be reused in many instances by using different sets of data or a different tool configuration.  BACE includes ESI-developed software integrated with layered third party COTS software.  Some examples of BACE tools are:

•A high level language and associated compiler, run time environment, for defining rules-based process flows describing application-specific behavior of lower-layer C++-coded primitive components.

•Datastore tools supporting access to different types of data storage, including relational and object oriented databases, file systems, and shared memory, in a manner independent of the actual storage modality.

•Common services tools providing security, object persistence, version control and reporting.

•Access tools providing open access for front-end processes (the protocol adapters) to the BACE processing components.

164

The back-end transaction processing portion of the NPAC SMS application implemented using BACE will comply with the following standards:

•Transport:

•DCE

•Network Management

•X.7nn

•SNMP

•CMIP

•Interoperability

•COSE 1170

•Database Access

•ANSI SQL, ODBC

•Programming Languages

•ANSI C, C++

2.1.3.1.3  Work Flow Manager

The BACE Work Flow Manager is used to manage the NPAC SMS application run-time environment.  This includes starting processes in a specific order at initialization time, monitoring the health of executing processes, restarting failed processes, and starting new processes to address application load requirements.  The work flow manager mediates processing and information requests from external systems by allocating work requests between PDEs.

165

2.1.3.1.4  Timer Manager

The ability to configure the timer manager provides the ability to support time sensitive tunable parameters in the NPAC SMS application.

The BACE Timer Manager is a run-time component capable of tracking large numbers of application timers and providing input into other application processes requiring time management and tracking.  The timer manager will be used to handle pre-scheduled events such as housekeeping and periodic audits.  The timer manager is capable of tracking and managing intervals of time between predefined events.  It provides the ability to ensure events take place within a predetermined time frame. For example, the timer manager ensures that the receipt of subscription transfer authorizations from both the old and new service providers occur within a given time frame.

2.1.3.1.5  Processing Descriptor Engines (PDEs)

The NPAC SMS application processes are implemented using BACE Processing Descriptor Engines (PDEs).  PDEs are implemented in object oriented C++ code.  PDEs perform the underlying processing steps or primitives that are used to express the rules-based processing flow of transactions.  The work flow manager dispatches PDEs as it interprets and executes the processing rules that describe the steps into which transactions are decomposed.  The PDE objects receive data and parameters from other application components, perform the required processing, and return the requested data and parameters to the appropriate objects.  The work flow manager controls PDE processing in conjunction with the timer manager.  The primary NPAC SMS PDEs are:

•Security

•Auditing

•Subscription Administration

•Service Provider Data Administration

166

•Network Data Administration

•Network Synchronization

•Reporting

•Billing

•Logging

•Housekeeping.

2.1.3.1.6  Datastore

BACE provides open connectivity to data storage mechanisms such as relational and object oriented data bases, file systems and shared memory.  Although the NPAC SMS application supports any standard datastore interface (ANSI SQL), the Lockheed Martin Team is proposing the use of ORACLE RDBMS.  The ORACLE products provide a suite of telecommunications datastore and analysis tools that fully complement the BACE and COTS software used in the proposed NPAC SMS application.

2.1.3.2  NPAC SMS Operational GUI (OpGUI)

The NPAC OpGUI features:

•Open, non-proprietary, standards-based GUI technology (HTTP + SSL).

•Readily and economically available GUI client software for users.

•Reduces software development requirements on SOA front-ends

•Secure access

•Flexible design

167

•Intuitive user interface

•On-line help

•Consistent presentation style

•Ease of navigation

•Data entry type checking.

The proposed NPAC OpGUI will significantly reduce the amount of software development required to implement NPAC SMS and SOA interfaces.

The guiding principles for the design of the proposed NPAC SMS OpGUI are flexibility and security.  The Lockheed Martin Team proposes to implement the NPAC SMS OpGUI using the flexibility afforded by worldwide web browser/server technology.  The NPAC OpGUI based on a client web browser will derive functionality from the secure NPAC SMS web server.  Open Market Secure WebServer runs on the NPAC SMS server and provides the front-end HTTPS (secure web) protocol handling with client browsers accessible from the NPAC network.  Coupled with BACE interface modules, operations from submitted to the web server are translated into a standard canonical format and forwarded into the BACE transaction processing system for actual execution.  The web-based GUI environment shares are common back-end transaction processing engine (BACE) as is used by the CMIP-based mechanized interfaces.  This ensures consistency and commonality in all operations, security, processes, and maintenance, independent of whether functions are invoked manually and via mechanized interface.

168

2.1.3.2.1  NPAC SMS Operational GUI Secure Access

Access to the proposed NPAC OpGUI is fully secured via a perimeter network firewall architecture and end-to-end smartcard access.  A user is authorized after a successful logon to the system using the window shown in Exhibit 2.1-14.  Application security logic and OpenMarket’s secure web server HTTPS facilitate dynamic configuration of the NPAC OpGUI based on the user’s security privileges.

This allows the NPAC OpGUI to enforce security and access requirements for predefined audiences.  Access privileges are defined and controlled by the NPAC OpGUI for the following user groups:

•Service Providers

169

•User Support Services (Customer Help Desk)

•Administrative Services and Facilities

•System and Software Support Group

•Quality Assurance and Control Group.

For an in-depth discussion of NPAC SMS security, please refer to Section 2.7, Security.

2.1.3.2.2 NPAC SMS Operational GUI Flexible Design

As previously referenced in the security overview, control of the presentation and configuration of the NPAC SMS Operations GUI is implemented at the WebServer.  This implementation facilitates graceful NPAC SMS design changes because the web browser will automatically pick up any recent design changes each time the user visits the NPAC SMS website.  This eliminates the need for distribution of updated user interface software to the service providers after design changes.

2.1.3.2.3  Intuitive User Interface

The users of the SMS will be able to effectively use the NPAC OpGUI because it conforms to existing standards and conventions for event-driven windows interfaces.  The standards and conventions are implemented after careful human factors engineering.  The intuitive user interface will decrease learning curves and lower training expenses.

The NPAC OpGUI is designed to present users with informational and error dialogue boxes when appropriate.  The dialogues present concise information indicating problem resolution when applicable.  This will augment the user’s ability to understand and correct problems.

170

The dialogue messages will be stored in the database and loaded into the SMS at run-time.  This minimizes the effort required to release new executables when error text modifications are desired.

2.1.3.2.4  On-Line Help

Application on-line help will be provided to the user at the following levels of depth:

•Context sensitive help (data field descriptions, constraints, examples)

•Window specific help

•System level help

•On-line user guide

•Functional procedural help (proposed future enhancement)

•Error “fix-it” facility (proposed as future enhancement).

The “Help” dialogue text displayed by the NPAC OpGUI will be loaded at run-time from the database.  This will provide for quick modifications to the help text and minimize releases.

171

2.1.3.2.5  Consistent Presentation Style

A consistent and standard presentation theme will be implemented.  This will aid in the user’s ability to use the NPAC OpGUI based on presentation style and standards.  The following presentation standards will be used for all window implementations:

•Unique background colors for required/non-required data fields

•Fast keys/hot keys

•Standard push button and menu sizes as appropriate

•Standard text fonts and size

•Data commonality presented in frames or groupings.

2.1.3.2.6  Ease Of Navigation

The window navigation will be aided with menu bars, toolbars and hypertext links.  The toolbar will provide the standard Netscape navigation (back, forward, home).  The menu options will be coded with “fast keys” to provide a more direct navigational path.  Navigating between data fields will be supported using tabbing orders.  Tabbing order will be left to right, top to bottom.

The NPAC OpGUI main control window will provide hypertext links for window navigation as shown in Exhibit 2.1-15.  The data is organized and presented based on user actions (i.e. Query, View).  The window configuration will be dynamically driven and created based on the authorized users’ login permissions.

172

When the user selects a hypertext label from the main control window (i.e. * Service Provider), the appropriate window will be displayed.  The NPAC OpGUI limits navigation to three levels below the main control window.  This allows inexperienced users to use the GUI without becoming “lost.”

2.1.3.2.7  Data Entry Validation

When appropriate, data entry fields will validate entries as entered.  For example, no characters will be permitted in a TN field.  The data fields will also be checked for length restrictions.

2.1.3.2.8  NPAC SMS Operational GUI Functionality.

The NPAC OpGUI will run on a wide variety of PCs and workstations via an appropriate web browser supporting the HTTPS standard (e.g., Netscape Navigator).  Authorized NPAC users will have the ability

173

to enter, modify, and manage SMS data.  The GUI will provide interfaces supporting the following data administration requirements:

•Queries

174

•Service provider data administration

•Subscription version administration

•Security administration

•Auditing administration

•Reporting administration

•NPAC network data administration

•Billing and resource accounting.

Query Functionality

The NPAC OpGUI will provide authorized users with the ability to query for NPAC SMS information such as subscription data, service provider data, service data, audit data and reports.  The query windows will be the focal point for locating, retrieving, viewing and modifying data.  Access to information is controlled by the user’s security privileges and enforced by the NPAC OpGUI.

Service Provider Data Administration Functionality

The NPAC SMS Operation GUI will provide a user interface for internal NPAC personnel to perform service provider data administration.  This will enable the authorized user to create, modify and configure service provider data.  This also includes mass updates, such as NPA splits and network data.

Security Administration Functionality

The NPAC SMS operation GUI will provide an internal user interface for security administration.  An authorized user will be able to configure group and user security permissions, maintaining encryption key information.

175

Subscription Version Data Administration Functionality

The NPAC OpGUI will provide a user interface for subscription version data administration.  This will enable an authorized user to create, modify, activate, disconnect, cancel, and query subscription versions associated with a service provider.  The authorized user will also have conflict resolution capabilities.

The NPAC OpGUI provides the capability of managing mass changes associated with subscription data.  This capability exceeds the RFP requirements allowing changes across a range of TNs.

Auditing Functionality

The NPAC OpGUI provides a user-friendly, intuitive interface for audit administration.  The NPAC SMS auditing capabilities are designed to keep routing information in the network synchronized.  The NPAC OpGUI allows authorized users to:

•Define and execute audits

•Define templates for repeated, periodic audits

•Query audit results, audit templates, and audit status.

Reporting Functionality

The proposed NPAC SMS contains a extensive library of predefined reports supporting the NPAC system and business requirements.  The NPAC OpGUI allows authorized users to:

•Schedule the generation of reports

•Reprint reports

•Select output devices for report destinations

•Define new reports

176

NPAC Data Administration Functionality

The NPAC OpGUI will provide a user interface for NPAC data administration.  This will enable an authorized user to create and alter system and application tunables.  Mass changes to network data associated with service providers (i.e.  NPA Splits, LRN, LIDB, Class DPC) will also be simplified through the NPAC OpGUI.

Billing Functionality

NPAC OpGUI billing and resource accounting functionality is a subset of the NPAC SMS reporting capabilities.

2.1.4   NPAC Operations

Lockheed Martin IMS is the only neutral third-party supplier with proven experience in the management and administration of a portable number database, ensuring timely and evenhanded service for all NPAC users.

The Continuum Series models xx18H and xx28H (e.g., 418H, 428H, 818H, 828H, etc.) are the latest addition to the Continuum Family, and feature the 180MHz PA-8000 microprocessor, representing a 4x increase in CPU performance over the 96 MHz PA-7100 processor.  In addition, a 4x increase memory capacity is available, up to 2GB of RAM can be supported.  The xx18H models feature one pair of duplex 180MHz PA-8000 CPU boards (one logical CPU), and the xx28H models feature two pairs of duplex 180MHz PA-8000 CPUs (two logical CPUs).  For a comparison of the specifications and relative performance of the Continuum Series Family, see Exhibits 2.1-7 and 2.1-8.  Note the Lockheed Martin NPAC SMS platform is based on the Continuum 428H system (2 x PA-8000).

177

Lockheed Martin IMS has been successfully managing the 800 NASC for the 800 Service Industry for nearly three years. In this capacity, we are responsible for the operational support services and administration required by users of the SMS/800 database.  The parallels between the service requirements for 800 portability and NPAC operations are striking.  Through our work as the 800 NASC and our current work for the Illinois NPAC/SMS, we have an in-depth understanding of the duties, services, and responsibilities required to operate the NPAC on behalf of NYCAC for the State of New York and, when desired, the surrounding region.

NPAC Operational Relationships

The NPAC is essential to the smooth operation of local number portability in a complex and evolving environment, interfacing and communicating with several different types of customers, systems, and external constituents.  Exhibit 2.1-16shows the users and constituents that the NPAC SMS supports.  In support of these entities, the NPAC must contain the diverse set of communications facilities shown in Exhibit 2.1-17, including facilities for supporting verbal and automated requests from NYCAC carriers and several ways to distribute information and reports, such as faxes, E-mail, and a public web-based bulletin board.  In short, we understand the clientele of the NPAC and the required system and facilities infrastructure required to provide superior NPAC services.

NPAC Service Components

Our response provides a comprehensive and responsive solution for the operation of the NPAC, as the neutral third party vendor.  Our technical and operational solution meets or exceeds all NPAC operations requirements.  The key components of our proposed NPAC service are illustrated in Exhibit 2.1-18.

178

The Lockheed Martin Team’s service approach results in levels of customer satisfaction that meet or exceed client expectations.  Our NPAC will operate in an open and ethical manner at all times, protecting and preserving the security of customer data.  These principles will be incorporated in the operation of the NPAC.  We track NPAC performance against built-in quality assurance standards and audits and feedback from NPAC users  and  the  NYCAC.   Our  management  approach  for  the  NPAC  has  proven successful many times over and incorporates a Management Review Committee comprising the Lockheed Martin Team’s senior company officials.

179

NPAC Service Requirements

NPAC service requirements fall naturally into a small number of functional areas that are associated with specific organizational groups in Lockheed Martin IMS’ NPAC organization.  NPAC function areas include:

Operational Functions

While the NPAC/SMS RFP has suggested that NPAC responsibilities be distributed among three distinct areas — System Administration, User Support, and System Support — we propose an enhanced functional organization structure that is based upon the successful 800 NASC model.  Our proposed NPAC functional organization is shown in Exhibit 2.1-19.

180

Our functional organization facilitates the managing of interfaces associated with the NPAC/SMS, improves internal communications and accountability, and ensures the highest level of responsive and evenhanded service to all NPAC users.

Management Review Committee

Our functional organization includes a Management Review Committee which is comprised of senior executives from both Lockheed Martin IMS and Evolving Systems, Incorporated to provide additional management oversight and periodic review of NPAC operational performance.

NPAC Director

The NPAC/SMS contract will be serviced within our Communications Industry Services line of business. The director of the NPAC, Ms. Audrey Herrel, will report directly to Joseph Franlin, Chief Operating Officer of CIS, who reports directly to Jeffrey Ganek, Senior Vice President and Managing Director of Communications  Industry  Services.

The NPAC director’s function includes responsibility for the following:

•Client relations

•Performance goals

•Day-to-day operations

•Industry satisfaction

•NPAC/SMS management.

181

User Support Services Group

The User Support Services group is the core business of the NPAC.  It ensures that the users are able to use the NPAC SMS system effectively to establish ported number records and obtain provisioning.  This group is the focal point for all NPAC SMS problem resolution. User support services’ functions include:

•User problem resolution

•User access assistance

•Scheduled system unavailability notification

•Service and network data table administration

•Mass change administration

•Software acceptance/new release testing

•New software release notification.

System and Software Support Group

System and software support functionality is focused on the creation and maintenance of an effective operational environment for NPAC operations and on resolving or coordinating resolution of all user or NPAC SMS problems pertaining to system availability or technical communications problems. This group is responsible for three functional areas, which include:

•Primary Data Center, Network Control Center, and Disaster Recovery Backup Operations:

•Data links and WAN service provider access monitoring

•IP switches monitoring

•Dial-up access support

•IP switches configuration and administration

•Backup/Disaster Recovery processor operations

•Backup/Disaster Recovery processor administration

182

•Backup/Disaster Recovery testing support.

•NPAC SMS Administration and Operations:

•Logon ID administration, password and security access code assignment

•Customer record security, access, input and modification assistance

•NPAC SMS service data table administration

•Server (Stratus) administration

•Production control (process scheduling, tape management, report distribution)

•NPAC PBX administration

•LINCSS trouble shooting and administration

•NPAC workstation administration

•Local SMS download monitoring

•NPAC SMS interface link monitoring and testing

•Software acceptance/new release testing support.

•Level 2 software support:

•NPAC SMS problem analysis and resolution

•NPAC SMS maintenance and enhancements

•NPAC SMS software acceptance/new release testing support

•Commercial off the shelf software support and testing.

Administrative Services and Facilities Group

The Administrative Services and Facilities Group encompasses the following tasks required to run the NPAC:

183

•Secretarial, clerical, administrative support, and office management services

•Human Resources

•Purchasing, leasing for NPAC internal operations

•Facility management

•Accounts payable and receivable

•Billing and adjustments.

Training and Documentation Services Group

Effective training in the operation and use of the NPAC SMS system and in NPAC services is a key factor in the acceptance of the NPAC by the Local Number Portability service community.  Therefore, we will provide:

•Training curriculum development

•Training material development in accordance with users’ needs

•Training delivery to NPAC users and internal staff

•Course schedules and registration information

•User training and documentation feedback

•Documentation inventory

•Documentation request processing and distribution, including Local Number Portability Guidelines

•NPAC SMS documentation issuance

•Software acceptance/new release training support.

184

Quality Assurance and Control Group

The establishment of a vigorous, effective Quality Assurance and Control Group is a key element of our proposal and is of vital importance to the success of the NPAC. Specific functions that are addressed by this group are:

•NPAC operations evenhandedness

•NPAC SMS system and NPAC operation performance standards development

•Reporting and analysis of quality performance

•NPAC SMS software acceptance testing, software release certification, and production system cut-over coordination

•Quality assurance programs and procedures development

•Quality assurance training

•Process improvement

•Change control

•Backup/Disaster Recovery processor testing and reporting

•Procedures and documentation review.

2.1.5   Risks, Responsiveness, Deficiencies, and Improvements

The Lockheed Martin Team is uniquely experienced and qualified to manage schedule risks, perform thorough requirements analysis, and recommend cost reductions within the spirit of the requirements.

As requested in RFP Section 1.4.3.2 (pg. 16), the following sections address:

(1) All areas that result in a potentially high degree of risk

(2) All areas that impose an unusually high degree of responsiveness, and

185

(3) Areas that are deficient and that could be improved.

The specifics regarding each of these issues are discussed as they occur in our proposal response to the RFP requirements.  The discussion below serves to summarize those issues and the way in which our proposal addresses or mitigates them.

The NYCAC’s RFP Evaluation/Procurement Team is to be commended for their work in defining the NPAC/SMS requirements in this RFP.  We take no exception to the requirements, but do recommend improvements or refinements in a few places.

2.1.5.1   Risks

The fundamental area of potentially high risk is regarding the overall deployment and turn-up schedule for the NPAC/SMS.  While the Lockheed Martin Team is uniquely suited to satisfy the commendably aggressive time frames requested in the RFP, we have extensively refined the proposed implementation schedule and testing plans to ensure that the key NPAC/SMS milestones can be achieved in the time frames desired by the NYCAC.  Recognizing that Lockheed Martin’s NPAC SMS development activities are well underway for deployment in support of the Illinois LNP LLC region, the primary schedule issues for the NYCAC are testing and the corresponding deployment schedules for Local SMS/SOA deployment by the initial participating service providers.  Key schedule dates are: start of service provider integration (turn-up) testing and limited operations on May 15, 1997 and start of full (live) operations on October 1, 1997.  However, this schedule relies on certain key dependencies that are appropriate to highlight as potential schedule risks.  They are:

1.Timely resolution of business contract issues leading to firm contract execution.  Given the nature of this procurement and LNP in general, there is an understandable level of uncertainty regarding potential contract terms, conditions, and structure and composition of the contracting entity

186

(NYCAC), and future regulatory activities.  In demonstration of our sincere commitment to this opportunity and to the industry, the Lockheed Martin Team has already started preparations for early deployment of the NPAC/SMS, as evidenced by the detail of our proposal.  To minimize risk to the schedule, we propose that a binding instrument (e.g., binding MOU/LOI) be executed shortly after selection with the NYCAC to reduce the Team’s cost exposure while continuing in good faith to meet the initial schedule.  We respectfully request that the NYCAC consider issuing a Letter of Intent (LOI) on or about January 2, 1997.

2.Timely specifications approval and signoff.  To ensure timely review, comments, and approval of project documentation (functional, interface, testing, etc.) we propose to conduct these activities in a to-be-formed NY NPAC Operations Committee and an NY NPAC SMS Mechanized Interface Support Committee to provide representation as a group for all interested companies.  We intend to deliver project specifications and documentation in advance of committed dates in the schedule, but will require timely NYCAC turn-around and approval to keep to the schedule.

3.Mechanized system availability for system-to-system testing.  Start of system-to-system testing (on 5/15/97) requires that SOA and LSMS systems supporting the mechanized interfaces be deployed and operational in at least one service provider’s network.  To reduce risk in the interoperability of these systems, DSET will make available interface interoperability certification testing services to system vendors or service providers (further described in Section 2.0.2.1.10) to formally pre-test interoperability of the interfaces in a testbed environment.  Completion of IIS conformance certification testing will be a mandatory requirement for all interconnecting NPAC users.

187

2.1.5.2   Areas of High Responsiveness

The Lockheed Martin NPAC/SMS service offering meets or exceeds all of the NYCAC RFP requirements.  Consequently, we do not feel there are any areas that require an unusually or inappropriately high level of responsiveness.  In several areas, such as disaster recovery and hardware platform availability, we felt that significantly exceeding the requirements was the prudent and ultimately cost-efficient approach given the inherently critical nature of the NPAC/SMS service to its users.

One important point to note within the spirit of this section, is the suitability of the volume projections supplied in requirement R10-17.  We understand the essential need for the NPAC/SMS to scale to handle the volumes and number of service providers/users indicated, and unambiguously have committed to serving those volumes and beyond as may be required.  Consequently, R10-17 has been used to drive both NPAC SMS system sizing as well as is expected to be the basis for evaluating and comparing total NPAC/SMS service bid costs

However, we understand that the actual experienced NPAC/SMS volume will be dictated by a number of factors, including: the number of service providers/users who have decided to participate in LNP, become an NPAC user, and deploy LSMS/SOA systems, including IIS certification testing; the schedule of opening central offices for porting by the incumbent LECs (NYNEX and Rochester Telephone) in the initial MSAs; and the rate at which service providers initially will be able to market, accept and process service orders for ports, which will also be affected by the rate at which service providers will be able process service orders amongst themselves.

The proposal states that the annual transaction estimates provided in R10-17 “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” (RFP p. 74).  We propose that the NYCAC and Lockheed Martin IMS jointly determine an appropriate rollout plan for the growth of NPAC/SMS services taking these factors into

188

consideration.  And we propose using such a plan to drive both NPAC/SMS capacity expansion as well as LSMS/SOA deployment schedules for participating service providers.

2.1.5.3   Deficiencies and Improvements

The following details areas where we recommend refining the NPAC SMS implementation to minimize costs and maximize efficiencies:

1.Requirements R7-107 through R7-109: we will support the encryption key management mechanism requested in these requirements, but do recommend a more efficient and equally secure PKCS key management mechanisms be used instead.  These mechanisms are a being adopted as standards within other areas in the telecommunications industry for security, for example, in CDPD, and provides for a much less costly means of performed key management that benefits service providers directly as well as the NPAC.

2.Requirements R5-26, R5-35, R5-51, R5-62, and R5-69: These require that SOAs need only specify the subscription TN attribute value to identify the specific subscription version/record (subscriptionVersionNPAC object instance) intended.  While this does off-load the SOAs from having to retain the version ID (record ID) of the latest instantiated subscriptionVersionNPAC object, it does cause a minor additional amount of work on the NPAC SMS to search for the latest version based on the TN value for each operation.  Additionally, if an SOA system does note the version ID (record ID) for versions it is involved in creating (acting as either old or new service providers), then it may reference that subscriptionVersionNPAC instance specifically by name (TN + version ID) for subsequent operations (e.g., M-SET directly to the subscriptionVersionNPAC in lieu of sending a modify action to the lnpSubscriptions container object).  This streamlines the NPAC SMS operation where SP SOA systems can support it.  In either case, both modes of reference

189

(indirect via the container, or direct to the version instance) are supported.  The functionality for both object reference modes is defined in the IIS.

3.NPAC SMS Interface CMISE Transaction Throughput: There has been much discussion within the industry concerning the necessary CMISE transaction throughput required for the NPAC SMS.  Currently, per requirements R6-24 and R6-25, NYCAC requires one (1) CMISE transaction per second per service provider SOA and Local SMS interface association.  However, from NYCAC’s answer to bidder question Q12, there also appears to be a business requirement to support a peak transaction rate of 25 ported numbers downloaded per second to each Local SMS interface association.  This throughput rate is also required for NPAC SMS systems in other jurisdictions:  specifically, the Illinois LNP LCC, MCAC (Mid Atlantic Region), and West Coast Region to name a few.

Using some additional assumptions that are widely supported within the industry —
1) 20% of all activations will occur using a range of numbers, and 2) the average number of ported TNs in a range activation is 20 — the result is a throughput requirement of 5.2 CMISE transactions per Local SMS interface association.  In addition, other jurisdictions require a throughput rate of two CMISE transactions per second for each SOA interface association.

Together, these derived CMISE requirements mean that the NPAC SMS must support a sustained load of 7.2 (SOA + LSMS) CMISE operations per second per service provider (uploader), and 5.2 CMISE operations per second (ops or tps) for each user (downloader).  Thus, the initial 10 service providers represent a system total of 72 CMIP operations per second, for an aggregate download rate of 250 TNs per second (25 to each of 10 service providers).  The derived interface performance requirements due to the aggregate number of ported numbers and service providers drive the overall

190

system throughput requirements, not the number of transactions identified in requirement R10-17. Our proposed NPAC SMS will support these higher, widely supported CMISE requirements as well as the transaction rates in R10-17.  In addition, our NPAC SMS architecture can readily scale to provide the CMISE throughput required to support 50 or more service providers.

4.Service Provider Network Data: Our information model design in the IIS enables service providers to query and, within reason, update their network data.  Mass network data updates will not be supported through the mechanized interfaces.  While this information is available via the LERG and LARG, these databases are not always timely.  It is important that the NPAC SMS network data view of a service provider’s network be current to avoid improperly invalidating a subscription version operation due to stale data.

5.NPAC Regionalization: As indicated in Requirement R6-27, the RFP requires the NPAC SMS to filter/screen broadcasts to service provider Local SMS associations on an NPA-NXX basis.  This allows service providers, for a local SMS association, to specify for which NPA-NXXs they would like to receive downloads.  We will completely support this requirement by adding screening tables within the NPAC SMS for linking service providers to NPA-NXXs for downloading purposes.  Using these tables, the NPAC SMS will only send/resend downloads for a given NPA-NXX to the proper service provider local SMS associations.

From our participation in many industry forums and states’ workshops, we understand that regionalization of NPAC service should include additional functionality.  As a part of our standard NPAC SMS Release 2 software, which we will deploy for NYCAC, the following additional functionality to support regionalized NPAC services will be provided:

191

•Establishment of portability areas (NPA-NXX groupings, such as a LATA or MSA) to validate service provider access and arrangements to port numbers for a given NPA-NXX

•Establishment of state-specific tunable parameters to allow timing and feature functionality to differ/vary by state within a regional NPAC to satisfy potential regulatory differences

•Performance of cost reapportionment and billing on a state basis to allow for different cost recovery methods employed or mandated by state regulatory agencies, if applicable

•Provision of screens and reports on portability area and state basis

•Provision of administrative utilities, screens, and reports to establish and maintain portability area to NPA-NXX and NPA-NXX to service provider Local SMS download association linkages.

1.NPAC Organizational Structure:  As described in proposal Section 12.1, we have reorganized the NPAC operations roles and responsibilities, as defined in RFP Section 12, to fit more logically into an NPAC organizational structure that reflects the required staff’s roles, responsibilities, and skill-sets.  This reflects our in-depth and unique experience in building and operating an NPAC-like operation.  A table mapping of the RFP-defined roles and responsibilities (RFP requirements) into the proposal NPAC organizational structure (proposal response) is provided in proposal Section 12.1 to facilitate requirements compliance verification.

192

NYCAC NPAC/SMS PROPOSAL 2.2  Business Process Flows

HIGHLIGHTS

•Thorough understanding of LNP, including business process flows, enables NPAC/SMS implementation to be seamlessly integrated within the broader framework of LNP deployment in New York and the region

•NPAC/SMS business process flows are managed in a manner that ensures error-free operation and tight coordination among the service providers

•Business process flow implementation is cost effective and of the highest quality

•Process flow procedures reflect a “need-to-be-involved” policy, minimizing NPAC involvement in inter-company processes and preventing unnecessary costs and overhead

•The NPAC/SMS design maintains flexibility in business process flows, allowing evolution of processes over time and recognizing the embryonic nature of LNP operation

2.2BUSINESS PROCESS FLOWS (RFP Sect. 2)

The Lockheed Martin Team, due to our extensive involvement and commitment to LNP as well as experience in number administration, thoroughly understands the business processes the NPAC/SMS must support for effective deployment of LNP.

Our operating experience and participation in LNP throughout the industry has ensured our clear understanding of NPAC/SMS’ mission and support of number portability in a competitive environment.  We are sensitive to the requirements of the service providers and their need to balance rigorous, error-free processing with low cost and minimal overhead.

Provision service processing is the primary activity of the NPAC/SMS.  The NPAC role is to ensure that prior to enabling the new service provider (SP) to activate the routing change, the new and old SPs must validate a number port, i.e., an LNP routing database change.  In changing facilities-based service providers, the nature of the service provider number portability (SPNP) makes inter-company coordination of manual wiring and switch provisioning changes necessary to change the serving switch of an end-user.  Consequently, inter-company communication to facilitate coordination and scheduling of these activities is required to support SPNP.  Due to this direct inter-company coordination, the provisioning process flows implemented by the NPAC permit, as required by

193

the RFP, involvement by the NPAC/SMS.  Their involvement, which is limited to the extent required, is essential to validate a number porting service order (subscription) prior to enabling the associated LNP routing change to be broadcast to LNP-participating service providers when the manual change-over is completed.

Because of the manual wiring and switch provisioning changes required by both SPs and inherent in SPNP, it is possible that an end-user may experience some service disruption while the associated wiring and provisioning changes are being made.  For business end-users who have substantial facilities and complex service arrangements, this cut-over process is likely to be labor-intensive and require tight coordination between the old and new service providers.  Upon completing the manual cut-over activities, the NPAC/SMS will, upon request of craft personnel at the new SP, activate the subscription, i.e., broadcast the LNP routing change to enable incoming calls to be routed correctly to the new SP’s switch now serving the end-user.  Upon receipt of the activation request, the NPAC/SMS becomes the critical path to restoring inbound calls to the end-user.  For this reason, the real-time performance and reliability of the NPAC/SMS to broadcast the associated routing change to all LNP-participating service providers is crucial to restoring full service to the end-user.  It is also essential that data consistency be maintained to ensure that the activation/broadcast process is error-free.  If the NPAC SMS were unable to complete the activation process, it would be necessary to:  1)  undo the manual cut-over process and resume service with the old SP switch, or 2) manually place the necessary LNP routing updates in all participating service providers.  This is a costly and disruptive impact.

Exhibit 2.2-1illustrates the nominal case of the provisioning flow followed by successful cut-over and activation, where the SPs, both new and old, correctly authorize the subscription.   The time axis in this chart is non linear — the time from initial end-user request to start of cut-over may take days or weeks,

194

whereas the time from activation request received at the NPAC/SMS to completion of the LSMS broadcast normally takes less than one second.

The Lockheed Martin Team has an in-depth understanding of the business process flows for the NPAC/SMS and the underlying familiarity with LNP required to work cooperatively with the service providers to operate the NPAC/SMS.  In LNP workshops throughout the states, as well as through our now-completed functional requirements definition process with the service providers in the Illinois SMS and Operations Committee, we have participated in the ongoing development and refinement of the LNP business process flows.  They are reflected in the IIS, which incorporate these flows into the CMISE operations and information attributes for NPAC interfaces, and the non-proprietary NPAC SMS Generic Functional Requirements Specification (FRS), both stemming from our work with the service providers in the Illinois LNP LLC region.  The rest of our Section 2.2 further describes these flows.  These flows form the basis for the core NPAC SMS functionality further described in Sections 2.3, 2.4, and 2.5.

The process flows supported by the NPAC/SMS are grouped into the following categories:

•Service Provisioning

•Service Disconnection

•Service Repair

•Conflict and Conflict Resolution

•Disaster Recovery and Backup

•Service Order Cancellation

•Audit Requests

•Report Requests

•Data Administration Requests.

195

In addition to illustrating the overall business process flows, we provide specific flows for the NPAC/SMS-view of the processes.  The process steps in these flow exhibits are annotated to reference specific text sections below describing the process step being reference in the diagram.  Exhibit 2.2-2 provides a legend for the symbols used in these internal flow diagrams and an index of the processes described in the following sections.

[Graphic Omitted: Legend of NPAC Business flow sysmbols]

Exhibit 2.2-2.  Legend of NPAC Business Process Flows illustrates symbols used throughout the remainder of this section.

Some salient points to note in the current provisioning process are:

1.Either the old or new service provider (SP) may create its view of a new port service order (subscription version) at the NPAC SMS first.

2.If, after the first create from either SP has occurred, the other SP has not yet created/authorized its view of the order (subscription version) within a tunable interval (defaults to 18 hours) prior to the due date specified, it will be sent a notification requesting it to do so.

3.If, after a second tunable time-out period (defaults to 18 hours) has expired and the other SP has still not created its view of the subscription version, then the subscription version is either placed into conflict (if old SP did not respond), or is canceled (if new SP did not respond).  In either case, both SPs are notified of the change in the status (conflict or cancel) of the version.  The version no longer defaults to valid pending if the old SP does not authorize.

196

4.In its create action, the old SP may either explicitly authorize the version or may indicate lack of authorization, in which case the version is placed into a conflict state.

5.Unlike the old SP, the new SP does not have an explicit authorize field for the version.  If the new SP performs its create function on the NPAC SMS for the TN in question and provides all the mandatory fields, then concurrence with the port is implicit.

6.A version may be modified by either SP while in a pending or conflict state, and only by the new SP once active.  Only fields appropriate for the SP are modifiable (i.e., the old SP may modify due date but not routing fields).  Any changes in relevant fields (such as due date) in the version are reported to both SPs’ SOAs as notifications.

7.Any changes in the status of the subscription version (e.g., pending->sending, pending->conflict) are reported by the NPAC SMS to both SPs’ SOAs as a notification.  This includes any status changes (including creates) performed by NPAC personnel on an SP’s behalf.

8.Accepted modifications of an active version cause an immediate “download” of the changed attributes, which takes the form of CMISE modify (M-SET) operations from the NPAC SMS to LSMS interface.  Also similar to an initial activate, a download results report is provided back to the new SP’s SOA indicating the results of the download.

9.The “invalid” state has been removed as a subscription version status.  The NPAC SMS will not store a subscription version that would otherwise be in an invalid status.  See Section 2.5 for a more complete description of version status and the allowed state transitions.

197

10.While the old SP may now place a version into conflict via the SOA interface, either SP may also initiate a conflict-off process via their SOA interface.  This was viewed by the service providers as a preferable way deal with states involving potential transition to conflict than requiring manual contact to the NPAC to place and remove a version from conflict.

11.The conflict resolution and cancel processes require both SPs to approve the state transition before it is official.  Tunable acknowledgment time-outs in the NPAC SMS will send notifications to an SP’s SOA to solicit their acknowledgment.  If acknowledgment is not received within a second tunable interval, then the version returns to its prior status.

12.If a version is placed into conflict explicitly by the old SP through a create action with its authorize field set to false, the old SP must still set the authorize field to true (explicitly authorize the port) after the conflict status has been removed.  Upon exiting conflict state, the old SP’s authorization field is returned to its prior state.

13.Pending disconnect processing is now supported.  Disconnect requests for a version may now specify an effective date at which time the NPAC SMS will automatically initiate CMISE delete operations (a delete broadcast) to the LSMSs.  If the effective date is not specified on a disconnect request, it defaults to immediate disconnect.

14.A customer disconnect date parameter is required on a disconnect request from the SOA to the NPAC SMS.  This is the date at which time the customer was disconnected from its most recent service provider.  When the disconnect is broadcast by the NPAC SMS (at the effective date or immediately), this date is forwarded to the donor service provider’s SOA by a notification.  This

198

allows the donor service provider to consider the amount of time the last service provider provided treatment on the disconnected number in order to apply the appropriate aging interval before reassigning the vacant number.  Disconnected ported TNs are deleted from all LSMSs and not considered to be ported by the NPAC SMS.

2.2.1   Provision Service Process (RFP Sect. 2.1)

Provision process flow implementation provides a rigorous yet cost effective implementation to support timely and reliable number porting activities on behalf of the service providers.

The Lockheed Martin NPAC/SMS supports in its initial release both service provider number portability (SPNP) and location portability, presumed to be initially intra-rate center portability.  However the NPAC SMS does not validate rate center boundaries for location portability service orders, nor is there any special processing of end-user location fields (they are downloaded to LSMSs as provided in the record by the SOA).  To distinguish between the two types of portability service orders and process flows, there are two possible values for the LNP-type field in a subscription version: LSPP (local service provider portability) and LISP (local intra-service provider portability).  The process flows for LISP are a subset of those for LSPP, since in the former case the old and new service provider are the same.  As a consequence, and due to their importance, the process flow descriptions that follow will focus on SPNP (LSPP) solely.  It should be also be noted that since the LNP-type field currently has no significance at the LSMS and SCP level, there can only be one active subscription version for a TN at one time regardless of whether that version is LSPP or LISP.  Consequently, only one subscription version for a TN of either LNP-type (LSPP or LISP) can be in a pending state in the NPAC SMS.

The latest LNP business process flows for service provisioning of SPNP are illustrated in Exhibit 2.2-3, parts 1 & 2.  In the nominal case (the TN in question is not the first ported TN in an NXX, and the

199

involved end-offices are already LNP-capable, etc.), this process flow is expected to take three business days end-to-end.

On overview of the service provisioning flow activities from the NPAC SMS view are shown in Flow 2.1 (Exhibit 2.2-4), described more specifically below.

Subscription Version Creation Process

The Subscription Version creation flow activities are shown in Flow 2.1.2, Exhibit 2.2-5.

Create Subscription Version (Flow 2.1.2.1)

When a number is ported, both the old and new service providers must perform a version-create action to the NPAC SMS.  The NPAC validates the data for each create action and attempts to validate the create with a corresponding version created by the other service provider.  If a create-action is missing from either provider after a tunable time period, the NPAC sends a notification requesting the missing  create-action.  If the data provided with the create action is valid, the NPAC SMS creates a pending subscription version and awaits the concurring create.  If the data is invalid, the NPAC SMS reports a specific error to the sender, indicating the specific fields in error, and discards the request (invalid subscription versions are not created).

Request Missing/Late Notification (Flow 2.1.2.2)

If authorization is not received from the old SP after both time-out intervals, or if the old SP explicitly denies authorization, the process flows to 2.4 (Conflict).  If the new SP create is not received after both time-out intervals, the process flows to 2.6 (Cancel).

200

[Graphic Omitted: Flow chart of provisioning process]

Exhibit 2.2-4.  High-level Overview of Provision Process Flow.

[Graphic Omitted:  Flow chart of subscription version creation process]

Exhibit 2.2-5.  Flow 2.1.2: Subscription Version Creation Process.

Service Providers Perform Physical Changes

The two service providers involved in the number port will coordinate and perform the physical loop and switch translations changes to their respective networks.

NPAC SMS “Activate and Data Download” Process

The NPAC network data broadcast download flow is shown in Flow 2.1.4, Exhibit 2.2-6.

New Service Provider Sends Activation to NPAC SMS (Flow 2.1.4.1)

The new service provider sends an activate action to the NPAC SMS.

NPAC SMS Broadcasts Network Data to All Service Providers (Flow 2.1.4.2)

Upon receipt of the activation request, the NPAC SMS broadcasts the subscription version data download in real time to all service providers’ LSMSs.

Failure – Notify NPAC (Flow 2.1.4.3)

If the NPAC SMS does not receive positive acknowledgment of the download from an LSMS, the NPAC SMS will resend the download to the service providers that did not acknowledge the original broadcast.  The NPAC SMS will perform the rebroadcast a tunable number of times within a tunable time frame.

201

Initiate Repair Procedures (Flow 2.1.4.4)

If the tunable resend parameters have been exceeded, the NPAC staff will initiate repair processes with the appropriate service providers.  The NPAC SMS will send a list of failed service providers to both the old and new service providers.

[Graphic Omitted: Flow chart of activation and download process]

Exhibit 2.2-6.  Flow 2.1.4: Activation and Download Process.

Service Providers Updates Network Routing Information

Upon receiving the download from the NPAC SMS, all service providers’ LSMSs will confirm the receipt of the download broadcast and update their network elements.  The involved service providers may also test their network changes.

2.2.2   Disconnect Process (RFP Sect. 2.2)

The Lockheed Martin’s Team NPAC SMS provides full support for the disconnect/aging process, and has the flexibility to modify this process over time should future public policy changes affect it.

This process flow defines the activities associated with the discontinuance of service for a ported number.  The disconnect business process flow is illustrated in Exhibit 2.2-7.  The NPAC disconnect service flow is shown in Flow 2.2,  Exhibit 2.2-8.

Customer Notification, Service Provider Initial Disconnect Service Order Activities (Flow 2.2.1)

When a ported number is being disconnected, the customer and service provider will agree on a date.  The service provider will send a disconnect action to the NPAC SMS indicating the date of the physical

202

disconnect of the number (customer disconnect date) and, optionally, the date that the disconnect information is to be broadcast to all local SMSs (the ‘effective release date’).

NPAC Waits for Effective Release Date (Flow 2.2.2)

The NPAC SMS will broadcast delete actions to the LSMSs at the effective release date specified by the service provider.  If no effective release date is specified on the disconnect request, the NPAC SMS processes the request immediately.

NPAC Performs Broadcast Download of Disconnect Data (Flow 2.2.3)

The NPAC SMS will broadcast the deletes to all LSMSs. If the broadcast is not acknowledged by all LSMSs, the disconnect information will be resent to those LSMSs not responding a tunable number of times within a tunable time frame. If the tunable parameters for the collection of responses have been exceeded, the NPAC staff will initiate repair processes with the appropriate service providers (Flow 2.3), and send a list of failed service providers to the service provider who requested the disconnect.  A notification is sent to the donor service provider’s SOA containing the customer disconnect date, so the donor service provider can apply the appropriate aging interval before reassigning the number.

[Graphic Omitted: Flow chart of disconnect process]

Exhibit 2.2-8.  Flow 2.2: Disconnect Process Flows at the NPAC SMS.

2.2.3   Conflict Resolution Process (RFP Sect. 2.3)

Our NPAC SMS facilitates conflict resolution with a minimum of NPAC involvement and cost while ensuring LNP database consistency.

203

The NPAC SMS does not provide actual conflict resolution between disputing service providers (SPs), but instead relies upon internal SP processes to resolve service disputes.  The NPAC SMS detects potential conflict scenarios through extensive data validation and automated management of the provisioning process flows.  A detected conflict results in automated notification to the SPs, thus ensuring minimal use of NPAC SMS resources and lower costs attributable to processing disputed service orders.

Once a conflict is detected by the NPAC SMS or initiated by either an old or new service provider, the NPAC SMS enables the subscription version in conflict to be queried and modified by both parties, as appropriate, and enables conflict resolution to be initiated via the SOA interface, thereby not requiring a manual contact to the NPAC.

The business process flows involving conflict are illustrated in Exhibit 2.2-9, parts 1 & 2.  The NPAC view of the conflict processes is illustrated in Exhibit 2.2-10 (Flow 2.4.1) and Exhibit 2.2-11 (Flow 2.4.3).

Subscription Version in Conflict (Flow 2.4.1)

Two different paths may cause the NPAC SMS to place a subscription version in conflict status: explicit service provider action, or NPAC SMS detected events, such as previous conflict resolution

[Graphic Omitted:  Flow chart of “conflict on” process]

Exhibit 2.2-10.  Flow 2.4.1: Conflict On Process at the NPAC SMS.

[Graphic Omitted: Flow chart of conflict resolution process]

Exhibit 2.2-11.  Flow 2.4.3: Conflict Resolution Process at the NPAC SMS.

204

acknowledgment not received (version returned back to conflict), or cancel acknowledgment not received (absence of confirmation to cancel version).

Change of Status Upon Problem Notification (Flow 2.4.1.1)

Conflict status “on” occurs for a subscription version when a service provider notifies NPAC SMS personnel of a disagreement between the new and old service providers as to whether or not a TN may be ported, or when the old service provider fails to respond to a request for concurrence, after time-out notifications.

Change of Status Upon Non-Concurrence (Flow 2.4.1.2)

Non-concurrence between service providers causes the NPAC SMS to place the subscription version in conflict during the “Create Version” process (Flow 2.1.2).

New Service Provider Coordinates Conflict Resolution Activities (Flow 2.4.2)

The new and old service providers use internal and inter-company processes to resolve the conflict. See Flow 2.4.3 (Exhibit 2.2-11) for a description of the conflict resolution process.

New Service Provider Notification of Conflict Resolution (Flow 2.4.3)

If less than 30 days [tunable parameter] have passed since the subscription version status was set to conflict “on” and a resolution was reached, either the old or new service provider will initiate the action to change the subscription version status to “Conflict Resolution Pending.” See Flow 2.4.3 for a description of the conflict resolution process.

205

Missing Conflict Resolution Concurrence Notification (Flow 2.4.4)

Once entering “Conflict Resolution Pending” status, the NPAC SMS sends a status change notification to both SP’s SOAs, and waits for concurrence notification from both service providers. If the conflict resolution concurrence is not received within four hours [tunable parameter], the NPAC SMS sends a request for the concurrence. If the conflict resolution concurrence is not received within four hours [tunable parameter] of the second notification, the NPAC SMS returns the subscription version status to “conflict.”

Subscription Version Cancellation (Flow 2.4.5)

Version Cancellation When Conflict Status “On” for 30 Days (Flow 2.4.5.1)

If the subscription version status has been set to conflict “on” for 30 days [tunable parameter] and no resolution has occurred, the NPAC SMS will cancel the subscription version, and notify both the old and new service providers of the cancellation.

Cancel Pending Notification (Flow 2.4.5.2)

If the subscription version is in conflict “on” and the new service provider requests to cancel the subscription version, the NPAC personnel will set the subscription version to cancel, and both service providers will be notified. (Flow 2.6).

Conflict Resolved (Flow 2.4.6)

When both service providers agree to resolve the conflict and have acknowledged the conflict resolution pending within the allowable time frame, the NPAC SMS will change the subscription version status to pending.  Both SPs’ SOAs are notified of the status change to pending upon successfully exiting the conflict resolution pending state.

206

2.2.4   Disaster Recovery and Backup Process (RFP Sect. 2.4)

Diverse, fully redundant NPAC/SMS service centers provide complete backup and disaster recovery capability.  They also provide backup cut-over in seconds with virtually no NPAC/SMS service disruption, far exceeding requirements in RFP Section 10 for availability.

Through the consistent application of network element-level standards for reliability, availability, and serviceability, the Lockheed Martin Team has succeeded in developing an NPAC/SMS solution that provides for virtually continuous availability.  Typical operational events, such as software and hardware upgrades, WAN upgrades, backups, archiving and purging, mass updates and NPA splits, might normally require some amount of NPAC SMS downtime.  Our solution is unique in allowing such activities to be conducted without necessarily causing NPAC/SMS service downtime.  In addition to there being no scheduled downtime, the Lockheed Martin NPAC/SMS service has the ability to survive any single and many types of multiple-point failures without causing NPAC/SMS service downtime or disruption.

The primary and backup NPAC/SMS service centers for the NYCAC region (Tarrytown and Chicago) are interconnected in such a way as to provide virtually real-time database replication to occur in both sites thereby allowing backup cut-over activities without disruption or downtime in seconds.

The design of our proposed NPAC SMS has been driven by our careful disaster recovery planning.  We considered three important factors in the design of the NPAC SMS:

•Risk mitigation

•Disaster recovery

•Cost.

207

The proposed NPAC SMS network topology consists of nationally diverse points-of-presence (POPs) interconnected by redundant, geographically diverse communications facilities.  This topology ensures a stable communication network unaffected by the largest unforeseen local and/or regional events.  In addition, each NPAC/SMS service center uses a redundant virtual LAN backbone, continuously available computing servers, and a real-time auto-replicating database to mitigate exposure to local risk.

The proposed solution facilitates the design, implementation, and testing of NPAC SMS disaster recovery processes far exceeding compliance with the RFP requirements.  Exhibit 2.2-12 illustrates several types of NPAC/SMS-related outages, our response strategy, and the expected restoration interval for that resource.  Note that most outages do not result in degradation to the NPAC or NPAC SMS.  Where degradation does occur, the restoration time interval refers to restoring the failed resource to return the NPAC SMS to full capacity well within 24 hours.

Possible NPAC SMS Outage Types and Corresponding System Resolution

Outage	Response	Restoration Time
CPU board failure in SMS server (Stratus)	Redundant component continues without disruption, failed board replaced while system on-line.	None
Disk failure in SMS server (Stratus)	Redundant component continues without disruption. Failed disk replaced while system on-line, system automatically mirrors new drive in background.	None
Power supply failure in SMS server (Stratus)	Redundant component continues without disruption. Failed power supply replaced while system on-line.	None
Fast ethernet port failure in SMS server (Stratus)	Redundant port provides uninterrupted connectivity (no TCP/IP circuits disrupted); failed component is replaced while system on-line.	None
Operating system failure in SMS server (Stratus)	If Unix-process related, the faulted process is automatically restarted; if kernel-level failure, Unix and SMS applications automatically restart, with transaction rollback/restart.	1-30 sec’s
Application software failure in SMS server (Stratus)	Failed process automatically restarted, error logged.	.5-1 sec
User workstation failure	User moves to alternate workstation while failed one is repaired/replaced. No loss of NPAC.	None for NPAC 2-10 min. for user.

208

Outage	Response	Restoration Time
LAN hub failure	LAN/WAN traffic automatically re-routed	None
WAN backbone link failure	WAN traffic automatically re-routed and/or dial-up backup (PRI-ISDN) established.	None
Service provider WAN link failure	Fallback to backup link (dial-up or dedicated).	0.01-15 sec’s
Tarrytown NPAC facility power failure	UPS with backup generator.	None
Tarrytown NPAC facility catastrophic failure	Cut-over to Chicago backup site; service provider links to Tarrytown POP revert to backup.	3-15 secs. – links <2 min. – SMS 1-48 hrs. – NPAC

Exhibit 2.2-12.  Sample NPAC outages and restoration intervals.

In the event of unplanned downtime or catastrophic failure of the primary NPAC SMS data center, cut-over of all interfaces to the backup site in Chicago occurs within a three-to-15 second interval, depending upon whether the NPAC WAN POPs in the affected service center are still available.  If not, the nature of the diverse and backup links to the service provider SOA and LSMS facilities.  For example, dial-up backup with ISDN would require approximately 3-5 seconds, whereas a V.34 analog modem connection would require approximately 7-15 seconds.  Cut-over and restoration of mechanized service with the NPAC SMS between the primary and backup data centers is extremely quick and virtually transparent to service provider systems.  Regardless of whether downtime is scheduled or unscheduled, the mechanized generic interface will automatically switch to the backup/disaster recovery machines within seconds greatly exceeding RFP requirements.  After the primary is back on line, these interfaces will be switched back.

The Lockheed Martin Team understands the scheduled downtime notification time frames in the RFP and will comply with all RFP specified notification procedures, methods, and time frames.

This process flow defines the backup and restore activities performed by the NPAC and the service providers.  The disaster recovery flow is shown in Flow 2.5, Exhibit 2.2-13.

209

2.2.4.1  NPAC Personnel Determine System Downtime Required (Flow 2.5.1)

If there is planned NPAC SMS downtime at the primary service center, the NPAC SMS will send an electronic notification to the service providers’ 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.  In virtually all circumstances of NPAC SMS system downtime, the backup NPAC/SMS will be used to provide access to the NPAC/SMS service until access to the primary is resumed.  Since the cut-over to backup usually takes several seconds, there is no effective NPAC/SMS service downtime in case of NPAC SMS system downtime.

If there is unplanned NPAC SMS downtime at the primary service center, the NPAC will assess how long the primary machine will be down. The NPAC will notify all of the service providers by electronic notification and telephone calls to the service providers’ contact numbers. The notification will describe the situation and the planned action.  The standard association establishment process documented in the IIS for the NPAC SMS interface enables service provider systems (LSMS and SOA) to attempt to associate to the backup machine any time an outage of the primary system is suspected.  The backup system will only accept association establishment attempts if a cut-over has occurred and it is acting as the live system.  This process ensures that the service providers LSMS and SOAs will attempt to switch

210

[Graphic Omitted:  Flow chart of disaster recovery process]

Exhibit 2.2-13.  Flow 2.5: Disaster Recovery Process illustrates that downtime of the primary NPAC SMS system does not constitute service downtime.

to the backup NPAC in case of unplanned NPAC SMS system downtime, and will again virtually eliminate any NPAC/SMS service downtime.

NPAC Notifies Service Providers of Switch to Backup NPAC and Start of Cut-over Quiet Period (Flow 2.5.2)

The NPAC service providers will switch to the backup or disaster recovery machine as indicated in the notification.

Service Providers Connect to Backup NPAC (Flow 2.5.3)

The service providers’ systems establish associations with the backup NPAC SMS system.  The network routers in both the NPAC WAN POPs and the service providers’ networks will route traffic to the backup NPAC SMS system along the most optimal route available.  If there is none, the routers will initiate dial-up or Internet backup connections to the NPAC WAN.  The process of obtaining a route for connecting to the backup NPAC SMS is transparent to both service providers’ systems and the NPAC SMS systems.

Backup NPAC Notifies Service Providers of Application Availability and End of Cut-over Quiet Period (Flow 2.5.4)

When the backup NPAC SMS system is prepared to act as primary, processes will proceed as normal.  Association establishment attempts from service provider systems will be accepted and normal NPAC SMS processing will resume.  Standard association establishment processes defined in the IIS cause the service provider systems and the NPAC SMS to re-synchronize their object trees (persistent object storage models) to resolve any ambiguities in which transactions were processed had the backup cut-over been the result of unplanned system downtime.

211

Service Providers Conduct Business Using Backup NPAC (Flow 2.5.5)

Service providers continue to process as normal when connected to the backup NPAC SMS.  If a service provider does use internal processes to request updates to LSMSs while waiting to be able to send them to the backup machine, the service provider will still resend the updates when the backup NPAC can begin processing them to ensure that every service provider and the NPAC SMS receive the update.

Backup NPAC Notifies Service Providers of Switch to Primary NPAC and Start of Cut-over Quiet Period (Flow 2.5.6)

When the primary machine is brought back up, the backup NPAC SMS will advise the service providers of the timing of their switch back to the primary machine.  At this time, the backup NPAC SMS will stop taking updates.  After the interface associations have quiesced, the associations are dropped by the NPAC SMS with a cause condition indicating that association re-establishment to the primary NPAC SMS system should be attempted.

Service Providers Reconnect to Primary NPAC (Flow 2.5.7)

The service providers re-establish associations with the primary NPAC application using their normal connections.  These associations will be accepted when the primary NPAC SMS is ready to resume on-line.

Primary NPAC Notifies Service Providers of Availability and End of Cut-over Quiet Period (Flow 2.5.8)

When the primary NPAC SMS is available and begins accepting associations, NPAC personnel will notify service providers of the end of the cut-over quiet period.

212

2.2.5   Repair Service

Our NPAC SMS provides extensive auditing, logging, reporting, and history file capabilities to assist in fault isolation and resolution.

Although not identified in Section 2.2 of the RFP, repair service flows will be required to repair service to the customer.  Given the potential connection between the repair processes and NPAC SMS Repair Audits (Type I), we have taken the liberty to discuss the current repair flows in Illinois.  Extensive facilities are provided to assist in fault isolation and resolution in support of the repair process.  Ad hoc reports, data consistency/validation checks, auditing, logging, and history file capabilities enable the NPAC to assist service providers in fault isolation and service restoration.  Automated transaction queuing and data consistency facilities minimize the service disruption caused by failure of the service provider’s system.

The repair business process flow is illustrated in Exhibit 2.2-14.  This repair flow is currently being refined in several states, including Georgia.  The NPAC repair service flow is shown in Flow 2.3, Exhibit 2.2-15.  This process flow defines the activities performed when a problem is detected by the NPAC SMS, a service provider, or a customer who contacts a service provider.

Repair process steps that do not involve the NPAC include:

•Service provider receives problem notification from customer (Flow 2.3.1-A)

•Service provider receives problem notification from another Service Provider (Flow 2.3.1-B)

•Service provider receives problem notification from NPAC SMS (Flow 2.3.1-C)

•Service provider analyzes the problem (Flow 2.3.2)

•Service provider performs repairs (Flow 2.3.3).

213

[Graphic Omitted:  Flow chart of SMS repair process]

Exhibit 2.2-15.  Flow 2.3: Repair Process Flow involving the NPAC SMS.

Request Broadcast of Repaired Data (Flow 2.3.4)

Audit capabilities in the NPAC SMS are used to aid in isolating problems.  A service provider may request a download of data to assist in the repair process, if necessary.

Broadcast Repaired Subscription Data (Flow 2.3.5)

If inaccurate routing data is found, the NPAC SMS will broadcast the correct data to any involved service provider’s networks to correct inaccuracies.

2.2.6  Service Order Cancellation Process

Exhibit 2.2-16 illustrates the business process flow for canceling a pending subscription version.  This flow defines the process performed when a service provider cancels a service order.  The service order cancellation flow is shown from the NPAC view in Flow 2.6, Exhibit 2.2-17.

Service Provider Issues Service Order Cancellation (Flow 2.6.1)

From the time a service provider sends notification of a new subscription version to the time the subscription version is activated, either service provider may send a message to the NPAC SMS to cancel the subscription version. If this occurs, the NPAC SMS will notify both service providers that the subscription version is in a cancel-pending state.

214

NPAC Requests Missing Acknowledgment from Service Provider (Flow 2.6.2)

When notified that a subscription version has been set to cancel-pending, both service providers must concur by returning a cancel-pending acknowledgment to the NPAC SMS within 18 hours [tunable parameter]. If the NPAC does not receive acknowledgment in the allowable time from one of the service providers, a request is sent to that service provider for a cancel-pending-acknowledgment.

[Graphic Omitted:  Flow chart of cancellation process]

Exhibit 2.2-17.  Flow 2.6: Cancellation Process Flow at the NPAC SMS.

215

If the missing cancel-pending-acknowledgment is not received within a tunable time frame, the subscription version status is set to “conflict.”  Both service providers are then notified that the subscription version status is now “conflict.”

NPAC Cancels the Subscription Version and Notifies both Service Providers (Flow 2.6.3)

When acknowledgment is received from both service providers within the allowed time frame, the NPAC SMS will set the subscription version to be canceled in its database and notify both service providers that the subscription version has been canceled.  All canceled subscription versions are purged from the NPAC database after a tunable period.

216

HIGHLIGHTS

•Lockheed Martin NPAC SMS features an enhanced logical data model to provide support for “regionalization” – supporting a multi-state region from a common NPAC/SMS

•New regional functionality includes: state-indexed tunable parameters, validation of users and processes within a portability area, and definition of portability areas (LATAs or MSAs) using NPA-NXXs

•Service providers may administer their network (NXX and LRN) and contact data directly through their SOA, LSMS, or the NPAC Operational GUI

•Automatic data downloading to local SMSs reduces support costs and ensures timely data dissemination and data integrity

•User-friendly graphical interfaces are provided for data administration and manipulation to reduce training and support costs

2.3NPAC DATA ADMINISTRATION (RFP Sect. 3)

The Lockheed Martin NPAC SMS features an enhanced logical data model to provide support for “regionalization” – supporting a multi-state region from a common NPAC/SMS.

2.3.1   Overview (RFP Sect. 3.1)

Key to the NPAC SMS’ ability to properly administer an LNP database is a sound logical data model for the different types of information required by the NPAC SMS to perform the services expected by its customers.  In addition to primary data on ported numbers (called subscription versions), the Lockheed Martin NPAC SMS maintains data related to the NPAC customers using the NPAC/SMS service (service providers and users) and the network data relevant to the portability areas that NPAC SMS serves.  Data describing an NPAC customer is called “NPAC customer data” or “service provider data.” Data describing the network data for a portability area is called “network data.”  For purposes of our proposal, the term “NPAC customer” is synonymous with both the terms “NPAC/SMS user” and “service provider.”  These terms all mean a NPAC/SMS customer who receives broadcasts of service data over an NPAC/SMS to LSMS Interface and/or provisions ported numbers via SOA access.

217

The Lockheed Martin Team has further developed the NPAC SMS logical data model to incorporate additional requirements that have been identified to support multi-state regional functionality.  These requirements have not yet been captured in the G-FRS and IIS documentation processes in the Illinois NPAC SMS committee, which has focused on an initial NPAC SMS Release 1 to support Chicago LATA 358 commensurate with timeframes in FCC Order 96-286, which mandates completion of live LNP testing there by August 30, 1997.  In support of the FCC timetables for LNP deployment in other MSAs in the Ameritech region, a subsequent NPAC SMS release (Release 2) will be deployed in 3Q97 that enables support of the entire region from the Chicago NPAC/SMS service center.  We propose to deploy the NYCAC with Release 2 at the outset.  Consequently, the NPAC SMS logical data model discussed in this section is based on NPAC SMS Release 2.

This section provides an overview of the external logical data model implemented in the Lockheed Martin NPAC SMS for data representation.  Various internal tables are also maintained to support various aspects of NPAC/SMS operations, such as tables for authorized login ids, security access control lists, and service element interpretation and rating information.  The external logical data model is broken into the following logical groups:

•Service Data.  Global tunable parameters referenced in the execution of NPAC SMS processes.  In support of regionalization, these parameters may be indexed by state to accommodate state-by-state variations of these tunable parameters should this be required.  For example, the Initial Concurrence Window parameter, which defaults to 18 hours, could be overridden in another state to a different value (e.g., 24 hours instead of 18) should local regulators require.  State-by-state variations of these parameters would only be appropriate where they do not affect service providers’ systems (LSMS or SOA)

218

•NPAC Customer Data.  (a.k.a. NPAC/SMS user or service provider data).  Data defining each NPAC customer, including, for example, their service provider ID (SPID), points-of-contact (POCs), allowed functions (uploader vs. downloader), portability areas (which areas this NPAC customer serves), and NPA-NXXs their LSMS for which they wish to receive downloads

•Subscription Data.  Data associated with a ported number (TN), through its lifecycle as a ported number from initial service order process through disconnection or porting back to donor switch

•Network Data.  Data describing the portability areas the NPAC SMS serves, including NPA-NXXs opened for porting, LRNs available for use by porting service providers, NPA-NXXs comprising distinct portability areas, and their relationships to service providers.

A high-level entity relationship diagram of these logical data tables is illustrated in Exhibit 2.3-1.  The sections that follow describe each of these four areas in detail.

Exhibit 2.3-2 provides a legend of the logical data model types referenced in the data tables.

[Graphic Omitted:  NPAC data model]

219

Exhibit 2.3-1.  High-Level Entity Relationship Diagram of NPAC SMS Logical Data Model

DATA TYPE LEGEND

Data Type	Description
Address	Network Address: raw binary data stored as unformatted bytes.
B	Boolean (True or False) indicator.
C	Character or Alphanumeric strings.
E	Enumeration.
M	Bit Mask comprised of one or more bytes.
N	Numeric data. (up to 32 bit integer, numeric data that can be arithmetically manipulated).
N(x)	Character string of “x” digits only.
T	Timestamp: month, day, year, hour, minute, and seconds.
TN	Telephone Number: 3-digit NPA, 3-digit NXX, 4-digit Station Number.

Exhibit 2.3-2.  Legend of Data Types for Logical Data Tables

2.3.1.1   Service Data (RFP Sect. 3.1.1)

Exhibit 2.3-3 illustrates the Service Data Table containing the global parameter data for LNP service support.  This table is further grouped by logical function.

Exhibit 2.3-3.  Tunable Parameters

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Initial Concurrence Window	SP_Initial_Concurrence_Window	18	hours	1-72
The hours prior to the final concurrence window at which time a notification is sent to the service provider who has not yet performed their subscription version create. [R5-21]
Final Concurrence Window	SP_Final_Concurrence_Window	18	hours	1-72
The hours prior to the due date in the subscription version at which time a second notification is sent to the service provider who has not yet performed their subscription version create. [R5-21]
Conflict Expiration Window	SV_Conflict_Cancellation_Window	30	days	1-180
The length of time conflict subscriptions will remain in the conflict state before cancellation. [R5-45]
Maximum Subscriber Query	Max_Subscriber_Query	50	record	10-150
The maximum number of active subscription versions returned by a query to the NPAC. [R4-30]
Pending Subscription Retention	Pending_SV_Cancellation	90	days	1-180
The length of time pending subscriptions will remain in the pending state before cancellation. [R5-23]

220

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Conflict Resolution-Initial Concurrence Window	Conflict_Resolution_Initial_Ack_Window	4	hours	1-72
The number of hours after the version is set to conflict resolution pending by which both service providers are expected to acknowledge the conflict resolution.
Conflict Resolution-Final Concurrence Window	Conflict_Resolution_Final_Ack_Window	4	hours	1-72
The number of hours after the second conflict resolution pending notification is sent, by which both service providers are expected to acknowledge the conflict resolution.
Cancellation-Initial Concurrence Window	Cancellation_Initial_Ack_Window	4	hours	1-72
The numbers of hours after the version is set to cancel pending by which both service providers are expected to acknowledge the pending cancellation.
Cancellation-Final Concurrence Window	Cancellation_Final_Ack_Window	4	hours	1-72
The number of hours after the second cancel pending notification is sent by which both service providers are expected to acknowledge the pending cancellation.
Old Subscription Retention	Purge_Old_SV	18	month	1-36
The length of time old subscriptions will be retained. [R5-2]
Cancel-Pending Subscription Retention	Purge_Canceled_Pending_SV	90	days	1-360
The length of time canceled subscriptions, with last status of pending, will be retained. [R5-3]
Cancel-Conflict Subscription Retention	Purge_Canceled_Conflict_SV	30	days	1-360
The length of time canceled subscriptions, with last status of conflict, will be retained. [R5-3]
Cancel-Conflict Resolution Pending Retention	Purge_Canceled_Conflict_Resolution_Pending_SV	30	days	1-360
The length of time canceled subscriptions, with last status of conflict resolution pending, will be retained.
Cancel-Disconnect Pending Retention	Purge_Canceled_Disconnect_Pending_SV	90	days	1-360
The length of time canceled subscriptions, with last status of disconnect pending, will be retained.

221

Subscription Tunables

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Subscription Activation Retry Attempts	Subscription_Version_Activation_Retry	3	attempts	1-10
The number of times a new subscription version will be sent to a Local SMS which has not acknowledged receipt of the activation request. [R5-60]
Subscription Activation Retry Interval	Subscription_Version_Activation_Retry_Interval	2	minutes	1-60
The delay between sending new Subscription Versions to a Local SMS that has not acknowledged receipt of the activation request. [R5-60]
Subscription Modification Retry Attempts	Subscription_Version_Modification_Retry	3	attempts	1-10
The number of times a modified active subscription version will be sent to a Local SMS which has not acknowledged receipt of the modification request.
Subscription Modification Retry Interval	Subscription_Version_Modifica-tion_Retry_Interval	2	minutes	1-60
The delay between sending modified active subscription versions to a Local SMS that has not acknowledged receipt of the modification request.
Subscription Disconnect Retry Attempts	Subscription_Version_Disconnect_Retry	3	attempts	1-10
The number of times the NPAC SMS will resend a subscription disconnect message to an unresponsive Local SMS. [R5-68]
Subscription Disconnect Retry Interval	Subscription_Version_Disconnect_Retry_Interval	2	minutes	1-60
The amount of time that shall elapse between subscription disconnect retries. [R5-68]
Local SMS Retry Attempts	LSMS_Retry_Attempts	3	attempts	1-10
The default number of times the NPAC SMS will resend a message to an unresponsive Local SMS.
Local SMS Retry Interval	LSMS_Retry_Interval	2	minutes	1-60
The default delay between sending messages to an unresponsive Local SMS.
SOA Retry Attempts	SOA_Retry_Attempts	3	attempts	1-10
The default number of times the NPAC SMS will resend a message to an unresponsive SOA.
SOA Retry Interval	SOA_Retry_Interval	2	minutes	1-60
The default delay between sending messages to an unresponsive SOA.
Failed Login Attempts	Failed_Login_Attempts	3	attempts	0-10
The number of allowable incorrect logon attempts
Failed Login Shutdown Period	Failed_Login_Shutdown_Period	60	seconds	0-300
The amount of time the NPAC SMS will wait to restart the logon process after a user has exceeded the Failed_Login_Attempts tunable.
Unused User Id Disable Period	Unused_User_Id_Disable_Period	60	days	1-360
The number of days for which a userid has not been used before the NPAC SMS disables that userid.

222

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Password Age Limit	Password_Age_Limit	90	days	1-360
The amount of time for password aging.
Password Expiration Notice	Password_Expiration_Notice	7	days	1-30
The amount of time prior to a password expiring that the NPAC SMS will notify a user.
Post Expiration Logins	Post_Expiration_Logins	2	logins	0-10
The number of logins a user is permitted after the user’s password has expired.
Password Reuse Limit	Password_Reuse_Limit	6	months	1-36
The amount of time in which a password cannot be reused.
Record Logons After Failure	Record_Logons_After_Failure	10	attempts	0-100
The threshold for consecutive failed logon attempts after which logon attempts will be recorded in the audit log.
Non-Use Disconnect	Non_Use_Disconnect	60	minutes	1-1440
The amount of idle (non-use) time before the NPAC SMS will disconnect a user’s logon session.

Communications Tunables

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Maximum Subscriber Query/Audit	Maximum_Subscriber_Query_Audit	50	SVs	1-200
The maximum number of active subscription versions that may be returned in a query operation, either for the purposes of querying a subscription version database or for performing an audit of those subscription versions. [R8-2]
Audit Response Time	Audit_Response_Time	30	seconds	1-300
The length of time allowed before recording in the audit results all local SMSs that have not responded to an audit.
Canceled Audit Retention Period	Canceled_Audit_Retention_Period	30	days	1-360
The length of time canceled audits will be retained.
Data Integrity Sample Size	Data_Integrity_Sample_Size	1000	SVs	1-5000
The number of active subscription versions in a sample to be monitored by the NPAC SMS.

223

Audit Tunables

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Local SMS Activation Log Retention Period	Local_SMS_Activation_Log_Duration	90	days	1-360
The number of days Local SMS activation responses will remain in the log.
Audit Log Retention Period	Audit_Log_Retention_Period	90	days	1-360
The length of time audit logs will be retained.
Error Log Retention Period	Error_Log_Retention_Period	90	days	1-360
The length of time system error logs will be retained.
History File Data Storage	History_File_Data_Storage	90	days	1-360
The length of time history logs will be retained.
Usage Log Retention	Usage_Log_Retention	90	days	1-360
The length of time usage logs will be retained.

Logs Tunables

Tunable Name	Tunable Variable Name	Default Value	Units	Valid Range
Key Change Interval	Key_Change_Interval	7	days	1-365
How often the key is changed automatically.
Re-verification Acknowledgment Period	Re-verification_Acknowledgment_Period	3	days	0-30
The maximum number of days allowed for the re-verification acknowledgment period.

Security Keys Tunables

2.3.1.2   Service Provider Data (RFP Sect. 3.1.2)

Service Providers may administer their network (NXX and LRN) and contact data directly through their SOA, LSMS, or the NPAC Operational GUI.

The Service Provider Data Table definitions are shown in Exhibits 2.3-4, 2.3-5 and 2.3-6.  Note that the portable NPA-NXX, LRN,  encryption key, and key encryption key data related to the service provider are specified in tables defined in Section 2.3.1.3 “Network Data.”

224

NPAC Customer Data contains information about NPAC customers participating in LNP in one of more of the portability areas served by the NPAC/SMS.

225

NPAC Customer Data Table

Attribute Name	Type (Size)	Description
NPAC Customer ID	C (4)	SPID: An alphanumeric code that uniquely identifies an NPAC customer.
NPAC Customer Name	C (40)	A unique NPAC Customer Name.
NPAC Customer Type	C (1)	An alphanumeric that indicates the type of NPAC customer. Valid values are: •     Facilities-Based •     Non Facilities-Based
NPAC Customer Allowable Functions	M	Each bit in the mask represents a Boolean indicator for the following functional options: •     SOA Management •     SOA Network Data Management •     LSMS Network Data Management •     LSMS Data Download •     LSMS Queries/Audits
NPAC Customer Download	M	Each bit in the mask represents a Boolean indicator for the following download options: •     Download Network Data
Portability Area Serviced	N x m	List of portability area IDs serviced by the NPAC customer, identifying portability areas where it’s able to participate in SOA subscription version operations (create, etc.)
Audits Accepted (Optional)	C (4) x M	List of SPIDs from whom this NPAC Customer will accept on-demand audits.

Exhibit 2.3-4.  NPAC Customer Data Table

226

NPAC Customer Contact Data Table

Attribute Name	Type (Size)	Description
NPAC Customer Contact ID	N	A unique sequential number assigned upon creation of the Contact record.
NPAC Customer ID	C (4)	SPID: An alphanumeric code which uniquely identifies an NPAC Customer.
Contact Type	C (2)	The type of NPAC Customer Contact Organization.  Valid values are: •BI - Billing. •CF - Conflict Resolution Interface. •LI - Local SMS Interface. •NC - NPAC Customer. •NF - Network and Communications Facilities Interface. •OP - Operations. •RE - Repair Center Contact Organization. •SE - Security. •SI - SOA System Interface. •UA - User Administration. •WI - Web Interface.
Contact	C (40)	Name of NPAC Customer Contact Organization.
Contact Address Line 1	C (40)	Contact Organization address Line 1.
Contact Address Line 2	C (40)	Contact Organization address Line 2.
Contact City	C (20)	Contact Organization city.
Contact State	C (2)	Contact Organization state.
Contact Zip	C (9)	Contact Organization zip code or postal code.
Contact Country	C (2)	Contact Organization country.
Contact Province	C (2)	Contact Organization province.
Contact Portability Area ID	N (-)	List of portability area IDs Contact covers. If absent, defaults to all covered by NPAC customer.
Contact Phone	TN	Contact Organization phone number.
Contact Fax	TN	Contact Organization Fax phone number.
Contact Pager	TN	Contact Organization Pager phone number.
Contact Pager PIN	C (10)	Contact Organization Pager Personal Identification Number (PIN).
Contact E-mail	C (60)	Contact Organization E-mail address.

Exhibit 2.3-5.  NPAC Customer Contact Data Table

227

NPAC Customer Network Address Data Table

Attribute Name	Type (Size)	Description
NPAC Customer Network Address ID	N	A unique sequential number assigned upon creation of the Network Address record.
NPAC Customer ID	C (4)	An alphanumeric code which uniquely identifies an NPAC Customer.
Network Address Type	C (1)	Type of Network Address. Valid values are: •S - SOA interface •L - Local SMS interface.
NSAP Address	Address (20)	OSI Network Service Access Point Address
TSAP Address	Address (4)	OSI Transport Service Access Point Address.
SSAP Address	Address (4)	OSI Session Service Access Point Address.
PSAP Address	Address (4)	OSI Presentation Service Access Point Address.
Internet Address	Address (12)	Internet address of the Service Provider Web interface.

Exhibit 2.3-6.  NPAC Customer Network Address Data Table

228

2.3.1.3   Subscription Data (RFP Sect. 3.1.3)

The Subscription Data Table definition shown in Exhibit 2.3-7 defines the subscription data for a ported TN.

Subscription Version Data Table

Attribute Name	Type (Size)	Description
Version ID	N	A unique sequential number assigned upon creation of the Subscription Version.
LRN	TN	The LRN is an identifier for the switch on which portable NPA-NXXs reside.
Old Service Provider ID	C (4)	Old Service Provider ID.
New Service Provider ID	C (4)	New Service Provider ID.
TN	TN	Subscription Version telephone number.
Local Number Portability Type	E	Number Portability Type. Valid enumerated values are: •     LSPP - Local Service Provider Portability (0) •     LISP - Local Intra-Service Provider Portability (1)
Status	E	Status of the Subscription Version. The default value is P for Pending. Valid enumerated values are: •     X - Conflict (0) •     A - Active (1) •     P - Pending (2) •     S - Sending (3) •     F - Failed (4) •     PF - Partial Failure (5) •     CR - Conflict Resolution Pending (6) •     DP - Disconnect Pending (7) •     O - Old (8) •     C - Canceled (9) •     CP - Cancel Pending (10)
CLASS DPC	N (9)	DPC for 10-digit GTT for CLASS features.

Exhibit 2.3-7. Subscription Version Data Table

229

Attribute Name	Type (Size)	Description
CLASS SSN	N (3)	CLASS SSN for the Subscription Version.
LIDB DPC	N (9)	DPC for 10-digit GTT for LIDB features.
LIDB SSN	N (3)	LIDB SSN for the Subscription Version.
CNAM DPC	N (9)	DPC for 10-digit GTT for CNAM features.
CNAM SSN	N (3)	CNAM SSN for the Subscription Version.
ISVM DPC	N (9)	DPC for 10-digit GTT for ISVM features.
ISVM SSN	N (3)	ISVM SSN for the Subscription Version.
New Service Provider Due Date	T	The due date planned by the new Service Provider for: •     Subscription Version Transfer of Service or •     Modification of a pending Subscription Version.
Old Service Provider Due Date	T	The due date planned by the old Service Provider for: •     Subscription Version Transfer of Service or •     Modification of a pending Subscription Version.
Old Service Provider Authorization	B	A Boolean indicator set by the old Service Provider to indicate authorization or denial of Transfer of Service for the Subscription Version to the new Service Provider.
New Service Provider Create Time Stamp	T	The date and time that the New Service Provider authorized Transfer of Service of the Subscription Version.
Old Service Provider Authorization Time Stamp	T	The date and time that the old Service Provider authorized Transfer of Service for the Subscription Version.
Activation Request Time Stamp	T	The date and time that the Subscription Version activation request was made by the new Service Provider.
Activation Broadcast Date	T	The date and time that broadcasting began to all local SMS systems for the activation of the Subscription Version.
Activation Broadcast Complete Time Stamp	T	The date and time that all Local SMS systems successfully acknowledged activating the Subscription Version.
Disconnect Request Time Stamp	T	The date and time that the Subscription Version disconnect request was made by the local Service Provider.
Disconnect Broadcast Time Stamp	T	The date and time that broadcasting began to all local SMS systems for the disconnect of the Subscription Version.

230

Attribute Name	Type (Size)	Description
Disconnect Broadcast Complete Time Stamp	T	The date and time that all Local SMS systems successfully acknowledged disconnecting the Subscription Version.
Effective Release Date	T	The date that the Subscription Version is to be disconnected from all Local SMS systems.
Customer Disconnect Date	T	The date that the Customer’s service was disconnected.
Pre-Cancellation Status	E	Status of the Subscription Version prior to cancellation. Valid enumerated values are: •     X - Conflict (0) •     P - Pending (2) •     CR - Conflict Resolution Pending (6) •     DP - Disconnect Pending (7)
Old Service Provider Cancellation Time Stamp	T	The date and time that the Old Service Provider acknowledged that the Subscription Version be canceled.
New Service Provider Cancellation Time Stamp	T	The date and time that the New Service Provider acknowledged that the Subscription Version be canceled.
Cancellation Time Stamp	T	The date and time that the Subscription Version became canceled.
Old Time Stamp	T	The date and time that the Subscription Version became old.
Conflict Time Stamp	T	The date and time that the Subscription Version was placed in conflict.
Conflict Resolution Pending Time Stamp	T	The data and time that the Subscription Version was placed in conflict resolution pending.
Old Service Provider Conflict Resolution Time Stamp	T	The date and time that the Old Service Provider acknowledged the resolution of a Subscription Version in conflict.
New Service Provider Conflict Resolution Time Stamp	T	The date and time that the New Service Provider acknowledged the resolution of a Subscription Version in conflict.

231

Attribute Name	Type (Size)	Description
Create Time Stamp	T	The date and time that this Subscription Version record was created.
Modified Time Stamp	T	The date and time that this Subscription Version record was last modified. The default value is the Create Time Stamp.
Porting to Original	B	A Boolean that indicates whether the Subscription Version created is to be ported back to the original Service Provider. The default value is False.
End User Location Value	C (12)	For future use. These attribute is unedited, and is downloaded as provided in the create.
End User Location Value Type	C (2)	For future use. These attribute is unedited, and is downloaded as provided in the create.
Modify Request Timestamp	T	The date and time that the Subscription Version Modify request was made.
Modify Broadcast Timestamp	T	The date and time that broadcasting began to all local SMS systems for the modification of the Subscription Version.
Modify Broadcast Complete Timestamp	T	The date and time that all local SMS systems successfully acknowledged modifying the Subscription Version.
Billing ID	C (4)	For future use. The default value is the Facilities Based Service Provider ID (NPAC Customer ID).

2.3.1.4   Data Used for Validation (RFP Sect. 3.1.4)

Exhibits 2.3-8, 2.3-9, and 2.3-10 illustrate the primary network data tables.  Note that NPA-NXXs are associated with a portability area, which is defined in a separate table.  Service provider contacts may also be portability-area specific.  Certain NPAC customers may also provide service only to a subset of the portability areas subtended by the NPAC/SMS, in which case the list of portability areas they do service is contained in the NPAC customer record.

232

A portability area consists of a list of the NPA-NXXs considered to be in that area.  Each portability area is defined in the Portability Area Table, along with a location (city) name, LATA number if appropriate, and state name for reporting purposes.

Each NPA-NXX contains a list of the LSMSs that want to receive downloads (create, modifies, deletes) for TNs in that NPA-NXX.  This list is consulted to determine the potential LSMSs to receive a download.  Those LSMSs in the list who have active download associations established with the NPAC SMS will receive the download for a TN in that NPA-NXX.  These fields are used to implement the download routing/filtering capability needed for regionalization, and indicated in requirement R6-27.

Portable NPA-NXX Data Table

Attribute Name	Type (Size)	Description
NPA-NXX Id	N	A unique sequential number assigned upon creation of the NPA-NXX record.
NPA-NXX	N (6)	The NPA-NXX open for porting.
NPAC Customer ID	C (4)	SPID (NPAC customer ID) of the donor network.
NPA-NXX Effective Date	T	The date that the NPA-NXX is available for LNP in the NPAC Customer networks.
Split new NPA-NXX	N (6)	The new NPA-NXX for an NPA-NXX split.
Split Activation Date	T	The date that the new NPA-NXX becomes available for use in an NPA-NXX split. This date represents the beginning of the permissive dialing period.
Split Disconnect Date	T	The data that the old NPA-NXX becomes unavailable for use in an NPA-NXX split. This date represents the end of the permissive dialing period.
NPA-NXX First-use Notification Sent	B	A Boolean that indicates if the first-use notification has already been sent for this NPA-NXX. When the first subscription version for an NPA-NXX has entered a staple pending state (both SPs have concurred), a notification is sent to all SOAs as a heads-up message. [R3-14] The default value is false (notification not yet sent).
Portability Area ID	N	Portability area this NPA-NXX is considered a part of.

Exhibit 2.3-8. Portable NPA-NXX Data Table

233

Attribute Name	Type (Size)	Description
Potential Download Targets	N x m	List of NPAC Customer Network Address Ids of those LSMSs that wish to receive downloads for TNs in this NPA-NXX.

LRN Data Table

Attribute Name	Type (Size)	Description
LRN ID	N	A unique sequential number assigned upon creation of the LRN record.
LRN	TN	Special TN value that may be used to route and terminate calls to ported TNs within NPAC customer’s network.
NPAC Customer ID	C (4)	SPID (NPAC Customer ID) of service provider on whose network the LRN terminates (owner of the LRN).

Exhibit 2.3-9.  LRN Data Table

Portability Area Table

Attribute Name	Type (Size)	Description
Portability Area ID	N	A unique sequential number assigned upon creation of the portability area record.
Portability Area Name	C (40)	City/Location name generally associated with this portability area (e.g., Chicago, New York, Rochester)
LATA Number	N	Number of LATA if portability area coincides with a LATA.
State Name	C (2)	State portability area resides in (e.g., NY, CT)

Exhibit 2.3-10.  Portability Area Table

234

2.3.2   NPAC Personnel Functionality (RFP Sect. 3.2)

Authorized NPAC personnel have access to all necessary NPAC data administration functions through the NPAC operations GUI (OpGUI).

The NPAC operational GUI (OpGUI) has been engineered from a human factor’s perspective to enable intuitive navigation and comprehension.  The user interface is consistent with commonly-used web browser-based applications.  Error checking and user notification are also provided.  The material below addresses the functionality as specified in requirements R3-1 through R3-7.  All transactions described that cause addition, deletion, and modification to NPAC SMS data are logged for tracking and reporting purposes.

This section addresses Service Data Administration in detail and the majority of the Network Data Administration.  Service Provider Data and Subscription Data administration are addressed minimally in this section since they are covered in detail in Sections 2.4 “Service Provider Data Administration” and 2.5 “Subscription Administration”.  Section 2.4 “Service Provider Data Administration” describes the functionality necessary to meet requirements R3-4 and R3-5.

Service Data Administration

The data in the Service Data Table, Exhibit 2.3-3, can be viewed from an operational perspective as subscription data related, security related, and audit related.  Using the OpGUI, NPAC-authorized personnel can initialize and modify the service data.  For ease of locating specific data parameters, the data is grouped logically in common functional areas and presented in a spreadsheet format that permits the user to modify the default values.  Authorized users are able to save modified settings or restore the original settings.  Service data cannot be accessed or modified across the SOA to NPAC/SMS or NPAC/SMS to LSMS mechanized interfaces.

235

Service Provider Data Administration

Authorized NPAC users are able to create, modify, and/or delete data in the Service Provider Data Tables, Exhibits 2.3-4, 2.3-5, and 2.3-6, using the OpGUI shown in Exhibit 2.3-11 [R3-4, R3-5].  Further details on the implementation of the service provider interface and administration are contained in Section 2.4 “Service Provider Data Administration.”

The service-provider data cannot be modified across the SOA to NPAC/SMS or NPAC/SMS to LSMS mechanized interfaces.

Network Data Administration

Network data administration is provided for in the network data tables previously shown in exhibits:

•Exhibit 2.3-8 — Portable NPA-NXX Table

•Exhibit 2.3-9 — LRN Data Table

Network data administration for a service provider can be initialized and administered via the OpGUI window shown inExhibit 2.3-12or via the NPAC/SMS to LSMS Interface [R3-1, R3-2]. Only network data administration from the OpGUI is addressed in this section.  The functionality available in the NPAC/SMS to Local SMS interface for network data administration is detailed in Section 2.6.2,  “NPAC SMS to LSMS Interface.”

LRN Administration

As shown in Exhibit 2.3-12, the OpGUI allows for addition and deletion of LRN data for a service provider by authorized users [R3-6]. When deleting LRNs for a service provider, an error dialog is

236

displayed whenever subscriptions reference the LRN. The LRN table is used to validate subscription administration requests.

NPA-NXX Administration

The NPA-NXX table is used for validating transaction requests, identifying the donor service provider, and for routing information to LSMSs.  The OpGUI allows for addition and deletion of NPA-NXX data for a service provider by authorized users.  When adding NPA-NXXs, the user is able to specify a range of NXXs to add to the NPA-NXX list associated with a specified service provider. As shown in Exhibit 2.3-12, the OpGUI permits this by allowing NPA-NXXs to be added in the NPA-NXX scrolled list [R3-3].

As shown in Exhibit 2.3-12 [R3-6], the authorized user is also permitted to delete NPA-NXX ranges.  Removing an NPA-NXX requires that there are no associated subscriptions with the NPA-NXX.  If no subscriptions are associated with the NPA-NXXs to be deleted, the user-entered data is validated. When the data is successfully validated, the user is prompted with a confirmation dialog.  The user is also notified of errors encountered during data validation.  After acknowledging the confirmation dialogue, a successful deletion dialogue is displayed.

If there are subscriptions associated with the NPA-NXXs to be deleted, the user is notified with an error dialogue indicating the delete cannot be performed since there are subscriptions associated with the NPA-NXX.

Mass Change Administration

Mass changes may be initiated for a group of subscription versions, whose version statuses are active, pending, conflict, conflict resolution pending, cancel pending, deferred disconnect or failed.  The group

237

of TNs to be modified may be specified by a standard set of query criteria, which includes TN range, and field value matches (e.g., LRN = old LRN value) [R3-7].

Subscription Version Administration

Authorized NPAC/SMS users are able to administer data changes to multiple subscription versions causing generation of mass changes.  Updates made to the following data may cause mass changes impacting multiple subscription versions [R3-6 and R3-7]:

•TN values (due to NPA splits)

•GTT information (DPC or SSN)

•LRN information.

The OpGUI window used for modification of this data is shown in Exhibit 2.3-13.  Mass updates to subscription information not associated with network data, such as subscription version status, are described in Section 2.5.

NPA Splits

As shown in Exhibit 2.3-14[R3-6 and R3-7], NPA splits are supported for authorized users of the OpGUI.  The authorized user is able to enter a range of NXXs for an NPA and is required to enter the following information for an NPA split:

238

Existing NPA-NXX(s)

•New NPA

•Date/Time of permissive dialing period start

•Date/Time of permissive dialing period end.

The NPAC SMS implements NPA splits by establishing a number mapping capability during the permissive dialing period so that a ported TN may be referenced by either its old or new NPA.  The NPAC split administration process is used to prepare the NPAC SMS to commence permissive dialing for a split area and to perform clean-up functions after the end of permissive dialing.  Prior to the start of permissive dialing, the NPAC SMS uses the NPA split information entered to establish the dual-NPA mapping for affected subscription versions.  During the permissive dialing period:

1.The NPAC SMS will accept either new or old NPA from a SOA, even for the same subscription version (TN).

2.LSMS and SOA systems are expected to accept either new or old NPA in NPAC responses.

3.For affected subscription versions activated during permissive dialing, NPAC will download only new NPA.

4.For ported TNs not ported during permissive dialing, the LSMS will locally perform, transparently to the NPAC SMS, any required mass updates required to replace the old NPA with the new in its database and within its network elements.

239

5.Any LRN changes caused by the split will be independently performed as standard mass updates by the NPAC on request by the owning service provider.

Prior to the end of permissive dialing, the NPAC SMS will substitute the new NPA for the old, while still enabling both old and new NPAs to reference the same subscription version.  After the end of permissive dialing, the NPAC SMS will delete the mapping to the old NPA, leaving the TNs with the new NPAs.  Due to both the NPAC SMS and LSMS/SOAs accepting both NPAs during the permissive dialing period, there is no need to synchronize the internal system conversion of records from old to new NPA.

LRN Administration

The OpGUI allows for modification of LRN values [R3-6].  The LRN can be modified for an entire switch as shown in Exhibit 2.3-13, or for a user specified range of subscriptions [R3-7] as described above in Subscription Version Administration.  When modifying an LRN associated with a service provider, the user is notified that the new LRN will be replicated for all subscriptions referencing the old LRN, and the user is required to acknowledge the dialogue before the replication of changes will occur.

2.3.3   System Functionality (RFP Section 3.3)

This section defines system download capabilities to LSMS as well as notification of network data changes to the service providers.  The NPAC/SMS is able to generate bulk database extracts for off-line transmission (e.g., via FTP, E-mail, tape) to service provider systems [R3-8].  Off-line transmission is appropriate to initialize new service provider systems or re-download significant volumes of data in case of disaster recovery for an LSMS [R3-8].

Network data change (adds or deletes) are propagated on-line to all interested LSMSs in the form of network data downloads, as noted in their NPAC customer profile.  [R3-9]  Additions or deletions of

240

NPA-NXXs, LRNs, and NPAC customers are downloaded [R3-10, R3-11].  See Section 2.6 for a description of the NPAC SMS to LSMS interface operations used to perform these functions.  In addition, network data is available for viewing from the public web-based electronic bulletin board [R3-10, R3-11].

Data updates for service, service provider, and subscription data are validated in the NPAC SMS against current network data [R3-12].  When mass changes have been generated due to an update, the NPAC SMS automatically downloads the required updates to the LSMS via the NPAC/SMS to LSMS interface [R3-13].  Data downloaded includes modified network data and subscription data.  In addition, our NPAC SMS provides a “heads-up” notice when the first pending subscription (both SPs concur) for a portable NPA-NXX occurs.  This notice is broadcast to all SOAs [R3-14].

241

This Page Intentionally Blank

242

NYCAC NPAC/SMS PROPOSAL 2.4 Service Provider Data Administration

HIGHLIGHTS

•Service provider data administration is streamlined by allowing portions of service provider data to be directly administered by the service provider through the NPAC SMS Operations GUI (OpGUI) or through the mechanized interface to the NPAC SMS

•Flexible window navigation makes it easy for the operator to add, modify, and delete service provider data, saving time and reducing support costs

•Automatic error checking and operator notification is provided with the OpGUI to ensure data integrity

•System security is inherent in the OpGUI design

2.4   NPAC/SMS USER DATA ADMINISTRATION (RFP Sect. 4)

Authorized users of the NPAC Operations GUI are able to create, view, modify, and delete the service provider information required by RFP requirements R4-1 through R4-5.

2.4.1NPAC/SMS User Data Administration and Management (RFP Sect. 4.1)

The service provider data administration functions allow authorized users to manage service provider data through the OpGUI.  Authorized users in this case includes remote service provider/user personnel as well as internal NPAC personnel.  In addition to access through the OpGUI, certain service provider data can be administered through the mechanized CMISE interfaces to the NPAC SMS.  NPAC service providers/users may only directly modify certain portions of their data to maintain security and integrity of the NPAC/SMS for all users.  All service provider data is administered by NPAC personnel.  The primary screen used for performing service provider data administration is illustrated in Exhibit 2.4-1.  It is important to note that within this section, the term “service provider” is used synonymously with the term “user” or “NPAC/SMS user,” and is not meant to distinguish between different types of NPAC customers (e.g., facilities vs. non-facilities based, or third party transaction providers).

243

2.4.1.1   User Functionality (RFP Sect. 4.1.1)

Security of OpGUI functions is provided by restricting window navigation and functions based on the level of user authorization.

Service provider data administration functions allow NPAC personnel to receive and record data needed to identify authorized NPAC customers (either service providers or users).  Service provider data indicates who the NPAC customer is and includes location, points-of-contact (POCs), security, routing, and network interface information.

Service provider administration supports functionality to manage service provider data.  There can be only one instance of service provider data for a specific NPAC customer.  The primary key for referencing an NPAC customer is the service provider ID, or SPID.  All NPAC customers will be required to have a valid (unique) service provider ID from the authoritative source accepted by the NYCAC.  Currently, it is expected that SPIDs will be the 4-digit OCN as assigned by NECA [R4-6].

Internal NPAC personnel utilize the OpGUI to perform service provider data administration functions, primarily using the screen illustrated in Exhibit 2.4-1.  The functions available from this screen include:

•Creation of a new service provider [R4-1]

•Modify service provider data [R4-2]

•Delete service provider data [R4-3]

•View service provider data [R4-4]

•View a list of subscriptions associated with a service provider as well as their own service provider data [R4-5].

244

2.4.1.2   System Functionality (RFP Sect. 4.1.2)

2.4.1.2.1   NPAC/SMS User Data Creation (RFP Sect. 4.1.2.1)

The service provider data creation defined in R4-6 through R4-11 is handled from the OpGUI window shown above in Exhibit 2.4-1.

Prior to activating a new NPAC Customer, the NPAC requires the following data:

1.Service Provider ID. [R4-6]

2.Service Provider name, address, phone number, and contact organization. If the NPAC customer ID (SPID) is not unique, an error message is displayed. [R4-7]

3.NPAC customer type.

4.Service provider allowable functions.

5.Service provider network address of NPAC SMS to local SMS interface.

6.Service provider network address of NPAC SMS to SOA interface.

7.Service provider security contact. Contact data is security data when contact type is “SE.” [R4-8]

245

8.Service provider repair contact name and phone number. The default service provider repair contact and phone number shall be the same as the service provider contact and phone number, if the service provider repair contact information is left blank. [R4-8]

9.Service provider billing name, address, phone number, and billing contact for NPAC SMS billing. The default for the service provider billing data shall be the same as the service provider data, if the service provider billing information is left blank. [R4-8]

10.Service provider download indicator.

11.Service provider maximum query.

The OpGUI ensures that all required data is entered and validated before allowing the user to leave the window [R4-9].  The following data is optional, and may be provided and entered into the NPAC SMS at a later time:  Service Provider Contact Type — SOA Contact, Local SMS, Web, Network Communications, Conflict Resolution, Operations, and User Administration Contact Address Information.

In addition, network data (NPA-NXXs and LRNs) for an NPAC customer who is a service provider is entered into the NPAC SMS subsequent to entering the service provider information via separate screens [R4-8].

Once the service provider data has been validated a message indicating creation success or error on the store is displayed [R4-10 and R4-11] and the data creation transaction success or failure is logged to the service provider administration transaction log [R4-3].  The NPAC SMS shall broadcast all additions,

246

modifications, and deletions of NPAC customer names via the NPAC SMS to LSMS interface to enable changes in NPAC customers to be forwarded to downstream service provider OSSs.

2.4.1.2.2   NPAC/SMS User Data Modification (RFP Sect. 4.1.2.2)

Service provider data modification, as defined in R4-12 through R4-18, is also handled from the OpGUI window shown above in Exhibit 2.4-1.  Navigational flow of the modify process from the Service Provider Query screen is shown in Exhibit 2.4-2.  Through the OpGUI, the user is able to:

•Input a Service Provider ID for the subscriber to modify [R4-13].  If the service provider ID does not exist, an error message is displayed; otherwise, the service provider information is populated on the window shown in Exhibit 2.4-1 [R4-14].  An alternate path would be to select a service provider for modification from the query window, as shown in Exhibit 2.4-3.  This would bring the user to this window with the service provider data populated.  The service provider query is performed as described in Section 2.4.3.1.  If, after successfully retrieving the service provider from the database, the user requests the service provider to be modified, the service provider window shown in Exhibit 2.4-1 is populated with the service provider data.

•Modify the service provider information shown in Exhibit 2.4-1 [R4-12] with the exception of the NPAC Customer ID (SPID) [R4-15].  The OpGUI ensures that all required data is entered and that all data modified is in the proper format [R4-16].  If the data validation fails, an error message indicating the specific data in error is displayed. [R4-17].

247

Successful modification of service provider data that could effect subscriptions is only allowed if there are no subscriptions associated with the service provider. [R4-18A].  If there are subscriptions that depend on modified data, a list of those subscriptions associated with the data modified is displayed with an error message indicating that they must be modified before service provider data can be modified [R4-18B].  The data modification transaction success or failure is logged to the service provider administration transaction log [R4-3].

2.4.1.2.3   Delete NPAC/SMS User Data (RFP Sect. 4.1.2.3)

Service provider data deletion, defined in R4-19 through R4-22, is handled from the OpGUI windows shown in Exhibits 2.4-3or 2.4-1.  A detailed view of the delete process from the Service Provider Query Window is shown in Exhibit 2.4-2. Through the OpGUI, the user is able to:

•Input a service provider ID for the subscriber to delete on the Service Provider Data Administration window shown previously in Exhibit 2.4-1 [R4-20].  If the service provider ID does not exist, an error message is displayed; otherwise, the service provider information is populated.  In the scrolled list shown in Exhibit 2.4-3 an alternate path for deleting a service provider would be to select a service provider for deletion as described in this section [R4-21] from the service provider query as shown in Exhibit 2.4-3.

•Delete service provider data.  Once the user selects delete for the service provider data [R4-19], a message indicating deletion success or error is displayed.  Successful deletion of service provider data is only allowed if there are no subscriptions, as well as no network data, in existence for the service provider [R4-22A].  If there are subscriptions associated with the service provider to be deleted, a list of those subscriptions are displayed with an error message indicating that they must be deleted before service provider data can be deleted [R4-22B].

248

If the service provider data is successfully deleted, the event is written to the history log with the date and time of deletion and the login of the NPAC user.  The data deletion transaction success or failure is logged to the service provider administration transaction log [R4-3].

2.4.1.3   NPAC/SMS User Queries (RFP Sect. 4.1.3)

The material below addresses the service provider queries for the OpGUI.  Mechanized interface queries of service provider data and their associated subscribers are discussed in Section 2.6 [R4-23].

Service Provider Query

The OpGUI Service Provider Query window is shown in Exhibit 2.4-3.  A process overview for operations in the Service Provider Query window is shown in Exhibit 2.4-2.  The search criteria for the query is either:

•Service Provider Name

•Service Provider ID [R4-25].

After entering the service provider name and/or the service provider ID, a query is performed to locate the service provider.

•If found, the service provider is displayed indicating the success of the search.  Based on the security level of the user, the user can then choose to modify, view, or delete the service provider [R4-2 through R4-4].  Both the modify and view options navigate the user to the service provider data administration window shown in Exhibit 2.4-1. [R4-24]

•If the service provider query is not successful, an error dialog message is displayed. [R4-26]

249

•Service providers are permitted to view their own data.  Access to other service provider data is not permitted. [R4-23]

•The “Delete” selection permits authorized users to delete service providers [R4-19]. Requesting a service provider to be deleted requires that no subscriptions be associated with the service provider [R4-19, R4-22A].  If there are subscriptions or network data associated with the service providers, an error dialog is displayed and the delete process discontinued [R4-22B].  If there are no subscriptions or network data associated with the service provider, the authorized user receives a confirmation dialog before deleting the service provider data.  After the service provider data has been deleted, the authorized user receives a successful information dialogue. [R4-22A]

•The “Subscriptions” selection navigates the user to the Query Subscription window shown in Exhibit 2.4-4.  A list of subscriptions for the service provider is displayed in a scrolled list format on this window [R4-24A]. The subscription query search criteria allows neutral subscriptions based on LRN [R4-24B] in addition to other subscription data.

Subscription List Query

The user is able to view all subscriptions associated with a service provider, including subscription status [R4-27].  The Query Subscription window is displayed in Exhibit 2.4-4 [R4-29].  A process flow for

250

querying subscriptions is shown in Exhibit 2.4-5.

The search criteria for retrieving the subscriptions is presented below [R4-29]:

•Subscription Version ID

•Subscription Version Status

•Local Number Portability Type

•Ported Telephone Number

•Old facilities-based Service Provider Due Date

•New facilities-based Service Provider ID

•Authorization from old facilities-based Service Provider

•Local Routing Number (LRN)

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•Billing Service Provider ID

•End User Location Value

•End User Location Type

•Customer Disconnect Date

•Effective Release Date

251

•Disconnect Broadcast Complete Time Stamp

•Conflict Time Stamp

•Activation Time Stamp

•Cancellation Time Stamp

•New Service Provider Creation Time Stamp

•Old Service Provider Authorization Time Stamp

•Pre-cancellation Status

•Old Service Provider Cancellation Time Stamp

•New Service Provider Cancellation Time Stamp

•Old Time Stamp

•Old Service Provider Conflict Resolution Pending Time Stamp

•New Service Provider Conflict Resolution Pending Time Stamp

•Create Time Stamp

•Modify Time Stamp

•Porting To Original.

The user enters subscription search criteria from the Query Subscription window.  When a search is requested, the user is notified if there are any records found matching the search criteria [R4-28 and R4-30].  If subscriptions were found for the service provider, a list is provided for user selection.  If the search would return more than the maximum number of records as specified in the maximum subscriber query tunable defined in Section 2.3, then a message to that effect is displayed along with the actual number of records that matched the search.  If the user wishes to receive a report of the search records, it may be requested through the OpGUI [R4-30].  The complete functionality available for the subscription administration is described in detail in Section 2.5.1.

252

NYCAC NPAC/SMS PROPOSAL 2.5 Subscription Administration

HIGHLIGHTS

•Both location portability and service provider number portability (SPNP) are standard components of the Lockheed Martin NPAC SMS

•Latest, up-to-date business process flows are implemented incorp-orating over six months of interactive work in the industry to refine NPAC/SMS processes and functions

•All SOA functions can be performed by authorized service provider personnel from the NPAC SMS Operational GUI (OpGUI), enabling service providers to support LNP deployment time-frames without immediate upgrades to existing SOAs

•Logic is provided in the OpGUI to ensure data integrity and to provide the user with help and error messages

•Efficient SOA interface function-ality cost effectively supports subscription version administration while enabling graceful expansion for future capabilities

2.5SUBSCRIPTION ADMINISTRATION (RFP Sect. 5)

Up-to-date business process flow implementation provides a rigorous yet cost effective implementation to support timely and reliable number porting activities on behalf of the service providers.

The subscription administration functions provided by the Lockheed Martin NPAC SMS solution allow for management of subscriber data versions needed to support LNP.  Subscription version administration functionality is available to authorized users via the mechanized SOA to NPAC SMS interface or from the NPAC SMS Operational GUI (OpGUI).  Both internal NPAC staff and authorized external users may perform subscription version administration from the secure NPAC user (or operational) GUI.

It is important to note that within this section, the term “service provider” is used synonymously with the terms “user” and “NPAC/SMS user,” and is not meant to distinguish between different types of NPAC customers (e.g., facilities vs. non-facilities based, or third party transaction providers).  Also, the term “service provider” is used synonymously with the term “SOA User” in the context of service provider actions performed over the SOA to NPAC SMS interface or via the OpGUI.  Finally, the term “subscription version” is used synonymously with the term “subscription record.”  A subscription version is a record in the NPAC SMS database referring to the state of a number port activity at a point in time.  Ported

253

number records are referred to as subscription versions.  Each version references a single telephone number, and has a specific state and timestamp associated with that particular record.  There may be multiple versions for a given number in the NPAC SMS, each representing the porting state of that number at different points in time, e.g. future (pending), present (active), past (old).

The security privileges for accessing this functionality via the OpGUI privileges are controlled at the time the user logs in using the NPAC SMS Logon Window shown in Exhibit 2.5-1.  Based on security configuration and permissions, the user is given access to subscription administration from the OpGUI Main Control window shown in Exhibit 2.5-2.  Access privileges for the mechanized interface are controlled as defined in Section 2.7.8.

While both machines and individuals constitute NPAC users for the purposes of discussing user functionality, the way in which those operations are submitted to the NPAC SMS naturally vary based on the interface type employed.  The NPAC SMS presents specific HTML-based screens and forms to live NPAC users, enabling them to perform the required subscription administration functions.  Service provider-based SOA systems interact via the SOA to NPAC SMS mechanized interface manipulating subscription versions as objects in a CMISE information object model.  Subscription version administration operations invoked through the SOA mechanized interface use the CMISE operations described in Section 2.6 (below) and the NPAC SMS IIS.  A mapping table provided in Section 2.6 associates subscription version administration functions, as well as others, into the CMISE operations, actions, and notifications used to communicate those processes through the interface.  Section 2.3 defines

254

the database tables and fields comprising the NPAC SMS database.  The Subscriber Data Table defined in Section 2.3contains all searchable subscription version records maintained in the NPAC SMS, compliant with the RFP Section 5 requirements.

The NPAC SMS, nonetheless, translates the interface-specific operation semantics (HTTPS vs. CMIP) into a common transaction model (implemented using BACE) where the database manipulation and resulting notifications or events are initiated.  Consequently, the subscription version administration processes are identical and consistent within the NPAC SMS regardless of how individual functions were

255

invoked.  Where appropriate, separate discussions of subscription version administration are provided for the mechanized interface and for OpGUI to clarify the user interface semantics.

2.5.1   Subscription Administration and Management (RFP Sect. 5.1)

Fully compliant, regionalized, management of subscription versions is provided in support of the current business process flows, for both SP SOA systems and internal and external NPAC users.

Version management is the core function service providers and users (NPAC customers) employ the NPAC SMS to perform.  Records for ported TNs are maintained as subscription versions, as described in

256

Sections 2.3 and 2.4.  As described in Section 2.2, the industry has developed enhanced business process flows stemming from work performed in various states workshops, including the Illinois ICC LNP Operations committee and the SMS committee.  The version management functions described in this section and implemented in the Lockheed Martin NPAC SMS reflect these refinements.  A summary of some of these process and implementation enhancements is provided below:

1.The LNP-type field is no longer considered part of the unique key required to identify a specific subscription version instance, as is suggested in.  There can only be one subscription version for a given TN in a pending or active state, for example, even in the case of different types of LNP.  The Lockheed Martin NPAC SMS supports both service provider number portability (SPNP) and location portability (presumed to be intra-rate center portability) and therefore supports two potential values for the LNP-type field: LSPP (for SPNP) and LISP (for location portability).  However, in the current generic requirements documents for LNP SCP, network elements, including LSMS, only expect to maintain a single record for a given TN.  Consequently, until such time as there is a need to support multiple records in network elements for a given TN, the NPAC SMS will enforce this constraint across LNP types.

2.In support of LISP (location portability), the Lockheed Martin NPAC SMS supports location portability as a simplified variant of the basic provisioning process flows.  Regardless of whether a TN has already ported, the current service provider (SP) for the TN may initiate a location port by performing a subscription version create as the “new” SP with an LNP-type of LISP.  In this case, the old and new SP are one and the same, so there is no need for the “old” SP to provide concurrence.  If the new SP create is performed correctly, then the version may be activated by the SP when ready to do so.

257

3.Another variation of the basic SPNP process flows is supported in the case of a previously ported TN that subsequently ports back to its original donor switch (in the donor service provider).  In this case, the new SP is the donor SP from whom the TN originally ported.  Their create request will have the “port to original” field set to true to invoke this scenario.  In this case, no routing fields (LRN or GTT) should be specified in the create.  After the old SP has concurred, the new SP may activate the version.  The download resulting from the activate is a delete operation to the LSMSs, causing them to delete the routing record from their network elements since routing is to revert back to default routing.  The TN is now considered a non-ported number.

4.The three future fields (Future 1, Future 2, and Future 3) have been deleted from the subscription version record. The two End User Location fields (Value and Type) remain.  It was determined to be preferable to add new fields later, at such time as a need is determined, to the subscription version record (and the IIS) and assign these fields self-descriptive names with actual coding format than to allocate three stub fields whose coding would probably have to change anyway once an actual use for them was determined.

5.The due date field is used to determine when concurrence or authorization-request notifications are sent.  If after the first subscription version create from either SP has occurred, the other SP has not yet created/authorized its view of the order (subscription version) within a tunable interval prior to the due date specified, it will be sent a notification requesting it to do so.  The “tunable interval” would be a total of the two timeout intervals, which default to 18+18 hours, or 36 hours before the specified due date.

6.If after a second tunable timeout period (defaults to 18 hours prior to due date) has expired and the other SP has still not created its view of the subscription version, then the subscription version is

258

either placed into conflict (if old SP did not respond), or is canceled (if the new SP did not respond).  In either case, both SPs are notified of the change in the version status (conflict or cancel).  The version no longer defaults to valid pending if the old SP does not authorize.

7.In its create action, the old SP may either explicitly authorize the version or may indicate lack of authorization, in which case the version is placed into a conflict state.

8.Unlike the old SP, the new SP does not have an explicit authorize field for the version.  If the new SP performs its create function on the NPAC SMS for the TN in question and provides all the mandatory fields, then concurrence with the port is implicit.

9.A version may be modified by either SP while in a pending or conflict state, and only by the new SP once it is active.  Only fields appropriate for the SP are modifiable (i.e., the old SP may modify the due date but not routing fields).  Any changes in relevant fields (such as due date) in the version are reported to both SPs SOAs as notifications.

10.While the initial due dates provided by both old and new SPs in their version creates must agree, either SP may subsequently modify its due date without requiring the other SP to perform a matching modify on its due date.  After the initial creates are performed, this field is for informational purposes only.

11.An active subscription version may be modified while there is a version pending for the same TN.  This is probably a rare scenario, but it was viewed as desirable to allow modifications to an active record by the current SP, even if there was another version pending that might change the SP.

259

12.Any changes in the status of the subscription version (e.g., pending->sending, pending->conflict) are reported by the NPAC SMS to both SPs’ SOAs as a notification.  These include any status changes (including creates) performed by NPAC personnel on an SP’s behalf.

13.Accepted modifications of an active version cause an immediate “download” of the changed attributes, which take the form of CMISE modify (M-SET) operations from the NPAC SMS to LSMS interface.  Also similar to an initial activate, a download results report is provided back to the new SP’s SOA indicating the results of the download.

14.When an active version is modified, its state changes to sending to reflect the fact that a broadcast is in process.  However, unlike the case of an activate, the version cannot be placed into a partial failure state if one or more LSMSs do not receive the download.  In that case, the version state returns to active.  All functions that result in an LSMS broadcast (activate, modify, and disconnect) send a download results report (notification) to the new SP’s SOA indicating the LSMSs that failed.  In the case of a modify of an active version that partially failed, this notification will contain the status of active not partial failure along with the list of LSMSs that did not receive the download, if any.

15.The invalid state has been removed as a subscription version status.  The NPAC SMS will not store a subscription version that would otherwise be in an invalid status.  There is no need to re-validate a subscription version upon activation, so there is no need for an invalid state. Re-validation on activate is redundant, since any create or modify operation that is accepted (not rejected due to error) for a version is guaranteed to leave the version in a valid state.  Otherwise, the operation is rejected.

16.While the old SP may now place a version into conflict via the SOA interface, either SP may also initiate a conflict-off process via its SOA interface.  This was viewed by the service providers as a

260

preferable way to deal with states involving potential transition to conflict than requiring manual contact to the NPAC to place and remove a version from conflict.  However, the functionality for an NPAC user to place or remove a version from conflict still remains.

17.The conflict resolution and cancel processes require both SPs to approve the state transition before it is official.  Tunable acknowledgment time-outs in the NPAC SMS will send notifications to an SP’s SOA to solicit it to provide their acknowledgment.  If acknowledgment is not received within a second tunable interval, then the version returns to its prior status.

18.If a version is placed into conflict explicitly by the old SP through a create action with its authorize field set to false, the old SP must still set the authorize field to true (explicitly authorize the port) after the conflict status has been removed.  Upon exiting conflict state, the old SP’s authorization field is returned to its prior state.

19.Pending disconnect processing is now supported.  Disconnect requests for a version may now specify an effective date at which time the NPAC SMS will automatically initiate CMISE delete operations (a delete broadcast) to the LSMSs.  If the effective date is not specified on a disconnect request, it defaults to immediate disconnect.

20.A customer disconnect date parameter is required on a disconnect request from the SOA to the NPAC SMS.  This is the date at which time the customer was disconnected from its most recent service provider.  When the disconnect is broadcast by the NPAC SMS (at the effective date or immediately), this date is forwarded to the donor service provider’s SOA by a notification.  This allows the donor service provider to consider the amount of time the last service provider provided treatment on the disconnected number in order to apply the appropriate aging interval before

261

reassigning the vacant number.  Disconnected ported TNs are deleted from all LSMSs and are no longer considered ported by the NPAC SMS.

A subscription version may only be in one of the following states:

•Active - Version is currently active in the network

Note: There may be another pre-active (e.g., pending) version in the system that will eventually supersede this version. Examples: 1) Pending version for the active subscription exists 2) Sending version for the active subscription exists.

•Canceled - A pending, conflict, conflict resolution pending, or disconnect pending version was canceled prior to activation in the network

•Cancel Pending - Version is awaiting cancellation acknowledgment from both service providers, at which time the version will be set to canceled

•Conflict - Version is in conflict (i.e., a dispute exists between the two service providers), awaiting resolution

•Conflict Resolution Pending - Conflict has been resolved, and the version is awaiting conflict resolution acknowledgment from both service providers, at which time the version will be set to pending

•Disconnect Pending - Version is awaiting the effective release date, at which time the version will be set to sending, and the disconnect request will be sent to all LSMSs

•Failed - Version failed activation, modification, or disconnect in ALL of the network LSMSs

•Old - Version was previously active in the network and was either superseded by another active version or was disconnected

•Partial Failure - Version failed activation in one or more, but not all, LSMSs in the network

262

•Pending - Version is either pending activation (approval had been received from both service providers) or pending creation/approval from one or the other service provider

•Sending - Version is currently being sent to all of the LSMSs in the network.

Exhibit 2.5-3 illustrates the possible subscription version states and the allowable transitions between states for the entire lifecycle of a subscription version.

[Graphic Omitted:  State diagram]

Exhibit 2.5-3.  Subscription Version Lifecycle State Transition Diagram

The following describes each of the allowed state transitions illustrated in Exhibit 2.5-3:

1.I.Conflict ® Canceled

2.

A.NPAC SMS Internal
NPAC SMS automatically sets a subscription version in conflict directly to canceled after it has been in conflict for a tunable number of days.

1.II.Conflict ® Cancel Pending

2.

A.NPAC Operations GUI - NPAC Personnel
User cancels a subscription version in conflict.

B.SOA to NPAC SMS Interface
User sends a cancellation request for a subscription version with a status of conflict.

1.III.Cancel Pending ® Conflict

2.

A.NPAC Operations GUI - NPAC Personnel
User sets a subscription version with a status of cancel pending  conflict.

263

B.NPAC SMS Internal
NPAC SMS automatically sets a subscription version with a status of cancel pending ® conflict if “cancel pending acknowledgment” has not been received from the old and/or new service provider within a tunable timeframe.

1.IV.Conflict Resolution Pending  Cancel Pending

2.

A.NPAC Operations GUI - NPAC Personnel
User cancels a subscription version with a status of conflict resolution pending.

B.SOA to NPAC SMS Interface
User sends a cancellation request for a subscription version with a status of conflict resolution pending.

1.V.Conflict  Conflict Resolution Pending

2.

A.NPAC Operations GUI - NPAC Personnel
User sets a subscription version with a status of conflict ® conflict resolution pending.

B.SOA to NPAC SMS Interface - New Service Provider
New service provider sends a conflict resolution pending request for a subscription version with a status of conflict.

C.SOA to NPAC SMS Interface - Old Service Provider
Old service provider sends a subscription version modification request for a subscription version with a status of conflict, which provides the old service provider’s authorization for the transfer of service.

1.VI.Conflict Resolution Pending  Conflict

2.

A.NPAC Operations GUI - NPAC Personnel
User sets a subscription version with a status of conflict resolution pending conflict.

264

B.NPAC SMS Internal
NPAC SMS automatically sets a subscription version with a status of conflict resolution pending ® conflict after conflict resolution pending acknowledgment has not been received from old and/or new service provider within a tunable timeframe.

C.SOA to NPAC SMS Interface - Old Service Provider
Old service provider sends a subscription version modification request for a subscription version with a status of conflict resolution pending, which revokes the old service provider’s authorization for transfer of service.

1.VII.Pending ® Conflict

2.

A.NPAC Operations GUI - NPAC Personnel

1.User sets a subscription version with a status of pending ® conflict.

2.User creates a subscription version for an existing pending subscription version for the old service provider and does not provide authorization for the transfer of service.

B.NPAC SMS Internal
NPAC SMS automatically sets a pending subscription version to conflict after authorization for transfer of service has not been received from the old service provider within a tunable time frame.

C.SOA to NPAC SMS Interface - Old Service Provider

1.Old service provider sends a subscription version creation request for a subscription version with a status of pending, which revokes the old service provider’s authorization for transfer of service.

2.If the current service provider sends an immediate subscription version disconnect request, a pending subscription version exists, and the old service

265

provider has not authorized transfer of service for the pending subscription version, the pending subscription version is set to conflict.

1.VIII.Conflict Resolution Pending ® Pending

2.

A.NPAC SMS Internal
NPAC SMS automatically sets a conflict resolution pending subscription version to pending after receiving conflict resolution pending acknowledgment from the old and new service provider.

1.IX.Pending ® Cancel Pending

2.

A.NPAC Operations GUI - NPAC Personnel
User cancels a subscription version with a status of pending.

B.SOA to NPAC SMS Interface
User sends a cancellation request for a subscription version with a status of pending.

C.NPAC SMS Internal

1.NPAC SMS automatically sets a pending subscription version to cancel pending after authorization for the transfer of service has not been received from the new service provider within a tunable timeframe.

2.NPAC SMS automatically sets a pending subscription version to cancel pending if an activation request is not received a tunable amount of time after the most current of the two due dates: either the new service provider due date or old service provider due date.

1.X.Cancel Pending ® Canceled

2.

A.NPAC SMS Internal
NPAC SMS automatically sets a cancel pending subscription version to canceled after receiving cancel pending acknowledgment from the old and new service provider.

266

1.XI.Creation - Set to Conflict

2.

A.NPAC Operations GUI - NPAC Personnel
User creates a subscription version for the old service provider and does not provide authorization for the transfer of service.

B.SOA to NPAC SMS Interface - Old Service Provider
User sends an old service provider subscription version creation request and does not provide authorization for the transfer of service.

1.XII.Creation - Set to Pending

2.

A.NPAC Operations GUI - NPAC Personnel
User creates a subscription version for either the new or old service provider. If the create is for the old service provider and authorization for the transfer of service is not provided, refer to step 11-A.

B.SOA to NPAC SMS Interface
User sends a subscription version creation request for either the new or old service provider. If the create is for the old service provider and authorization for the transfer of service is not provided, refer to step 11-B.

1.XIII.Disconnect Pending ® Cancel Pending

2.

A.NPAC Operations GUI - NPAC Personnel
User cancels a subscription version with a disconnect pending status.

B.SOA to NPAC SMS Interface - New Service Provider
User sends a cancellation request for a disconnect pending subscription version.

267

1.XIV.Disconnect Pending ® Sending

2.

A.NPAC SMS Internal
NPAC SMS automatically sets a deferred disconnect pending subscription version to sending after the effective release date is reached.

1.XV.Pending ® Sending

2.

A.NPAC Operations GUI - NPAC Personnel
User activates a pending subscription version.

B.SOA to NPAC SMS Interface - New Service Provider
User sends an activation message for a pending subscription version.

1.XVI.Sending ® Failed

2.

A.NPAC SMS Internal
NPAC SMS automatically sets a subscription version from sending ® failed after all Local SMSs fail subscription version activation or disconnect after the tunable retry period expires.

1.XVII.Failed ® Sending

2.

A.NPAC Operations GUI - NPAC Personnel
User resends a failed subscription version.

1.XVIII.Partial Failure ® Sending

2.

A.NPAC Operations GUI - NPAC Personnel
User resends a partial failure subscription version.

1.XIX.Sending ® Partial Failure

2.

A.NPAC SMS Internal
NPAC SMS automatically sets a subscription version from sending ® partial failure

268

after one or more, but not all, of the local SMSs fail the subscription version activation or disconnect after the tunable retry period expires.

1.XX.Sending ® Old

2.

A.NPAC SMS Internal
NPAC SMS automatically sets a sending subscription version to old after successful completion of a disconnect or “porting to original” port to all local SMSs.

1.XXI.Sending ® Active

2.

A.NPAC SMS Internal
NPAC SMS automatically sets a sending subscription version to active after the subscription version activation is successful in all of the local SMSs.

B.NPAC SMS Internal
NPAC SMS automatically sets a sending subscription version to active after the subscription version modification is successfully broadcast to any of the local SMSs.

1.XXII.Active ® Old

2.

A.NPAC SMS Internal
NPAC SMS automatically sets the previously active subscription version to old once a subscription version activation, modification, or disconnect is successful in local SMSs.

1.XXIII.Immediate Disconnect ® Sending

2.

A.NPAC Operations GUI - NPAC Personnel
User disconnects an active subscription version and does not supply an effective release date.

B.SOA to NPAC SMS Interface - Current Service Provider
User sends a disconnect request for an active subscription version and does not supply an effective release date.

269

1.XXIV.Deferred Disconnect - Set to Disconnect Pending

2.

A.NPAC Operations GUI - NPAC Personnel
User disconnects an active subscription version and supplies an effective release date.

B.SOA to NPAC SMS Interface - Current Service Provider
User sends a disconnect request for an active subscription version and supplies an effective release date.

1.XXV.Modify Active ® Sending

2.

A.NPAC Operations GUI - NPAC Personnel
User modifies an active subscription version.

B.SOA to NPAC SMS Interface - Current Service Provider
User sends a modification request for an active subscription version.

2.5.1.1Record Management (RFP Sect. 5.1.1)

This section addresses the functionality necessary for management of subscriber versions specified in requirements R5-1 through R5-6  A subscription version is a view of the state of a ported (past, present, or future) phone number (TN).  The SMS will maintain for each subscription version its status, which will include the values of:  pending, conflict, sending, active, failed, old, and canceled [R5-1].  A complete list of all possible subscription states and their transitions was provided in above in Section 5.1.  Multiple subscription versions created through a range level request are maintained as individual subscription versions [R5-5].  Only one pending version is allowed per subscription [R5-4], regardless of LNP-type, and only one version per subscription is allowed to be active, pending, sending, conflict, or failed.  Multiple old and canceled versions are stored until purged, per R5-2 and R5-3 and as discussed below.

270

Versions retained in the database longer than the tunable retention period are purged by the nightly NPAC SMS housekeeping process.  The housekeeping process uses the following Service Data Table (tunable parameters) variables defined in Section 2.3 for removing versions from the database:

•Old versions are purged based on the number of days specified in “Old Subscription Retention,” which defaults to 18 months, and is further described in Section 2.3. [R5-2]

•Canceled versions with a last status of pending are purged based on the number of days specified in “Cancel Pending Subscription Retention,” which defaults to 90 days.  [R5-3]

•Canceled versions with a last status of conflict are purged based on the number of days specified in “Cancel Conflict Subscription Retention,”  which defaults to 30 days.[R5-3].

To facilitate the purging of data, the time that a version status is changed, e.g. to old or cancel, and the previous status are stored in the subscription version.

Any administrative changes to versions results in log entries being created in the subscription administration log [R5-6].  In addition to logging the data required in R5-6 under the circumstances specified, the NPAC SMS housekeeping processes log records with an activity type of purge to enhance the traceability of subscription version administration transactions.  Information recorded in the log includes:

•Activity Type: create, modify, activate, query, all status types, and all acknowledgments.

•Service Provider ID

•Initial Version Status

•New Version Status

•Userid and/or Login

271

•Local Number Portability Type

•Date

•Time

•Ported Telephone Number

•Status Flag - successful or failed

•Subscription version ID (when assigned).

2.5.1.2   Subscription Administration Requirements (RFP Sect. 5.1.2)

The Lockheed Martin NPAC/SMS faithfully implements the subscription administration requirements ensuring cost efficient and error-free operation.

Section 2.5.1.2.1 addresses user functionality of subscription administration.  Both mechanized and user GUI views of these functions are discussed, followed by a system functional discussion in Section 2.5.1.2.2.

2.5.1.2.1   User Functionality (RFP Sect. 5.1.2.1)

Extensive user functionality is provided, consistent with the mechanized interface for operational flexibility and redundancy.

NPAC users are able to perform subscription version administration by invoking the operations defined in requirements R5-7 through R5-13:

•Create a subscription version/record.  Create requests are validated prior to instantiating a new subscriber data table record for this version, at which time it enters a pending status [R5-7].

272

However, all create requests are logged.  Exhibits 2.5-4and 2.5-5illustrate the OpGUI screens that may be used to create subscriptions.

•Modify a subscription version/record.  A subscription version in an allowed state may be modified by an authorized user (e.g., appropriate service provider [SP]).  An authorized user may only modify certain fields depending on the type of user (old or new SP) and the state of the version.  Only validated modifies are accepted and generate database record updates.  All modify attempts are logged.  Allowed version states are: pending, conflict, or active [R5-8].  Exhibits 2.5-6and 2.5-7illustrate the OpGUI screens used to perform subscription modifies.

273

•Activate a subscription version/record.  Activation causes a subscription version to be broadcast to all LSMS interfaces [R5-9].  Exhibit 2.5-8 illustrates the OpGUI screen used to query for and activate a version.

274

•Place or remote a version/record from conflict. A user may place a version into or out of conflict, using the OpGUI screen illustrated in Exhibit 2.5-8. A conflict state must be resolved into a valid pending state prior to activation [R5-10].

•Disconnect a version/record.  Disconnecting places a version into an old state, and deletes the version from the LSMSs, effectively reverting call routing to default [R5-11].  A user may initiate a disconnect using the OpGUI screen illustrated in Exhibit 2.5-8.

•Cancel a version/record.  Places a version in an allowed state into a canceled state.  Versions may be explicitly canceled that are either in conflict or pending state[R5-12].  A user may initiate a cancel using the OpGUI screen illustrated in Exhibit 2.5-8.

•Perform version/record queries.  Enables a version or versions, and associated fields, matching the search criteria to be obtained.  For GUI users, the query results are displayed or reported using the OpGUI screen illustrated in Exhibit 2.5-8 [R5-13].

Next, the user GUI-view of subscription administration is presented followed by a discussion of the mechanized interface semantics of invoking these same functions.

2.5.1.2.1.1   NPAC User GUI Functionality

Sophisticated, yet cost effective, GUI capability minimizes user errors and streamlines productivity and flexibility.

The OpGUI provides a subscription version interface permitting the user to perform the following subscription administration tasks (R5-7 through R5-13):

275

•Creating subscription versions

•Modifying subscription versions

•Querying and retrieving a subscription list

•Activating subscription versions

•Conflict resolution

•Disconnecting subscriptions

•Canceling subscriptions.

The create, modify, and query of subscription versions is available for authorized users.  Each is discussed in the following sections.

The subscription version status update capability provides authorized users the ability to change the subscription version status (activate, disconnect, or cancel).  The allowed subscription version status modifications are illustrated in Exhibit 2.5-3.

2.5.1.2.1.2   Mechanized Interface Functionality

A fully compliant, mechanized SOA interface supports version administration per the latest business process flows.

The mechanized SOA to NPAC SMS interface provides the primary facility over which service providers perform subscription version administration. The IIS includes the complete GDMO information model for the objects, attributes, packages, actions, and notifications that comprise this interface.  Also included in Section 2.6 (below) is a table that maps functional RFP requirements to individual elements within the information model to demonstrate complete requirements compliance and to relate the administration

276

semantics to the information model. All of the functional user requirements, R5-7 through R5-13, are implemented across this interface.

Note that most user functionality is performed via actions to the lnpSubscriptions container object.  This is mandated to comply with requirements R5-26, R5-35, R5-51, R5-62, and R5-69, which require that SOAs need only specify the subscription TN attribute value to identify the specific subscription VersionNPAC intended.  Additionally, if an SOA system does note the version ID for versions it is involved in creating (acting as either old or new service provider), it may reference that subscriptionVersionNPAC instance specifically by name (TN + version ID) for subsequent operations (e.g., M-SET directly to the subscriptionVersionNPAC in lieu of sending a modify action to the lnpSubscriptions container object).  This streamlines the NPAC SMS operation where service provider SOA systems can support it.  In either case, both modes of reference (indirect via the container, or direct to the version instance) are supported.

Further detail on the SOA to NPAC SMS interface is provided in Section 2.6 and the IIS.

2.5.1.2.2   System Functionality (RFP Sect. 5.1.2.2)

Fully compliant system functionality is provided to manage subscriptions fairly and consistently.

In addition to subscription version processes invoked by users over either type of interface, other processes internal to the NPAC SMS also manipulate subscription versions.  Certain transient version states are timed (e.g., pending) to enable the NPAC SMS to provide the necessary time-out responses in those conditions.  For example, if the old service provider fails to issue a version create for a version previously created by a new service provider, then a subscriptionVersionOldSP-ConcurrenceRequest

277

notification is sent to the old SOA to solicit concurrence (in the form of a new version create action) with the new service provider subscription version.

2.5.1.2.2.1   Subscription Record Creation (RFP Sect. 5.1.2.2.1)

Efficient version creation is supported through both mechanized interface and user GUI.

A subscription version create is performed upon the initial receipt of a valid create action from either the old or new service provider.  Across the mechanized interface, this operation is performed by sending a create action to a container object (lnpSubscriptions) in the NPAC SMS.  This instantiates a new subscriptionVersion object after validating the request and verifying that there are no previous versions in a state precluding a new create.  These semantics are used in order to allow the old and new service provider to launch their respective create actions asynchronously and independently of each other.  Both old and new service providers have specific fields (attributes) they are allowed to specify in the create action to correctly populate the record.  These fields correspond with those identified in requirements R5-14, R5-15, and R5-16

New subscription versions can also be created via the OpGUI.  Subscriptions can be created by either the old (current) or new service provider.  Depending on the originator of the create request, the required data to process the create differs.  Therefore, the subscription create request originating from the old service provider is shown in Exhibit 2.5-4 [R5-14]; and the subscription create request originating from the new service provider is shown in Exhibit 2.5-5 [R5-15].  A process flow explaining the GUI subscription create request is shown in Exhibit 2.5-9.  All data entered by the user will be validated both interactively and upon the submission of the create request.

278

Specifically, the NPAC SMS requires the following data from the NPAC personnel or old service provider upon subscription version creation for an SPNP port or “porting to original” port: [R5-14]

•Local Number Portability Type - Port Type

•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 subscription versions 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 initially planned to occur

•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

279

•Authorization from old facilities-based service provider - indication that the transfer of service is authorized by the ported-from service provider.

In the case of a location port (LNP type = LISP), the old and new service provider are the same, so no old service provider create function is appropriate.  The NPAC SMS requires the following data from NPAC personnel or the new service provider upon subscription version creation for an LSPP or LISP port [R5-15]:

•Local Number Portability Type - Port Type.  This field must be set to “LSPP” for SPNP ports, or “LISP” for a location port

•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 subscription versions 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 initially planned to occur

•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.  In case of LISP, this is the same as the new service provider

•Porting to Original - flag indicating whether or not this is a port back to the donor switch.
If this flag is set to “FALSE”, then the following fields must also be provided.  Note that any of these fields, except for the LRN, may be explicitly set to a null value.

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

•Class DPC

•Class SSN

280

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

If the “port to original” flag is set to “TRUE,” then none of the above LNP routing fields should be specified.

•The following fields may be optionally specified on the new service provider’s create [R5-16]:

•Billing Service Provider ID

•End-User Location - Value

•End-User Location - Type.

Only one create action is accepted for a subscription from both the old and new SP for a TN, otherwise an error is returned [R5-17].

Each create action is validated using:

•Ported TN Validation

•Service Provider Validation

•Network Data Validation.

281

The ported TN validation includes verifying that the NPA-NXX of the TN exists in the Portable NPA-NXX Table shown in Section 2.3 indicating that the NPA-NXX is opened for porting in one of the portability areas served by the NPAC SMS [R5-18].

The service provider validation includes the following data validation [R5-18]:

•Subscriber Data Table, defined in Section 2.3, to ensure that both old and new service providers are valid NPAC customers authorized to perform porting functions (specifically for OpGUI submitted create requests)

•That both service providers are shown as providing service in the portability area indicated by the NPA-NXX of the TN

•Due dates between new and old service provider match.

The network data validation requires that the new LRN is associated with the new service provider using the LRN Table shown in Section 2.3  [R5-18].

If an active version exists for the TN (a previously ported TN), the old service provider ID must be the current service provider in the new create [R5-19].  If any of the validations discussed above do not succeed, an error is returned to the originator of the create action [R5-20].  If a valid subscription version already exists, the subscription is marked as pending and retained [R5-20].  If the validations failed and there is no valid subscription version, the subscription version is not created [R5-20].

282

If all the validations are successful, a check is performed to ensure that both providers have authorized the transfer [R5-21].  If there is a discrepancy in the authorization of the transfer, the SMS sets the concurrence date by which both service providers must agree.  The concurrence date is calculated using the “Service Provider Concurrence Window” tunable variable in the Service Data Table shown in Section 2.3 [R5-21].  The subscription version is then marked with a pending status.  When the date expires, the NPAC SMS emits a request (a subscriptionVersionOld/NewSP-ConcurrenceRequest notification from lnpSubscriptions object) to the other service provider to solicit its create action [R5-22].

If there is still no response after a second interval in the tunable Service Data Table “Service Provider Concurrence Cancellation Window,” the NPAC SMS either cancels the version (if the new failed to create) or places the version in conflict (the old SP failed to create). [R5-23]  In either case, an appropriate notification is emitted to both service providers (a subscriptionVersionStatusAttribute ValueChange notification from the subscriptionVersionNPAC object) to inform them of the change in status of the subscription (cancel or pending-authorized).

283

2.5.1.2.2.2   Subscription Record Modification (RFP Sect. 5.1.2.2.2)

Subscription modification is performed in a fully compliant and efficient manner.

Generally, the new service provider (logical owner of the version) may modify subscription versions in certain allowed states (e.g., pending, active).  The mechanized interface functionality to modify versions is described in section 2.6.

The OpGUI also provides the user the capability to modify subscription versions associated with a specified service provider [R5-8].  Navigation to the modify interface is preceded by the Query Subscription Window displayed previously in Exhibit 2.5-8 and explained in the process flow in Exhibit 2.5-10 (which follows Exhibit 2.5-11).  Changes and additions can be made to subscription version data if the subscription version status is pending or conflict [R5-24].  Since an OpGUI query for the version to be modified is performed first,  the user already specified the service provider id and the ported TN in the query window, omitting the need for re-entry of the data [R5-26, R5-35].  The service provider data and the ported TN will be displayed as read only in the Modify Subscription windows displayed in Exhibits 2.5-6 and 2.5-7.

Depending on the status of the subscription version, the user is able to modify a unique set of allowed data [R5-27, R5-36, R5-37].  Exhibit 2.5-11 indicates the OpGUI windows used for viewing and modifying subscription versions based on the subscription version status:

Versions Status	Exhibit	RFP Requirement
Pending	2.5-6	R5-27
Conflict	2.5-6	R5-27
Active	2.5-6	R5-36, R5-37

Exhibit 2.5-11.   Version Modification Screens for the User GUI

284

2.5.1.2.2.2.1Modification of a Pending or Conflict Subscription Record (RFP Sect. 5.1.2.2.2.1)

Policies for versions modifications are implemented in a fully compliant manner.

If a subscription version status is pending or conflict, the user is permitted to modify the subscription.  If the subscription version status is sending, failed, canceled, or old,  the user is not permitted to modify the subscription [R5-25].  If the user has selected a subscription with a status of sending, failed, canceled, or old, the ‘Modify...’ option is not selectable on the user GUI or it generates an error if attempted via the mechanized SOA interface.

Since only a single subscription version for a given TN may be in one of the modifiable states (active, pending, or conflict), only the TN value needs to be specified to uniquely identify the intended version [R5-26].

After querying and retrieving subscription versions into the Query Subscription window, a GUI user can select subscription versions displayed in the subscription list.  After selecting a subscription version, the user has viewing and modify options based

285

on the status of the subscription version selected.  The OpGUI windows used for viewing and modifying subscription versions based on the subscription version status are explained in Exhibit 2.5-6.

The NPAC SMS allows the following data to be modified in a pending, conflict, or conflict resolution pending subscription version by the new/current service provider or NPAC personnel: [R5-27, R5-28]

•LRN

•Due Date.

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•Billing Service Provider ID

•End-User Location - Value

•End-User Location - Type.

The subscription data is modified only after the modification request passes validation [R5-29, R5-18].  Within the user GUI, each data field on the Modify Subscription window shown in Exhibits 2.5-6 and 2.5-7 is revalidated [R5-29, R5-18].  If the data validation is successful, the user is notified with an information dialog indicating successful validation.  Successful validation results in the a notification of the modification be sent to both service providers (via an attributeValueChange notification from the

286

subscriptionVersionNPAC object).  If the modification causes the version to change state, then a status change notification is sent to both service providers informing them of the change [R5-31].  If the data validation fails, the originator of the request is notified of the specific data validation error via an error dialog [R5-30] for the user GUI, or an error return on the modify operation for the mechanized SOA interface.  Upon failure, no changes shall be made [R5-30].

2.5.1.2.2.2.2   Modification of an Active Subscription Record (RFP Sect. 5.1.2.2.2.2)

Permitted modifications of an active subscription are logically treated as creating a newly activated version.

Should the current service provider for an active subscription desire to modify (update) any of the routing information associated with the TN, a modify of the active version is performed [R5-33].  Again, since there can be only one active version for a subscription, only the TN value or the version ID need be specified to identify the specific version to be modified [R5-35].  Only routing information (LRN or GTT) or the optional billing ID and end-user location fields may be modified [R5-36 and R5-37].  If successful, this creates a new subscription version for the updated information, which is treated as an immediate activation [R5-34, R5-40].  The newly activated (modified) version is broadcast immediately out to all LSMS interfaces using the standard download and resend process, including retransmit time-outs [R5-40, R5-41].  The result of this download is forwarded to the current service provider, including a list of any LSMSs that did not receive the download.  The prior version is marked as old and stored until purged as usual.

After querying and retrieving subscription versions into the subscription query window, the GUI user can select subscription versions displayed in the subscription list.  After selecting a subscription version, the user has viewing and modify options based on the status of the subscription version selected.  If the

287

subscription version status is active, processing and navigational flow is the same as described in Section 2.5.1.2.2.2.1.

After modifications have been requested to the subscription, the subscription data is validated [R5-38].  Each data field on the subscription modify window shown in Exhibit 2.5-7 are revalidated for the GUI user [R5-38].  If the data validation is successful, the user is notified with an information dialogue indicating successful validation [R5-31].  Through the mechanized SOA interface, the modification is either confirmed or an error is reported.  After successful completion of validation, the current date and time is used as the activation date and time stamp, the version is marked as sending and the originator notified [R5-40].  If the data validation fails, the originator of the request is notified of the specific data validation error via an error dialogue [R5-39].

If the modifications to the active version are rejected, a new version is not created and no changes are made to the current active version subscription version [R5-39].

2.5.1.2.2.3   Conflict Subscription Record (RFP Sect. 5.1.2.2.3)

Automated conflict removal processing, as requested by the industry, streamlines NPAC/SMS involvement in conflict scenarios and thereby reduces overall costs without eliminating necessary safeguards.

The OpGUI provides authorized users the capability to alter the subscription version status in and out of conflict. To alter the status of a subscription version, a query must be used to locate the subscription version.  This is performed in the Query Subscription window shown in Exhibit 2.5-8.  The ported TN or version ID are required data to successfully perform the query and retrieve the subscription [R5-42].  The flow for placing a version subscription in or out of conflict is shown in Exhibit 2.5-12.  Version state

288

changes for conflict-on and conflict-off generate the appropriate notifications to both involved service providers (via a subscriptionVersionStatusAttributeValueChange notification from the subscription VersionNPAC object).

2.5.1.2.2.3.1   Placing a Subscription Record in Conflict (RFP Sect. 5.1.2.2.3.1)

Conflict processing is invoked only for a minimal case of NPAC SMS processing, or upon explicit request of either service provider.

If, querying the version in the OpGUI, the status of the selected subscription version is pending, the conflict option is selectable in the OpGUI screen [R5-44].  Otherwise, the conflict option is not selectable [R5-43].  If selected, the subscription version is saved with the updated version status. The version status associated with the subscription version will be modified to conflict [R5-10, R5-44].  If the conflict request passes validation, the conflict time stamp is populated with the current date and time and the originator of the request is notified of successful completion [R5-44].  In addition, a subscription-

VersionStatusAttributeValueChange notification is sent to both service providers’ SOAs informing them of the change in version status.  This is visible to the authorized user in the subscription version scrolled list in the subscription query window shown in Exhibit 2.5-8.  If the subscription version remains in

289

conflict for the period indicated in the ‘Version Conflict Cancellation Window’ tunable parameter (30 days default), the subscription is automatically canceled by the NPAC SMS [R5-45].

In addition to using the OpGUI, a version may be placed into conflict from the mechanized interface by an explicit non-concurrence from the old service provider on its initial create.  Again, a notification is sent to the new service provider informing it of the change and the need for the two providers to resolve the dispute between themselves.

290

2.5.1.2.2.3.2   Removing a Subscription Record from Conflict (RFP Sect. 5.1.2.2.3.2)

Automated conflict removal via the mechanized interface and manually is supported to streamline the removal of conflict status.

An authorized user is permitted to remove a subscription version from conflict if the version status of the subscription selected in the subscription scrolled list in Exhibit 2.5-8 is conflict [R5-10, R5-46, R5-48].  If the user permissions or subscription status do not meet the criteria, the conflict option is not selectable, thus preventing the user from making an error and omitting the need for an error dialogue and acknowledgment [R5-47].

After changing the subscription version with the updated version status, the subscription version data is validated [R5-48].  If the subscription version passes validation, the version status associated with the subscription version is modified to pending [R5-50].  This is visible to authorized users in the subscription version scrolled list in the subscription query window shown in Exhibit 2.5-8.  If the version validation fails, the SMS issues an error message to the originator, a new version is not created and the current version remains in conflict [R5-49].

Once the conflict is resolved, the new service provider may initiate a conflict resolution process via the mechanized interface, which requires the old service provider to acknowledge the removal from conflict status.  If acknowledgment is not received within two tunable periods of time—each causing an acknowledgment request to be sent—then the version is returned to conflict.  If acknowledgment is received, then the version resumes its prior status (pending).  In all cases, any change in status of the version is reported back to both service providers.

291

2.5.1.2.2.4   Subscription Record Activation (RFP Sect. 5.1.2.2.4)

Version activation is performed in a timely and robust fashion to minimize service disruption to the end-user.

Once the physical cut-over process for moving an end-user’s facilities over to the new service provider is complete, the new service provider performs a version activation to cause all network routing data (via the LSMS interfaces) to be updated with the updated routing information.  Activations may be initiated from both the mechanized SOA interface and from authorized OpGUI sessions.

The OpGUI provides authorized users the capability to activate subscription versions associated with a specified service provider [R5-9].  The flow for version activation is shown in Exhibit 2.5-13.  The TN or the version ID is required to successfully perform the query and retrieve the subscription [R5-51].  An authorized user is permitted to ‘Activate’ the subscription version if the version status of the subscription selected in the subscription scrolled list in Exhibit 2.5-9is pending.  If the user permissions or subscription status do not meet the criteria, the ‘Activate’ option is not selectable, thus preventing the user from making an error and omitting the need for an error dialogue and acknowledgment [R5-52].

From the SOA interface, a version receiving an activate request must be in a pending status, otherwise an error is returned.

292

Any modifications to the version are validated when performed, otherwise the modification is rejected [R5-54], guaranteeing that the version is valid as defined in R5-18 [R5-53].  The NPAC SMS broadcasts the version update to all the LSMS interfaces [R5-55, R5-56].  The subscription version is marked with a sending status and the current date and time recorded as the Activation Broadcast Date and Time Stamp [R5-57].  Based on the NPA-NXX of the TN to be downloaded, the NPAC SMS identifies all interested LSMSs using the NPA-NXX table described in Section 2.3.  A download operation (see Section 2.6) is broadcast to each LSMS identified [R12-1].  The NPAC SMS logs the activation responses from the

293

LSMSs and makes them accessible to authorized users [R5-58].  If a positive response is received from all involved LSMSs, the new subscription version is marked as active and the previously active version (if there is one) marked as old [R5-59].

If activation fails because of a network node failure, the activation message remains in a retry queue and is resent to the LSMS that failed.  Re-transmissions are attempted at a tunable interval called ‘Activation Send Interval’ listed in the Service Data Table in Section 2.3 [R5-60].  The maximum number of resends is a tunable parameter called ‘Activation Send Retries’ in the Service Data Table.  If successful activation is not achieved for a particular LSMS, notification is sent to the NPAC administrator and special processing will be accomplished to remedy the failure.  The version status is marked as a partial failure for the activation.  However, if the activation fails at all the LSMSs, the NPAC administrator is notified by the SMS, and the status is set to failed.  In case of partial or total failure, the download results report sent to the activating SOA includes a list of the LSMSs that failed.  If, case of total download failure, there was a previous active version for the TN, it remains in effect [R5-61].

2.5.1.2.2.5   Disconnect Subscription Record (RFP Sect. 5.1.2.2.5)

Deferred as well as immediate disconnect processing is supported by the NPAC SMS.

In the case of service disconnection to a previously ported number, the current (new) service provider for that number may issue a disconnect to return the ported number to default routing.  This is equivalent to logically deleting the record from the network.  Disconnect operations are supported over both the mechanized SOA interface and the user GUI.  Disconnect requests from both the mechanized interface and the OpGUI may optionally specify an effective release date, when the NPAC SMS will process the “download” portion of the disconnect and actually broadcast the delete operations to the LSMSs [R5-65].  If no effective release date is specified, the disconnect operation is processed immediately [R5-65].

294

Also, a customer disconnect date is required on a disconnect request.  Upon the effective release date (or immediately), the disconnect date is sent to the donor service provider’s SOA as a notification.  This allows the donor service provider to take into account the amount of time the TN has been given treatment in the disconnecting network (time since customer disconnect date) in determining how long to age the TN before allowing it to be reassigned.

A version to be disconnected is referenced by the TN or version ID [R5-62].  Only an active version may be disconnected; otherwise, an error is returned [R5-63].  However, if the latest version has a status of pending, failed, or conflict and there is a previous active version still in effect, the disconnect returns an error [R5-64].  The active version must not have another version in the process of superseding it (i.e., not another pending).

From the mechanized SOA interface, a disconnect is requested by sending a disconnect action to the version object.

From the user GUI, the disconnect subscription version flow is shown in Exhibit 2.5-14.  The ported TN and LNP type are required data to successfully perform the query and retrieve the subscription [R5-62].  An authorized user is permitted to ‘Disconnect’ the subscription version if the version status of the subscription selected in the subscription-scrolled list in Exhibit 2.5-8 is ‘Active’ [R5-63].  If the selected subscription status is not active or there are additional subscription versions with a status of pending, failed, or conflict, the ‘Disconnect’ option will not be selectable, thus preventing the user from making an error and omitting the need for an error dialogue and acknowledgment [R5-64].

295

If the validation is successful, the NPAC SMS broadcasts delete messages to the LSMSs [R5-65].  The subscription version is marked with a sending status and the current date and time recorded as the broadcast date and time stamp [R5-65].  The NPAC SMS logs the delete responses from the LSMSs [R5-66].  If a delete response is received from all of the LSMSs, the disconnect date is updated and the current version status marked as old.

If disconnect fails because of a network node failure, the delete message remains in a retry queue and is resent to the LSMS(s) that failed. The resends are sent at a tunable interval called ‘Disconnect Send

296

Interval’ listed in the Service Data Table [R5-68], initially the default interval will be 2 minutes.  The maximum number of resends is a tunable parameter called ‘Disconnect Send Retries’ in the Service Data Table which will initially default to 3 retries. If disconnect is not achieved for a particular LSMS, notification is sent to the NPAC administrator and special processing is performed to remedy the failure.  The version status is marked as a partial failure for the disconnect.  However, if the disconnect fails at all the LSMSs, the NPAC administrator is notified by the SMS, and the status is set to failed [R5-67].

2.5.1.2.2.6   Subscription Record Cancellation (RFP Sect. 5.1.2.2.6)

Version cancellation may be performed via the mechanized interface and the OpGUI, and requires acknowledgment by both service providers.

Subscription versions with a status of pending or conflict can be canceled.  Cancel operations may be performed through both the mechanized SOA interface and through the OpGUI. A cancel request must be acknowledged by both SPs, including when a record is in conflict.  While waiting for acknowledgment, a version is in cancel pending state.

Through the mechanized SOA interface, a cancel operation is initiated by sending a subscriptionVersionCancel action to the lnpSubscriptions contained object, specifying the TN or the version ID attribute value to identify the intended subscriptionVersionNPAC object of the cancel [R5-69].

To cancel a subscription version through the user GUI, an authorized user performs a query to locate the subscription version.  Queries are performed using the Query Subscription Window shown in Exhibit 2.5-8.  The version ID or the subscription TN are required to successfully perform the query [R5-69].  The query returns all (the most recent) versions of the subscription placing them in the query results list

297

in the subscription query window.  The amount of data retrieved for SP searches is restricted consistent with the limits applied for scoped and filtered M-GETs across the mechanized SOA interface.  The user uses this list to choose the specific subscription version to be canceled.  If there are no subscriptions matching the search criteria, the user is notified with an information dialogue message requiring acknowledgment [R5-70].  The flow for canceling a subscription version is shown in Exhibit 2.5-15.

A subscription version status must be pending or conflict before authorized users can cancel it [R5-69].  If the subscription version status is not pending or conflict or the user security permissions are insufficient, the cancel option on the OpGUI is not enabled.  This prevents the user from creating a cancellation status error requiring the error notification requirement stated in R5-70.

When the status of the subscription version is successfully set to canceled, the subscription record cancellation date and cancellation time stamp are populated with the current date and time.  The originator of the request is notified indicating successful completion of the cancellation process [R5-71].

2.5.1.3   Subscription Queries (RFP Sect. 5.1.3)

Use of common NPAC SMS query semantics between both mechanized and user interfaces enforces consistency in NPAC/SMS policies and functionality.

298

Subscription versions may be queried for any ported TN without changing the subscription data [R5-13 and R5-72].  Again, both the mechanized SOA interface and the NPAC user GUI support this functionality.

Through the mechanized SOA interface, queries may be performed by sending a properly scoped and filtered M-GET to the lnpSubscriptions object at the NPAC.  If one or more versions are found, copies of the subscriptionVersionNPAC objects containing the attributes listed in [R5-74] are returned in reply to

299

the M-GET, subject to the maximum query limit tunable described in Section 2.3.  If no versions are found matching the criteria specified, an appropriate error response is returned indicating no matching versions were found.

The NPAC SMS will return the following output data for a subscription version query request initiated by NPAC personnel or an SOA to NPAC SMS interface user: [R5-74]

•Subscription Version ID

•Subscription Version Status

•Local Number Portability Type

•Ported Telephone Number

•Old Facilities-based Service Provider Due Date

•New Facilities-based Service Provider Due Date

•New Facilities-based Service Provider ID

•Old Facilities-based Service Provider ID

•Authorization from Old Facilities-based Service Provider

•Location Routing Number (LRN)

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

300

•Billing Service Provider ID

•End-User Location Value

•End User Location Type

•Customer Disconnect Date

•Effective Release Date

•Disconnect Broadcast Complete Time Stamp

•Conflict Time Stamp

•Activation Time Stamp

•Cancellation Time Stamp

•New Service Provider Creation Time Stamp

•Old Service Provider Authorization Time Stamp

•Pre-cancellation Status

•Old Service Provider Cancellation Time Stamp

•New Service Provider Cancellation Time Stamp

•Old Time Stamp

•Old Service Provider Conflict Resolution Pending Time Stamp

•New Service Provider Conflict Resolution Pending Time Stamp

•Create Time Stamp

•Modified Time Stamp

•Porting to Original

•List of all Local SMSs that failed activation, modification, or disconnect.

For queries to the NPAC SMS from an LSMS, only active records are visible, and only the following attributes will be returned:
[R5-74]

301

•Subscription Version ID

•Ported Telephone Number

•Location Routing Number (LRN)

•New Facilities-based Service Provider ID

•Activation Time Stamp

•Class DPC

•Class SSN

•LIDB DPC

•LIDB SSN

•CNAM DPC

•CNAM SSN

•ISVM DPC

•ISVM SSN

•End-User Location Value

•End-User Location Type

•Billing Service Provider ID

•Local Number Portability Type.

The OpGUI can also be used to retrieve the service provider’s subscription version for a single TN.  A process flow for subscription queries is shown in Exhibit 2.5-10.  The authorized user can perform queries using the Query Subscription Window shown in Exhibit 2.5-8.  Allowed query criteria include: version ID, subscription TN, and version states [R5-73].  The query returns all versions of the subscription data matching the specified criteria [R5-74], placing them in the query results list in the Query Subscription Window shown in Exhibit 2.5-8.  The user can choose the specific subscription

302

version to be viewed from this list.  If there are no subscriptions matching the search criteria, the user is notified with an information dialogue message requiring acknowledgment [R5-75].

303

NYCAC NPAC/SMS PROPOSAL 2.6 NPAC SMS Interfaces

HIGHLIGHTS

•The Lockheed Martin Team provides world-class depth of NPAC/SMS and CMIP experience, minimizing the deployment risks for service providers and higher certainty of satisfying regulatory LNP deployment timetables

•Completely neutral and experienced Team guarantees openness and responsiveness in maintaining complete interface specifications.  Developed current interoperable interface specification (IIS) document in conjunction with the Illinois NPAC SMS Committee

•Interface certification testing services are available to service providers and their vendors to validate SOA and LSMS interface implementation early in development cycle

•Extensive Team experience in CMIP security, applications, development toolkits (GDMO compilers), testing, management, information modeling, and standards

•CMIP mechanized interfaces complemented with low-tech, web-based, user GUI—allows deferral of SOA upgrades to support CMIP interface to NPAC

2.6NPAC SMS INTERFACES

(RFP Sect. 6)

The Lockheed Martin Team proposes world-class depth of CMIP experience, minimizing the deployment risks for service providers and providing higher certainty of satisfying regulatory LNP deployment timetables.

The Lockheed Martin Team has experience in developing telecommunications software systems that employ the same technologies required in the NPAC SMS.  We provide the highest level of credibility and neutrality in deploying the NPAC SMS system and its interfaces.  For example, our team is:

•Experienced in: CMIP/TMN, web (HTTP), number portability, security, industry standards, and number administration operations

•The leading supplier of turnkey business service operations, systems integration, and number administration services (Lockheed Martin)

•The leading supplier of TMN-related development and testing tools (DSET)

304

•The leading supplier of telecommunications software engineering services for service providers and their network equipment vendors (ESI)

•The leading supplier of continuously available computer system platforms to mission-critical telecommunications applications (Stratus).

The Lockheed Martin Team developed the current industry NPAC SMS Interoperable Interface Specification (IIS) document in conjunction with the Illinois NPAC SMS Committee, representing six months of effort iterating the interface design with the input and feedback from service providers and their vendors/implementers.  We hosted a three-day NPAC Interface Forum in July to present to the industry the details of the interface design, and we plan to host another public Interface Forum November 1996.  Recognizing the criticality of standardizing and gaining consensus on a fully-open, non-proprietary NPAC interface standard, Lockheed Martin has ensured that the NPAC interfaces always remain in the public domain by requiring that any derived works from the IIS are also placed in the public domain.  This is accomplished by maintaining a copyright on the IIS document, with the approval of the Illinois NPAC SMS Committee, and providing full rights to modify and distribute the document in any form subject to the terms of the GNU General Public License (GNU GPL), the industry standard for permanently placing works in the public domain.  Further, the machine readable GDMO and ASN.1 source code definitions of the object model are freely available, also protected by the GNU GPL.

Similar to other sections of our proposal, the term “service provider” is used synonymously in this section with the terms “user” and “NPAC/SMS user,” and is not meant to distinguish between different types of NPAC customers (e.g., facilities- vs. non-facilities-based, or third-party

305

transaction providers).  Also, the term “service provider” is used synonymously with the term “SOA user” in the context of service provider actions performed over the SOA to NPAC SMS interface or via the OpGUI.  Finally, the term “subscription version” is used synonymously with the term “subscription record.”  A subscription version is a record in the NPAC SMS database referring to the state of a number port activity at a point in time.  Ported number records are referred to as subscription versions.  Each version references a single telephone number and has a specific state and timestamp associated with that particular record.  There may be multiple versions for a given number in the NPAC SMS, each representing the porting state of that number at different points in time, e.g. future (pending), present (active), past (old).

This section defines the interfaces between the NPAC SMS and the service providers’ Service Order Administration (SOA) system and their LSMS.  These CMIP interfaces are referred to as the SOA to NPAC SMS interface and the NPAC to LSMS interface respectively.  The NPAC SMS Operational GUI (or OpGUI) also provides a web-based interface to support SOA-like functionality for NPAC personnel and authorized service provider personnel.

The NPAC OpGUI, introduced in Section 2.1.3.2 (above), is a highly-secure, standardized, GUI supporting both internal NPAC operations personnel and external NPAC end-users.  NPAC end-users may use the OpGUI on the NPAC to provide surrogate SOA functions by directly interacting with the NPAC, thereby providing a ‘low-tech’ interface to the NPAC SMS to support SOA functions.  This Lockheed Martin-originated enhancement was first offered in the Lockheed Martin NPAC/SMS proposal to Illinois, and has since been adopted as desired, and in some cases mandatory, functionality for NPACs in other regions.  It significantly reduces the NPAC user deployment effort by eliminating the need to update existing SOA systems to accommodate the CMIP-based SOA interface to the NPAC.  Consequently, service providers can focus on deployment of the LSMS/SCP facilities necessary for LNP

306

deployment in their networks, and defer upgrades or replacements of their existing SOAs as a separate business decision.  Consequently, the overall deployment risk of LNP is reduced, in support of the commendably aggressive timetables in the FCC LNP order (96-286).

Exhibit 2.6-1 summarizes the CMIP implementation of the NPAC interfaces by function and identifies the interface type (LSMS vs. SOA), the direction of the operation, and the specific CMIP operation and referenced object type.

307

Function	Direction (To/From)	CMIP Operation	Referenced Object Type
Abort/Cancel Audit Request	from SOA	M-DELETE	subscriptionAudit
Audit Complete	to SOA	M-EVENT-REPORT:  subscriptionAuditResults	subscriptionAudit
Audit Discrepancy	to SOA	M-EVENT-REPORT:  subscriptionAuditDiscrepancyRpt	subscriptionAudit
Audit Request SOA	from SOA	M-CREATE	subscriptionAudit
Cancellation Acknowledgement	from SOA (new service provider)	M-EVENT-REPORT: subscriptionVersionNewSPCancellationAcknowledge	lnpSubscriptions
Cancellation Acknowledgement	from SOA (old service provider)	M-EVENT-REPORT: subscription VersionOldSPCancellationAcknowledge	lnpSubscriptions
Conflict Resolution Acknowledgement	from SOA (new service provider)	M-EVENT-REPORT: subscription VersionNewSP-Conflict ResolutionAcknowledge	lnpSubscriptions
Conflict Resolution Acknowledgement	from SOA (old service provider)	M-EVENT-REPORT: subscription VersionOldSP-Conflict ResolutionAcknowledge	lnpSubscriptions
Conflict Resolution Pending	from SOA (new service provider)	M-ACTION: subscriptionVersionNewSP-ConflictResolutionPending	lnpSubscriptions
Customer Disconnect Date	to SOA	M-EVENT-REPORT: subscriptionVersionDonorSP-CustomerDisconnectDate	subscriptionVersionNPAC
Network Data Download	from LSMS	M-ACTION: lnpDownload -or- M-GET: scoped and filtered for intended serviceProvLRN, serviceProvNPA-NXX service provider attributes.	lnpNetwork
Exhibit 2.6-1 Summary of functions via the Mechanized SOA and LSMS Interface. (Page 1 of 3)
Network Data Update	from LSMS or from SOA	M-CREATE: or M-SET: on relevant serviceProvLRN, serviceProvNPA-NXX service provider attributes.	serviceProvLRN, serviceProvNPA-NXX

308

Function	Direction (To/From)	CMIP Operation	Referenced Object Type
New NPA-NXX	to LSMS	M-EVENT-REPORT: subscriptionVersionNewNPA-NXX	subscriptionVersionNPAC
Recovery Complete	from LSMS	M-ACTION: lnpRecoveryComplete	lnpNPAC-SMS
Request for Cancellation Acknowledgement	to SOA	M-EVENT-REPORT: subscription VersionCancellationAcknowledgment Request	subscriptionVersionNPAC
Request for Conflict Resolution Acknowledgement	to SOA	M-EVENT-REPORT: subscription VersionConflictResolutionAcknowledgment Request	subscriptionVersionNPAC
Request for Version Create	to SOA (old service provider)	M-EVENT-REPORT: subscriptionVersionOldSPConcurrence Request	subscriptionVersionNPAC
Request for Version Create	to SOA (new service provider)	M-EVENT-REPORT: subscriptionVersionNewSPCreate Request	subscriptionVersionNPAC
Subscription Version Activate	from SOA	M-ACTION:  subscriptionVersionActivate	lnpSubscriptions
Subscription Version Cancel	from SOA	M-ACTION: subscriptionVersionCancel	lnpSubscriptions
Subscription Version Change Notification	to SOA	M-EVENT-REPORT: attributeValueChangeNotification or subscriptionVersionStatusAttributeValue Change	subscriptionVersionNPAC
Subscription Version Conflict	from SOA (old service provider)	M-ACTION: subscriptionVersionOldSP-Create setting subscriptionOldSP-Authorization = FALSE Note: This is an enhancement based on the current IIS, superseding RFP narrative 5.1.2.2 for manual-only conflict on/off	subscriptionVersion
Exhibit 2.6-1 Summary of functions via the Mechanized SOA and LSMS Interface. (Page 2 of 3)
Subscription Version Create	from SOA	M-ACTION: subscriptionVersionOldSP-Create or subscriptionVersionNewSP-Create	lnpSubscriptions
Subscription Version Delete	to LSMS	M-DELETE: scoped and filtered for intended subscriptionVersion criteria.	subscriptionVersion
Subscription Version Disconnect	from SOA	M-ACTION: subscriptionVersionDisconnect	lnpSubscriptions

309

Function	Direction (To/From)	CMIP Operation	Referenced Object Type
Subscription Version Download	to LSMS	M-ACTION: on a range of TNs subscriptionVersionLocalSMS-Create -or- M-CREATE:  for an individual subscriptionVersion	lnpSubscriptions
Subscription Version Download Request	from LSMS	M-ACTION: lnpDownload -or- M-GET:  scoped and filtered for intended subscriptionVersionNPAC criteria.	lnpSubscriptions
Subscription Version Modify	from SOA	M-ACTION:  subscriptionVersion Modify -or- M-SET: on relevant subscriptionVersionNPAC attributes for pending, active, conflict-pending, conflict versions.	lnpSubscriptions
Subscription Version Modify	to LSMS	M-SET: scoped and filtered for intended subscriptionVersion criteria setting relevant attributes.	lnpSubscriptions
Subscription Version Query	from SOA from LSMS	M-GET: scoped and filtered for intended subscriptionVersionNPAC criteria setting relevant attributes.	lnpSubscriptions
Subscription Version Query	to LSMS	M-GET: scoped and filtered for intended subscriptionVersion criteria.	lnpSubscriptions
Exhibit 2.6-1 Summary of functions via the Mechanized SOA and LSMS Interface. (Page 3 of 3)

310

2.6.1   SOA to NPAC SMS Interface (RFP Sect. 6.1)

The mechanized SOA to NPAC SMS interface provides complete functionality for subscription version administration and audits to ensure seamless NPAC SMS operation with service providers.

The SOA to NPAC SMS interface, which allows communication between a service provider’s Service Provisioning Operating Systems and/or Gateway systems and the NPAC SMS, supports the retrieval and update of subscription information. This secure interface, as defined in IIS, uses strong two-way peer authentication with encryption to prevent unauthorized access.  The following SOA processes are supported via the interface:

•SOA requests for subscription administration to the NPAC SMS and responses from the NPAC SMS to the SOA.

•Audit requests from the SOA to the NPAC SMS and responses from the NPAC SMS to the SOA.

•Notifications from the NPAC SMS to the SOA of subscription version data changes, need for concurrence or authorization for number porting, conflict-resolution, cancellation, outage information, or customer disconnect dates.

•Service provider data administration from the SOA to the NPAC SMS.

311

2.6.1.1   Request Administration (RFP Sect. 6.1.1)

The SOA interface provides a highly modular, extensible, two-way communications path between the NPAC SMS and service providers.

The SOA to NPAC SMS Interface supports the following request administration functions:

•SOA requests for subscription administration and responses from the NPAC SMS to the SOA.

•Audit requests from the SOA to the NPAC SMS and responses from the NPAC SMS to the SOA.

•Notifications from the NPAC SMS to the SOA.

To use the SOA to NPAC SMS interface for execution of the above transactions, the SOA must, as defined in the Section 2.7.8 “OSI Security Environment” [R6-1], establish an association providing user ID, system ID, and password for strong authentication.

Each subscription administration request sent over the interface is capable of supporting multiple independent transactions that can fail without causing the whole request to fail, similar to the CMIP implementation of CARE record management per ANSI T1.246 [R6-2].  All subscription administration requests are acknowledged with at least one response transaction from the NPAC SMS [R6-3], since all CMIP operations are performed in confirmed mode.  Atomicity and recovery of subscription operations are assured at the NPAC by waiting until confirmation of any interface operation has been received before committing the associated database transactions.

312

2.6.1.2   Subscription Administration (RFP Sect. 6.1.2)

Complete subscription administration functionality is implemented to provide full SOA functionality.

Service providers’ subscription administration functionality includes the capability over the SOA interface to:

•Create a subscription version or range of versions [R6-4]

•Modify a subscription version or range of versions [R6-4]

•Activate a version or range of versions [R6-6]

•Disconnect a subscription version or range of versions [R6-6]

•Cancel a subscription version [R6-4]

•Acknowledge cancellation of a subscription version

•Remove a subscription version from conflict

•Acknowledge resolution of a subscription version conflict

•Retrieve a specific subscription version or range of versions [R6-5].

Service providers create versions from the SOA using an M-ACTION to the NPAC SMS.  Version modification, activation, and cancellation are accomplished using an M-ACTION or, optionally, an M-SET to the NPAC SMS.  Service providers can disconnect subscribers using an M-ACTION to the NPAC SMS.  M-EVENT-REPORTS (notifications) are sent to involved SOAs for object creation, deletion, and attribute value changes.

For retrieving subscription versions, the M-GET operation is used to retrieve specific subscription version for a TN.  A scoped, filtered M-GET is used to retrieve all subscription versions for a TN.  Other

313

types of filtering and scoping operations are supported for subscription versions in the SOA to NPAC SMS interface.

2.6.1.3   Notifications (RFP Sect. 6.1.3)

SOA notifications ensure that involved service providers’ SOAs are fully informed of relevant events for their subscriptions.

SOAs are sent notifications to ensure that they are fully informed of relevant events for their subscriptions.  Notification of creation, deletion, or data value changes for subscription versions will be sent to the SOA as they occur.  Based on tunables specified in the NPAC SMS Service Data Table shown in Section 2.3, notification may be sent to service providers as part of the subscription administration process.  If a service provider has not authorized transfer of service for a TN in the number of days specified in the “Service Provider Concurrence Window” variable, an M-EVENT-REPORT is sent to the service provider via the SOA to NPAC SMS interface [R6-7].  This notification will indicate to the service provider that authorization is needed for the pending subscription version.  If the service provider has not acknowledged version conflict resolution or cancellation within a timeframe specified by the NPAC SMS, notifications will be sent requesting conflict resolution acknowledgment or cancellation acknowledgment. The donor service provider SOA is notified of the customer’s disconnect date. SOA systems are also sent notifications to ensure they are aware of planned down time in the NPAC SMS.

If a due date for a subscription has been modified by the old or new service providers, an M-EVENT-REPORT is sent to the service providers via the SOA to NPAC SMS interface indicating that the value has changed [R6-8].

314

2.6.1.4   Service Provider Data Administration

The Lockheed Martin NPAC service allows service providers to view and modify their service provider data directly through the mechanized interface with the NPAC to further automate the management of NPAC service provisioning.

Service providers can use, read, and update their own service provider information on the NPAC SMS using the SOA to NPAC SMS interface [R6-;  Page 53], or the LSMS to NPAC SMS interface.  Service providers can update information in their service provider profile as well their own network data.  Changes to network data that result in mass updates are prevented by the NPAC SMS to SOA interface.  Mass changes must be initiated by the service provider contacting the NPAC personnel directly.

2.6.2   NPAC SMS to LSMS Interface (RFP Sect. 6.2)

The LSMS mechanized interface supports real-time downloads of LNP routing data to facilitate timely cut-overs of the end-user’s service.

The NPAC SMS to LSMS interface is used for communication between a service provider’s LSMS and the NPAC SMS for support of LNP network element provisioning.  This interface, as defined in the IIS developed by Lockheed Martin, is also a secure interface that uses strong two-way peer authentication with encryption to prevent unauthorized access.

2.6.2.1   Transaction Administration (RFP Sect. 6.2.1)

Two-way LSMS to NPAC SMS communications help ensure accuracy and timeliness of LNP routing data to service provider networks.

315

The NPAC SMS to LSMS interface supports the following LSMS-related functions:

•Subscription download from the NPAC SMS to the LSMS

•Network data download from the NPAC SMS to the LSMS

•LSMS requests for subscriber and/or network data download from the NPAC SMS and responses from the NPAC SMS to the LSMS

•Queries from the NPAC SMS to the LSMS and responses from LSMS to the NPAC SMS, for audits and mutual-database sampling integrity checks

•LSMS requests for viewing and updating their own service provider information to the NPAC SMS and responses from the NPAC SMS to the LSMS

•Notifications from the NPAC SMS to the LSMS of planned NPAC SMS outages and the first use of a new NPA-NXX.

To use the NPAC SMS to LSMS interface for execution of the transactions above, an LSMS must establish an association providing user ID, system ID, and password, as defined in Section 2.7.8, “OSI Security Environment” [R6-9].

2.6.2.1.1   Subscription and Network Data Download

Extensive network data download and query capability guarantees consistent network data for both default LNP routing and NPAC/SMS data validations.

When downloading new or modified network or subscription data from the NPAC SMS to the LSMS, a confirmed CMIP M-CREATE or M-ACTION is used.  If for some reason there is a failure returned by the LSMS on the response indicating a need to resend the download request for some or all of the

316

objects, it is resent by the NPAC SMS at a later time. [R6-10, R6-11, R6-15].  The LSMS is able to request subscriber information to be downloaded from the NPAC SMS by using the CMIP M-GET [R6-10], or request a time-range resend by sending a CMIP M-ACTION.  The LSMS is able to request a subscription or range of subscriptions based on filter criteria [R6-12].  Filters provide the capability to support a variety of subscriber data download requests such as requests for a TN, a range of subscriptions based on a time range, or a range of subscriptions based on service provider [R6-14].  Network data can also be downloaded to the LSMS from the NPAC SMS by using the CMIP M-GET [R6-15].  NPA-NXX data can be downloaded using filter criteria specified by the LSMS.  Filters provide the capability to support a variety of network data download requests such as requests for specific NPA-NXX, a range of NPA-NXXs, or all network data for a service provider.

2.6.2.1.2 Subscription Audits

Subscription auditing enables the NPAC SMS to verify network routing data through selected LSMSs to support accurate updates of LNP routing information.

The specific audit process employed over the NPAC SMS to LSMS interface has been modified since the RFP requirements were originally drafted last year as a result of the interactive development of the IIS in the Illinois NPAC SMS Committee.  Three types of audits result in NPAC SMS to LSMS interface audit activity:

•Service provider-initiated, on-demand audits (Type I — Repair Audits)

•NPAC-initiated audits, which use the same methodology as Type I — Repair Audits, for service (e.g., broadcast) assurance.

317

•Background mutual-database sampling integrity audits performed by the NPAC (Type II - Network Integrity Audits)

All three types of audit functions are supported over the LSMS interface by the NPAC querying/viewing an LSMS for a subscription or range of subscriptions in question [R6-12], and performing the comparison of the retrieved data at the NPAC.  A CMIP M-GET operation is used by the NPAC to query/view the LSMS.  This operation may be filtered and scoped to obtain multiple subscriptions in one query, if appropriate.

The LSMS query in support of audits supports the capability to request a subscription or range of subscriptions based on TN [R6-12], or other criteria, such as activation timestamp.  The query response allows the NPAC to determine audit pass or failure for each subscription TN requested [R6-13].  If discrepancies are found during the audit execution, M-EVENT-REPORTS are sent at the time they are discovered from the NPAC SMS to the SOA containing the discrepancy information [R6-13].  Full audit capability for the NPAC SMS to LSMS is described in detail in Section 2.8.  An LSMS may also query the NPAC or request the NPAC to resend a subscription or a range of subscriptions, based on criteria such as TN range or activation timestamp.  An LSMS may use a CMIP M-GET operation, including filtering and scoping criteria, to perform an NPAC query, or may send an lnpDownload M-ACTION to the NPAC SMS to request a resend [R6-14].  Download operations to the LSMS are required to be acknowledged (all CMIP operations are performed in confirmed mode) by the LSMS, thereby providing the NPAC SMS with an indication of the results of the download [R6-15].

318

2.6.2.1.3   Service Provider Data Administration

Functionality to support viewing and modification of service provider and network data from the NPAC SMS to LSMS or SOA interface is recommended to ensure consistency between validations performed by the NPAC SMS and actual SP network data used by the LSMS and SCPs. This gives service providers increased utility and decreases their dependencies on NPAC personnel.

Service providers are only authorized to M-GET and M-SET their own service provider network data.  Service providers are also authorized to M-CREATE, M-DELETE, M-GET, and M-SET their own network data in addition to being able to M-GET the network data associated with other service providers.  Changes to network data that result in mass updates are also prevented by the NPAC SMS to LSMS interface.  Service Providers have to contact the NPAC personnel directly to initiate mass changes in the LNP network.

2.6.2.2   Network Subscription Administration (RFP Sect. 6.2.2)

Subscription versions are administered by the NPAC SMS to ensure consistency of LNP routing data in the network.

The NPAC SMS performs subscription administration for creating, modifying, and deleting subscription data in the network and for audit requests.  The NPAC SMS adds, deletes, and modifies subscription information on the LSMS, using the CMIP operations specified in Exhibit 2.6-1.  The NPAC SMS may download, modify, or delete, subscription data [R6-16] as described above in Section 2.6.2.1.  When requesting audits of subscriptions, the NPAC SMS has the capability to specify a subscription or range of subscriptions [R6-17].  Full audit capability for the NPAC SMS to LSMS is described in the Audit Administration Section 2.8.

319

2.6.3   Interface Transactions (RFP Sect. 6.3)

The full CMISE suite of confirmed primitives is utilized to minimize cost and overhead of mechanized interface communications.

The SOA to NPAC SMS interface and the NPAC SMS to LSMS interface use the CMIP protocol.  M-CREATE, M-DELETE, M-SET, M-GET, M-CANCEL-GET, M-EVENT-REPORT (notification), and M-ACTION CMISE primitives are supported.  The interfaces are defined using these services in a manager-agent relationship [R6-18].  All CMISE primitives are used in confirmed mode.  The errors supported for each CMISE primitive in the interfaces are shown in Exhibit 2.6-2.

CMISE Primitive	Errors
M-EVENT-REPORT (notification)	invalidArgumentValue, noSuchArgument, noSuchObjectClass, noSuchObjectInstance, processingFailure
M-GET	accessDenied, classInstanceConflict, complexityLimitation, getListError, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, resourceLimitation, syncNotSupported
M-SET	accessDenied, class-InstanceConflict, complexityLimitation, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported
M-ACTION	accessDenied, class-InstanceConflict, complexityLimitation, invalidArgumentValue, invalidFilter, invalidScope, noSuchAction, noSuchArgument, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported
M-CREATE	accessDenied, class-InstanceConflict, duplicateManaged-ObjectInstance, invalidAttributeValue, invalidObjectInstance, missingAttributeValue, noSuchAttribute, noSuchObjectClass, noSuchObject-Instance, processingFailure
M-DELETE	accessDenied, class-InstanceConflict, complexityLimitation, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported
M-CANCEL-GET	mistypedOperation, noSuchInvokeID, processingFailure
Exhibit 2.6-2.  Summary of standard CMIP primitive errors

2.6.4   Interface and Protocol Requirements (RFP Sect. 6.4)

Fully open, non-proprietary, mechanized interface specifications ensure that key LNP technology remains available to the industry and all service provider and vendor participants.

320

The SOA to NPAC SMS interface and the NPAC SMS to LSMS interface definitions provided in the IIS, authored by the Lockheed Martin Team, are open, non-proprietary interfaces [R6-19], permanently placed into the public domain to prevent any entity from attempting to create a proprietary derived work.

Switched, as well as dedicated communications links, are supported over high capacity reliable and redundant links.  See Section 2.1 (above) for detailed information about the connectivity provided the NPAC SMS to support the SOA and LSMS interfaces and the remote web access.

321

2.6.4.1   Protocol Requirements (RFP Sect. 6.4.1)

2.6.4.1.1   OSI Protocol Requirements

Robust, cost effective, and high performance OSI stack implementation ensures interface availability and expandability.

The SOA to NPAC SMS interface and the NPAC SMS to LSMS interface are implemented over the OSI protocol stack [R6-20] shown in Exhibit 2.6-3.  The NPAC Operational GUI service provider SOA support is implemented over the local and remote web interface shown in Exhibit 2.6-3.

Layer	Mechanized Interface	Local & Remote Users	Function
	CMIP Agent Server	Secure Web Server (Netscape Server)	User
7	CMISE, ACSE, ROSE	HTTPS	Application
6	ANSI T.224		Presentation
5	ANSI T.224	SSL	Session
4	TCP, RFC1006	TCP	Transport
3	IP	IP	Network
2	PPP, FR, MAC, ATM	PPP, FR, MAC, ATM	Link
1	DS-1/3, DS-0 x n, ISDN, V.34	DS-1/3, DS-0 x n, ISDN, V.34	Physical

Exhibit 2.6-3. NPAC SMS primary network protocol stacks.

The DSET CMIP TMN Agent ToolBox is used to create the CMIP Protocol Adapters in the NPAC SMS necessary to process transactions to and from the SOAs and LSMSs.  The DSET TMN Agent Tool box

322

provides a GDMO compiler, a CMIP agent server, a high-performance ROSE/ACSE/CMISE layer protocol stack with built-in security features per 2.7, a GDMO agent test, an ASN.1 C/C++ toolkit, and other advanced features that simplify agent development, significantly reducing the development time of the NPAC SMS.  The Stratus UX OSI/9000 Core Stack layered software product provided by Stratus is used for RFC1006-compliant lower layer support, and is identical to the HP-UX OSI/9000 stack product from HP.

Multiple associations per service provider can be supported by either protocol stack [R6-21].  Furthermore, there are different functional services that any individual interface association may request, as indicated in Exhibit 2.6-4.  For example, administration of network and service provider data may be performed from either the SOA or LSMS, based on the functional data units requested for any specific association to the NPAC SMS.  For further information on multiple association support, see Section 2.6.4.2 below and the IIS.

2.6.4.1.2   Web-based User GUI Protocol Requirements

A functionally consistent and alternate interactive web-based GUI ensures that all mechanized interface operations can also be manually invoked within the NPAC or by service provider personnel.

The NPAC Operations GUI is implemented using the secure web protocol (HTTPS).  Exhibit 2.6-3 illustrates this stack.  When a user’s web browser attempts to establish an HTTPS (secure web application protocol) session with the NPAC SMS, the SSL (secure sockets layer) protocol is initialized.

323

	Association Request Initiator
Association Function Type	Appropriate for SOA	Appropriate for LSMS
SOA Management (Audit and Subscription Version) Accessible Classes: lnpSubscriptions subscriptionAudit subscriptionVersion subscriptionVersionNPAC	Yes
Service Provider and Network Data Management Accessible Classes: lnpNetwork lnpNPAC-SMS lnpServiceProvs serviceProv serviceProvLRN serviceProvNetwork serviceProv-NPA-NXX	Yes	Yes
Network and Subscription Data Download Accessible Classes: lnpNetwork lnpSubscriptions		Yes
Query/Audit Accessible Classes: All		Yes
Exhibit 2.6-4.  NPAC SMS interface functional association types.

The SSL protocol is a proposed industry standard and is currently defined in the IETF Internet-Draft SSL v3.0 (Dec. 1995) - Secure Socket Layers proposed standard.  Part of the SSL initialization sequence is a public key exchange or identification.  A key certification server within the NPAC SMS provides to the web browser the public key for the web server on the NPAC SMS.  Once the SSL initialization is complete, a secure, encrypted channel is established between the NPAC SMS web server and the user’s web browser that ensures integrity of the user’s session with the NPAC SMS.

324

On the NPAC SMS, the Open Market Secure WebServer (domestic version with RC4 encryption) provides secure sockets layer (SSL) protocol with RC4 encryption, and PKCS/X.509 key management, for secure HTTP access to the web-based user GUI.  The Fast-CGI and JAVA interfaces into the Open Market WebServer are used to translate user actions (forms uploaded/downloaded) into NPAC SMS application-level transactions.  A front-end process similar to that used with the CMIP agent server (protocol adapter) is utilized to translate the requested operation into a standard internal BACE transaction format.  Once formatted, the transaction is forwarded to BACE for actual processing.  The reverse process results in generating a response to the user, via the same APIs, to display the results of the operation.  Where common user GUI and CMIP operations are performed, the same internal BACE transaction is used for that operation.  Consequently, common operations (e.g., version creation, modification, activation, etc.) are processed in the NPAC SMS identically to ensure consistency of operation and minimize wasted software development and maintenance costs that might otherwise have been required to maintain two similar tracks of transaction processing code.

2.6.4.2   Interface Performance Requirements (RFP Sect. 6.4.2)

The mechanized interface implementation provides availability consistent with the continuously available computer and network platform on top of which it operates.

The SOA to NPAC SMS Interface and the NPAC SMS to LSMS Interface is continuously available on a 24-by-7 basis with at least 99.9% availability [R6-22 and R6-23].  The SMS NPAC interface availability is ensured not only by the hardware and software redundancy provided with the Lockheed Martin Team solution, but also by the network management operational facilities that aid in operator awareness and responsiveness to support that availability.

325

There has been much discussion within the industry concerning the necessary CMISE transaction throughput required for the NPAC SMS.  Currently, per requirements R6-24 and R6-25, NYCAC requires one (1) CMISE transaction per second per service provider SOA and Local SMS interface association.  However, from NYCAC’s answer to bidder question Q12, there also appears to be a business requirement to support a peak transaction rate of 25 ported numbers downloaded per second to each local SMS interface association.  This 25 ported numbers downloaded throughput rate is also required for NPAC SMS systems in other jurisdictions, specifically the Illinois LNP LCC, MCAC (Mid Atlantic Region), and West Coast Region, to name a few.

Using some additional assumptions that have become accepted within the industry — 1) 20% of all activations will occur using a range of numbers, and 2) the average number of ported TNs in a range activation is 20, plus using the range-activate/range-download process defined in the IIS — a range of TNs may be downloaded to the LSMS in a single CMIP operation using the subscriptionVersionLocalSMS-Create M-ACTION.  Consequently, the implementation of the 25 TNs per second business requirement as identified in question Q12 at the NYCAC NPAC/SMS Bidders’ Conference can be satisfied within the scope of existing LSMS system technologies with a derived throughput requirement of 5.2 CMISE transactions per local SMS interface association.  In addition, other jurisdictions require a throughput rate of two CMISE transactions per second for each SOA interface association.

Together, these derived CMISE requirements mean that the NPAC SMS must support a sustained load of 7.2 (SOA + LSMS) CMISE operations per second per service provider (uploader), and 5.2 CMISE operations per second (ops or tps) for each user (downloader). Our proposed NPAC SMS will support these higher, widely supported, CMISE requirements [R6-24 and R6-25], and is able to support full scalability of the NPAC SMS to continue to satisfy them in the future.  The Lockheed Martin Team has

326

spent a considerable amount of resources engineering the G-FRS and the IIS to allow both service provider systems (LSMS/SOA) and the NPAC SMS to reasonably satisfy the original business requirement (download 25 TNs/second) and allow this requirement to be met as LNP across the industry scales up to meet the significant growth in the number of participating service providers and users (i.e., growth to 50 service providers/users or more).  Our ability to creatively offer a low-risk solution to the engineering challenges of developing a world-class IIS for NPAC services is additional evidence of the Lockheed Martin Team’s commitment to the satisfy the industry’s needs for supporting LNP deployment for the long-term.

In order to support the number of associations necessary to support the LNP-participating service providers and users in New York, it will be necessary to run multiple instances of the OSI stack software and CMIP Protocol Adapters on the NPAC SMS.  The Lockheed Martin NPAC SMS can be readily configured while running to support additional CMIP protocol adapters allowing for additional associations without incurring service downtime.  Further detailed discussions of NPAC SMS capacity and performance relating to the OSI interfaces and the system as a whole are provided in Section 2.10.2.

327

2.6.4.3   Interface Model Requirements (RFP Sect. 6.4.3)

Extensive depth of CMIP and telecommunications expertise and commitment to open industry processes ensures timely availability and responsiveness to interface specifications and the standards process.

The Lockheed Martin IMS Team understands and completely supports the continued development of open, non-proprietary, specifications for these interfaces that can ultimately be standardized for operational and functional consistency of LNP administration throughout the industry [R6-26].  Any derivations (including subsequent editions) of the current IIS, whether developed by Lockheed Martin or any other entity, are now required to be placed in the public domain by virtue of Lockheed Martin’s copyright on the IIS document and the inclusion of the GNU General Public License (GNU GPL) providing full rights to modify and distribute subject to the terms of that license.  The GNU GPL requires that any derivative works continue to be subject to the GNU GPL, thereby ensuring that the NPAC interface development activity forever remains non-proprietary.

328

The interface model specified in the IIS, developed by the Lockheed Martin Team, utilizes ISO 10165-4, “Generalized Definition of Managed Objects (GDMO),” to define the object and attribute structures, and is summarized below.

IIS Overview

The following five exhibits show the class hierarchy diagram for all managed objects (Exhibit 2.6-5), Log Record Objects (Exhibit 2.6-6), the LSMS (Exhibit 2.6-7), and the NPAC SMS naming hierarchies for the LSMS (Exhibit 2.6-8) and the SOA (Exhibit 2.6-9).  These exhibits illustrate the structure of the interface definitions provided in the IIS.

Managed Object Model Inheritance Hierarchy

The Managed Object Model Inheritance Hierarchy shows the inheritance hierarchy used for object definitions in the NPAC SMS to LSMS and the SOA to NPAC SMS interfaces (Exhibit 2.6-5)

Log Record Managed Object Hierarchy

The Log Record Managed Object Hierarchy shows the inheritance hierarchy of the log records used in the NPAC SMS to LSMS and SOA to NPAC SMS interfaces (Exhibit 2.6-6).

NPAC SMS to LSMS Naming Hierarchy for the NPAC SMS

The NPAC SMS to LSMS Naming Hierarchy (Exhibit 2.6-7) for the NPAC SMS shows the naming hierarchy used in the NPAC SMS to instantiate objects defined in the NPAC SMS to LSMS interface.  Shaded objects are instantiated at NPAC SMS start-up and are not created via M-CREATE or M-DELETE requests.  All other objects are created at start-up from a persistent object store on the NPAC

329

SMS or from actions taken while the NPAC SMS is running.  Each object class belongs to one or more association functions, as identified in Exhibit 2.6-4.

NPAC SMS to LSMS Naming Hierarchy for the LSMS

The NPAC SMS to LSMS naming hierarchy (Exhibit 2.6-8) for LSMS shows the naming hierarchy used in the LSMS to instantiate objects defined in the NPAC SMS to LSMS interface.  Shaded objects are instantiated at LSMS start-up and are not created via M-CREATE or M-DELETE requests. All other objects are created at start-up from a persistent object store on the LSMS or from actions taken while the

[Graphic Omitted:  system hierarchy]

 [Graphic Omitted:  Managed object model diagram]

Exhibit 2.6-6.  NPAC IIS Managed Object Model Inheritance Diagram.

LSMS is running.  Each object class belongs to one or more association functions, as identified in Exhibit 2.6-4.

SOA to NPAC SMS Naming Hierarchy for the NPAC SMS

The SOA to NPAC SMS naming hierarchy for the NPAC SMS (Exhibit 2.6-9) shows the naming hierarchy used in the NPAC SMS to instantiate objects defined in the SOA to NPAC SMS interface.  Shaded objects are instantiated at NPAC SMS start-up and are not created via M-CREATE or M-DELETE requests.  All other objects are created at start-up from a persistent object store on the NPAC SMS or from actions taken while the NPAC SMS is running.  Each object class belongs to one or more association functions, as identified in Exhibit 2.6-4.

[Graphics Omitted:  Naming hierarchy diagrams]

330

NPA-NXX Download Filtering

Our NPAC SMS Release 2 will have several distinct features to support regionalization, including having the NPAC SMS to filter broadcasts to service provider Local SMS associations on an NPA-NXX basis [R6-27].  This allows service providers, for a specific Local SMS association, to specify the NPA-NXXs for which they would like to receive downloads [R6-27]. We will completely support this requirement by adding screening tables within the NPAC SMS for linking service providers to NPA-NXXs for downloading purposes.  Using these tables, the NPAC SMS will only send/resend downloads for a given NPA-NXX to the proper service provider local SMS associations.  It is also important to note that the existing Interoperable Interface Specification (IIS) does not have to be changed to support this filtering of downloads to service providers, because the NPAC SMS will do the screening/filtering centrally and send the appropriate downloads to the proper service provider local SMS associations using the same mechanism contained in the current IIS.

331

NYCAC NPAC/SMS PROPOSAL 2.7  Security Requirements

HIGHLIGHTS

•NPAC WAN comprehensively safeguarded via extensive access control for authentication and authorization, using smartcards, public key crypto systems (PKCS), and physical security

•Internet access fully secured via perimeter network firewall architecture and end-to-end smartcard access control using V-One’s SmartWall

•Hardened Stratus UX operating system using McAfee/FSA’s Power Login Security Software product enforces NPAC SMS server security

•Extensive application interface security via X.741/X.509/TA-1253-compliant mechanized interface security and secure HTTPS

•Audited, rigorous, development and operational practices ensures correct implementation of comprehensive security strategy

2.7SECURITY REQUIREMENTS

(RFP Sect. 7)

Our fully-compliant, comprehensive, and multi-tiered system and operational security design ensures the integrity and complete confidentiality of NPAC/SMS data.

Introduction

As a world-class systems integrator who is responsible for the operation of many national, mission-critical defense systems, Lockheed Martin is well versed in the precautions required to ensure continuous system operation, operational integrity, and data integrity.  By virtue of this highly relevant experience combined with our development of the Illinois NPAC/SMS system and work in other state workshops, we have complete understanding of the critical nature and security requirements of the NPAC/SMS.  We understand that the NPAC/SMS contains highly competitive information and sensitive ported number routing information and that access to such information must be strictly controlled.

Specifically, our security strategy for the NYCAC NPAC/SMS consists of system capabilities and processes that:

•Take advantage of operating system security mechanisms

332

•Utilize many third party tools to enhance operating system capabilities

•Use encryption wherever possible

•Enforce network configuration/connectivity prerequisites for controlling network and system access

•Safeguard the system software and control the software development process

•Control and determine NPAC/SMS system administration procedures.

After carefully reviewing NYCAC NPAC/SMS security requirements in Section 7.0 and elsewhere in the RFP, we have noted that they are identical to the security requirements of the NPAC/SMS that we are developing for Illinois.  Thus, we propose the same hardened, multi-tiered security approach that we are using for Illinois’ NPAC/SMS for use in the NYCAC NPAC/SMS.  Our proposed NPAC/SMS application software, suite of security products, and operational procedures are in complete compliance with NYCAC NPAC/SMS security requirements and oftentimes exceed the stated requirements, offering enhanced security management and functionality at no additional cost.

Several proven third party products are proposed to implement the NPAC/SMS security features, including:

•McAfee/FSA’s Power Login and Power Broker Security — UNIX security packages that harden a standard UNIX OS environment to provide extensive user, login, password, filesystem access, auditing, monitoring, and security detection capabilities.

•V-One’s SmartWall smartcard system — Physical smartcard or security token (floppy disk) for firewall access control authentication and IP datastream encryption for secure Internet user access.

333

•Security Dynamics SecurID — Physical smartcard system for authenticating remote dial-up PPP access to the secure NPAC WAN in conjunction with the NPAC network access servers which perform the SecurID validation.

•Security Dynamics ACE/Server — Security authentication server that is queried by the NPAC network access servers to validate access attempts using the SecurID smartcard.

•DSET CMIP Protocol Stack — Security package within the DSET CMIP protocol stack and agent server provides X.741/TA-1253 two-way peer authentication association control, PKCS/X.509 key management, and RC4 CMIP message encryption.

•Open Market WebServer — Server that provides secure sockets layer (SSL) protocol with RC4 encryption and PKCS/X.509 key management for secure HTTP access to the web-based user GUI.

•RSA Certificate Issuing System (CIS) — Complete solution for issuing and tracking digital certificates for the NPAC and users, using Oracle for integrated management of NPAC physical, network, and system level access control.

•RSA BSAFE Development Toolkit — Standard security API library for use in developing additional application security and key exchange facilities for the NPAC/SMS.  Includes routines for crypto algorithms (RSA, DES, RC2, RC4, Diffie-Hellman, etc.) and key exchange and management.

•Oracle Security Network Services — Provides for authentication and encryption of peer-to-peer connectivity for other Oracle server instances (e.g., security for Oracle Advanced Replication

334

Server), and SecurID smartcard authentication for direct Oracle users (e.g. NPAC internal staff for ad hoc report generation, and database administrators).

Standards used in the NPAC SMS to meet the security services requirements include:

•Bellcore TA-1253 Generic Requirements for Operations Interfaces Using OSI Tools: Network Element Security Administration — This standard addresses login requests and key management.

•ITU X.509 Information Technology — Open Systems Interconnection — The Directory: Authentication Framework — This standard addresses encryption and two way strong association authentication.

•ITU X.741 OSI Systems Management, Objects and Attributes for Access Control — This standard addresses user access on the basis of user’s privilege/security clearance level and access control rules.

•ITU X.803 Upper Layers Security Model — This standard addresses the general OSI security model.

•ANSI T1.243-1995 Telecommunications — Operations, administration, maintenance, and provisioning (OAM&P) — Baseline Security Requirements for the Telecommunications Management Network (TMN).

•NMF “Omnipotent 1 Specifications and Technical Reports, Application Services Security of Management,” Forum 016, Issue 1.0, Aug. 1992 — Security policy and threat management.

335

•ITU Rec. X.690/ISO IS 8825-1 Annex D — ASN.1/BER encoding of digital signatures and encrypted cyphertext.

•OIW Stable Implementation Agreement, Part 12, 1995 — Supported digital signature algorithms for use in OSI security.

•Committee T1 Technical Report No. 40 “Security Requirements for Electronic Bonding Between Two TMNs” — Reports on use of TA-1253/X.741/X.509 security in the EB trial.

•ISO/IEC 7816 “Identification cards Integrated circuit(s) cards with contacts” — Standards for smartcards.

•IETF Internet-Draft SSL v3.0 (Dec. 1995) — Secure Socket Layers proposed draft.

•RSA PKCS Standards.

Using the aforementioned suite of security products and standards, security is imposed on all types of communications — Internal NPAC Users, Local and Remote GUI Users, and Mechanized Interface — within the NPAC/SMS.  The following exhibits summarize the security implementation for each of the three types of communication stack technologies employed in the NPAC/SMS.  Exhibit 2.7-1 addresses security within the NPAC regarding NPAC system administration and internal NPAC facilities (e.g., e-mail, Oracle DBMS backup-site replication).  Exhibit 2.7-2 illustrates the security implementation for NPAC user access to the web-based user GUI.  This stack architecture is used consistently for all NPAC GUI users, regardless of access mode (local or remote) or user-type (internal

336

or external).  Exhibit 2.7-3 covers the security architecture for the OSI stack for the mechanized interfaces.

Function	NPAC System Support	Security Functions
	(Internal Only)
User	UNIX daemons, Oracle, Net management	Power Login (UNIX security) Oracle Secure Network Services
Application (7) Presentation (6)	Oracle, ftp, smtp, telnet, X, DNS, TACACS+, NFS, X.400, lpr, SNMP	Encryption (Oracle) Proxy Server (UNIX network services)
Session (5)
Transport (4)	TCP/UDP	Packet Filtering
Network (3)	IP	Connection Control
Link (2)	PPP, MAC, ATM	CHAP SecurID authentication
Physical (1)	DS-1/3, DS-0 x n, ISDN, (backup)	Physical facility access Privileged access ports, called ID

Exhibit 2.7-1.  System Administration Security

Function	Local and Remote GUI Users	Security Functions
Application Transaction Server	BACE	Object instance, attribute, and operation access control by userid (screens, menus, forms, etc.)
Communications User	Secure Web Server (Open Market Web Server)	Power Login login/password
Application (7) Presentation (6)	HTTPS
Session (5)	SSL	PKCS Key exchange RCH Encryption
Transport (4)	TCP	Packet Filtering
Network (3)	IP	Internet: SmartWall bastion proxy
Link (2)	PPP, Frame Relay, MAC, ATM	CHAP, SecurID authentication on dial-up
Physical (1)	DS-1/3, DS-0 x n, ISDN, V.34	Dedicated: physical Dial-up: private access numbers called ID

Exhibit 2.7-2.  User GUI Security

337

Function	Mechanized Interface	Security Functions
Application Transaction Server	BACE	Object instance, attribute, and operation access control by userid
Communications User	DSET CMIP Agent Server	Object access rules Interface semantics
Application (7)	CMISE, ACSE, ROSE	Strong two-way peer authentication (x.741/TA-1253) Key management (x.509/PKC5) Message encryption (RC4)
Presentation (6)	ANSI T1.224
Session (5)	ANSI T1.224
Transport (4)	TCP, RFC 1006, OSI Transport Class 0	Packet filtering
Network (3)	IP	RFC1006 connections only
Link (2)	PPP, Frame Relay, MAC, ATM	CHAP authentication, SecurID on dial-up
Physical (1)	DS-1/3, DS-0 x n, ISDN, V.34	Dedicated: physical Dial-up: private access numbers, Called ID

Exhibit 2.7-3.  Mechanized Interface Security

The remainder of this section describes our fully compliant responses to the more than 100 security requirements in Section 7.0 of the RFP.  Our NPAC/SMS security approach is completely integrated and, as such, our responses to the detailed requirements sometimes cross subsectional boundaries in RFP Section 7.0.

2.7.1   Identification (RFP Sect. 7.1)

The NPAC/SMS provides comprehensive NPAC user identification and account security management in full compliance with Section 7.1 requirements, ensuring that all users are uniquely identified and tracked within the NPAC/SMS.

338

Every NPAC user (individual and machine, external or internal) has a separate unique user login account on the NPAC SMS with unique user identification codes (userids) and passwords [R7-1].  These accounts are used for both security and resource accounting purposes, and well-defined procedures for adding and deleting users are described in a Standard NPAC Security Practices and Procedure document [R7-50].  All user logins are set up such that users, after satisfying network access controls, must, at a minimum, enter their login userid and their password within the appropriate user environment (mechanized interface or user GUI) to gain access to the NPAC SMS [R7-10] and identify themselves with their assigned userid before performing any actions [R7-2].  We understand that there will be different userids for the LSMS function and the SOA functions for users that are both LSMS users and SOA users [R7-2].  Other than properly authorized internal NPAC system administrators and network operations personnel, all user login accounts are disabled from shell access.  This, in addition to physical and network access security (by NPAC services), restricts users to their proper operational environment (mechanized interface or user GUI).  In addition:

•All Stratus UX (UNIX) default user types will be disabled to prevent unauthenticated NPAC/SMS access [R7-30]

•No password will be null [R7-20]

•The UNIX mechanism that permits bypassing authentication verification based on trusted path will be disabled [R7-11].

The user gains access to the NPAC SMS after proper authentication.  By default, Stratus UX maintains a list of currently active users [R7-3] and records the invoking owner/user (userid) of every process currently executing/running on the SMS [R7-4].

339

McAfee/FSA’s Power Login Security Software product operates on top of Stratus UX, using its security administration tool to provide a hardened secure environment for user account management.  Power Login can be used to:

•Perform login activation/deactivation

•Identify valid users that have not been active for a pre-determined amount of time and schedule login activation/deactivation for a pre-determined time.  For example, Power Login can disable userids after a period of inactive use [R7-5].  A default of 60 days will be used

•Reactivate or delete disabled user logins [R7-6]

•Temporarily suspend/disable [R7-7] and optionally automatically activate disabled user logins [R7-8]

•Change password aging requirements.

The user login activation/deactivation mechanism of the Power Login tool provides the ability to create new users.  It also permits activation or deactivation of those users based on time, allowing only certain users to have access to the NPAC SMS during pre-defined time periods — time-of-day, day-of-week, etc. [R7-39].  Similarly, when users go on vacation, their login can be disabled during that time period.

Also, as further explained in Section 2.7.1.3.2, Login Procedures, when user access has been granted, the NPAC SMS determines whether any active login session exists for that user.  If one is found, users are

340

asked whether they want to continue with this second login.  If they reply yes, the second login continues and the first is terminated by the system.  If, however, the user replies no, the second login is terminated [R7-9].

2.7.2   Authentication (RFP Sect. 7.2)

Comprehensive NPAC user authentication is enforced within the NPAC/SMS in full compliance with Section 7.2 requirements, ensuring that all users are authenticated before accessing and using the NPAC/SMS.

As illustrated in Exhibits 2.7-1 through 2.7-3, comprehensive user authentication is provided within the NPAC/SMS through a multi-tiered access control strategy.  While, as discussed below in 2.7.2.1, a user password is required at the application layer.  A user only gains access to the system after satisfying the lower-layer access requirements.  These access control mechanisms are discussed later in Section 2.7.3.  Also, as described in Section 2.7.1, all access to the NPAC SMS requires complete user authentication; the NPAC SMS will not support ways to bypass authentication mechanisms [R7-11] and any UNIX-based facility that permits circumventing this requirement will be disabled.

2.7.2.1   Password Requirements (RFP Sect. 7.2.1)

Powerful password administration for the NPAC SMS is provided by McAfee/FSA’s Power Login Security Administration, ensuring that all passwords are encrypted, secure, and “reasonably” resistant to guessing.

A C-2 level security concept called shadow passwording is implemented in the NPAC SMS.  In shadow passwording, a special file contains all passwords that have been encrypted (one-way encrypted form)

341

[R7-15 and R7-17]; unencrypted passwords are not stored and, thus, are inaccessible by NPAC personnel [R7-17].  The encrypted password file is invisible and inaccessible to normal, non-privileged users [R7-12 and R7-16].  That file can only be accessed through the appropriate tools by authorized NPAC system administrators who have “root” level privileges [R7-12 and R7-16].  The encryption technique uses a one-way function called crypt, which adheres to a DES encryption algorithm [R7-15].  There is no known method to easily decrypt the encrypted text without knowing the encryption key, other than relentless random guessing.  For this reason, relentless repetitive guessing is the only mechanism to attack our proposed password approach.  Repetitive random guessing is deterred by instituting a time-out threshold when a failure occurs.  The encryption algorithm makes it extremely difficult (and time-consuming) to determine if any duplicate passwords exist.  There is no provision whereby a single password entry can be shared by multiple userids [R7-13].  Also, the system will not prevent a password from being used if it is already associated with another userid. [R7-14].

Power Login’s security administration capabilities include the ability to administer access control variables associated with user accounts.  For example:

•Password aging is completely supported and enforced according to a specific period of time in days.  The default will be initially set to 90 days [R7-23]

•Notification of expired passwords is completely supported and enforced [R7-24 (1)].  User will be notified within an NPAC-specific period of time prior to their password expiring, and require any user whose password has expired to enter a new password before allowing that user access to the system.  The default for notifying users when their password will expire will be initially set to 7 days [R7-24 (1)]

342

•Passwords are not reusable by the same user for a NPAC-specifiable period of time.  The default for password reuse will initially be set to 6 months [R7-25]

•Passwords are at least 6 alphanumeric characters in length (at least one character must be alphabetic, one numeric or punctuation character) [R7-26]

•Passwords will not contain the associated userid [R7-26]

•Passwords are “reasonably” resistant to brute-force guessing [R7-27] through satisfying the password complexity requirements in RFP requirement R7-26

•Passwords initially generated are random [R7-27] and satisfy the password complexity requirements in RFP requirement R7-26.

When users are either required to change their password or they desire to change it, a change password function within their operational environment is invoked.  This mechanism includes a means to re-authenticate their current user password and test to verify their new password [R7-21].  If a valid user is unable to login (that is, they forgot their password), the NPAC system administrator is able to reset the user password to a known value [R7-22].  The new password is created using a password generator.

Our responses to requirements R7-18 and R7-19 are addressed and satisfied in Section 2.7.3.1.2, Login Procedures.  Our response to requirement R7-20 is addressed above in Section 2.7.1, Identification.

343

2.7.3   Access and Control (RFP Sect. 7.3)

Extensive, multi-tiered, access control is implemented within the NPAC SMS and network in full compliance with Section 7.3 requirements, ensuring that all NPAC SMS resources — transactions, data, files, printers, tape facilities, software tools, software executables, etc. — can only be accessed and used by authorized users.

This section describes access and control to the NPAC SMS system and to NPAC SMS resources.  Access to the NPAC SMS is permitted for authorized users (local and remote) and authorized remote systems [R7-28].  The user login and system administration processes and the association establishment features of the mechanized interfaces provides for initial entry or modification of authorized users and authentication information [R7-29].  Once an authorized user gains access to the system, a set of system and application access control levels determines what resources that user is allowed to access and use.

2.7.3.1   System Access (RFP Sect. 7.3.1)

Network, system, and application-level access control layers provide extensive control of NPAC/SMS security.

This section describes how users of the NPAC SMS are authorized to access the NPAC SMS and other resources.  Network access control procedures are discussed (Section 2.7.3.1.1), followed by a discussion of the user GUI login procedures (Section 2.7.3.1.2).  Access control procedures for the mechanized interfaces are discussed in Section 2.7.8, OSI Security Environment.

344

2.7.3.1.1   Network Access

A comprehensive network access control layer safeguards access to the NPAC network prior to allowing system or application-level access attempts.

The types of NPAC network access methodologies supported are:

•Physical access to the NPAC network for internal users.

•Communication lines to service providers, primarily for mechanized interfaces.

•Dial-up access for authorized internal and external users, including dial-up backup support for the communication lines to service providers that enable authorized remote access.

•Internet access by authorized users, primarily for remote user access.  This access can also be used to support mechanized interfaces to service providers, given the level of authentication and encryption in ACSE/CMISE portion of the stack.

Access control for each of these modes is further discussed below:

345

2.7.3.1.1.1   Physical Access

Physical cardkey access to dedicated NPAC facilities and microsegmented NPAC LAN provide extensive NPAC network physical security.

Internal NPAC staff gain access to an NPAC facility through cardkey security facilities that control access to individual security zones within the facility, by user.  The NPAC portion of the facilities in both the Primary and Backup/Disaster Recovery NPAC locations are dedicated for NPAC use and are separately zoned.  Users access the NPAC network via workstations within the NPAC facilities.  Workstations, connected to a microsegmented (by workgroup/function) NPAC LAN, are terminated at the NPAC enterprise IP switching hub in the NPAC data center for that facility.

The switching hub provides IP packet filtering for that microsegment based on the NPAC network services and systems they are authorized to access.  Also, the switching hub only forwards packets destined for ports accessible off that microsegment, thus preventing a user from surreptitiously capturing all packets on the NPAC LAN.  This capability also helps to ensure high scalability of the NPAC network for future expansion without sacrificing security.

User workstations require a local userid/password to gain access to the workstation and identify the user on the local NPAC workgroup server.  Once the user is logged into the workstation, client software (e.g., Netscape web browser) is started through which the user attempts to access the NPAC/SMS.

346

2.7.3.1.1.2   Service Provider Primary Communications Access

CHAP authentication and IP firewall protect the NPAC network while supporting dedicated lines to service providers.

Communications to service providers are terminated in NPAC WAN routers within the NPAC switching hub.  The remote user system must satisfy the CHAP protocol to authenticate the system and login to the NPAC network.  Firewall functionality, specifically IP packet filtering, is also used to enable access only to the NPAC SMS for the services (e.g., RFC 1006 for mechanized interfaces) authorized.

2.7.3.1.1.3   Dial-up Access

Dial-up access is fully secured using SecurID smartcard, CHAP authentication, and IP firewall, to protect the NPAC network.

Dial-up facilities provided by the NPAC SMS physically reside on the non-secure side of the firewall; thus, they also have to pass the firewall scrutiny.  Dial-up authentication is enforced using the CHAP protocol for all types of dial-up access, since PPP is the only supported link level protocol for dial-up ports.  CHAP enforces two-way peer authentication by forcing any remote device attempting a PPP connection to give the device name, a random value, and a secret, encrypted password that only the NPAC can recognize.

Internally within the NPAC network, the network access server ports on the NPAC switching hub/router use the TACACS+ protocol for validating the remote user by querying the security server on the NPAC SMS.  This protocol is the industry standard for authorization, authentication, and accounting for dial-up access.

347

Dial-up facilities are provided via several primary-rate ISDN (PRI) spans terminating on the network access server ports.  Both V.34 analog and ISDN circuit switched data calls (DS0 x n) are supported on a common pool of physical ports and trunk circuits.  These shared facilities support both remote user access for internal and external NPAC users, as well as for dial-up primary or backup data links to service providers.  Dial-up access numbers are maintained in two separate pools to segregate mechanized interface dial-up links from remote users, and capture CallerID information for screening and reporting.

Remote/Dial-in users must use an authorized SecurID smartcard, which is validated by the network access server ports by launching a query to the Security Dynamics ACE/Server running on the NPAC SMS [R7-43].  Having once satisfied both CHAP and SecurID authentication, users are allowed access only to the specific NPAC services for which they are authorized.  Normally, remote users are constrained to accessing the user GUI (via HTTPS protocol) implemented on the NPAC SMS by the Open Market Web Server.  In this case, the SSL layer protocol is initiated to encrypt the user’s login attempt and session, as further described in 2.7.3.1.2 (below).

Mechanized interface dial-up links (for backup or primary, where suitable) are expected to originate from a remote system or a remote router port.  Dial-up access for mechanized interface allows access only to the NPAC SMS for RFC 1006 access (via TCP port 102) and will be pre-screened for pre-authorized CallerID’s.  The OSI security environment is then activated to perform the strong two-way peer authentication at the ACSE-layer described below in 2.7.8.  To further reduce the security risk, only specially authorized personnel with smartcard access are permitted to perform dial-up access [R7-41].

348

2.7.3.1.1.4   Internet Access

Highly robust, cost effective, and proven perimeter-network firewall with smartcard access control ensures NPAC/SMS security while enabling authorized Internet access to facilitate efficient communications with service providers.

The NPAC/SMS network architecture utilizes a perimeter sub-network as a logical gateway network between the unsecure Internet and the fully secure NPAC/SMS network.  The perimeter network is formed using two firewall routers (one of which is within the NPAC switching hub) that employ IP packet filtering and other mechanisms to control the types of allowed traffic into and out of the perimeter network.  The sole node on the perimeter network is the SmartWall server from V-One, Inc., a UNIX-based PC-server acting as a dedicated bastion host server to mediate services between the Internet and NPAC/SMS.  The bastion host is treated as a semi-secure host, acting as a mail gateway, ftp server, public web server, and proxy server for explicitly allowed services.  The use of a bastion host to eliminate direct TCP/IP communications with any host within the NPAC/SMS network, in addition to controls on the perimeter sub-network,  ensures full security within the NPAC/SMS by eliminating all known security threats.

Remote users authorized for Internet access are assigned a separate SmartCat smartcard that is authenticated upon access by the SmartWall bastion server [R7-43].  SmartWall performs two-way peer authentication and public key exchange of the remote user, followed by RSA encryption of the IP datastream between the remote user and the bastion host.  The remote user may then invoke authorized services with the NPAC network, normally constrained to the user GUI on the NPAC SMS.  However, since SmartWall provides for IP datastream encryption, other Internet services, such as ftp or an NPAC-specific newsgroup, may be permitted to enable cost efficient access to NPAC services and data.

349

2.7.3.1.2   Login Procedures

Secure user login facilities ensures that GUI users are fully authorized and authenticated.

Access to the user GUI requires obtaining NPAC network access to the Open Market Web Server running on the NPAC SMS.  For internal NPAC users, physical access to the NPAC facility and a login at the user’s workstation authorizes them to start a web browser on their workstation.  When the web browser attempts to establish an HTTPS (secure web application protocol) session with the NPAC SMS, the SSL (secure sockets layer) protocol is initialized.  Part of the initialization sequence is a public key exchange or identification.  A key certification server within the NPAC SMS provides to the web browser the public key for the web server on the NPAC SMS.  Once the SSL initialization is complete, a secure, encrypted channel is established between the NPAC SMS web server and the user’s web browser that ensures integrity of the users session with the NPAC SMS.

The Open Market Web Server on the NPAC SMS server causes the web browser to present a login menu to the user.  When a user attempts to log into the user GUI, at a minimum, they must enter their userid and their password.  Exhibit 2.7-4shows the login window.  The login/password information forwarded back to the NPAC SMS web server is encrypted through the secure, trusted SSL layer channel previously established [R7-31].  It should be noted that the use of a secure web browser/server ensures that no clear text data, including passwords, is sent over the public or shared data network [R7-19].

350

Twenty lines of warning message are included on the login window stating that this is a private computer system and authorization is required for access [R7-47].  The required default warning message: “NOTICE: This is a private computer system.  Unauthorized access or use may lead to prosecution!” is shown in Exhibit 2.7-4 [R7-47].  Passwords entered are not displayed (suppressed and fully blotted out) and the cursor does not move as the password is entered [R7-18].  Once the login information and password information has been gathered, the NPAC SMS validates the access request, even if an invalid userid is entered [R7-37].  First the userid is validated.  Next, the inputted password is converted to the encrypted form as stored in the shadow password file and compared with that user’s password.  If the comparison succeeds, the user is granted access [R7-28]; otherwise access is denied

351

with an “invalid” message that does not indicate which information (userid vs. password) was invalid [R7-38].

When access has been granted, the NPAC SMS determines whether any active login session exists for that user.  If one is found, users are asked whether they want to continue with this second login.  If they reply yes, the second login continues and the first is terminated by the system.  If, however, the user replies no, the second login is terminated [R7-9].  Once the user becomes actively logged in, the system displays to the user:

•An advisory message, as mentioned above, warning of the consequences of unauthorized use.  This message is configurable by NPAC administrative personnel [R7-45, R7-46]

•Date and time of the user’s last successful system access [R7-48]

•The number of unsuccessful attempts by that userid to access the system, since the last successful access by that userid [R7-48].

At this point, the user can perform the required tasks using the NPAC SMS application user interface.  The user interface is referred to as the NPAC Operational GUI.  The NPAC Operational GUI uses security tables to enforce application-layer security and access requirements for a pre-defined audience.  The following users groups use the NPAC SMS Operational GUI:

•Service Providers (remote NPAC users)

•User Support Services Group (Customer Help Desk)

•Administrative Services and Facilities Group

•System Software and Support Group

•Quality Assurance and Control Group.

352

The NPAC SMS application window configurations are dynamically driven based on the authorized user’s login permissions.  This provides an additional security layer by enabling and disabling user interface features and data access.  If the system detects no activity from a user for a duration of 60 minutes, that user is automatically logged off [R7-32].

If a failure should occur during the login process, the system reflects only that a login failure occurred [R7-38] – the cause of the failure is not reported and the attempted passwords are not recorded [R7-76].  The user is able to re-attempt the login procedure.  After three consecutive fails, the system [R7-33]:

•Issues a security alarm to NPAC network operations personnel [R7-34]

•Waits 60 seconds before allowing a subsequent attempt [R7-35]

•Adds an entry in the system log [R7-76].

Note, even though the login threshold has been exceeded, the NPAC SMS does not suspend the userid [R7-36].

The login procedures described above apply to all user types.  To further protect unauthorized access, users can be excluded/granted system access based on method or location of entry [R7-40]; this applies to privileged users as well [R7-42].  For example, the NPAC SMS can ensure that only privileged users, like “root”, only be permitted to login at the system console [R7-42] or login on a specific network device or port.

Once a user GUI session is established via correct login, resource-level access control is provided within the NPAC SMS application transaction processes.  A user may either exit the system by choice, or the

353

system logs-off the user.  McAfee/FSA’s Power Broker monitors these events to ensure that a graceful and secure log-off is performed [R7-44].

2.7.3.2   Resource Access (RFP Sect. 7.3.2)

Extensive resource access control for all NPAC users is provided by McAfee/FSA’s Power Login, the NPAC SMS application software, and Oracle, ensuring that access to NPAC SMS resources is only granted to authorized users and that users only access their data.

Power Login in conjunction with Stratus UX provides user account security, group level security, and sysadmin level security.  User account security establishes the access capabilities of a specific authenticated user [R7-55].  Group level security establishes the access capabilities of all users within a specific group (either primary group or secondary group) [R7-57 and R7-58].  Sysadmin level security restricts access to system administration tools [R7-60], including the modification of resource access rights and privileges.

The NPAC SMS security facilities establish well-defined access control levels [R7-49], allowing only well-privileged “root” users responsible for security administration to authorize or revoke users as well as representing management domains that define control of resources given to a user or group of users [R7-55, R7-57, and R7-58].  Procedures for adding and deleting users are described in a Standard NPAC Security Practices and Procedures document [R7-50].

Through controlled access levels, the NPAC SMS grants and restricts access to and use (read, write, execute) of all system resources — transactions, data, files, print facilities, tape facilities, software tools, and software executables — only to authorized users [R7-51, R7-52, R7-53, and R7-54].  All users belong to one or more access control levels.  The userid is used within the NPAC SMS application transaction

354

processes (implemented in BACE) to provide fine-grain control of access privileges to screens and menus, as well as to database tables, records, and data fields.  Stratus UX maintains access control lists (ACLs) which are used to overwrite, update, and execute privileges to specific users [R7-54].

Authorized NPAC system administrators who have been set-up with sysadmin level security can use the Power Login/Broker tools to maintain and administer these levels [R7-60].  This includes what resources are part of each level and what set of users can assess that level [R7-61].  Only authorized system administrators may access the Power Login/Broker and Stratus UX access control lists [R7-62].

In addition to the access control performed at the system, database tables exist that define application level access control based on data content of a specific field, attribute, table, record (row), etc.[R7-59].  The same philosophy for access control defined for the system exists for application code.  Where necessary, database entries are encrypted as an additional measure to prevent unauthorized access to them [R7-56].

The Oracle Security Network Services module provides for authentication and encryption of peer-to-peer connectivity for other Oracle server instances. In addition to NPAC physical network security, this provides security for the Oracle Advanced Replication feature, ensuring that all inter-NPAC facility communications for real-time database replication remain secure.  Further, SecurID smartcard authentication for direct Oracle users is also mandated.  The includes NPAC internal staff for ad hoc report generation and database administrators.  Consequently, where limited direct access to the NPAC database is allowed within the NPAC, full security is maintained.

Our responses to requirements R7-30 and R7-39 are located above in Section 2.7.1.

355

2.7.4   Data and System Integrity (RFP Sect. 7.4)

Robust data and system integrity features safeguard NPAC/SMS operations.

Standard NPAC Security Practices and Procedures define how the various aspects of data and system integrity is maintained, including mechanisms and procedures to:

•Monitor security alerts

•Monitor system resources [R7-65]

•Detect error conditions that could propagate through the system [R7-65]

•Detect communication errors [R7-65]

•Detect link outages [R7-65]

•Run database integrity checks [R7-67]

•Monitor backup system resources and the NPAC SMS database

•Ensure real-time data replication of the NPAC SMS database of the backup/disaster recovery system.

Also, the NPAC/SMS contains many features to protect data integrity, such as enforcement of:

•Proper rules and range value checking on all data inputs and updates [R7-66]

•Proper handling of duplicate/multiple data inputs [R7-66]

•Proper checking of return statuses and messages/notifications/replies of the mechanized interfaces [R7-66]

•Serialization of all update transactions for record keeping [R7-66]

•Checking of inputs for reasonable values [R7-66].

356

Stratus UX combined with Power Broker detects unauthorized changes in files based on access level signature assigned to files/resources and file/resource system owners [R7-63 and R7-64]. Thus, the NPAC SMS can identify the originator of any accessible resources [R7-63] and any information received across communication channels [R7-64].  Power Login/Broker provides capabilities to enforce security policy and to notify the security administrator when particular events are happening.

2.7.5   Audit (RFP Sect. 7.5)

Comprehensive auditing and intrusion monitoring insure proper implementation of NPAC security strategy.

The Security Practices and Procedures Standard NPAC document defines how and what type of information is audited. The document includes who has access to the auditing information and how long audit information must be maintained.

2.7.5.1   Audit Log Generation (RFP Sect. 7.5.1)

Integrated audit log and report generation provide required security management information.

The NPAC SMS takes advantage of all the auditing capabilities provided by the NPAC SMS application transaction processes and Stratus UX.  Stratus UX has three auditing facilities: 1) user login logging; 2) user accounting logging; 3) system logging.  Whenever a user login attempt is performed, an event is logged, whether the user login is successful or not [R7-73].  The event includes the userid, time, and

357

device requested.  User accounting is a UNIX facility that logs every process executed by every user [R7-69] for traceability.  The accounting output includes date/time, user id, point of entry, process, resources accessed, and result of the operations [R7-69, R7-75].   This log may be selectively viewed for actions performed by a specific user or users [R7-78]. Stratus UX’s system logging is a configurable logging capability that permits monitoring the kernel, user processes, mail system, authorization system, etc.  Meanwhile, Power Broker can detect when file system privileges of files have been changed [R7-73].  It also audits incoming requests and/or the use of facilities such as telnet, finger, rsh, exec, talk, etc.  The audit data is available on-line for a minimum of 90 days and archived off-line for a minimum of two years [R7-68].  This allows for after-the-fact-investigation of all system activity, including all:

•Successful and unsuccessful user logins

•Processes executed

•File access attempts (successful and unsuccessful) [R7-73]

•Data, transaction, resources access attempts (successful and unsuccessful) [R7-73].

All auditing activity is controlled at the system administrator access control level.  The ability to change auditing information, access log files, and view logging information is not permitted by any user other than the privileged user “root” who is a system administrator [R7-70, R7-71, R7-72, and R7-74].  There is no provision to disable NPAC action auditing [R7-74].

2.7.5.2   Reporting and Intrusion Detection (RFP Sect. 7.5.2)

Extensive security alarming and report generation enable robust security monitoring.

358

The NPAC SMS permits the examination of audit information.  Extensive accounting, authorization, and authentication records are generated from the NPAC network.  Using this audit information, specific audit/exception/summary/detail reports can be created to report on specific processes, userid access, communication failures, etc. [R7-77]

The alarms generated by the NPAC SMS application, NPAC network, Power Login, and Stratus UX are fed via SNMP traps into the NPAC Network Management System (NMS) to provide a single point for real-time problem monitoring.  Alarms are displayed on the NMS GUI.  Alarms recognized by the NMS include system related activity as well as network related behavior, allowing the NPAC to monitor specific network addresses or terminals [R7-79] and to take the least disruptive action when security infractions accumulate to indicate a potential security violation or breach [R7-80].  The NPAC network provides full IETF RMON2 services for application fingerprint auditing and complete protocol stack tracing/decoding.  This enables the NMS to perform extensive network security and performance monitoring.  Our response to requirement [R7-76] is located above in Section 2.7.3.1.2.

2.7.6   Continuity of Service (RFP Sect. 7.6)

Continuity of service is ensured through extensive fault tolerance, redundancy, and application integrity checks.

The NPAC architecture has been designed to provide complete redundancy.  If a catastrophic hardware or software failure should occur, regardless of origin, deliberate or accidental, automatic switch over to a hot spare component occurs [R7-81].  The auditing system detects and reports whether a condition exists due to software problems or degrades performance below prespecified minimums [R7-82].  For example,

359

if the ORACLE database engine goes down on the NPAC SMS, the audit or network management system would trigger a fail over if the database engine could not be restarted.

Continuity of service will be maintained as new releases of software are deployed.  The software is driven based on the release version and all database tables have a release version associated with them. A master release table exists that identifies the exact revision numbers of the latest software installed [R7-85] and allows two sets of software releases to execute at the same time and permits automatic switch-over to the new release without interrupting service.

Our responses top requirements R7-83 and R7-84 are located in Section 2.7.7.

2.7.7   Software Vendor (RFP Sect. 7.7)

Industry standard development, code inspection, test, and configuration management practices and processes ensure faithful implementation and maintenance of NPAC security.

Throughout the Security Section reference has been made to a document called Standard NPAC Security Practices and Procedures.  The document explicitly describes all facets of the security policy, including:

•System administration practices (setting up access control, users, etc.)

•Network configuration prerequisites

•Backup and restoration procedures [R7-84]

•Procedures associated with hot-spare fail-over or recovery without compromising protection [R7-83]

•Utilize third party tools to enhance operating system capabilities

•Procedures for release new software

•NMS monitoring [R7-65].

360

A corporate policy is in place governing the software development process as well as software inspection practices.

2.7.7.1   Software Development Practices

Audited, rigorous, software development practices and processes ensures high quality of software and security implementation.

A copy of the corporate inspection practices is contained in Appendix F of this proposal.  The inspection practices define inspections of designs and code reviews which constitutes ESI’s policy governing its internal development of software.  Additional, corporate policies and procedures govern the security of developed software throughout the entire software lifecycle [R7-86].  Traceability matrices are generated and designs verified against the requirements so that no unauthorized mode of entry (“back door”) is designed or “built into” the NPAC SMS application software to violate or bypass any security procedures [R7-87] for any purpose.  Furthermore, formal code reviews are conducted to verify that the design is followed.  A formal test plan is generated and a test report published that again validates system software security.  All modes of entry into the NPAC/SMS for maintenance, support, or operations are documented in the operator’s manual and no other entry modes are designed into the software [R7-88].

2.7.7.2   Data Integrity

Multi-level integrity checking in network, system, application, and database safeguards NPAC operation while providing errors containment and notification.

361

Data integrity checks are performed by both the SMS application and the Oracle database [R7-66].  The application software provides both levels of access and data entry checks.  The SMS Operational GUI validates data entry fields as the data is being entered.  Error messages provide concise dialog indicating problem resolution when applicable.  Proper serialization of update transactions is also performed by the application software.  There is built-in data integrity checking in the Oracle database as well.

2.7.8   OSI Security Environment (RFP Sect. 7.8)

The security solutions proposed for the NPAC SMS OSI interfaces meet the letter of the requirements and also suggest improvements for key exchange.

This section addresses the security mechanisms to be implemented by the Lockheed Martin Team for the SOA to NPAC SMS and the Local SMS to NPAC SMS OSI interfaces implemented in accordance with the standard Interoperable Interface Specification and using the DSET CMIP Agent Toolkit on the NPAC SMS.

2.7.8.1   Threats (RFP Sect. 7.8.1)

All known OSI security threats are thwarted with standards-compliant mechanized interface design and implementation.

The NPAC SMS interface may be subjected to attack in a variety of ways to attempt to disrupt customer, service provider, and NPAC SMS operations.  Methods used to thwart these attempts are described below in Section 2.7.8.2.

362

2.7.8.2   Security Services (RFP Sect. 7.8.2)

The full suite of security facilities within the OSI stack implementation protects mechanized interface operation.

The following security services are used in the NPAC SMS to satisfy requirements R7-89 through R7-93:

•Authentication — Strong two-way peer authentication upon association set-up is done using data in the access control field as described in Section 2.7.8.3.2 [R7-89]

•Data origination authentication — Data authentication is done by validating data sent in the access control field as described in Section 2.7.8.3.3 [R7-90]

•Integrity and Non-repudiation — Integrity and non-repudiation are achieved by use of digital signature algorithms as described in Sections 2.7.8.3.1 and 2.7.8.3.4 [R7-91 and R7-92]

•Access Control — Access control will be implemented through the use of authentication upon association and authorization of requests in the NPAC SMS based on userid as defined in Sections 2.7.8.3.3 and 2.7.8.3.5 [R7-93].

2.7.8.3   Security Mechanisms (RFP Sect. 7.8.3)

NPAC/SMS and mechanized interface operation secured by extensive implementation of OSI security facilities.

363

This section provides the detailed information about the implementation of the security mechanisms listed in Section 2.7.8.2 Security Services.

2.7.8.3.1   Encryption (RFP Sect. 7.8.3.1)

Full RSA-compliant RC4 CMIP message encryption provides the strongest data security available.

To support non-repudiation, a Public Key Crypto System (PKCS) based on RSA and layered with RC4 encryption [R7-94] is used in the access control information for each transmission of data across the OSI interfaces.  The digital signature algorithm, supported in OIW Stable Implementation Agreement, Part 12, 1995, is applied to the ASCII representation of all signed data fields, without any separators between those fields or other additional characters [R7-96].  Since the digital signature is based on RSA encryption, the size of the modulus for each key is 600 bits [R7-95].

2.7.8.3.2   Authentication (RFP Sect. 7.8.3.2)

X.741 and TA-1253-compliant strong two-way peer authentication provided by the DSET CMIP Agent Toolkit validates mechanized interface connection attempts.

Strong two-way peer authentication at association setup time is done in the NPAC SMS OSI interfaces using Bellcore TA-1253 and ITU X.741 and X.509.  Our NPAC SMS software supports the Authentication and Access Control information required by the Interoperable Interface Specification [R7-97], which includes a Secure Association Establishment Section that mandates the use of an “authenticator” in full compliance with the elements listed in RFP requirement R7-97.  Exhibit 2.7-5

364

provides the appropriate syntax for the authenticator in a CMIP access control field [R7-98].  This authenticator is used by the NPAC SMS mechanized interfaces, and is documented on the IIS.

2.7.8.3.3   Data Origin Authentication (RFP Sect. 7.8.3.3)

Data origin authentication is assured through consistent use of the CMIP access control field.

Data origination authentication is supported by the authentication information sent in all CMIP messages using the access control field specified above in Exhibit 2.7-5.  The sequence number field is used for authentication as a counter that each party using the OSI interfaces maintains and increments independently to prevent replay or resequencing of messages [R7-99].  The generalized time stamp and digital signature is validated using TA-1253 for each CMIP message to ensure that messages were not tampered with, replayed, or intercepted.  The userid and password is used to validate that the originator is authorized to access the NPAC SMS via the OSI interfaces defined using TA-1253.

365

2.7.8.3.4   Integrity and Non-repudiation (RFP Sect. 7.8.3.4)

Even notifications contain the authenticator in the access control field to ensure consistent integrity and non-repudiation of information.

Since CMIP notifications do not have an access control field, the notifications use the management extension field to contain the NPAC SMS CMIP access control field defined in Exhibit 2.7-5 [R7-100 and R7-101], ensuring the data origin authentication, integrity, and non-repudiation of origin for each notification.  Our NPAC SMS software implements the standard Interface Interoperable Specification, which the Lockheed Martin Team developed.  This specification mandates and, thus, our NPAC SMS software will enforce, that all notifications are sent in a confirmed mode [R7-102].  Digital signatures, sequence numbers, and the generalized time stamp for all CMIP messages are used to ensure that the message was not tampered with, replayed, or intercepted.

2.7.8.3.5   Access Control (RFP Sect. 7.8.3.5)

Full application-level access control and mechanized interface semantics (SOA vs. LSMS) are enforced consistently after association authentication.

After authenticating a user, the NPAC SMS enforces access control to information using X.741 and the application security data tables based on userid and the type of OSI interface being used — SOA to NPAC SMS or NPAC SMS to Local SMS.  Our NPAC/SMS application in implementing the standard Interoperable Interface Specification 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-104] and 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

366

NPAC SMS database and the value of the Generalized Time in that message [R7-105].  The NPAC SMS will also mandate that the Generalized Time in the message is within five minutes of the NPAC SMS system clock [R7-105].

2.7.8.3.6   Audit Trail (RFP Sect. 7.8.3.6)

Extensive audit logging ensures maintenance of OSI interface security.

As required in R7-106, the audit trails are maintained in a log (as defined in ISO/IEC 10164-6 and 10164-8, 1992) for the following information [R7-106]:

•Association setup messages

•Association termination messages

•Invalid messages:

•Invalid digital signature

•Sequence number out of order

•Generalized time out of scope

•Invalid userid and/or password specified (Sender not authorized for implied request)

•All incoming messages regardless of whether or not they cause changes.

2.7.8.3.7   Key Exchange (RFP Sect. 7.8.3.7)

An RFP-compliant key exchange is completed, supported with enhancements made to key list identification and management.

367

Key exchange between the NPAC and each carrier will be handled in accordance with requirements R7-107 through R7-111 and enhanced by a fully automated key exchange process and use of dynamically-changeable key lists.  We also offer an alternative key list transmission approach for NYCAC’s consideration.

The key exchange between the NPAC and each carrier can be accomplished as defined in the RFP by exchanging key lists between both parties.  The list could be exchanged in person or electronically via two different secure channels such as secure FTP transmission or sending of a diskette.  The originator of the list of keys will also provider the receiver with signed (in ink) paper copy of the MD5 hashes of the keys in the list [R7-107].  Once lists have been exchanged, both recipients send an acknowledgment that consists of the MD5 hash of each one of the keys in the list.  These acknowledgments are sent via two different electronic channels such as diskette and e-mail.  In addition, the recipient calls the sender by phone and provides the MD5 hash of the whole list for further confirmation [R7-108].

The NPAC issues on a monthly basis a paper list of the MD5 hash keys and all of the public keys it and its clients use.  This is accomplished using the NPAC SMS Operational GUI reporting facilities since key information is maintained on-line in the NPAC SMS databases.  Upon receipt of the list and verification of its own list, the client returns an acknowledgment to the NPAC by phone or e-mail [R7-109].

Each key list contains a unique identifier (Key List ID) and consists of 1000 encryption keys, uniquely numbered from 1 to 1000, and 10 Key Encryption Keys (KEK), numbered from 1001 to 1010.  Only encryption keys shall be used from digital signatures.  KEKs are used to transmit a new list of keys.  All encryption key values are 600 bits in size.  The whole new list will be signed using a KEK.  KEK sizes shall range from 1000 to 1200 bits.  Keys in subsequent lists are numbered 2000 to 3010 using the Key

368

List ID in conjunction with the position of the key within a particulate key list [R7-110].  Finally, it is important to note that the carriers in Illinois, many of whom belong to the NYCAC, have agreed that the transmission of key lists should occur using public key crypto systems (PKCS).  This approach is completely secure and simplifies the management of key lists for all parties.  We ask that the NYCAC carefully consider this option.

More than one key list, each with 1,000 keys, is supported in NPAC SMS software.  Thus, at any given time, service providers can switch key lists, identified by a key list ID, and keys over the interfaces if they suspect a security problem.  The Interoperable Interface Specification (IIS) supports the use of multiple key lists.  The approach of having several different key lists is superior to the approach of only having one list available, because generating a key list is time-consuming and mechanisms must be in place for the interfaces to switch/use keys and key lists in a moments notice any time they suspect a compromise in security.  As the usable keys in a key list and the key lists themselves deplete, the NPAC SMS will generate and transmit new key lists as appropriate.  Also, emergency key lists should be stored by all carriers under lock and key, just in case a severe breach in security is detected, and the active key list(s) is compromised.  If this were to occur, the NPAC could notify the security representatives on each local service provider and instruct them to load and use their emergency key list.

As required, every message exchanged via the OSI interfaces that contains a key identifier has a new encryption key chosen.  New encryption keys are also chosen any time there is suspicion that the key has been compromised or if the key has been in use for more than a year.  Keys used during a year are larger than the keys used the previous year by at least 20 bits.  After usage of a key has stopped, that key is not used again [R7-111].

369

This Page Intentionally Blank

370

NYCAC NPAC/SMS PROPOSAL 2.8  Audit Administration

HIGHLIGHTS

•Lockheed Martin NPAC SMS provides the highest operational integrity with NPAC audit capabilities, including mutual-database integrity sampling, to ensure consistency of LNP routing data throughout the region

•On-demand, service-provider-initiated audits (Type I - Repair Audits) are supported with NPAC-based audit screening capability to enforce inter-company business arrangements for accepting audit requests at the LSMSs

•Audit functionality available to authorized users through the NPAC Operations GUI, as well as through the SOA mechanized interface

•The OpGUI enables authorized users to create and save templates for reuse

2.8AUDIT ADMINISTRATION

(RFP SECT. 8)

Lockheed Martin’s NPAC SMS provides the highest operational integrity, with NPAC audit capabilities that include mutual-database integrity sampling, to ensure consistency of LNP routing data throughout the region.

The Lockheed Martin NPAC SMS provides several functions — in full compliance with the RFP and the revised auditing requirements — and incorporates the latest industry developments to ensure the highest operational integrity of the NPAC/SMS service and LNP database.  Our NPAC SMS includes the following auditing and audit-related functions:

•Service provider query capability for verification of NPAC/SMS data, satisfying Requirements R8-1 to R8-3 (Section 2.8.1)

•Service provider-initiated, on-demand audits with audit screening for Local SMSs a.k.a Type I - Repair Audits (Section 2.8.4)

•NPAC-initiated audits, which use the same methodology as Type I — Repair Audits (Sections 2.8.3 and 2.8.4)

•Mutual-database integrity sampling a.k.a. Type II — Network Integrity Audits (Section 2.8.3)

•Bulk audits using FTP a.k.a Type III — Housekeeping Audits (Section 2.8.5)

371

Exhibit 2.8-1 summarizes the implementation of these processes in the NPAC SMS relative to the roles played by the SOA, LSMS, and NPAC SMS systems.

Function	SOA Role	NPAC SMS Role	LSMS Role
Service provider verification (query) of NPAC SMS	Queries NPAC SMS	Responds to query requests from either SOA or LSMS	Queries NPAC SMS
Service provider-initiated on-demand audits (Type I — Repair Audit)	Initiates audit request identifying target LSMSs	•Validates audit request. •Screens audit request based on which target LSMSs will accept audits from the requester. •Queries LSMSs. •Compares query result with NPAC SMS copy. •Initiates corrective measures to any fix discrepancies. •Reports results.	•Responds to NPAC SMS queries. •Processes corrective measures to fix any discrepancies
NPAC-initiated audits (Uses same methodology as Type I — Repair Audit)	N/A	•Queries LSMS. •Compares query result with NPAC SMS copy. •Initiates corrective measures to fix discrepancies. •Reports results.	•Responds to NPAC SMS queries. •Processes corrective measures to fix discrepancies
Mutual-database integrity sampling (Type II — Network Integrity Audit)	N/A	•During off-peak periods, provides random statistical queries of LSMSs in background. •Compares query result with NPAC SMS copy. •Reports results.	•Responds to NPAC SMS queries.
Bulk FTP Audits (Type III — Housekeeping Audit)	N/A	•Generates database extracts and stores on FTP server	•FTP extract file from NPAC SMS •Compares LSMS data with NPAC extract. •Generates report, fix discrepancies.

Exhibit 2.8-1. Audit Functions Summary for NPAC SMS

These processes are further described in the sections below.

372

2.8.1   Service Provider Verification of Data in NPAC/SMS (RFP Sect. 8.1)

Full CMISE query (M-GET) functionality is supported at the NPAC SMS for SOA and LSMS verification of NPAC SMS data.

The NPAC SMS may be queried from both LSMS and SOA systems over the mechanized interface in real-time to verify the NPAC SMS’ view of subscription, network, or service provider contact data [R8-1].  Queries for subscription versions may request a given TN or a range of TNs, or specify a filter criteria to indicate the versions intended to be returned in the query [R8-1].  Using standard CMISE M-GET functionality, either all or a specific list of fields may be requested to be returned in the query result [R8-1].  The maximum number of versions returned by the NPAC SMS in response to a single M-GET request is limited by the maximum subscriber query tunable parameter (defaults to 50) defined in Section 2.3  [R8-2].

Appropriate security access control privileges, as defined in Sections 2.5 and 2.7, are enforced to ensure proper use of this function for verification purposes.  For example, an SOA may view only pre-active subscription versions (e.g., pending or conflict) that it is involved in as either the old or new service provider [R8-3].  An LSMS may only view active versions, regardless of the current service provider for the version.

2.8.2   Periodic Audits (RFP Sect. 8.2)

Per the October 11, 1996 NYCAC NPAC/SMS Bidders’ Conference, this section concerning periodic audits and its subordinate requirements R8-4 through R8-6 have been eliminated and replaced with requirements for Type III — Housekeeping Audits.  Section 2.8.5, below, is a discussion on how our

373

NPAC SMS implements Type III — Housekeeping Audits in complete accordance with the requirements contained in the Audit Handout.

2.8.3   NPAC/SMS Verification of Data in Local SMS (RFP Sect. 8.3)

Both on-demand NPAC/SMS verification of LSMS data and random background statistical database sampling (Type II — Network Integrity Audits) are provided to measure overall LNP database consistency.

NPAC/SMS verification of specific LSMS data is performed as an NPAC-initiated audit.  NPAC-initiated audits may be used, for example, to perform service assurance and troubleshooting regarding suspect download, on-line, or off-line mass updates, or potential system re-synchronization problems.  These audits are initiated by NPAC personnel when indicated by a problem condition and are not performed as a normal part of NPAC/SMS operations.  One or more LSMSs are queried by the NPAC SMS over the LSMS mechanized interface, and the LSMS-copy of the data is compared at the NPAC SMS.  Only those fields being audited will be specified in the query (M-GET) request to the LSMS and may employ request a single TN or a range of TNs [R8-7].  The NPAC SMS will support limiting the size of a range of TNs that may be queried from the LSMS [R8-8], however this size limitation at the LSMS was eliminated as requirement in the Illinois LNP LLC region.

Similar to on-demand service provider repair audits, any discrepancies detected by the NPAC SMS cause it to re-download the discrepant information to the LSMS to correct the problem.  This may take the form of either an M-CREATE (create a version that is missing), an M-SET (modify a version with discrepant data), or an M-DELETE (delete a previously ported version that is no longer active).  A full report of the audit results is generated.  A complete description of the on-demand audit process may be found in Section 2.8.4.1, below.

374

Type II — Network Integrity Audits

In addition to the NPAC-initiated, on-demand audits to verify LSMS data, the NPAC SMS performs random statistical sampling of data at LSMSs, a.k.a Type II — Network Integrity Audits, also using queries.  This is an automatic, scheduled, non-manual-intervention, background process that runs on the NPAC SMS during off-peak periods and performs a random statistical query of LSMS data over the LSMS mechanized interface to measure the consistency of data between the LSMSs and the NPAC SMS.  The result of this process is a monthly report indicating any discrepancies found and generating an overall consistency score for data storage between the NPAC SMS and LSMSs.  The results of this report are researched to identify the cause of the discrepancies and initiate corrective measures to fix any systematic problems that may be revealed (at either the NPAC SMS or one or more LSMSs).

2.8.4   On-Demand Audits (Type I — Repair Audits)

Service provider-initiated, on-demand audits, with recipient screening, are standard in Lockheed Martin’s NPAC SMS for NYCAC.

Requirements R8-1 through R8-3 and the title of RFP Section 8.1 all refer to service provider verification of NPAC SMS data via queries.  However, the audit write-up provided to vendors at the October 11, 1996 NYCAC NPAC/SMS Bidder’s Conference, states that three types of audits should also be supported:

•Type I — Repair Audits

•Type II — Network Integrity Audits

•Type III — Housekeeping Audits.

375

Thus, it appears that NYCAC would like to have the capability for on-demand, service provider-to- service provider audits a.k.a Repair Audits.  We offer the use of on-demand service provider repair audits, a standard feature in the Lockheed Martin NPAC SMS generic releases, for use by NYCAC.  Our implementation of this type of audit is summarized in Exhibit 2.8-1 (above), and is in complete accordance with the Audit Handout provided at the NYCAC NPAC/SMS Bidders’ Conference.  Our implementation enables the NPAC SMS to screen an SOA audit request from those LSMSs that may be specified in the audit request where the LSMS operator (service provider/user) has indicated it will not accept audits from the requesting service provider.  This audit screening capability in the NPAC SMS allows service providers to identify to the NPAC SMS the service providers from which they will or will not accept audits.  This data is stored in the service provider profile tables defined in Section 2.3 and may be updated as required.  Presumably, this information is used to indicate where inter-company business arrangements may permit inter-provider audits to be processed and where such arrangements may not exist.  The use of the screening capability itself is optional should inter-provider audit functionality within NYCAC not be based on inter-company business arrangements.

The material presented in the rest of Section 2.8.4 describes the on-demand repair audit administration functionality for service providers available from the SOA to NPAC SMS interface and from the OpGUI.

2.8.4.1On-Demand Repair Audits: Service Provider SOA to NPAC SMS Functionality

Authorized service providers of the SOA to NPAC SMS interface can create audit requests on a single TN or on a specified range of TNs and receive audit results.  Such requests are initiated through the

376

NPAC SMS. The TN range for audit requests is limited by the “Audit Request TN Range” specified in the Service Data Table shown in Section 2.3.  In addition to specifying a range of TNs to be audited, the service provider may also define the scope of an audit by specifying the following information and audit parameters:

•Audit Name

•Requester ID (service provider ID)

•Target LSMSs: all or a specific list of service providers

•Perform a full or a partial audit for the following attributes

•LRN

•CLASS GTT

•LIDB GTT

•ISVM GTT

•CNAM GTT

•Block audit: In case of a range of TNs, perform an LSMS query for every numerical TN in the range, regardless of whether the NPAC SMS has a version for the TN.  This verifies that only TNs that are currently ported are in the LSMS

•Audit TN activation date and time range.

Upon an audit request being successfully created, the NPAC SMS creates and logs a notification that is sent back to the service provider SOA indicating the audit request was created.  The NPAC SMS uses its audit screening capability to determine if all of the target LSMSs specified in the audit request will accept an audit from the service provider requesting the audit.  Those that will not are flagged as not auditable in the audit results.  Only those LSMSs that will accept an audit from that requesting service provider are actually audited.

377

If discrepancies are found in any of the audited fields in any of the target LSMSs, notifications containing audit discrepancy reports are sent back to the requesting SOA during the audit, using the SOA to NPAC SMS interface.  These discrepancies are logged on the NPAC SMS for tracking and reporting purposes and made available for retrieval by an authorized user. Notifications can also be logged on the SOA for local use by the SOA.  Discrepancy reports include information on the following error types:

•Record field mismatches between the NPAC SMS and local SMSs

•Record missing in local SMS

•Record missing in NPAC SMS

•Audit request not accepted by recipient.

Notifications are sent to the SOA when the status of an audit changes during the audit processes.  Valid audit statuses include:

•In-progress

•Canceled

•Complete.

A notification containing audit results, sent when the audit completes,  indicates the success or failure of the audit and the number of discrepancies found.

2.8.4.2On-Demand Repair Audits: Service Provider NPAC Operational GUI User Functionality

Access permissions are set up for a user session when the user logs on to the NPAC SMS Logon Window. Users are granted access based on the security configuration of their logon IDs.  Authorized users are able to navigate to the audit functionality supporting the audit administration windows via the

378

OpGUI Main Control Window.  From there, authorized service providers may navigate from the main control window to the audit administration windows shown in Exhibits 2.8-2 and 2.8-3.  These windows provide the functionality for service providers to create audit requests with audit parameters and view the audit query results.  The flow for querying audit components is detailed in Exhibit 2.8-4.

2.8.4.2.1   Repair Audit Creation

An authorized service provider may issue an audit request for processing by the NPAC SMS using the audit administration window shown in Exhibit 2.8-5.  The providers may request audits by specifying the same information and audit parameters (with the exception of requester ID) that are available via the SOA to NPAC SMS interface.

2.8.4.2.2   Repair Audit Viewing

Authorized service providers may view audit results and audit parameters from the audit query window shown in Exhibit 2.8-3.  Specifying an audit to view and selecting “View Results...” causes the window shown in Exhibit 2.8-6to be displayed.  Service providers may only view their own audit results.

2.8.4.2.3   NPAC Personnel Audit Administration

NPAC personnel have access to the audit administration functionality via the OpGUI windows shown in Exhibits 2.8-6 and 2.8-7.The OpGUI supports the functionality described below for NPAC personnel:

•Audit templates support (Section 2.8.4.2.4)

•Audit creation

•audit parameter specification

•prioritization

•Audit queries (Section 2.8.4.2.5)

379

•Audit viewing

•Audit cancellation (Section 2.8.4.2.6)

•Audit modification (Section 2.8.4.2.7).

2.8.4.2.4   Audit Templates

The OpGUI enables authorized users to create and save audit templates for reuse, thereby decreasing the time necessary to create an audit request.

Authorized users of the OpGUI may create, modify, and delete audit templates.  To do so, the user is required to enter a name associated with the audit template and the audit information and parameters.

2.8.4.2.5   Audit Queries

Audit queries for viewing audit requests and their current status are supported by the OpGUI for NPAC personnel from the Audit Query Window shown in Exhibit 2.8-7.  If the status of the audit is In Progress, the current progress of the audit is displayed in the active status box in Exhibit 2.8-7.  An authorized user can view the audit results from the audit query and cancel or modify an audit, as described below.

2.8.4.2.6   Audit Cancellation

If the status of an audit is In Progress or Scheduled, the audit can be canceled (by authorized NPAC personnel) from the audit query window shown in Exhibit 2.8-7.  If an audit is canceled, audit requests on the Local SMS are canceled using the NPAC SMS to local SMS interface and the audit status is changed to Canceled.  The audit cancellation on the NPAC SMS and local SMSs is recorded in the audit log.  Canceled audits are maintained in the system for a tunable number of days, as specified in the “Cancel Audit Retention” variable shown in Section 2.3.

380

2.8.4.2.7   Audit Modification

Audits with a status of Canceled are modified and resubmitted as a new audit (by authorized personnel) using the audit query window shown in Exhibit 2.8-7.  After specifying which audit to modify and selecting ‘Modify,’ the audit administration window shown in Exhibit 2.8-5 is displayed pre-populated with the canceled audits execution parameters.  When the user completes the necessary parameter modification, a new audit with a new audit ID is created for processing.

2.8.4.2.8   Audit Report Management

As the NPAC SMS performs an audit, it automatically generates audit log records to report discrepancies.  These discrepancies are used in the creation of audit results reports.  Because the NPAC SMS generates the audit log records in parallel with the audit NPAC SMS, users can create audit result reports while the audit is in progress.

The audit results report identifies:

•The service provider or NPAC user ID requesting the report

•The name and ID number of the audit

•The service provider(s) whose TN(s) were audited

•TN(s) audited

•Date and time of audit initiation

•Date and time of audit completion

•Subscription data mismatches between the NPAC SMS and the service provider

•Subscription records missing in the service provider network

•Subscription records missing in the NPAC SMS

•Audits that were not performed due to screening

381

•Total number of discrepancies.

Once an audit is run and an audit results report is created, the NPAC SMS stores the reports, making them available for retrieval and re-distribution.  NPAC users are able to print reports, view them via the GUI user, or electronically transfer them to user-designated destinations via FTP, E-mail, or fax.  The reports are retained for a tunable number of days before they are archived as specified in the “Audit Report Retention” shown in Section 2.3.  Data is retained in the audit logs for reporting purposes for the number of days specified with the tunable “Audit Log Retention” variable shown in Section 2.3.

2.8.5   Type III — Housekeeping Audits

Bulk FTP (Housekeeping) audits are supported in complete accordance with NYCAC requirements.

As indicated in Exhibit 2.8-1 above, the Lockheed Martin NPAC SMS implements Bulk FTP/Housekeeping audits in complete accordance with the Audit Handout provided at the NYCAC NPAC/SMS Bidders’ Conference.  These audits are mainly used for the purposes of performing routine database synchronization with LSMSs.

To implement these audits, our NPAC SMS automatically generates (no manual intervention required) database extract files at regular, predetermined intervals, and places the extract files on a secure FTP server.  At its own pace and schedule, each LSMS performs a FTP, downloading the NPAC SMS database extract files in order to compare the data in the NPAC SMS with its own database.  If discrepancies are found, the LSMS can then perform any corrective measures.

382

This Page Intentionally Blank

383

NYCAC NPAC/SMS PROPOSAL 2.9  Report Management

HIGHLIGHTS

•Built-in regionalized reporting — based on portability areas (NPA-NXX level groupings), NPA-NXXs, and/or state boundaries

•User-friendly graphical user interface for ease of use

•Real-time report generation capabilities for timely report distribution

•Batch and single reporting capabilities offering flexibility

•Data security to safeguard service provider competitively sensitive information

•Library of pre-defined reports for accessibility

•Ad hoc reporting to quickly satisfy one-time report requests

2.9   REPORT MANAGEMENT (RFP Sect. 9)

The NPAC SMS uses a secure, user-friendly reporting module to deliver comprehensive information—on a regional basis as necessary—to authorized NPAC and Service Provider users.

2.9.1   Overview (RFP Sect. 9.1)

The reporting capabilities for the proposed NPAC SMS are implemented through a standard, flexible, user-friendly reporting module that has three components: 1) the NPAC SMS Operational GUI, 2) a collection of reporting Processing Descriptor Engines (PDEs), and 3) a library of pre-defined regionalized reports.  The reporting module integrates ORACLE’s SQL*ReportWriter software into the NPAC SMS application to leverage proven COTS software, thus lowering implementation costs.  ORACLE’s SQL*ReportWriter provides considerable report design flexibility and extensibility, which facilitates the creation of new, pre-defined reports for inclusion in the report library and creation of ad hoc reports.

As shown in the following table, Exhibit 2.9-1, our suite of pre-defined NPAC SMS reports meets/exceeds the reporting requirements established in Section 9 of the RFP.

384

Reporting Requirements Matrix

Reporting Requirement	Satisfied by NPAC SMS Report(s)
List of ported TNs for a service provider	Service Provider’s Subscription List by Status
List of pending subscription orders for a service provider	Service Provider’s Subscription List by Status
Subscriptions without concurrence	Subscriptions Listed Area by Status
Status of pending subscription order for a TN being ported	Subscriptions Listed Area by Status
Date/Time Stamp of Subscription Port (Activation)	Subscription Report — All Data
Date/Time Stamp of Subscription Disconnect (Activation)	Subscription Report — All Data
Records that required conflict resolution	Subscriptions Listed Area by Status
Previous service providers and dates of service for ported TNs	Subscription Report (Old Versions)
Date/Time Stamp of Broadcast time for transactions	History Log Report
Subscription order records in error	Error Log Report
Download requests in error	Subscription Report (Failed Status)
Log of Missing Response from SOA for order matching	Error Log Report
Log of Missing Response from Local SMS for downloads	Error Log Report
Log of Unauthorized Access Attempts	Invalid Access Attempts Report
Counts of events and usage as described in resource accounting	Performance and Resource Accounting Reports
CPU usage	Overall System CPU Usage Report
Number of transactions handled and transactions per second	NPAC SMS Application Performance (subscription version downloads per second)
Measure of time starting from the receipt of subscription order activation to the broadcast of transaction to Local SMSs	NPAC SMS Application Performance Report (“activate” to “broadcast” processing time)
Measure of time starting from the receipt of subscription order activation to the receipt of response from Local SMSs	NPAC SMS Application Performance Report (SOA transactions per second)
NPAC SMS to Local SMS link utilization	NPAC SMS to Local SMS Link Utilization Report
NPAC SMS to SOA link utilization	NPAC SMS to SOA Link Utilization Report

Exhibit 2.9-1.Our NPAC SMS contains numerous pre-defined regionalized reports that meet NYCAC Section 9.0 requirements.

385

2.9.2   User Functionality (RFP Sect. 9.2)

The NPAC SMS reporting functions, including on-line report viewing, selection of easy to read pre-defined reports, scheduling of report production, and definition and selection of output destinations, are integrated in the NPAC SMS Operational GUI, providing a consistent presentation [R9-8].  The strong security component underlying the NPAC SMS Operational GUI limits the user’s ability to access reporting functions and data to the privileges specific to login IDs in the application security tables [R9-9].  The NPAC SMS Operational GUI security design allows report selection and data presentation to be enabled or disabled according to authorized user access privileges.

Specifically, the NPAC SMS Operational GUI provides authorized users the ability to:

•Select the type of report required from the standard suite of pre-defined reports [R9-1]

•Select the output destination of reports generated.  Destinations are printer, file system, local file system, E-mail, display, fax machine, or FTP [R9-2, R9-10, and R9-13]

•Reprint reports from previously saved report outputs, including backup output files [R9-3]

•Report from archived files [R9-3]

•Create customized reports through an ad-hoc facility [R9-4]

•Define scope and filtering for items to be included in the pre-defined and customized reports [R9-5].  For example, in the Subscription List by Status Report, users can limit the report to list only those

386

subscription versions whose statuses are active.  Additionally, all reports can be filtered on a State and/or Portability Area basis.

•Receive reports on information related only to their service provider-specific activity [R9-6].  For example, in the Subscription List by Status Report, only authorized users of either the old or new service providers would be able to view subscription versions for a portability area that has a status of conflict or conflict pending.

•Schedule report production times to balance system load and produce reports automatically

•Select the report output type and destination [R9-2] such as on-line viewing [R9-8], hard-copy printing [R9-8], files, e-mail, fax machine, and FTP [R9-10 and R9-13].

Some examples of report outputs are provided in Appendix D [R9-7]. The initial suite of pre-defined reports available to the NPAC and authorized service provider users are listed in Sections 2.9.2.1 to 2.9.2.10 below.  Using these reports as a base, we will customize these reports and report formats to meet NYCAC-specific requirements after contract award.

2.9.2.1   NPAC Business Information Reports

While this category of reports is not referenced in the RFP, these reports are required to support the day-to-day business operations of the NPAC.  They involve accounting, facilities, human resources, emergency response and disaster recovery information.  Examples include:

•NPAC Personnel List (Appendix D, Exhibit D-1)

•NPAC Emergency Contacts List

•NPAC Equipment Inventory

387

•NPAC Contact Vendor List.

2.9.2.2   Service and Network Data Reports

This report category provides authorized NPAC users with information for the service and network data described in Sections 3 and 4 of the RFP.  The following service and network data reports are available:

•NPAC System Tunable Parameters by State Report (Appendix D, Exhibit D-2)

•LRN Report (Appendix D, Exhibit D-3)

•Open NPA-NXX Report by Portability Area (Appendix D, Exhibit D-4).

2.9.2.3   Service Provider Reports

These reports present the network, subscription, and business data associated with the service providers.  Service Provider Reports include:

•Service Provider Portability Area Validation

•Service Provider Profile(Appendix D, Exhibit D-5)

•Service Provider’s Subscription List by Status (Service Provider’s own data only)

•Service Provider Local SMS Filtering/Routing

•Service Provider Audit Screening.

2.9.2.4   Subscription Data Reports

This report category provides authorized NPAC users with information for the subscription data described in Section 2.3.1.3 of this RFP response.  Subscription Data Reports include:

388

•Subscription Report (Appendix D, Exhibit D-6)

•Subscriptions listed by Status (Appendix D, Exhibit D-7)

•Subscriptions listed by Service Provider by Status.

2.9.2.5   System Reports

System reports provide information on usage measurements.  Authorized NPAC users are able to generate system reports for daily, weekly, monthly, and annual time periods.  System reports include:

•Overall CPU System Utilization Report

•System Statistics Report — Storage Utilization (Appendix D, Exhibit D-8)

•NPAC SMS Application Performance (subscription version downloads per second)

•NPAC SMS Application Performance (Local SMS broadcast time — “activate” to “broadcast” processing time)

•NPAC SMS Application Performance (SOA and Local SMS transactions per second rates)

•NPAC SMS Application Performance (SOA/Local SMS response time)

•NPAC SMS Application Performance (Provider SMS Database Sampling)

•NPAC SMS to SOA Link Utilization and Performance

•NPAC SMS to Local SMS Link Utilization Performance

•IVR Usage Report

•NPAC SMS Application Performance (Interface Transaction Rate).

2.9.2.6   Security Reports

This report function can only be accessed by authorized NPAC users.  Access to the following reports is provided:

389

•NPAC SMS User Report (Appendix D, Exhibit D-9)

•NPAC SMS User Permission Report (Appendix D, Exhibit D-10)

•Security Log

•Invalid Access Attempts Report

•NPAC Encryption Keys Report.

2.9.2.7   Log File Reports

The NPAC SMS contains several logs to record all actions taken and processes launched and executed within the system for resource accounting and tracking.  The following log reports are available:

•History Log Report

•Error Log Report (Appendix D, Exhibit D-11)

•Event Log Report (Appendix D, Exhibit D-12)

•Notification Log Report (Appendix D, Exhibit D-13)

•Subscription Transaction Report

•Service Provider Administration Report

•Subscription Administration Report.

2.9.2.8   Audit Reports

Our NPAC SMS report module contains reports that pertain to on demand service provider to service provider audits (if desired by the NYCAC and enabled) and NPAC initiated audits.  Audit reports include:

390

•Audit Results Report

•Archived Audit Results Report.

2.9.2.9   System and Network Management Report

The following reports are used to monitor and report on the efficacy, availability, reliability, and operational performance of the NPAC SMS system and network:

•System Availability Report (Annual Up-time, Scheduled System Downtime, Unscheduled System Downtime)

•System MTTF and MTTR Report

•System Disaster Recovery Report.

2.9.2.10   NPAC Operations Performance Reports

The following administrative performance reports are used to report on the efficiency and responsiveness of NPAC staff and customer service functions:

•Telephone Call Processing Report (Call Response Performance, Abandoned Call Rate, Callback Performance, Problem Resolution Performance)

•Documentation Order Processing Performance Report

•Logon Administration Processing Performance Report

•Customer Record Security Performance Report

•NPAC SMS Table Administration Performance Report

•Mass Change Administration Performance Report

391

•System Unavailability Notification Performance Report

•Software Acceptance Test Report.

2.9.3   System Functionality (RFP Sect. 9.3)

The proposed NPAC/SMS reporting module will be implemented using a collection of report generation PDEs.  The PDEs offer and fully support:

•Real-time processing for single or batch reports requested by authorized users

•Pre-scheduled processing for single or batch reports requested by authorized users

•Distribution of reports to user-defined output destinations

•Definition of new report production schedules

•Provision of easy to read on-line and hard copy reports of the requested information.

•Ability to transmit/transfer reports using FTP [R9-10]

•Tracking of reporting requests and activities in the NPAC SMS History Log [R9-11]

•Tracking of reporting errors in the NPAC SMS Error Logs [R9-12].

392

This Page Intentionally Blank

393

NYCAC NPAC/SMS PROPOSAL 2.10   NPAC SMS Reliability, Availability, Performance & Capacity

HIGHLIGHTS

•The Lockheed Martin solution offers the “highest” possible NPAC/SMS service availability, through network element-level availability and engineering standards that employ a diverse, fault-tolerant, real-time synchronized, mated-pair architecture

•Redundant NPAC data centers, each with fully redundant high-speed LAN and WAN backbones, guarantee availability of a primary or backup site for transparent NPAC operations and diversity of service provider access to the NPAC

•Stratus Continuum Series, based on HP PA-RISC processors in a symmetrical multiprocessing (SMP) architecture, enable NPAC SMS to be upgraded (CPU, memory, disk) while fully on-line and operating without any disruption

•Software architecture enables NPAC SMS software processes to be distributed seamlessly across multiple hosts, further enabling future NPAC SMS growth beyond individual servers

2.10   NPAC SMS RELIABILITY, AVAILABILITY, PERFORMANCE AND CAPACITY (RFP Sect. 10)

2.10.1Availability and Reliability (RFP Sect. 10.1)

Highest possible NPAC service availability is assured through the Lockheed Martin NPAC/SMS solution, using network element-level engineering standards.

The Lockheed Martin NPAC/SMS service offering provides the highest possible service availability through the strict application of engineering and availability standards usually applied only to service provider network elements.  Failure of any single component, system, network, or facility does not disable the NPAC/SMS service.  Data centers with redundant wide-area networking and continuously-available NPAC SMS platforms (provided by Stratus) allow the NPAC/SMS service to provide continuous availability if one or several of the underlying components fail.  The two NPAC SMS platforms and interconnecting WAN serving the State of New York — and, if applicable, other states joining the NYCAC — are engineered to replicate database updates between the two systems in real-time, enabling link cut-overs to the backup system to occur in seconds.  Consequently, there is no planned downtime of the NPAC/SMS service, nor does NPAC SMS system unavailability constitute NPAC/SMS service unavailability.  In case of planned NPAC SMS system outage (e.g., software

394

upgrade, or maintenance) or unplanned outage (software crash) in the primary (Tarrytown) site, the NPAC service will cut over to the backup site (Chicago NPAC) almost instantaneously without causing NPAC service disruption or outage.  Upon reactivation of the primary NPAC SMS system, service can be resumed on the primary system without incurring service outage or disruption.

The two NPAC/SMS service centers (Tarrytown, NY and Chicago, IL) assigned for support of New York and the NYCAC region will be interconnected to the same secure NPAC WAN.  Each of these facilities will have dedicated NPAC SMS platforms solely for used by the NYCAC NPAC SMS system.  Consequently, disaster recovery or backup cut-over activities occurring in the Illinois LNP LLC region will not affect or degrade the failover capabilities available to the NYCAC NPAC SMS.

As described in Sections 1.6 and 2.1 (above), the Lockheed Martin NPAC/SMS service consists of :

1.Two redundant and geographically diverse NPAC/SMS service (data) centers for disaster recovery in the event of a facilities outage or disaster.

2.Redundant, diverse WAN facilities consisting of both dedicated and switched facilities to ensure interconnection of the two service centers in the event of a communications outage.

Diverse WAN POPs for service provider/user interconnection into the Lockheed Martin NPAC WAN.  Unless there is a facilities disaster, all communications facilities have full access to either service center.  Consequently, cut-over to the backup service center does not rely on specific communications links.  Also, dedicated and switched (e.g., dial-up, frame relay) facilities are available for both diversity and cost efficiency.

395

3.Continuously-available, fault-tolerant NPAC SMS platforms in each service center to ensure platform availability without degradation in the event of any component failure.

4.Distributed NPAC SMS systems comprising a logical NPAC SMS system for a service center.

5.Traffic and load engineering standards that allow the NPAC database to be replicated in near real-time between the NPAC SMS platforms in the two service centers.

The NPAC SMS, based on the Stratus Continuum series of fault tolerant computers, provides a cost-effective, on-line, transaction-processing capability, with software and performance-transparent fault tolerance and significant expandability.

The Stratus-based NPAC SMS server also provides full network management instrumentation for centralized control and monitoring by the NPAC network management group.  The hardware, Stratus UX operating system, communications stacks, application software, and RDBMS support either SNMP or CMIP-based remote management.

As detailed in this section, the Stratus NPAC SMS server, software, and redundant WAN and LAN communications facilities provide a reliable 7x24 NPAC capability.  Our NPAC/SMS solution significantly exceeds the availability and reliability RFP requirements in RFP Section 10.1, requirements R10-1 to R10-14, including the following specific requirements:

•99.9% reliability of NPAC SMS, including all functionality and data integrity [R10-2]

•24 by 7 NPAC SMS and interface operations [R6-22, R10-1]

•99.9% availability of NPAC SMS interfaces [R6-23]

•24 hours or less of NPAC SMS scheduled downtime per year [R10-5]

396

•Nine hours or less of NPAC SMS unscheduled downtime per year [R10-3]

•One hour or less NPAC SMS mean-time-to-repair [R10-4]

•Restoration of receiving, processing, and broadcasting updates within 24 hours after a disaster [R10-13]

•Full functionality within 48 hours after a disaster [R10-13].

As described below in 2.10.1.1, our proposed Stratus Continuum hardware completely complies with the hardware design requirements specified in R10-9.  As required, our proposed Stratus Continuum-based NPAC SMS provides:

•Functional components with on board automatic self checking logic for immediate fault locating [R10-9]

•Continuous hardware checking without any performance penalty or service degradation [R10-9]

•Duplexing of all major hardware components for continuous operation in the event of a system hardware failure [R10-9]

•Hardware, which is fault tolerant, that is transparent to the service providers [R10-9].

Also, Stratus Continuum computers can detect and correct single bit errors during data transmission between hardware components [R10-7].

Given that NPAC SMS system unavailability does not cause NPAC/SMS service unavailability, both scheduled and unscheduled service unavailability should be extremely rare.  However, in the very unlikely event of service downtime, the NPAC will notify all service providers via an electronic broadcast message (e.g., e-mail, and web-based electronic bulletin board) if possible, stating the functionality that is unavailable, the reason for the downtime, and the estimated length of the downtime.

397

Otherwise, the NPAC will contact the service providers via their contact numbers [R10-10].  Also, all affected and unposted transactions will be resumed when the service resumes [R10-8].  If only partial functionality is available, the highest priority will be given to receiving, processing, and broadcasting updates [R10-11].  Please refer to the IIS document (Sections 5.1.1.10, 5.2.4, and 6.7.1) for a description of the interface recovery procedures used to re-synchronize LSMS and SOA systems with the NPAC SMS in case of service restoration.

Finally, as described in Section 2.1, the NPAC/SMS WAN and LAN are redundant, offering automatic, alternate routing during communication link outages, including outage of both vendor system hardware and/or facilities provided by Service Providers [R10-12].  All networking components provide complete diagnostic capabilities, allowing the NPAC SMS to monitor the status of all communications links and detect and report failures [R10-6].

2.10.1.1   NPAC/SMS Hardware Reliability

Even with a hardware failure, Stratus-based NPAC SMS delivers consistent, full performance, making NPAC/SMS operations immune to hardware failure.

The Stratus® Continuum™ Series, Stratus’ latest and most advanced family of application platforms, delivers the availability, features, and performance needed for large mission-critical OLTP applications.  The Continuum product family, which uses Hewlett-Packard’s PA-RISC 7100 and 8000 microprocessor technology to deliver exceptional levels of processing power, was specifically designed to incorporate a completely new system architecture that keeps pace with the advances being made in CPU performance.

398

Stratus Continuous Processing

Stratus originated a unique, automatic, hardware-based, fault-tolerant architecture and continues to enhance its implementation.  No technology other than Stratus combines trouble-free setup and robust processing with transaction availability.

Stratus Continuous Processing is based on the premise that to create a continuously available system, all aspects of the system design must be addressed.  Stratus provides features such as duplex self-checking hardware [R10-9], operating system maintenance and diagnostics, on-line upgrades, on-line service, and on-line system administration, thus avoiding potential sources of downtime.  In addition, Stratus’ fully integrated approach keeps the application, data, and processing available and free of corruption.

Stratus fault tolerance begins with power-up diagnostics that spot potential problems before they occur.  During operation, all computation, storage, and I/O proceed in parallel on duplex hardware.  Each circuit board checks itself for hardware errors at every machine clock cycle [R10-9].  If a logic fault is detected, the system stops the faulty board instantly while the duplex partner board continues to execute the program in a normal manner and at normal speed.  Thus, if a board should fail, there is no need for intervention by the operating system.  The failed board simply drops out of service and is automatically reported to a Stratus Customer Assistance Center.  This approach has the added advantage of catching transient errors as well as “hard” failures, resulting in higher availability and increased assurance of data integrity.

Memory is duplicated and ECC-protected and memory controller logic is self-checking.  Advanced “sniffing” circuitry checks memory for errors, ensuring that seldom-used memory locations do not develop non-correctable errors.  “Sniffing” does not affect the performance of ongoing work [R10-9].

399

Disks and disk controllers are also duplicated to prevent a failure from corrupting data or interrupting the system’s operation.  Whenever a write operation is requested, the operating system writes the data to both parallel disks; when a read operation is required, it comes from the disk whose read-write heads are closest to the data, thereby minimizing access time and offering performance benefits in read-heavy environments.  If a disk failure occurs, all disk I/O operations continue on the good drive until the malfunction is repaired.  When the failure is repaired, the system automatically restores the disk.  Here again, the application software is unaware of the failure or the redundant hardware architecture.

Continuum Models

For distributed and departmental environments, the Continuum family offers the 400, 600, and 1200-series models.  These high performance systems provide open, continuously available computing.  The performance of the systems in each of these series is roughly equivalent, the primary difference being in the amount of communications links and disk storage expandability.  Since the Stratus systems in the Lockheed Martin NPAC/SMS architecture do not directly terminate individual communications links to service providers, the I/O expandability of the 600- and 1200-series systems is not required.  Instead, common high-speed communications facilities (fast ethernet, FDDI, and ATM) are used to interconnect each Stratus system into the NPAC LAN at each service center, through which access to NPAC users is provided.

Hands-Off Availability

Because Stratus has designed continuous availability directly into the Continuum architecture, customers have the highest possible uptime with virtually no additional configuration, reprogramming, or administrative costs.  On-line service and system administration allow both the customer and Stratus to monitor the status of the system and the application.  In the event of a component failure, the Stratus architecture ensures that the system continues to function uninterrupted at peak performance, while

400

Stratus’ around-the-clock customer assistance center is automatically alerted to ship a user-installable replacement.

Thus, by addressing all aspects of system design needed for continuous availability, Continuum makes the world’s highest degree of reliability effortless and transparent to the user.  Duplexed, self-checking hardware and self-checking logic minimizes the chances of application or operating system downtime.  In addition, Stratus’ design eliminates routine planned downtime by allowing on-line service, upgrades, and systems administration.

Power Fail Ride Through Enhancements

The Continuum architecture (specifically the 600- and 1200-series models) features a robust power subsystem and DC-powered disk drives.  Although the NPAC data centers employ UPS systems and back-up generators to maintain power during blackouts, the power fail ride-through for Continuum Series systems has been expanded to 45 seconds (over the six-second ride-through available with prior Stratus models), to ensure against data loss, including full disk read/write operations.  This is significant, because more than 80 percent of power failures are of a duration of less than 10 seconds.

If power has not been restored after 45 seconds, application processing is suspended.  The operating system then copies all volatile data to disk, ensuring against data loss, while keeping data in memory.  After the data is written to disk, the system completes its shutdown.  When power is restored, a normal system restart occurs, minimizing application downtime and ensuring 100-percent data integrity.

Memory and Disk Configurations

The Stratus Continuum Series Family is illustrated in Exhibit 2.10-1.  Continuum Series models 610, and 1210 feature one pair of duplex CPU boards incorporating the 72MHz PA-7100 microprocessor.  Models

401

425, 620, 625, 1220, and 1225 feature one pair of two-way SMP CPU boards.  The xx20 (620 and 1220) models incorporate the same PA-7100 microprocessor with up to 512MB memory.  The xx25 models utilize two 96MHz PA-7100s microprocessors with up to 512 MB of memory.  Disk is expandable up to 82GB.  Model 1245 features two duplex pair of two-way SMP CPU boards (comprising four logical CPUs) with the 96MHz PA-7100s microprocessor and up to 1GB memory and up to 178GB disk.

[Graphic Omitted:  System family diagram (Stratus)]

Exhibit 2.10-1.  Stratus Continuum Series I Family

The Continuum Series models xx18H and xx28H (e.g., 418H, 428H, 818H, 828H, etc.) are the latest edition to the Continuum Family, and feature the 180MHz PA-8000 microprocessor, representing a 4x increase in CPU performance over the 96 MHz PA-7100 processor.  In addition, a 4x increase in memory capacity is available, supporting up to 2GB of RAM.  The xx18H models feature one pair of duplex 180MHz PA-8000 CPU boards (one logical CPU), and the xx28H models feature two pairs of duplex 180MHz PA-8000 CPUs (two logical CPUs).  For a comparison of the specifications and relative performance of the Continuum Series Family, see Exhibits 2.10-2 and 2.10-3.  Note the Lockheed Martin NPAC SMS platform is based on the Continuum 428H system (2 x PA-8000).

Model	CPU & Clock	Number of SMP CPUs	Max Memory	Relative Perf.
610S, 610, 1210	72 MHz PA-7100, 512KB Cache	1	512 MB	1.0
412	96 MHz PA-7100, 512KB Cache	1	512 MB	1.2
415, 1215	96 MHz PA-7100, 2MB Cache	1	512 MB	1.5
620, 1220	72 MHz PA-7100, 512KB Cache	2	512 MB	1.6
422	96 MHz PA-7100, 512KB Cache	2	512 MB	1.8
425, 625, 1225	96 MHz PA-7100, 2MB Cache	2	512 MB	2.7
1245	96 MHz PA-7100, 2MB Cache	4	1 GB	4.5
418H, 818H,   1218H	180 MHz PA-8000, 2MB Cache	1	2 GB	5.9

402

Model	CPU & Clock	Number of SMP CPUs	Max Memory	Relative Perf.
428H, 828H,   1228H	180 MHz PA-8000, 2MB Cache	2	2 GB	10.0

    Exhibit 2.10-2.  Stratus Continuum I Series Specifications Summary

[Graphic Omitted:  Stratus Continuum performance chart]

     Exhibit 2.10-3.  Stratus Continuum I Performance Comparison

Expandability

The Continuum architecture makes it easy to incrementally expand a system as needs increase.  All models within the 6xx and 12xx Continuum Series are on-line upgradable simply by swapping processor boards or by adding additional processor boards.

The design of the memory, disk, and I/O subsystems also makes incremental, on-line growth easy.  The Continuum family supports up to three I/O communications processors, four logical RISC processors, 2GB of duplex memory, 178 GB of duplex disk, and 84 I/O adapters, allowing up to 1,344 direct connect communications lines.

Future Stratus Continuum systems will incorporate newer processor technologies, from both HP (PA-RISC) as well as from the HP/Intel joint venture (Merced), resulting in significant performance improvements, as illustrated in Exhibit 2.10-4, to ensure continued scalability of the NPAC SMS capability.

Communications

The Stratus Continuum Series supports a broad range of industry-standard local- and wide-area communications technologies, including OSI, X.25, X.400, TCP/IP, ethernet, fast ethernet, FDDI, ATM,

403

and ISDN.  To meet this diverse need, the Continuum Series supports a wide range of I/O adapters, including 16-line asynchronous adapters, universal communications adapters, ethernet adapters, token ring adapters, X.21 communications adapters, and cannel attach I/O adapters.

[Graphic Omitted:  performance roadmap chart]

Exhibit 2.10-4.  Performance Roadmap for Future HP & HP/Intel-based Systems

The 400-series Continuum systems utilize a dual PCI bus architecture for I/O, offering the highest industry standard I/O bus available.  Consequently, both disk and communications I/O capabilities is not bottlenecked.

Transparently Redundant High-Speed LAN Ports (RNI)

While the Stratus system directly supports a wide variety of communications interfaces, the NPAC/SMS architecture calls for all NPAC SMS communications to be routed through redundant fast ethernet ports via the redundant NPAC data center virtual LAN.  The Stratus UX operating system supports a feature unique to Stratus: Redundant Network Interface (RNI).  With RNI, each of the two fast ethernet ports have an independent MAC-layer address for unambiguous packet-level routing and availability monitoring.  At the IP layer of the protocol stack, however, both physical ports share a common IP address, thereby enabling the Stratus to be dual-homed simultaneously off of both NPAC data center LANs.  Failure of one virtual LAN or fast ethernet port has no effect on TCP/IP virtual circuits established to the Stratus’ IP address, since the IP address remains available through the remaining port.  Lost packets are automatically re-transmitted in conjunction with standard TCP/IP reliable transmission protocol and routed via the available port.  Consequently, all single points of failure are completely transparent to service providers and their communications facilities.  Virtual circuit connections for both mechanized and user interfaces remain intact.  Also, during normal operation, data transmission into the

404

Stratus may be load-shared across both ports.  Standard packet sequencing logic in the TCP layer of the stack re-sequences packets regardless of the transmission path or sequence.

405

2.10.1.2   NPAC/SMS Software Reliability

Highly robust, self-auditing, and fault resilient NPAC SMS software based on proven platform software offers the highest availability.

The NPAC SMS operating system and layered platform products (e.g., communications, Oracle RDBMS) provide an extremely reliable, proven base upon which the NPAC SMS application layer operates.  The NPAC SMS application software and interfaces use proven application support facilities such as the BACE environment described in Section 2.1.3.  BACE provides an extremely robust, fault resilient environment that isolates software failures to specific processing steps and transactions and, thereby, safeguards overall NPAC SMS availability.  The BACE environment provides for application process parallelism (failure of a process instance does not render the NPAC SMS unavailable).  This feature also optimizes system performance in the Stratus SMP (symmetrical multi-processing) environment.  Database-stored rules-based process flow control isolate faults to specific processing steps and not to entire transactions, thereby preventing data corruption due to undetected errors.  Internal software auditing facilities constantly verify the internal health of the BACE operating environment to provide early detection and resolution.

[Graphic Omitted:  Chart depicting high-level application configuration]

Application software parallelism is further accomplished by virtue of distributing the NPAC SMS application system over several Stratus systems.  In support of the capacity requirements of R10-15 and R10-17, the NPAC SMS for the NYCAC region would grow to a total of five (5) Stratus Continuum Model 428Hs, each with two 180MHz PA-8000 processors and two GB of memory interconnected via ATM.  The NPAC SMS application software subsystems (CMIP agents, web-server, BACE, and Oracle server) will be distributed across these six systems, organized into three subsystems as illustrated in Exhibit 2.10-5.  While we expect that this configuration will support the R10-17 project volumes, there is

406

no theoretical limit to the expandability of the architecture, and Lockheed Martin IMS is prepared to expand the NPAC/SMS in order to satisfy the demand.

Exhibit 2.10-5.  Fully Configured NYCAC NPAC SMS configuration consisting of five Stratus Continuum 400 Series Model 428H systems.

In each of the three layers of NPAC SMS software (operating system, layered platform products, and applications), extensive remote system management instrumentation provides real-time software status to NPAC network operations personnel.  This management information enables extensive system, network, and software performance trending and analysis.  The associated reports will be made available to service providers [R10-14].

2.10.2   Capacity and Performance (RFP Sect. 10.2)

The NPAC/SMS offers high performance while providing for unlimited growth in capacity due to both functional or geographic jurisdictional factors with only incremental cost to hardware, network, and software.

The initial NPAC/SMS configuration has been engineered in full compliance with requirements R10-15 through R10-21 and R6-22 through R6-25.  There has been much discussion within the Industry concerning the necessary CMISE transaction throughput required for the NPAC SMS.  Currently, per requirements R6-24 and R6-25, NYCAC requires one (1) CMISE transaction per second per service provider SOA and Local SMS interface association.  However, from NYCAC’s answer to bidder question Q12, there also appears to be a business requirement to support a peak transaction rate of 25 ported numbers downloaded per second to each Local SMS interface association.  This throughput rate is also required for NPAC SMS systems in other jurisdictions: specifically, the Illinois LNP LCC, MCAC (Mid Atlantic Region), and West Coast Region to name a few.

407

Using some additional assumptions that are widely supported within the industry — 1) 20% of all activations will occur using a range of numbers, and 2) the average number of ported TNs in a range activation is 20 — the result is a throughput requirement of 5.2 CMISE transactions per Local SMS interface association.  In addition, other jurisdictions require a throughput rate of two CMISE transactions per second for each SOA interface association.

Together, these derived CMISE requirements mean that the NPAC SMS must support a sustained load of 7.2 (SOA + LSMS) CMISE operations per second per service provider (uploader), and 5.2 CMISE operations per second (ops or tps) for each user (downloader).  Thus, the initial 10 service providers represent a system total of 72 CMIP operations per second, for an aggregate download rate of 250 TNs per second (25 to each of 10 service providers).  The derived interface performance requirements due to the aggregate number of ported numbers and service providers drive the overall system throughput requirements, not the number of transactions identified in requirement R10-17. Our proposed NPAC SMS will support these higher, widely supported CMISE requirements as well as the transaction rates in R10-17.  In addition, our NPAC SMS architecture can readily scale to provide the CMISE throughput required to support 50 or more service providers [R10-15].

The R10-17 estimated ported numbers directly drive database storage and processing overhead capacities. Other activities, such as mass updates, audits, and reports do add to aggregate system load (5-12%, depending on assumptions).  But the nature of these activities (generally scheduled and lower priority) does not compete directly with bandwidth requirements for downloads and so does not factor into system performance sizing considerations except for disk capacity.  Our NPAC SMS can be readily scaled, adding the storage capacity necessary to support the required transaction estimates provided in R10-17.

408

In practice, the peak time for LSMS interface transactions are likely to be during off-hours, reflecting the time window when end-user facility cut-overs typically occur.  Consequently, the LSMS transaction peaks will not coincide with busy hour peaks for SOA transactions, which are expected to primarily occur during the business day.  In practice, these two transaction rates (LSMS vs. SOA) are not necessarily additive since the peak periods are unlikely to overlap.

As designed, our NPAC SMS exceeds both the <60 second broadcast update and the <3 second acknowledgment requirements [R10-19 and R10-20].

To satisfy R10-16, the NPAC SMS load generated by internal NPAC personnel is largely driven by the effective number of service provider requests for SOA and audit transactions.  We have also included in our sizing the load due to the estimated 30+ NPAC staff [R10-16].  Other non-transactional operations will be performed either locally on the users workstation or on a workgroup server.  Reports, history file reviews, etc., can be performed without burdening the NPAC SMS real-time response.  Large reports and usage-billing processing may be performed on the backup NPAC SMS in the backup data center since it has a current copy of the database (replicated in real-time from the primary) and can do so without adversely affecting its ability to step in as the primary, if required.  This further off-loads bulk processing from the primary SMS server.  NPAC SMS software processes in the Stratus that service mechanized interface transactions are configured to run with the UNIX real-time class priority, thereby insulating system response time from non-transactional operations.  With respect to R10-16, we anticipate that growth in NPAC usage will result in incremental additions of internal NPAC users, thereby causing a corresponding incremental load on the NPAC SMS [R10-16].

409

With respect to data storage, the NPAC SMS will be initially configured with 40GB of storage to maintain the subscription version and related database tables, as well as history records for one year (assuming an anticipated 30% churn), resource accounting records, service element usage records, transaction logs, security logs, etc.  This satisfies requirement R10-18.  To accommodate both planned and unplanned increases in system growth due to functional and/or geographic jurisdiction expansion, it is essential that the NPAC be extremely scalable.  The Lockheed Martin Team NPAC provides for expansion in three dimensions to satisfy requirement R10-21:

•NPAC SMS server expansion.  A single Stratus Continuum I fault tolerant system may be smoothly scaled up to two logical RISC SMP CPUs, 2GB of duplex memory, 178 GB of duplex disk, and 84 I/O adapters, allowing up to 1344 direct connect communications lines.  Further, upgrading the NPAC SMS may be performed on-line while the system is live, ensuring no disruption to operations due to unanticipated system upgrades.  This provides for scalability of a single processor system, as illustrated in Exhibit 2.10-6.

[Graphic Omitted:  graphic depiction of server expansion]

Exhibit 2.10-6.  NPAC SMS server expansion

•NPAC SMS software distribution.  The NPAC SMS software processes are configured to operate in a distributed fashion across multiple servers, as illustrated in Exhibit 2.10-7.  The initial system configuration, dictated by R10-15 and R10-17, and the derived CMISE requirements discussed above call for five (5) Stratus Continuum Model 428H systems operating cooperatively in a distributed

410

fashion.  There are several functional boundaries across which software may be distributed (e.g., front-end communications processing, database storage, rules-based process execution) to one or more additional servers, depending upon the nature of the NPAC/SMS system growth and needs for increased system bandwidth.  This advanced architecture enables unprecedented flexibility and cost savings in future system growth while retaining complete use and re-deployment of existing software and hardware.

[Graphic Omitted:  Chart showing server scalability]

Exhibit 2.10-7.  NPAC SMS scalability through software distribution

•NPAC network expansion.  The NPAC network design also supports a significant amount of functional, load, and geographic expansion while incrementally building upon existing infrastructure.  Use of cell-based fast hub (ATM-supportable) switching technologies ensures no upper limit on NPAC network capabilities to support expansion in POPs,  data centers, NPAC personnel, service providers, or NPAC SMS servers in a highly cost effective and non-disruptive manner.  Exhibit 2.10-8 illustrates the potential to expand NPAC/SMS services through the addition of NPAC/SMS service centers networked to accommodate the future increased capacity (e.g., location portability and number pooling) and functional requirements (trans-regional data interchange).

Exhibit 2.10-8.  NPAC SMS scalability through NPAC network expansion

[Graphic Omitted:  Map depicting SMS network]

411

This Page Intentionally Blank

412

NYCAC NPAC/SMS PROPOSAL 2.11  Billing/Resource Accounting

HIGHLIGHTS

•NPAC/SMS provides extensive resource accounting and usage data recording to enable detailed service element billing, if desired, to individual service providers based on usage-based cost

•Flexible, table-driven billing system can adapt to future regulatory cost recovery policies that may affect the NPAC pricing to service providers

•Extensive resource accounting and reporting capabilities enable Lockheed Martin to trend system usage and plan for upgrades to NPAC infrastructure gracefully with no disruption to ongoing operations

2.11BILLING/RESOURCE ACCOUNTING

(RFP Sect. 11)

2.11.1Overview (RFP Sect. 11.1)

NPAC/SMS performs extensive resource accounting and usage data recording to enable, if desired, detailed service element billing to individual service providers based on either direct usage-based cost or monthly pro-rata share billing.

The Lockheed Martin Team is sensitive to the problems faced by service providers in addressing the broader issue of cost recovery related to deployment of LNP.  The costs of operating the NPAC are part of the LNP deployment costs and, to the extent that such costs can be associated with an individual service provider’s use of the NPAC services, they can be correlated to the actual costs of offering those services.

Conceptually, billing to individual service providers based on their actual use of NPAC services should largely insulate NPAC services and the financial arrangements with service providers from impacts due to the mechanism eventually erected for the recovery from the rate base of those costs incurred by the service providers.  Once the final cost recovery methodology has been approved, there may be ways in which NPAC cost accounting mechanisms used in determining usage-based billing may be modified to dovetail with the way those costs are accounted and recovered.  Consequently, the Lockheed Martin Team

413

recognizes that flexibility in NPAC/SMS resource accounting and service element rating and billing is highly desirable.

Detailed Usage-Based Accounting and Billing

To support a detailed, usage-based accounting and billing scheme for NPAC users (service providers), the NPAC/SMS generates a substantial amount of highly detailed resource accounting data that is used to capture actual system and resource usage for processing in the NPAC billing system.  The NPAC billing system aggregates detailed resource accounting usage records and uses a combination of database-stored rules-based processes and usage element tables to determine the usage of NPAC service elements.  NPAC service element usage data is then rated using another rules-based and table-driven process to render invoices to service providers and supporting reports and audit data.

Pro-rata Cost Re-apportionment

Because our NPAC SMS and supporting systems record resource usage on a detailed, fine grain basis, our NPAC can easily reapportion usage-based cost elements to accommodate the cost recovery mechanism required by NYCAC for compensating the NPAC vendor.  We will work with the NYCAC to determine the method in which to bill NPAC/SMS users.

Detailed Resource Accounting Sources

Resource accounting data is generated from the following sources (thereby forming resource categories) within the NPAC:

•NPAC network access servers

414

•NPAC WAN routers

•NPAC SMS transaction processing subsystem

•NPAC SMS communication subsystem

•NPAC SMS batch (audits, reports, etc.) processing

•NPAC SMS remote user processing

•NPAC internal user workgroup server (e.g., faxes, PBX/ACD call records).

Detailed Resource Accounting Data

The NPAC SMS will measure all of the items listed in RFP Section 11.1, A to U, as well as others.  Examples of resource accounting data captured (by service provider) include:

•Interface link session data (duration, timestamp, machine id, packets sent/received, etc.)

•Remote user session data (duration, timestamp, access method, user id, packets sent/received) — Item A

•CMIP transaction data for LSMS and SOA interfaces (CPU usage, messages, acknowledgments, retries, errors)  — Items B, C, D, E, J, K, M, R

•HTTPS user transaction data (screens viewed, forms submitted, errors)

•Database transactions data (CPU usage, reads, writes) — Item R

•Database storage data (pending records, active, history, conflict, canceled) — Items F, G, H, L

•Database transmission data (bulk uploads/downloads) — Item Q

•Security data (keys exchanged, validations, violation attempts, failures)

•Subscription processing data (number of records created, corrected, queried/viewed, deleted, etc.)  — Items I, P

•Audit data (number requested, size, updates/corrections required) — Items N, O

415

•Report data (number/type requested, CPU time, errors)

•NPAC support data (number of phone calls, faxes, E-mails, voice mails)

•NPAC operational data (cut-overs to backup, errors) — Item S

•Service provider (NPAC/SMS user) connectivity data (number of links by types)  — Item T

•Non-standard NPAC resource usage — Item U.

2.11.2   Assumptions (RFP Sect. 11.2)

NPAC/SMS provides the necessary facilities to support the basic operating assumptions of detailed usage-based resource accounting with no performance degradation to the basic functions of the NPAC.

The NPAC SMS is sized to support the resource accounting recording overhead along with the actual usage itself.  Thus, the resource accounting measurements will not cause degradation in the performance of the basic functions of the NPAC.

2.11.3   User Functionality (RFP Sect. 11.3)

Recording of NPAC usage data is table-selectable to manage the overhead and amount of data generated.

In full compliance with RFP requirement R11-1, NPAC system administration personnel are authorized to invoke system tunable parameters and configuration data to enable or disable the recording of specific types of resource accounting data, or modify recording thresholds and intervals [R11-1].

416

2.11.4   System Functionality (RFP Sect. 11.4)

NPAC SMS system functionality enables the capture of a superset of resource accounting data identified above.

The NPAC SMS captures the type of resource accounting information described in 2.11.1 (above).  In addition to capturing this information, the NPAC SMS will:

•Measure and record the usage of NPAC resources on a per service provider basis [R11-2]

•Generate usage measurements for login sessions [R11-3] and for the allocated mass storage [R11-4] for each service provider

•Measure the number of transactions processed [R11-5] and the number of transactions downloaded to [R11-6] for each service provider, as well as the number of records sent in response to a request for resend of data from the service provider [R11-7].

After capturing, recording, and formulating the required usage information, the NPAC will render detailed periodic bills [R11-8] to the individual services providers in accordance with the Master and Service Agreements.

417

This Page Intentionally Blank

418

NYCAC NPAC/SMS PROPOSAL 2.12  Number Portability Administration Center

HIGHLIGHTS

•A functional organization shaped by experience and tailored to NPAC needs

•Skilled in the provision of independent, even-handed customer support

•Knowledgeable in the organizational dependencies and interfaces necessary for the delivery of portable number service

•Full regional NPAC SMS software and NPAC operations support from day one

•Proven capability to deliver and support telecommunications industry software

•Proven processes, procedures, measurements, and controls that ensure high customer satisfaction

2.12NUMBER PORTABILITY ADMINISTRATION CENTER (RFP Sect. 12)

2.12.1 Number Portability AdministrationCenter (NPAC) (RFP Sect. and 12.1)

The Lockheed Martin Team is the only neutral third-party supplier with proven experience in the provision of software support, data center operations, and the management and administration of a portable number database.

Lockheed Martin and its teammates for this procurement, including Evolving Systems, Inc. (ESI), have a detailed understanding of NYCAC NPAC/SMS needs and the ability to satisfy those needs according to NYCAC’s aggressive, but attainable, schedule — NPAC up-and-running, to support porting of live numbers by October 1, 1997.  As detailed throughout this section, Lockheed Martin is an experienced operator of data centers throughout the country, and ESI has demonstrated its capability and been recognized for the design, development, and support of high quality telecommunications application software, including the NPAC SMS for Illinois.

Lockheed Martin has a proven track record of successfully managing and administering the 800 number portability database for more than three years.  We are also responsible for the operational support services and administration required by users of the SMS/800 database.  The parallels between the

419

service requirements for 800 portability and for NYCAC’s local number portability are striking.  The knowledge and experience gained in coordinating and scheduling the inter-company testing and support for the delivery of SMS/800 software releases ensures a seamless transition for the introduction, maintenance, and future enrichments of the NPAC SMS application software with ESI.

2.12.1.1   NPAC Role (RFP Sect. 12.1, Page 78)

As operator of the SMS/800 NASC, we have developed a clear understanding of the role and responsibilities of the NPAC.

As the current 800 NASC administrator, Lockheed Martin is well versed in the activities required to operate and administer the NPAC SMS and understands that the NPAC must be operated in support of a consortium of local service providers. We further understand NYCAC requirements and recognize the need to provide these services in an evenhanded and neutral manner.

Utilizing our unique and extensive experience in NPAC-like operations, we have designed an in-depth organizational structure to implement the NPAC operations requirements.  In order to describe the proposed NPAC operations structure logically, we have taken the liberty of re-sequencing our response to Section 12 of the RFP to correspond with our proposed organizational structure.  Exhibit 2.12.1-1illustrates the mapping of RFP Section 12 to the corresponding sections in our proposal.

2.12.1.2   NPAC Organizational Interfacing (RFP Sect. 12.10)

In forming the Lockheed Martin Team, we assured that all Team companies were experienced and prepared to interact with diverse sets of organizations that comprised a full range of NPAC users.  Our User Support Services, System and Software Support, and Administrative Services and Facilities Groups are prepared to work with the main organizations and types of NPAC users (primary and secondary) as

420

illustrated in Exhibit 2.12.1-2.  Additionally, we will work with the service providers’ support and service administration organizations as well as third-party vendors who develop local SMS and SOAs for service providers.

2.12.1.3   Operational Functions (RFP Sect. 12.1, Page 78)

The NPAC contract will be serviced by our Communications Industry Services (CIS) line of business.  Our proposed director of the NPAC, Ms. Audrey Herrel, reports directly to Joseph Franlin, Vice President, Operations of CIS, who reports directly to Jeffrey Ganek, CIS Senior Vice President and Managing Director.

The RFP requires the NPAC to perform three primary functions:  System Administration, User Support, and System Support.  In response to this requirement, we propose an expanded and enhanced functional organizational structure based on our successful 800 NASC support, while allowing for the incorporation of software development coordination activities and maintenance of NPAC SMS database operations.  Our proposed NPAC organization is shown in Exhibit 2.12.1-3.  NPAC core responsibilities and functions are fully covered in our User Support Services Group, System and Software Support Group, and Administrative Services and Facilities Group.

Our NPAC organization concentrates staff expertise, reduces internal lines of communications, improves accountability, and clearly delineates responsibilities.  It facilitates the management of the interfaces associated with the NPAC environment, and provides the highest level of responsiveness to all users of the local number portability service.  We are also providing a Management Review Committee to provide additional management oversight and periodic review of NPAC operational performance.  The remainder of this section (2.12.1.3) is an overview of the responsibilities of each NPAC group.

421

User Support Services

The User Support Services Group satisfies the core business of the NPAC.  It ensures, foremost, that the users can use the NPAC SMS effectively to establish subscription version records and obtain provisioning services.  User support also includes the production support functions that prepare and maintain the operating environment access interfaces for the NPAC users.  These functions include:

•User problem resolution

•User operational assistance

•Scheduled NPAC SMS unavailability notification

•Service administration

•Mass change administration

•Software update notification

•Subscription administration

•Audit administration

•NPAC software acceptance/new release testing support.

Systems and Software Support Group

System support functionality is focused on the creation and maintenance of an effective operational environment for the NPAC and on resolving or coordinating resolution of all user NPAC SMS problems pertaining to system availability or technical communications.  Primary service functions performed in the three functional areas — NPAC SMS Administration and Operation, Network Control Center and Backup Disaster Recovery Operations, and Software Support — are:

•Logon administration and organizational access code assignment

422

•Customer (subscription version) number record security

•Server system configuration and administration

•Production control

•NPAC LAN administration

•NPAC PBX administration

•LINCSS Trouble Reporting System administration

•Workstation administration

•Local SMS download problem resolution

•NPAC report administration

•Failure recovery administration and notification

•NPAC SMS interface link monitoring and testing

•Data links monitoring

•Data network router and switch monitoring

•Administration and configuration of IP switches

•Backup/disaster recovery processor system administration

•Backup/disaster recovery testing support

•NPAC SMS software problem analysis and resolution

•NPAC SMS software applications maintenance

•COTS software update testing

•NPAC SMS interface operational support

•NPAC SMS tunable parameter table updates and maintenance

•System security tables updates and maintenance.

423

Administrative Services and Facilities Group

Administrative services include several management tasks required to run the NPAC.  These functions include:

•Secretarial, clerical, administrative support, and office management services

•Human Resources management, including workforce planning and staffing

•Capital equipment planning and acquisition for NPAC internal operations

•Facility management

•Purchasing/leasing

•Order processing for NPAC services

•Management of accounts payable and receivable

•NPAC SMS billing and adjustments administration.

Training and Documentation Services Group

Effective training in the operation and use of the NPAC SMS system and NPAC services is a key factor in the acceptance of the NPAC by the local number portability service community.  For this reason, we propose to:

•Develop training curricula in accordance with users’ needs

•Deliver training to NPAC users and internal staff

•Provide course schedules and registration information

•Track and act upon user training and documentation feedback

•Enhance and maintain training materials

•Publish documentation

•Maintain documentation inventories

424

•Process documentation orders and distribute documents, including number portability guidelines

•Provide new software release training support.

Quality Assurance and Control Group

The establishment of a vigorous, effective quality assurance process is a key element of our proposal and is of vital importance to the success of the NPAC.  Specific functions that are addressed by our Quality Assurance and Control Group include:

•Ensuring service evenhandedness

•Monitoring system and operations performance

•Developing productivity and system performance standards

•Coordinating NPAC SMS testing

•Developing quality assurance education and training programs

•Introducing process improvement initiatives

•Reporting and analyzing quality performance

•Establishing system and physical site security administration standards

•Developing procedures and document reviews and/or audits

•Directing NPAC SMS software acceptance/new release software acceptance testing and certification

•Providing backup/disaster recovery testing reporting.

425

2.12.1.4   Administrative Functions (RFP Sect. 12.1, Page 78)

As discussed above and throughout the remainder of this section, our services include all of the administrative and technical functions needed to successfully manage and operate the NPAC.  We will be accountable for all personnel and the legal and financial management associated with the NPAC.  This includes billing management, staffing, equipment and facility procurement, facility management and readiness, and other daily management tasks.  The NPAC director — working with the administrative services and facilities group manager, Lockheed Martin IMS Human Resources, and ESI — is responsible for the administration of NPAC staffing, thereby ensuring the attainment of contractual and operational needs.

As stated above, our User Support Services Group is responsible for working with local service providers to update tables for routing calls of ported local numbers.  The Training and Documentation Services Group will distribute the most current version of ported local number administration guidelines.  In addition, our presence at industry forums will ensure the gathering and provision of industry defined needs to our Systems and Software Support Group, enabling requirement definition, prioritization, development, and introduction of NPAC SMS software enhancements and releases.

The NPAC will contain highly qualified Lockheed Martin Team members who have a clear understanding of industry issues, are experienced in the provision of ported number administration services, and possess the required data center skills to successfully manage and administer the NYCAC NPAC/SMS.

426

This Page Intentionally Blank

427

2.12.2System Administration and User Support (RFP Sect 12.1, Page 78 and Sect. 12.8)

The NPAC User Support Services Group provides a single point of contact for NPAC/SMS users, ensuring consistent, reliable, and timely assistance.

Asingle, centrally managed group dedicated to serving all user needs and performing system related administrative tasks is essential to providing the high level of customer service required in the NPAC/SMS environment.  For this reason, we are proposing that most of the responsibilities of System Administration (RFP page 78 and RFP Sections 12.4, 12.6, and 12.7) and User Support (RFP Sections 12.8 12.8.1 and 12.8.3) be performed by the same organizational element — the User Support Services Group.  Software acceptance testing responsibilities (Sections 12.5 and 12.8.2) are discussed in Section 2.12.6 of our proposal.  Our organizational approach ensures that the Lockheed Martin Team’s NPAC User Support Group will become the focal point for interfacing with the service providers for system access, support, and information required for local number portability provisioning.

In the Lockheed Martin organization, the User Support Services Group is responsible for the required system-related administrative functions of the NPAC, including: user access (where appropriate will be referred to the System Support Services Group), scheduled system unavailability notification, NPAC SMS Table administration, mass changes, and NPAC SMS software acceptance/new release testing support.  This organizational approach allows users to use the system effectively in establishing subscription records and performing provisioning services; to resolve system access, customer record (subscription) number record input, and modification problems; and to clarify questions they have about NPAC SMS features and capabilities.

428

As discussed in this section, the primary activities of the User Support Services Group include:

•Subscription Administration

•Scheduled system unavailability (notification via NPAC electronic mail and facsimile) — also scheduled system unavailability is broadcast via the NPAC SMS Interfaces

•Service provider and network data table administration

•Mass change coordination and administration and operational assistance

•User problem resolution and operational assistance

•Software update notification (via NPAC electronic and facsimile)

•Software acceptance/new release testing for the NPAC SMS features and functions listed above

•Audit Administration of the NYCAC agreed-upon audit types.

Our placement of the relevant System Administration responsibilities under the auspices of the User Support Services Group provides NPAC/SMS users with the highest level of service by ensuring that system administrative functions are accurate and timely. Furthermore, we ensure that these fundamental responsibilities are closely managed and better understood within the context of all user needs, and the group is better able to focus on their primary mission — providing effective support to the NPAC/SMS user community.

2.12.2.1   Scheduled System Unavailability Notification (RFP Sect. 12.4)

Our experience and 100% on-time track record for notifying SMS/800 NASC users 14 days in advance of scheduled system unavailability ensures NPAC SMS users of timely notification for scheduled system unavailability.

429

The User Support Services Group is responsible for notifying NPAC SMS users of scheduled system unavailability for routine maintenance as well as immediate system unavailability due to non-critical system failures [R12-11].  These notifications, example shown in Exhibit 2.12.2-1 will be delivered via E-mail, facsimile, and posted on the NPAC web-based electronic bulletin board.

We issued more than 100 Client Service Bulletins,and more than 300 SMS/NEWS electronic Bulletin Board messages in operating the SMS/800 NASC in 1995.  These messages informed users about

430

scheduled system unavailability, new and existing SMS/800 features and procedures, new software releases, network changes, and other issues that impacted the SMS/800 user environment.

In our operation of the NPAC/SMS, we will have open lines of communication to facilitate good working relationships with all NPAC users, keeping them fully informed about all issues such as scheduled system unavailability that could impact their work, including system unavailability.  We will inform users well in advance of any planned/scheduled system unavailability, usually within 14 days — 24 hours in advance at a minimum.

2.12.2.2   Service Administration (RFP Sect. 12.6)

Our proven controls and procedures managing the 800 NASC for the 800 industry ensure that the administration of NPAC database tables will be timely, accurate, and complete.

The experience we gained and success we achieved in operating the 800 NASC has demonstrated that placing responsibility for administration of service provider and network data tables in the User Support Services Group ensures proper control and management of this fundamental interface.  The functions for NPAC data table administration performed by the User Support Services Group, as shown in Exhibit 2.12.2-2, include:

431

•Creating and maintaining the appropriate service provider and network data tables (e.g., portable NPA-NXX and LRN) [R12-18]

•Mapping table information to the appropriate codes [R12-19]

•Creating and maintaining descriptive data table labels [R12-20]

•Performing customer impact analysis resulting from table maintenance

•Notifying NPAC users of any impacts

•Conducting NPAC software acceptance/new release testing for features and functions associated with mass changes

•Maintaining service provider information and network data tables.

Strict controls and verification procedures will be in place to ensure that timely, accurate, and complete table updates are performed in NPAC/SMS. These controls and procedures will be based on the existing and readily adaptable 800 NASC and Illinois NPAC table administration procedures.

The 70 or more NPAC system tunable parameters are contained in a System Tunable Parameters Table.  These parameters will be administered by the System and Software Support Group, because the parameters are technical in nature and are mainly used to control/manage NPAC SMS system resources.

432

2.12.2.3   Mass Changes Administration (RFP Sect. 12.7)

Our proven controls and procedures for managing mass changes for the 800 service industry ensure that NYCAC NPAC SMS mass changes administration is timely, accurate, and complete.

Coordination of mass changes requires close working relationships with the responsible organizations.  Our experience and success in operating the 800 NASC demonstrate that placing responsibility for the coordination of NPA split/mass changes in the User Support Services Group ensures proper control and management of this activity.Specifically, for mass changes, the User Support Services Group will:

•Maintain a close working relationship with organizations responsible for NPA mass changes and scheduling [R12-21]

•Receive and log mass change notification from the appropriate entity — NANPA for NPA splits; local service providers for mass LRN, DPC, or SSN changes

•Schedule dates for running mass change processing

•Perform impact analysis on the affected NPAC SMS administration tables, users and customer records [R12-22 and R12-23]

•Update the required NPAC SMS network data and mapping tables [R12-25]

•Coordinate and assist the System and Software Support Group in the monitoring of downloads to the carrier local SMS systems [R12-25]

•Review and disseminate output from mass change processing

•Notify affected NPAC users of dates/phases for pending NPA Splits or other mass changes via E-mail, facsimile, (Number Portability Bulletin example shown in Exhibit 2.12.2-3 and the NPAC web-based Bulletin Board [R12-24]

433

We are implementing controls and procedures to ensure timely, accurate, and complete administration of NPA splits/mass changes.  A sample NPA Split Control Checklist is shown in Exhibit 2.12.2-4.  These controls and procedures will be based on our existing, proven, and readily adaptable NPA split/mass changes procedures.

2.12.2.4   User Problem Resolution (RFP Sect. 12.8.1)

Our 800 NASC experience and proven success in resolving user problems and responding to inquiries for the 800 service industry ensures timely resolution and tracking of NPAC SMS user problems and inquiries.

The activities of the User Support Services Group include resolution of all user problems and inquiries associated with the NPAC SMS system.  These include:

•User access and security permission assignment coordination with the System and Software Support Group

•Data link problem resolution in conjunction with the System and Software Support Group [R12-30]

434

•Logon ID and password coordination with the System and Software Support Group

•Service provider data and network data

•NPA splits/mass changes

•Customer record (subscription) access, input, and modification problems [R12-26 and R12-28]

•NPAC SMS features and capabilities [R12-27]

•System status information and notification

•Acceptance test new NPAC SMS software releases [R12-29]

435

•New software release notification

•Scheduled system unavailability notification.

A typical problem is a user being unable to enter information into a subscription record in the NPAC SMS.  When this occurs, the NPAC User Support Services Group assists by pulling up the subscription record in question, examining its contents, and advising the user of the action(s) required to enter the information.

If the User Support Services Group cannot resolve a user problem on the initial contact, they negotiate a status/resolution commitment time with the user, thus setting an expectation for when the problem will be resolved.  If the problem is not resolved by the committed time, the User Support Services Group contacts the user, provides the current problem status, and negotiates a new commitment time. Any problem that cannot be resolved by the User Support Services Group is escalated to the appropriate NPAC operations support individual for resolution.  Our 800 NASC analysts resolve 92% of user problems on the initial contact; we expect this same high percentage for the NYCAC NPAC.

Our problem resolution and tracking system, LINCSS, will support NPAC operations by recording and tracking problems and their associated resolutions.  LINCSS is a real-time system that records the date and time of the problem report, the name or logon ID of the NPAC user reporting the problem, the nature of the problem, the priority assigned to the problem, any associated background information, plus any additional information required.  We currently use LINCSS for supporting the 800 NASC and Illinois NPAC/SMS.  A brief description of LINCSS is located in Appendix F.

436

2.12.2.5   Software Update Notification (RFP Sect. 12.8.3)

We will notify NPAC SMS users of major releases of NPAC SMS software at least 60 days before the new software is installed in the production system, allowing them to modify impacted internal local portability provisioning procedures.

Our 800 NASC experience has demonstrated the benefits of software update notifications sent early and often (multiple follow-up notifications).  This approach provides users ample time to prepare and reminds them to adjust the operations that may be impacted by the impending software changes.

The NPAC User Support Services Group will notify NPAC users of upcoming releases of NPAC SMS software using a Number Portability Bulletin (NPB) on the public NPAC web page [R12-36].  A sample NPB pertaining to a NPAC/SMS software update is shown in Exhibit 2.12.2-5.  We plan to issue major software release notifications 60 days prior to the scheduled software general availability date. These notifications include reason(s) for software release, a summary description of the release, descriptions for new feature/functionality, and changes to existing features/functionality.

Unscheduled software updates are occasionally required to fix critical system problems.  When these occur, we will notify the users as quickly as possible.  The NPB that notifies users of an unscheduled software update will identify the problem(s) being corrected.  All software release notifications will include documentation updates.

437

2.12.2.6   Subscription Administration

The NPAC User Support Group’s responsibilities for Subscription Administration include the following:

•Perform manual subscription administration, including version:

•Creation

•Authorization

•Modification

•Activation

•Disconnection

438

•Cancellation

•Querying

•Place and remove versions in conflict state

•Generate subscription reports, both pre-defined and ad hoc.

These functions are primarily performed upon request from an authorized service provider, in addition to mechanized subscription administration functions via the SOA interface, or functions not appropriate via the mechanized interface, e.g., conflict status changes and ad hoc report generation.

2.12.2.7   Audit Administration

Commensurate with the types of auditing the NYCAC member carriers agree upon, now and in the future, the NPAC User Support Group’s will have responsibility to administer and monitor the associated audit activities, such as:

•Performing on-demand service provider to service provider audits (Type I — Repair Audits) on behalf of carriers

•Generating NPAC Initiated Audits, mainly for trouble shooting, problems with Local SMS downloads

•Initiating database integrity sampling audits (Type II — Network Integrity Audits) to sample local SMS systems/database for accuracy with the NPAC SMS database

•Monitoring audit progress

•Evaluating of audit results

•Reviewing, administering, and distributing audit reports.

439

This Page Intentionally Blank

440

2.12.3  Training and Documentation Services Group

Our thorough and effective training program will ensure that NPAC users receive a level of training that consistently exceeds the contractual requirements, providing efficient and secure services for the NPAC/SMS service community.

As part of our support of the NYCAC NPAC/SMS, the Training and Documentation Services Group is responsible for ensuring that the user community receives proper training, particularly with respect to those system features that undergo additions, deletions, and/or modifications. Our guidelines require that this group pay specific attention to user feedback, primarily by documenting comments made by users during calls to the help desk. The activities the group performs to satisfy this responsibility include:

•Providing training to NYCAC NPAC/SMS users

•Preparing training schedules and conducting registration

•Documenting and tracking orders

•Maintaining, publishing, and delivering documentation

•Developing and maintaining training curricula

•Providing NPAC SMS software acceptance/new release testing support.

Training

The Lockheed Martin Team has extensive experience in developing and delivering training for technologically sophisticated programs.  Our existing 800 NASC training program (SMS/800 Database and Service Management System and 800 Network Management) and the NPAC SMS training program we are currently developing for the Illinois NPAC/SMS will be customized to meet the unique NYCAC NPAC SMS requirements, where and when used as the foundation for NPAC SMS User Training.  Exhibit 2.12.3-1is a partial table of contents for a prototype NPAC SMS User Training Instructor Guide.

441

User satisfaction starts with effective training; we will place major emphasis on initial and follow-up training offered to the NPAC/SMS user community.

We propose offering a User Training Course that is based on our SMS/800 experience and our work to date for the Illinois NPAC/SMS and covers how to use the system and what service providers need to know regarding Local Number Portability.  Specifically, the training will address:

•NPAC SMS system use, with classroom instruction that includes hands-on practice

•What a service provider needs to know about local number portability service provisioning, subscription administration and management, version management, audit management, and report management

•General training related to the service industry

•Functions and services of the NPAC

•NPAC SMS system functions for ported number record searching, administration and provisioning

•User-oriented reports

•User-oriented administrative/operational procedures, such as problem reporting and resolution, conflict management, and regulatory concerns.

We propose that NPAC SMS User training be characterized by hands-on exercises based on actual operational cases.  Our training and documentation capabilities make it possible to perform large-group training for new NPAC SMS users and for local number portability service providers not currently using

442

NPAC services.  Specialized feature/function training will provide the in-depth knowledge needed for specific operational functions, including a full program of continuing education for current NPAC users.

Since NPAC is a service-oriented support function involving a high degree of interaction with users, every NPAC staff member will undergo the full set of NPAC SMS User training, plus additional training on his/her specific NPAC functions.  Training will be conducted for our employees and recent hires who are new to the NPAC.  Our Training and Documentation Services Group is responsible for teaching new job skills to NPAC staff members who assume new technical or supervisory responsibilities; providing additional emphasis in areas requiring improved performance; re-emphasizing fundamental skills or practices; and introducing changes in systems or practices.  In addition, a regular program of refresher training, including units in quality assurance and security, will be provided for all NPAC staff members and management personnel.

When appropriate, we will provide and use the following training techniques:

•Formal classroom training (lecture, computer-based training, individual instruction, role playing, and simulation exercises)

•Hands-on training, e.g. user training

•On-the-job experiential learning

•Computer help screens

•Motivational support

•Quick reference guides

•Job aids, e.g., visual/symbolic instruction guides.

443

It is our experience that selecting the appropriate training methodologies enhances retention and learning and minimizes training expenses (cost and time).  For example, interactive training techniques transfer more information in a shorter time.  Interactive technologies can reduce training time by approximately 33% compared to classroom instruction while ensuring greater retention and higher levels of consistency.  This approach challenges the trainee, provides the flexibility of self pacing, and improves learning through immediate feedback.

Most training will occur at our dedicated training facility.  The Lockheed Martin NPAC training facility for NYCAC will be located in our Tarrytown, New York Primary NPAC Facility, adjacent to NPAC operations.  The training room will be equipped with white boards that allow for diagrams and notes by the training manager.  A pull down screen will be positioned at the head of the class for use with an overhead or slide projector.  The room will be equipped with excellent lighting, acoustic wall material, and wall-to-wall carpeting.  It includes a PC/overhead video projector system for instructors.  We intend to locate the training room in a quiet area of the NPAC, away from printers and telephones.  Training is also provided on-site at NPAC/MS user locations.  The NPAC training center is equipped with basic PC workstations linked to our NPAC/SMS training system.

The training staff includes personnel who will develop, administer, and perform training and produce documentation.  The NPAC will maintain literature describing training and documentation that is available, including schedules, content, and prices.  This literature will be updated quarterly or more frequently, if appropriate, and made available to users on the NPAC SMS web-based electronic bulletin board and in brochures.

We will develop NYCAC NPAC/SMS training materials based upon the user guides and manuals using our 800 NASC materials and other current Illinois NPAC/SMS documentation as a starting point.  Training materials will be modified to reflect new software releases and changes in functionality.

444

All required training and job support materials, including instructor and user guides, trainee exercises, and classroom materials will be designed and produced to meet user needs. Instructional materials for trainers and train the trainers will also be produced, and participants will have procedures, operators manuals, and other job aids and training materials to assure their training is complete.

Documentation

Technical documentation will cover NPAC operations to assure that users are aware of the functions and services available to them.

Trainees will receive student guides for each of the training courses they take and instructors will receive instructor guides and classroom materials.  As we now do for 800 NASC users, we will send out training updates thirty days before new software releases.  Number Portability Bulletins (NPB) will be issued usually within two weeks before minor changes affecting NPAC users are implemented.  Training materials will be updated to reflect changes in software and procedures that impact upon the users.  An electronic User Bulletin Board will be maintained to provide information on training and course scheduling as well as other information of interest to NPAC users.  Periodic newsletters are also planned.

Technical Assistance

The experience we gained in our role as the SMS/800 trainer ensures that we will provide appropriate subject matter assistance and advice on an as-needed basis to NPAC SMS users.

Our User Support Services group will provide 24-hour assistance seven days a week to NPAC SMS users through our 1-800/888 hotline and will respond to all questions and issues regarding Training and Documentation raised by NPAC users.  In addition, user feedback on training and other problems raised in the hotline calls will be entered into our problem tracking system and, by analyzing frequently-mentioned difficulties or repeatedly-asked questions, we will improve and focus our training on problem areas and revise our training courses and manuals to remedy user difficulties.

445

2.12.3.1   Training Delivery and Administration (RFP Sect. 12.8.4)

Our training delivery methodology and administration process ensures class availability, proper handling of registration requests, and provision of actual NPAC user training.We currently administer SMS/800 training classes, developing course curricula and training materials, scheduling the courses, adding classes based on demand, and conducting the training courses.  Our SMS/800 training experience and ongoing work for the Illinois NPAC/SMS can be readily adapted to provide a proven, effective NPAC training solution for NYCAC NPAC/SMS users.

We currently provide the following training services for SMS/800 users:

•User and internal staff training

•Course schedules and registration information, including brochures, forms, and welcome letters

•Training material enhancement and maintenance

•Documentation inventory maintenance

•Document request processing and distribution.

An example of our proposed NYCAC NPAC user training registration form is shown in Exhibit 2.12.3-2, and an example of our training welcome letter is provided in Exhibit 2.12.3-3.  We understand the importance of user training as it relates to the success of local number portability.  We therefore propose to provide NPAC user training ourselves, thus maintaining close contact with NPAC users and, in the process, obtaining first-hand information about NPAC performance and NPAC user concerns.

By providing both NPAC training and operational support, we will solidify the image of the NPAC as a competent, evenhanded, independent organization whose primary emphasis is on supporting NPAC

446

Users. This will enable us to continually improve our service to the NPAC user community.  Additionally, by using LINCSS, our problem tracking system, we will ensure all training feedback received from NPAC Users is incorporated for inclusion in future training updates.

Our emphasis on training is further demonstrated by our establishment of a dedicated Training and Documentation Services Group specializing in the administration and provision of NPAC user training and documentation.  The Training and Documentation Services Group will be the primary contact for course schedules [R12-37], registration information [R12-37], and the availability of NPAC education [R12-38].  In addition to training NPAC users, The group will be responsible for training our own NPAC staff. The User Support Services Group will attend training courses prior to their being offered to any NPAC users.

2.12.3.2   Documentation Delivery and Order Administration (RFP Sect. 12.8.5)

Our documents ordering administration procedures are based on SMS/800 experience and ensure that all documentation order requests are received, filled, shipped within 24 hours, and properly billed.Document-ordering administration includes the Training and Documentation Services Group’s processing of document requests [R12-39], billing [R12-40], distribution of document updates [R12-41], documentation order status, and inventories.   In addition, the Training and Documentation Services Group will provide literature that discusses the documentation available to user, how to order documentation, and the associated prices of documentation [R12-42].  Concentrating the responsibility for training and documentation in a separate unit apart from the User Support Services Group, enhances the overall efficiency and responsiveness of the NPAC.

Our existing 800 NASC documentation order administration procedures are an excellent foundation for the NYCAC NPAC operation. These proven procedures are being tailored to meet NPAC requirements. The Lockheed Martin-developed problem resolution and tracking system — LINCSS (Lockheed Martin

447

IMS NPAC Client Support System), which we currently use to support the 800 NASC and Illinois NPAC/SMS projects — will be used to log all requests for documentation and training, and will support:

•Order entry for NPAC SMS documentation and requests

•Order status tracking through to fulfillment

•A client file for order verification

•Source record for NPAC SMS documentation billing.

LINCSS will also provide reports, including information on ordering, tracking, and delivery of the NPAC documentation and training.  Documentation requests will be entered into LINCSS as they are received by the Training and Documentation Services Group, and reports will be generated daily to ensure that orders are fulfilled within 24 hours.  Reports will provide NPAC operations with a history of all documentation requests and their final fulfillment.

2.12.3.3   Training and Documentation User Feedback (RFP Sect. 12.8.6)

User feedback will be recorded in LINCSS to ensure that NPAC SMS training and documentation is continually improved and refined to meet user needs. This unique problem resolution and tracking system will provide the NPAC with the capability to record all problems associated with NPAC SMS.  The User Support Services Group, the centralized point of contact for all NPAC user problems, will log on to the system and enter information as it is received.  The reports provided by LINCSS will enable NPAC management to identify frequently reported problems, potentially leading to NPAC SMS system enhancements and modified approaches to training.

The Training and Documentation Services Group is an integral part of our plan to ensure a high level of service delivery.  All feedback received from NPAC and NPAC SMS user contact — telephone calls,

448

questionnaires, and meetings — will be assessed and incorporated through proper channels into our training and documentation [R12-43].  Exhibit 2.12.3-4is a sample questionnaire that will be used to solicit feedback from students upon completion of NPAC SMS user training.

Our training program is designed to meet the needs of users on an ongoing basis.  We will collect user feedback to help us develop new courses, refine existing courses, and to update all documentation to meet the evolving and changing needs of the NYCAC NPAC users.

449

HIGHLIGHTS

•Skilled technical staff resolve Local SMS download data communications problems

•Efficiently fulfills NPAC SMS report requests within 24 hours

•Coordinates resolution of system availability and technical communications problems

•Ensures that interfaces from the NPAC SMS to other number portability administrative systems are operating properly

2.12.4System and Software Support Group (RFP Sect. 12.9)

Highly skilled staff within our NPAC facilitate the daily operation of the NPAC/SMS.

The System and Software Support Group is responsible for monitoring and maintaining the NYCAC NPAC/SMS operating environment and administering and maintaining the NPAC infrastructure.  Their responsibility includes the NYCAC Primary NPAC/SMS Facility in Tarrytown, New York, as well as the NYCAC NPAC/SMS Disaster Recovery site in Chicago, Illinois. The group, structured to facilitate reliable and efficient operation of the NPAC and the NYCAC NPAC/SMS, is partitioned into three organizations: NPAC/SMS Administration and Operation; Network Control Center; and Software Support.  Exhibit 2.12.4-1illustrates the interaction of these three functional organizations. Their individual responsibilities are summarized below.

NPAC/SMS Administration and Operation. Personnel assigned to this organization design, administer, and maintain the NPAC Tarrytown infrastructure, i.e., the NPAC PC-based Local Area Network,  upgrading all operating and application software for the administrative systems including the trouble tracking and reporting system (LINCSS), billing system, word processing software, spreadsheet software, project management software, logon ID administration, and password and security permission assignment.  This responsibility includes the systems at the Chicago NYCAC NPAC/SMS disaster recovery site and the primary NYCAC NPAC/SMS location in Tarrytown.

450

•Network Control Center (NCC).  Located at the Primary NYCAC NPAC/SMS Facility in Tarrytown, personnel assigned to this organization perform a systems and software support function for the entire NPAC network, including monitoring the WAN, local service provider links, the IP switches, and all other NPAC/SMS facilities using the HP OpenView-based integrated network management system.

•Level 2 Software Support. Personnel assigned to this function are responsible for providing users with NPAC SMS interface operational support and conducting COTS software update testing. They maintain the system software and provide problem analysis and resolution when software problems are identified.

The NPAC is equipped with a sophisticated data and voice phone system that ensures reliable access to all NPAC personnel, regardless of time of day.  Operation of the system is the responsibility of the Systems and Software Support Group. The NPAC SMS generates many system performance, ported number record, and problem exception reports.  This group is responsible for generating reports to fulfill NPAC user requests, validating the accuracy of the report generation process, resolving any problems in the comprehension of these reports by the users, and arranging for distribution of the reports. It is also responsible for coordinating the resolution of all user or NPAC SMS problems relating to system availability and communications.  These communications include notifying all NPAC SMS user groups of an unscheduled system unavailability or failure and providing status on the system’s recovery.

The group also provides assistance in resolving data communications problems with other NPAC SMS service systems identified through our continual monitoring of the NPAC SMS interfaces.  Automatic reports are generated to assist system users.  Additionally, the skilled technical staff in this group oversee and resolve local SMS download data communications problems as discussed below.

451

2.12.4.1   Logon Administration (RFP Sect. 12.2)

The success we have achieved in securing user access to the SMS/800 NASC database ensures that NPAC user access is controlled and administered in an accurate and timely manner.

The System and Software Support Group’s responsibility for logon administration procedures includes:

•Assisting users with new NPAC logon requests [R12-1]

•Verifying NPAC logon signature approval [R12-2]

•Assigning unique logon ID, password, and appropriate user class and security permission [R12-3]

•Updating the NPAC/SMS database and adding new users [R12-4]

•Notifying users of logon ID activation [R12-5]

•Resolving logon ID and password problems [R12-6]

•Performing NPAC SMS software acceptance/release testing support for system logon, electronic mailbox, and security features.

The tasks needed to activate a new user from logon request to user notification are shown in Exhibit 2.12.4-2.

Requests for access to NPAC SMS are submitted to the logon administrator via the NPAC Logon Access Request Form.  A sample form is shown in Exhibit 2.12.4-3.

Upon receiving an accurately completed and properly approved NPAC Logon Access Request Form, the NPAC logon administrator provides individuals with a unique logon ID and password. Each form is reviewed for accuracy, completeness, and proper signature authorization using the designated signature

452

form file maintained by the NPAC logon administrator for each NPAC user company.  Accurately completed and approved requests are assigned a unique logon ID, password, and user class/security permissions.

Each logon ID is entered in the NPAC SMS, initialized, and tested to ensure that appropriate user class and security permissions have been assigned.  It is the logon administrator’s responsibility to notify users of logon ID activation, mail them the processed NPAC Logon Access Request Form, and file a copy in the NPAC logon access request file.

All user access problems are entered in our Trouble Tracking and Reporting System LINCSS (Lockheed Martin IMS NPAC Support System), ensuring timely problem resolution.

The NPAC User Support Services Group attempts to resolve all problems as they are encountered. Access problems that cannot be resolved by a user support services analyst are assigned a priority level and escalated to the logon administrator within the System and Software Support Group.  If the logon administrator is unable to resolve an access problem, the appropriate NPAC support group is contacted for assistance.

2.12.4.2   Customer Record Security (RFP Sect. 12.3)

We understand the requirements to safeguard confidential NPAC information from unauthorized access or disclosure.

Our security procedures, monitoring and reporting tools, and high commitment to ethics and workplace integrity ensure that such information will be maintained in the most secure conditions possible. We will work with the NYCAC to establish user boundaries defined by distinct user classes and security permission groupings similar to the approach for the Illinois NPAC/SMS system [R12-7].

453

The appropriate security permission level and NPAC SMS function access will be assigned to distinct user classes and security groupings [R12-8].  These user classes and security permission groups will be published in the NPAC user class definitions and security permission groups document. A preliminary table of contents for this document is shown in Exhibit 2.12.4-4.

The logon administrator assigns logon IDs and access to NPAC SMS data and features in accordance with the NPAC user class definition and security permission groupings document, ensuring that NPAC users are granted access to the correct data and functions [R12-8].  Our procedures are designed to prevent an NPAC user from gaining access to the confidential information of another user and to block improper access attempts, exercising absolute control of access to customer information [R12-9].

We will monitor, log, and report unauthorized NPAC SMS access attempts and security violations [R12-10], execute the appropriate corrective actions and notifications, and complete and file a security discrepancy violation report.  A file of such reports and any other security issues and problems will be maintained and available for review by the NYCAC.  The file will also be used by the NPAC Quality

Assurance and Control Group to monitor the integrity of the system and to evaluate NPAC security policies and procedures.

2.12.4.3   Local SMS Download Problem Resolution (RFP Sect. 12.8.7)

Local SMS downloads will be monitored to ensure accurate and timely transmission of subscription and routing data from the NPAC SMS.

454

The NPAC System and Software Support Group will be staffed by personnel who are well versed in the NPAC SMS system’s technical capabilities.  This in-depth system knowledge, together with established operating procedures, ensures the timely resolution of all local SMS download problems.

The Group is responsible for monitoring local SMS downloads and for analyzing the information contained on exception reports resulting from unsuccessful local SMS updates [R12-44].  Resolution of subscription version/record and routing data download failures to a service provider’s network has the highest priority.  If a local SMS download failure is catastrophic (more than 50% of records fail to download) or if previous “re-sends” consistently prove unsuccessful, we will notify the administrative group(s) of the affected local SMS owner(s).  If problems are not resolved by a mutually agreed-upon time, we will notify all affected service providers.  Finally, we will continue problem resolution efforts until the identified local SMS download problems are resolved.

2.12.4.4   NPAC SMS Report Administration (RFP Sect. 12.9.1)

NPAC SMS report requests will be fulfilled quickly and efficiently within 24 hours.

The NPAC System and Software Support Group is responsible for administering the NPAC SMS reports.  This includes logging all NPAC SMS user report requests, generating and distributing the reports to fulfill NPAC SMS user requests [R12-45 and R12-47], validating the accuracy of the report generation process [R12-46], and resolving any problems with report interpretation [R12-48].

All users who have NPAC SMS logons may receive reports.  A critical function of NPAC SMS report administration is to verify the types of reports that can be received by a particular user or group based on security or permission level.  Upon verifying the proper security authorization for the report(s) requested, the requested report(s) are generated and distributed [R12-45].

455

All requests for standard NPAC SMS reports will be fulfilled by the Systems and Software Support Group within 24 hours.

2.12.4.5   Failure Recovery Administration and User Notification (RFP Sect. 12.9.2)

Our System and Software Support Group will provide users with frequent and detailed updates on the status of the NPAC SMS system after a failure has occurred.

In the event of an unscheduled primary NPAC SMS system outage, the following events will occur:

•The NPAC SMS interface associations between the primary NPAC SMS and service provider SOAs and local SMSs will drop

•The Backup/Disaster Recovery System in Chicago, Illinois will assume NPAC SMS operations

•The communication links to the service providers will be routed/re-established to the Backup/Disaster Recovery System

•The System and Software Support Group will notify NPAC SMS users the current and projected system outage (shutdown or failure) status through the issuance of a Number Portability Bulletin (NPB) [R12-49].

NPBs are broadcast by the NPAC/SMS E-mail System, or sent via broadcast faxes, and published on the NPAC web-based bulletin board.  A sample NPB informing users of an unscheduled system outage is illustrated in Exhibit 2.12.4-5.

The System and Software Support Group will serve as the key point of contact for system recovery status [R12-50].  This Group will notify the NPAC SMS user community within 15 minutes of a system failure,

456

and also provide updates on the system’s status every 30 minutes until the system is up and running and available to users.  Users also will receive a recorded message with status information when calling the NPAC hotline.

When the primary system becomes available, NPAC/SMS users are provided with an explanation of the condition that caused the system to become unavailable, as well as the time period during which transactions may have been lost.  However, lost transactions should not occur because NPAC SMS operations should automatically fall over to the backup/disaster recovery machine, and the Interoperable Interface Specification contains a mechanism for local SMS and SOA systems to re-sync with the NPAC SMS in case of failure.  We will assist users in reconciling failed transactions, should they occur.

2.12.4.6   NPAC SMS Interface Monitoring (RFP Sect. 12.9.3)

We will assist in the resolution of data communication problems between the NPAC SMS and other systems [R12-51], and provide technical assistance to users with problems accessing the NPAC SMS [R12-52].

The NPAC System and Software Support group provides technical support to users who encounter difficulty with their terminals or in connecting to the system.  This group analyzes problems, identifies possible causes, and assists users in regaining access to the system [R12-51 and R12-52].

System support analysts assigned to the group have the technical skills to quickly diagnose a problem.  After diagnosis, they communicate with the appropriate team member in the NPAC/SMS support group to resolve the problem. The analysts will also conduct communication tests between service provider local SMS and SOA systems, using a suite of tests to detect performance of availability problems.  Test results will be available for analysis and reporting [R12-53].

457

As with all other system problems, user access and data communication problems will be permanently recorded in our LINCSS trouble reporting and tracking system.

This Page Intentionally Blank

458

HIGHLIGHTS

•Geographically separate, fully redundant and replicated production data centers ensure non-stop operations during a catastrophic site failure, such as fire at the primary data center

•Collocated NPAC operations with our primary data center in Tarrytown offers economies of scale and cost savings

•Proven operator of 24x7 systems and data centers throughout the country

2.12.5NPAC SMS Data Center Facility and Operations (RFP Sect. 12.11)

Our fully redundant and geographically separate primary and backup/disaster recovery data centers ensure 99.9% reliability and less than 9 hours of unscheduled downtime.

The Lockheed Martin Team fully understands the importance of the NPAC SMS in allowing businesses and residents in New York to change local service providers and the potential impact if the NPAC SMS is down when activation notices are sent.  As such, we looked at several alternatives for providing backup and disaster recovery operations.  We considered locating dual machines in the same data center; however, we quickly dismissed this approach since a disaster at the site, such as a fire, could render both processors inoperable.  This approach is just too risky.

We also considered a second approach where we could contract-out the backup/disaster recovery operations to a third party, such as COMDISCO.  However, the processors provided at these facilities are typically shared and not dedicated.  Thus, when a large-scale disaster occurs, many customers are vying for the same machine.  Accordingly, we also dismissed this approach as inferior.

Thus, to absolutely ensure that the 99.9% reliability [R10-2] and less than 9 hours unscheduled downtime per year [R10-3] RFP requirements are met, coupled with the requirement to resume processing within 24 hours in the event of a disaster [R10-13], we determined that only fully redundant and fault tolerant

459

processors at geographically separate data centers will guarantee the RFP-required reliability and availability of the NPAC SMS for NYCAC.

The primary NYCAC NPAC SMS Data Center will be collocated with the NPAC at Lockheed Martin’s Tarrytown, New York, Data Center located at 777 Old Saw Mill River Road.  This data center supports systems that are used by more than 140 federal, state, and local government clients, as well as supports the 800 NASC.  The center is highly secure, professionally operated, and supports mission-critical, 24x7 systems on a wide range of hardware platforms.  It supports a large nationwide network and processes millions of business transactions per day.  This data center will also serve as the backup/disaster recovery NPAC/SMS facility for the Illinois LNP LCC NPAC/SMS.

In addition, the Tarrytown Data Center has a complete Network Control Center (NCC).  We plan to use this as the NCC for the NPAC SMS to monitor all service provider links to the Tarrytown Data Center and the backup/disaster recovery data center as well as the redundant DS-1 lines between both data centers.

To serve as the backup/disaster recovery data center, the Team has selected Lockheed Martin’s Chicago NPAC/SMS Facility.  This facility is data center ready with raised flooring, UPS, chillers, backup power generators, and a security system.  This facility will serve as the primary facility for the Illinois LNP LLC NPAC/SMS.

At each of these facilities, there will be dedicated NPAC SMS platforms solely for use by the NYCAC NPAC SMS system.  Consequently, disaster recovery or backup cut-over activities occurring in the Illinois LNP LLC region will not affect or degrade the fail-over capabilities available to the NYCAC NPAC SMS.

460

Data Center Operations

To ensure effective, reliable, and responsive operations, our System and Software Support Group will perform the following major operations as well others:

•System administer the NPAC SMS

•Monitor on-line performance using automated tools

•Optimize NPAC SMS performance and resource utilization

•Monitor, control, and secure access to all system resources

•Formulate and implement automation enhancements to reduce operator intervention

•Maintain backup tape libraries at both the Tarrytown and Chicago Data Centers

•Manage and control the WAN between the data centers and POPS for service provider connectivity

•Schedule and track production batch jobs to successful completion

•Investigate, track, resolve any and all NPAC SMS failures

•Resolve and escalate all problems according to in-place procedures

•Produce and distribute daily status and problem reports

•Request preventive maintenance services on all equipment

•Conduct disaster recovery testing at periodic, mutually-agreed time intervals.

We are confident that our fully redundant, dual, primary and backup/disaster recovery approach is responsible and the best choice for NYCAC, guaranteeing the RFP-required system reliability and uptime.

461

This Page Intentionally Blank

462

2.12.6   Software Release Acceptance Testing (RFP Sections 12.5, 12.8.2, and 12.9.4)

Our structured and comprehensive software acceptance test standards ensure that only high quality NPAC SMS application software is released to the field.

Lockheed Martin currently provides software acceptance release testing for the SMS/800 system.  For more than 3 years, we have developed and executed thousands of test cases for this system.  This number portability application software testing experience will be beneficial during our support of the NYCAC NPAC SMS by ensuring that the NPAC SMS application software is tested thoroughly and efficiently.  We propose to perform comprehensive acceptance tests on every new release of the NPAC SMS software before certifying it for production release.  We envision that NYCAC representatives will want to review our software acceptance test plans and procedures, and we welcome NYCAC’s involvement not only in the initial rollout of the NPAC SMS for New York but in subsequent releases of the NPAC SMS software as well.

Lockheed Martin’s teammate, Evolving Systems, Incorporated (ESI), will enhance the NPAC SMS software that we are developing to support NPAC services for Illinois, creating a standard Release 2 that will be deployed for NYCAC.  ESI will perform unit and integration testing.  Upon completion of the initial release of the NPAC SMS and for each subsequent release, ESI submits the new NPAC SMS software to the NPAC quality assurance and control manager, who develop a release acceptance test plan [R12-12, R12-30, and R12-54].  The test plan includes major milestone dates, release certification criteria, test scenario requirements, considerations for new features, test case pass/fail criteria, and pre-production installation test plan requirements.  The NPAC quality assurance and control manager certifies each release for production installation [R12-17, R12-35, and R12-59] coordinates new release testing across all NPAC operational

463

functions.  Testing is performed on both new features and on modified existing.  Acceptance test plans for major releases include full regression testing.

All NPAC operational functions participate in new release testing and are assigned to test those NPAC SMS features/functions associated with their specific procedural duties [R12-13, R12-31, and R12-55].  New release software feature/function testing responsibilities include [R12-14, R12-32, and R12-56]:

•Performance of unit, integration, volume, and stress testing for all releases of NPAC SMS software by ESI

•Performance of the following by the NPAC User Support Services Group:

•Subscription version record access, security, input, and modification testing

•Service provider and network data tables administration testing

•Mass changes testing

•Electronic bulletin board testing.

•Performance of the following by the System and Software Support Group:

•Logon administration and passwords testing

•User access and security testing

•SOA and LOCAL SMS interfaces testing

•Report availability/verification testing

•Interface monitoring testing

•Service data and diagnostic procedure testing

•Test scripts testing.

464

NPAC subject matter experts test features, verify compliance with user requirement specifications, identify software errors, generate and resolve testing trouble reports [R12-15, R12-33, and R12-57], and track and report test results [R12-16, R12-34, and R12-58] to ensure that only high quality software is released.  A major milestone plan, as exemplified by Exhibit 2.12.6-1, is developed for each software release.  Also a detailed plan is developed to schedule and track progress for new feature testing, existing feature testing, and regression testing.  Test plans are designed to thoroughly test feature functionality for ensuring compliance with user specifications and detecting software errors.

Test plans comprise individual test case scenarios, where each scenario describes the test and specifies an objective.  These scenarios identify the test data and set up requirements, (e.g., logon ID security class and permissions, subscription

465

version and tables data); describe actions to be performed; explain the results to be expected; and describe the procedures to document actual test results [R12-16, R12-34, and R12-58].

Software release acceptance testing is performed in a controlled test environment and all test (pass/failure) results are tracked and reported to our teammate, ESI, and NYCAC [R12-16, R12-34, and R12-58].

466

2.12.7  Administration (RFP Sect. 12.12)

A dedicated Administrative Services and Facilities Group focuses on the required administrative and financial functions.

The NPAC Administrative Services and Facilities Group performs the administrative and billing activities required under the contract.  We structured this group’s responsibilities to focus them entirely on NPAC administrative and financial functions with no direct NPAC/SMS support duties.  These organizational modifications concentrate staff expertise, reduce internal lines of communications, improve accountability, and delineate responsibilities in a manner that satisfies and, in most cases, exceeds the requirements of the RFP.

Our current 800 NASC and other operational experience has shown that certain functions occasionally require a higher level of subject matter expertise than that found within the administrative staff.  Our proposed division of responsibilities enhances NPAC/SMS security, improves efficiency of the administrative functions, and focuses all NPAC/SMS system administration, user support, software support, and systems support issues in the units equipped to provide this service, thereby correcting this problem and improving the overall level of NPAC support. Exhibit 2.12.7-1 identifies the functional organizations responsible for meeting or exceeding the key administration requirements listed in Section 12.12 of the RFP [R12-60 through R12-75].

The Administrative Services and Facilities Group’s functions include secretarial, clerical, office and facilities management, leasing/purchasing, human resource administration, payroll administration for the NPAC staff through Lockheed Martin IMS headquarters, and NPAC accounting operations.  Other duties

467

assigned to the group include all administrative and financial tasks pertaining to purchasing the physical NPAC/SMS facility and its planning and management.

The group is responsible for processing bills to the local number service providers and Local SMS owner-operators.  The extensive experience we have in providing similar billing services for several of our lines of business ensure that we are fully prepared to staff and administer the local number portability billing functions.

This Page Intentionally Blank

468

2.12.8     Facility Requirements (RFP Sect. 12.13)

Our planned primary NPAC facility, located in a production data center with ample office space and features, provides a professional and productive environment.

NPAC facilities planning is critical; many factors have to be considered, such as:

•The need for primary and backup/disaster recovery sites to meet reliability and availability requirements

•The location of both NPAC sites — they need to be geographically separate so a single disaster does not affect both sites simultaneously

•The ability of NPAC sites to offer not only a secure data center environment, but also provide an ideal service center environment

•The ability of NPAC sites to expand to meet future needs

•The accessibility of the primary NPAC site

•The communications network that connects service providers to the NPAC SMS — it must offer multiple access points for cost effectiveness and diverse routing for high availability.

We considered all of these factors when selecting our primary and backup/disaster recovery NPAC sites and the NPAC SMS communications infrastructure.

Communications Network

As fully described above in Section 2.1, a frame relay network will be used to provide a virtual point-of-presence (POP) in New York LATA 132.  In addition, actual, facilities-based POPs will be located at the primary NPAC facility in Tarrytown and at the backup/disaster recovery NPAC facility in Chicago.

469

Service providers will have the option to connect to any POP to access either NPAC facility.  Dial-up facilities will be supported at each NPAC facility as well.

Tarrytown Primary NPAC Facility

After careful consideration of the factors listed above, Lockheed Martin has selected our Tarrytown Data Center to serve as the primary NPAC facility for performing all NPAC functions [R12-79].  This facility is located at 777 Old Saw Mill River Road, Tarrytown, NY, and has been designed to emphasize security and data protection.  The risk of disruption due to power outages has been virtually eliminated through the combination of multiple power grids feeding the complex and an uninterruptable power supply (UPS). Further protection is provided by multiple fire detection and prevention systems; sensors that constantly monitor temperature, humidity, and electrical flow; video surveillance; and protected security guards 24 hours a day, 365 days a year.

Our primary NPAC facility is designed to meet all RFP specifications and requirements, including:

•Dedicated solely to NPAC and data center functions [R12-76]

•Separate from other parts of the facility with secure access points [R12-77]

•Contiguous, housing all NPAC and data center staff members and equipment [R12-78]

•Equipped with telecommunication links available with diverse routing disaster protection [R12-80]

•Equipped with sufficient backup power (backup power generators) to maintain operation through electrical outages of at least eight hours [R12-81].

The primary NPAC will occupy approximately 12,000 square feet within the Data Center.  Additional space is available immediately adjacent to this space to support expansion, when required.  Aside from

470

its superior data center readiness, this facility is also designed to provide a comfortable and efficient working environment for NPAC staff, flexibility for staff growth, and additional requirements as they may develop.

Primary NPAC Office Furnishings

The NPAC and NPAC SMS will be configured with office equipment — desks, files, computers, copiers, and telephones — to provide a professional work environment.

User, systems, and administrative personnel are being provided modular furniture units that provide a spacious and functional work area while maintaining an appealing appearance consistent with the rest of the facility.  Furniture for the conference room and managers’ offices is of a caliber consistent with the quality of professionalism required to meet with clients.  The office design, which provides an orderly and functional work place with separate offices for managerial and professional personnel, meets all federal, state, and local building codes pertaining to work conditions.  The proposed floor plan is illustrated in Exhibit 2.12.8-1.

Primary NPAC Physical Access Security

Cardkey access readers will be provided to prevent unauthorized access to the NPAC facility.  In addition, certain areas within the facility, such as the data center area, will be safeguarded using sophisticated handprint readers.  Hand prints are scanned and compared with a file of digitized prints of personnel authorized to enter the area.  Problems normally associated with unauthorized use of lost, stolen, or duplicate keys, cards, and passwords are overcome with the handprint identification technology.  This technology allows only personnel associated with the NPAC/SMS to access the quarters.

471

All visitors to the NPAC offices will be required to sign in and sign out for entry and exit at the NPAC.  This procedure ensures records of entry and exit at both the building and the NPAC/SMS office level.  Additionally, a record of NPAC/SMS employee activity will be automatically recorded by the handprint card key identification devices.

All physical security systems record all illegal access attempts.  NPAC management personnel will review and evaluate on a regular basis both the illegal entry attempts and the overall security procedures.

Primary NPAC Office Equipment

Lockheed Martin supports more than 140 private sector and state and local government clients nationwide.  For many of these clients, we have established new offices that provide back-office administrative services as well as services that require direct interfacing with the public.  For example, we established and operate the Number Administration Service Center (NASC) for the SMS/800 and established and operate offices for collecting parking ticket fines and fees in several large U.S. cities, including Los Angeles, Washington D.C., Boston, and Philadelphia.  We also established several offices in many counties and states across the country for collecting outstanding child support payments and numerous service centers to issue toll tags and collect revenue for toll roads that utilize electronic toll collection.  Simply put, we are experts in establishing new offices for back office and customer service operations.

We have designed an effective, straightforward office layout for the NPAC/SMS that provides an orderly and productive work environment.  Management personnel will have private offices with desks and furnishings.  Other employees will have dedicated work areas in the form of modular units.  These units

472

are rugged, contain storage and drawers, have a large work surface, and provide privacy.  Each unit also accommodates a computer.

Employees within the same unit/group are located close to each other to facilitate communication and work flow.  Also, each unit/group will have access to common filing, storage, shelf, and equipment space.

Primary NPAC Local Area Network

Access to the NPAC SMS and a common set of administrative systems is cost-effectively provided using a local area network.

Each employee is equipped with a workstation (PC) or terminal and has access to a common set of data processing software for word processing, spreadsheets, order processing, billing, project management, and problem tracking.  Authorized employees are also able to access the NPAC SMS.  Rather than providing each with a PC to perform administrative tasks and a second terminal to provide access to the NPAC SMS system, we propose to establish a feature-rich local area network (LAN) at the NPAC where each staff member will have a single dedicated PC connected to the LAN.  The software environment that provides control of the LAN will incorporate two industry standards: 1) Microsoft Network over TCP/IP as the LAN operating system, and 2) Microsoft Windows 95 for the user workstation interface.  From the LAN, users will have access to word processing, spreadsheet, and project management software through communication gateways to the NPAC SMS system.

473

Highlights of our NPAC LAN include:

•Fast and powerful Pentium PC workstations

•File servers (primary and secondary) to provide high availability; if the primary fails, processing will be performed by the secondary file server

•High quality laser and inkjet printers that are evenly spread throughout the NPAC facility for convenience and maximum utilization

•Notebook PC’s with modems, for off-hour remote NPAC support

•Dedicated uninterruptable power supplies (UPS) for each critical LAN component, with main power protection coming from a large, centralized UPS system

•Share fax modem pool for sending and receiving faxes

•Searchable CD-WORM based document archive server.

The LAN approach also allows administrative functions of the NPAC such as billing and problem tracking/resolution to be seamlessly integrated into the overall operation.  Also, with a LAN, printers can be cost-effectively shared by all employees and strategically placed throughout the facility for improved productivity and usage.

Copies of all software, back-up tapes, documentation, authorized signatures, and other required operational information will be maintained at our off-site vault.  This approach ensures that all materials necessary for the establishment of a disaster recovery site will be accessible within one hour after a declaration of a disaster condition at the primary NPAC facility.

474

Chicago NPAC/SMS Backup/Disaster Recovery Site

To provide the highest possible availability, we decided to have a fully redundant, geographically separate Backup/Disaster Recovery Site.  Our proposed Backup/Disaster Recovery Site is our Chicago NPAC facility, which will be also used to support the Illinois LNP LLC NPAC/SMS. The facility is data center ready, with the appropriate environmentals — backup power generator, chillers, multiple power feeds, UPSs, raised flooring, and controlled access.

475

2.12.9   Telecommunications Requirements (RFP Sect. 12.14)

A toll-free 1-800/888 number and a feature-rich digital telephone system with individual telephone lines, direct inward dialing (DID), 24-hour hotline, voice messaging, automatic call distribution, call transferring, call waiting, and paging provides professional and efficient support of NYCAC NPAC/SMS users.

Voice Communications

A high quality telephone system with state-of-the-art features is required to assure the ability of the NYCAC NPAC to respond to user inquiries.  As shown in Exhibit 2.12.9-1, we have selected the expandable, fully featured, ISOTEC IDS™ 228 digital telephone system from EXECUTONEInformation Systems to support our NPAC operations.  This system is configured with advanced automatic call distribution and system add-on INFOSTAR™/VX2 (Voice Messaging).

Each NPAC staff member will have an individual telephone line and a telephone on his/her desk [R12-82 and R12-87].  The system provides for both direct dial access and for receiving calls from an automatic call distributor.  Using this telephone system, NPAC staff will be able to transfer calls to and receive calls from any telephone extension within the NPAC [R12-88].

The NPAC will have a listed, primary, toll-free 1-800/888 hotline number available 24 hours a day [R12-83].  The ISOTEC IDS™ 228 has direct inward dial (DID) functionality where staff members are able to answer the hotline directly at their desks [R12-88].  Also, when integrated with EXECUTONE’s INFOSTAR™/VX2, the ISOTEC IDS™228 system has an integrated voice message/mail system [R12- 84], allowing callers to leave voice messages easily [R12-89].  When a caller leaves a message, a light/lamp indicator on the telephone station is illuminated, providing a visual signal that a message has

476

been left [R12-89].  If the phone is being used when a call comes in, an audible tone is sounded to inform the telephone user that a call is waiting.  NPAC staff are able to put callers on hold when the need arises.

Around the Clock, 24-hour Support

Since the NPAC is available 24 hours a day, 7 days a week, 365 days a year, NPAC SMS system users are able to reach a “live” NPAC staff member at any time [R12-89 and R12-90].  During off-hours, 6:00 p.m. until 9:00 a.m. (Eastern Time) the next morning and on weekends and holidays, users can reach NPAC analysts through the same off-hour procedures used successfully in the 800 NASC.  When users reach the NPAC during off-hours, the telephone system will present them with the following options:

•Contact the NPAC staff member on call

•Call back during normal business hours

•Leave a message.

If the user wishes to contact an NPAC staff member, the NPAC telephone system immediately pages the primary NPAC support person on call.  If the primary support person on call does not respond to the telephone page within 15 minutes, the system automatically pages the secondary, backup NPAC support individual.  This system ensures that on-call support personnel and NPAC managers can be quickly contacted during off-hours.

While on call, NPAC support personnel are equipped with portable notebook PCs, an additional telephone line at their residence, and a cellular telephone. These devices allow the support person to access NPAC SMS via a secure dial-up connection while maintaining voice contact with the NPAC SMS user.

477

Our off-hours approach is secure, cost-effective, and guarantees access to NPAC support personnel 24 hours a day [R12-90].  By using notebook PCs, on-call NPAC staff members are able to perform all of the required functions, including receiving the latest status of the NPAC SMS during scheduled or unscheduled downtime as if they were sitting at their desk [R12-90].  This proven procedure has provided responsive service to the SMS/800 users.  It will be tailored, as appropriate, to provide the required local network portability 24x7 coverage for the NYCAC NPAC.

Call Accounting and Management Reports

The ISOTEC IDS™ 228 and its system add-ons provide several call accounting and management reports, including:

•Call Accounting Reports — System Detail, Summary, and Traffic Reports

•Call Management Reports — Events Log Reports Agent Split Summary, Split Summary, Line Group, Line Sub-group.

These reports are used by management staff and supervisors to measure overall NPAC and individual staff member performance as well as to refine operational procedures to provide NPAC SMS users the most responsive support possible.

We understand that we will be responsible for the cost and management of the NPAC telephone system and meeting or exceeding the required qualitative and quantitative performance standards [R12-92].

Data Communications [R12-85]

In addition to the data communication facilities that will be provided for service provider connectivity to both the primary NPAC in Tarrytown and the backup/disaster recovery NPAC in Chicago, as completely

478

detailed in Sections 1.6, 2.1, and 2.10, a local area network (LAN) with communication gateways will be located within the Tarrytown NPAC, allowing PCs on the LAN to connect directly to NPAC SMS server and providing access to print and fax servers [R12-86].  By using a PC Windows-based LAN, NPAC staff will be able to connect to the NPAC SMS system as well as simultaneously access our problem/trouble reporting system, LINCSS.

Should a disaster occur in the Tarrytown Primary NPAC facility, operations will be transferred to our NPAC backup/disaster recovery site in Chicago, and NPAC operations will be reestablished as rapidly as possible.  An ethernet LAN is already available at this facility for connecting to the NPAC SMS and supporting the daily operations performed by the NPAC.  We plan to exercise our NPAC disaster recovery provisions annually.

We recognize as our responsibility the acquisition and management of the data communications facilities between the primary NPAC and the NPAC SMS operating units as well as the data communications facilities between the Tarrytown primary site and the Chicago backup/disaster recovery location [R12-93].

This Page Intentionally Blank

479

HIGHLIGHTS

•A permanent, full-time Team of 32 professionals time phased for statewide expansion

•Staff dedicated to NPAC responsibilities

•Implementation Team transitions into the ongoing operation organization

•Headed by an individual experienced in system development, project management, customer service delivery, and the administration of portable number databases

•Seamless transition from statewide to regional local portability service

2.12.10  Staffing (RFP Sect. 12.15)

Our NPAC is staffed with dedicated, highly qualified, permanent, full-time personnel for smooth implementation and effective on-going operations.

Lockheed Martin has an impressive track record for quickly implementing and starting up operations for high volume, customer sensitive information processing activities.  Our proven approach, which will be applied to the NYCAC NPAC SMS, includes the use of existing Lockheed Martin resources for highly qualified, proven individuals to meet the unique demands of the NYCAC NPAC SMS implementation and ongoing operations.  These resources are supplemented with subject matter experts who: 1) have successfully implemented and supported single-application solutions, 2) have established an NPAC-like operation in a number portability environment, namely the SMS/800 NASC, and 3) have participated in the current implementation of the Illinois NPAC/SMS.

This section of our proposal describes the managerial structure, human resource approach, and key personnel we propose to assign to the implementation and operation of New York statewide and possible regional roll-out of NYCAC NPAC SMS services.  In this Section, we describe the staffing totals and individual qualifications of key management personnel, our proposed management structure and organization, our approach to training and development, and our proposed NPAC staff for key supervisory positions.

480

2.12.10.1   Management Structure and Organization

Placement of the NPAC implementation and operations organizations high in our company structure ensures senior management attention and focus.

To assure we satisfy the requirement for the NPAC organization to provide high quality, consistent, reliable, and evenhanded service, we have adopted the following management and staffing strategy:

•Lockheed Martin IMS has been designated by the Lockheed Martin Corporation as the corporate entity selected to implement and operate the NPAC SMS.  This company — Lockheed Martin IMS — has been guaranteed full support by the Corporation, including management commitment and participation, financial support, and access to the corporate-wide personnel base to staff key management and technical positions

•The NPAC organization reports to a high level within Lockheed Martin IMS, thus assuring company management attention and resources

•A Management Review Committee comprising executives from Lockheed Martin IMS and Evolving Systems, Inc. (ESI) has been established to enhance implementation of the NYCAC NPAC SMS. Key executives — Robert Castaldi, CIO of Lockheed Martin IMS, and George Hallenbeck, CEO of ESI — will provide oversight to software implementation milestones.

Management Focus

We have taken several steps to ensure the appropriate level of additional management involvement in the NPAC SMS undertaking.  We are proposing:

481

•A short organizational chain of command between the director of our NPAC organization and the Chief Operating Officer of Lockheed Martin IMS.  The NPAC Director reports to the Vice President of CIS Operations, who reports to the CIS Senior Vice President and Managing Director, who, in turn, reports directly to the Chief Operating Officer of Lockheed Martin IMS.

•An internal Management Review Committee chaired by Richard Hartung, Executive Vice President of Lockheed Martin IMS.  This committee will provide independent management oversight in reviewing the performance of the NPAC SMS implementation and operation teams.  The committee consists of executives drawn from Lockheed Martin and ESI.

•A Lockheed Martin audit performed by an internal audit group that reviews the performance of all Lockheed Martin IMS projects.  The audit group, which reports directly to the Chief Financial Officer of Lockheed Martin IMS, will audit NPAC operations on an annual basis.

Lockheed Martin Staff Resources

Lockheed Martin can and will draw upon an enormous reserve of managerial and technical skills from within the Lockheed Martin Corporation to provide highly qualified staff for the implementation and operations team.

Within its personnel universe of nearly 200,000 people, Lockheed Martin currently employs more than 5,000 information systems and customer service professionals at its many data centers across the country.  Approximately 10,000 employees are engaged in NPAC-related technical disciplines, including systems integration and software engineering.

482

We have assembled an NPAC staff that is representative of Lockheed Martin’s tremendous depth of systems and administrative expertise and talent.  The proposed NPAC Director — Audrey Herrel — is currently a key manager with Lockheed Martin IMS.  Ms. Herrel is thoroughly familiar with all facets of the number portability environment and has extensive experience in system development and customer service delivery.  Her selection ensures a smooth implementation of the NPAC/SMS.

Lockheed Martin has more than ample depth, skills, and resources to staff the NPAC organization.  We currently employ more than 1,500 professional, technical, management, and administrative employees, about two-thirds of whom support operations and perform functions directly comparable to the NPAC requirements.

Our Tarrytown Data Center, where the primary NPAC/SMS system for NYCAC will be located, has an experienced staff of more than 150 people working in the areas of user and system support, production control, system operations, technical services, telecommunications, software development, and database administration.

In addition to a source for permanent staffing, these personnel are available to assist the NPAC operation whenever out-of-the-ordinary technical issues arise.  The NPAC can obtain support in such areas as specialized system support, data communications, database administration, PC/LAN/WAN support, and user assistance.

We are proposing a permanent NPAC staff of 23 full-time employees during the first year of operation, expanding to a full complement of 32 as service providers are added and transaction volumes increase due to roll-out within New York State [R12-94].  This dedicated staff will be supported by the

483

management review committee, the implementation team, and internal and external subject matters experts.

Organizing and Staffing the NPAC/SMS

The NPAC/SMS contract will be serviced within the company’s Communications Industry Services (CIS) line of business.  Ms. Herrel will report directly to Joseph Franlin, CIS Vice President of Operations, who reports directly to Jeffrey Ganek, Lockheed Martin’s Senior VP and Managing Director of Communications Industry Services.

Exhibit 2.12.10-1 depicts the NPAC/SMS implementation organization responsible for the system design, development, engineering, integration, testing, and delivery of the NPAC/SMS application, communication network, and primary and backup data facility [R12-94].  This organizational structure is based on Lockheed Martin’s extensive experience in system development projects of this nature and is characterized by the emphasis placed on delivering the major subsystems associated with the NPAC/SMS.  These subsystems are:

•Local Number Portability application

•Primary (Tarrytown) and backup (Chicago) data centers

•Local Number Portability SMS Communications Network, and

•Number Portability Administration Center (NPAC).

These four subsystems comprise the NPAC/SMS to be delivered in compliance with the RFP’s stated requirements and schedule.  A complete preliminary project plan for NYCAC NPAC/SMS implementation is provided and discussed in Section 2.0.2.

484

The implementation organization includes the following groups:  1) Management Review Committee;  2) Quality Assurance and Control;  3) User Support Services;  4) Administration Services and Facilities; 5) NPAC SMS Product Development;  6) Networking, Engineering, and Infrastructure; and 7) Training and Documentation Services.  The responsibilities of each group are briefly defined below:

Management Review Committee.  Chaired by Mr. Hartung, this group of carefully selected senior executives from IMS and ESI will receive weekly reports as to the progress of major subsystem deliverables and adherence to customer requirements, delivery schedule, and quality principles.  Any exceptions to expected outcomes will be addressed immediately and a corrective action plan implemented.  The Management Review Committee will ensure that the appropriate sense of urgency is embraced within their respective companies and that the necessary resources are made available to address any deviation from expectations.

Quality Assurance and Control.  This group will develop standards for performance and productivity, measure performance against these standards, promote continuous process improvement, affirm customer satisfaction, and assure system (virtual and physical) and operational security, including policy and procedure.  In addition, this organization is responsible for developing system test plans in concert with the User Support Services, System and Software Support, and Network Engineering and Infrastructure Groups, and the local service providers.

User Support Services.  During implementation, the User Support Services Group will work closely with local service provider users to establish policies, processes, and procedures that facilitate the actual flow of business during operation of the NPAC.  Specifically, this includes verifying and understanding interfaces, user problem resolution and escalation procedures, industry guidelines, mass change administration logons, and customer record security.  In addition, group members will be trained on the

485

local number portability application in order to assist users and conduct the new release acceptance testing.

Administrative Services.  This organization is responsible for planning and executing the construction and furnishing of the NPAC and NPAC data center, initiating the recruiting process, and providing for new employee orientation.  In addition, group members will become experts in the local portability billing system and establish the necessary financial accounts and clerical support for the implementation team.

NPAC SMS Product Development.  Thoseassigned to this group are responsible for managing development of the NPAC/SMS application being undertaken by ESI, a leader in the development of telecommunications system software.  Assisting the manager will be Robert Castaldi, Lockheed Martin IMS CIO and his staff, and Mark Foster, a consultant with more than 20 years of systems development experience in the telecommunications industry.  Most recently, Mr Foster has assumed a prominent, proactive role in the Illinois NPAC/SMS implementation.  This group will ensure that all subsystems are developed in accordance with local service provider requirements and that they are integrated, tested, working, and available by the committed due date — May 15, 1997.

Networking, Engineering, and Infrastructure.  This organization is responsible for implementing the state-of-the-art network design required to facilitate the porting of local numbers.  They are the designers of the NPAC communications infrastructure that supports the operations organization in providing high quality, evenhanded, and responsive service.  Furthermore, this group will migrate into the operations organization by performing the functions associated with the Network Control Center and the NPAC SMS Administration and Operations Group.

486

Training and Documentation Services.  During implementation, this organization provides NPAC/SMS application user documentation, training material, and instructor and student guides.  Members of the group also produce and publish various industry documents, such as local portability guidelines and dial-up access procedures, and train the NPAC staff on the use of the local portability application and the NPAC policies and practices. In addition, the training manager assists local carriers in their transition to the NPAC SMS by training their staff.  By providing the training function, we are reinforcing our understanding of the industry’s needs and creating an additional conduit for the passage of information from the NPAC users.

Our proposed implementation organization employs Lockheed Martin personnel as well as outside experts for the specialized tasks that are not required on an ongoing basis.  Personnel with specialized expertise in the telecommunications industry, applications and systems software, database management, data and voice communications, legal and regulatory issues, and finance have been identified for support during implementation.

The hallmark of this implementation organizational structure is how well it parallels the architecture of the ongoing operational organization shown in Exhibit 2.12.10-2.  This, of course, is by design as we capitalize on our experience as an integrator of systems and manager of the subsequent operations.  It is this replication of organizational structure that allows those involved with all aspects of the implementation planning and execution to migrate to the day-to-day management and delivery of quality, evenhanded NPAC services.

NASC Operations

Exhibit 2.12.10-2 illustrates our proposed operations organization and the responsibilities and staffing (in brackets) associated with these functions.  This structure is rooted in the RFP requirements, Lockheed Martin’s extensive experience in operating the SMS/800 NASC for more than three years, and a

487

management philosophy centered on understanding and satisfying the NPAC user’s needs.  As previously highlighted, this NPAC/SMS transition team will become part of the operations staff upon delivery of the NPAC/SMS on May 15, 1997, thereby assuring the availability of experienced personnel to support NYCAC NPAC/SMS testing and subsequent live operations on October 1, 1997.  Some of the unique features of the NPAC ongoing organization are as follows:

User Support Group  Staffed with a manager and ultimately eight (8) analysts, this organization is the primary point of contact for the local service providers during the 9:00 AM (Eastern Time) to 6:00 PM (Eastern Time) hours of operation of the NPAC.  These operating hours ensure maximum responsiveness to the user community; however, we are prepared to extend these NPAC office hours should local service providers warrant a change.  Our initial proposed staff of four (4) analysts is predicated upon the following assumptions:

•incoming call volume of approximately 40 calls per business day on average

•Average analyst busy time of 4.0 minutes per call

•Average analyst wrap-up time of 3.5 minutes per call

•A performance standard of 90% of all “hotline” calls answered within 10 seconds

•7 days a week, 365 days a year on-call coverage for a 15-hour period (6:00 p.m. Eastern Time to 9:00 a.m. Eastern Time)

•Vacation, holiday, and sick time coverage

•New feature and regression testing to support one major software release per year with 800 test cases per release

•Processing of new local service provider applications

•System security maintenance of approximately four logon requests a business day

•Approximately nine NPA splits a year

•Approximately 25 report requests a month

488

•100 client services bulletins per year

•600 table maintenance transactions per month

•One disaster recovery test per year

•Subject matter expertise on all facets of the NPAC/SMS application.

These staffing estimates are drawn from our extensive experience in managing the SMS/800 NASC.  In the absence of any sizing information in the RFP beyond NPAC SMS transaction in Requirement R10-17, the foregoing assumptions provide the basis for staff changes brought about by workload deviations from the stated assumptions.  These deviations are likely, given the embryonic nature of local number portability.  The initial phases of a new service offering, the associated increased volume of both new and inexperienced users of the NPAC, and the probable migration from a New York-only to a regional NPAC/SMS service can certainly impact on the flow, nature, and volume of work.

Shifts for the initial nine-hour coverage are organized to ensure that 90% of all calls are answered within 10 seconds.  The System and Software Support Group staff will be cross-trained and have the technical proficiency to handle system, software, and user support functions.  As a result, they will be available to support user inquiries and provide coverage during peak activation times.  Periods of high volume could also occur as a result of software releases with new features, new local service providers, or NPA Splits/Mass changes.

User access to the NPAC staff during off-hours, 6:00 p.m. Eastern Time to 9:00 a.m. Eastern Time, is provided through our proposed use of pagers.  A member of the User Support staff and Systems and Software Support Services staff is on-call during off-hours.  A call placed to the NPAC hotline after hours is automatically routed to the primary on-call analyst’s pager.  The primary analyst is required to respond to this page within 15 minutes.  Should he or she be involved in another call, the NPAC’s PBX

489

automatically pages the secondary on-call analyst. On-call NPAC analysts are equipped with pagers, laptop PCs , calling cards, cellular telephones, and additional telephone lines in their homes.

System and Software Support Group.  This organization comprises the following three groups:

•Network Control Center.  Housed within the Lockheed Martin state-of-the-art Tarrytown, New York Data Center, the network control staff monitors the local portability wide area network and local service providers access links to this network.  In addition, they administer the configuration of the IP switches and monitor their performance.

•NPAC/SMS Administration and Operations.  Staffed with eight (8) personnel (three systems administrators and five system support analysts), the NPAC/SMS Administration and Operations Group is responsible for the hardware and third-party software infrastructure of the NPAC/SMS.  More specifically, the system support analysts monitor and administer the NPAC local area network, PBX/ACD, trouble and tracking system, and all PC hardware and software. They are cross-trained on the NPAC/SMS application to facilitate assisting user support personnel and to provide a frame of reference for problem resolution.  Shifts for system support analysts are organized to provide coverage during peak activation hours to facilitate resolution of activation failures.

The three system administrators are responsible for the Stratus platform, operating system, all third-party security, and database software.  Specifically, they configure and administer the servers, schedule processes, manage production control, administer report generation, monitor system performance, monitor and administer system interfaces, install third party software updates, and monitor and audit security functions.

490

•Level Two Software Support.  Initial user contact with the NPAC is accomplished over the NPAC hotline to a user support analyst.  Upon determining that the problem is of an application software nature, the analysts refer the issue to Lockheed Martin IMS’ software maintenance support group staffed by ESI, which is thoroughly familiar with all aspects of the NPAC/SMS application design and coding.  Staff at ESI analyze the problem and assess its impact upon system utility and performance.  This assessment determines the priority awarded the problem.  A priority one, for example, requires around-the-clock expenditures of resources to resolve the issue.

This proposal and, more importantly, the proposed price include this level of software support throughout the life of the contract.  In effect, the NPAC/SMS is a turnkey solution that allows the local service providers to confidently move ahead with their business.

The remaining groups within the operations organizational structure — Quality Assurance and Control, Administration Services and Facilities, and Training and Documentation Services — continue to perform in a manner established during the implementation phase of local number portability.  Their responsibilities are reflected above in Exhibit 2.12.10-2.

2.12.10.2  Staff Selection, Training and Development

The key NPAC management and supervisor positions are being staffed with individuals who possess many years of management experience.

Staffing and staff training and development of the NPAC personnel are coordinated through the Lockheed Martin IMS Human Resources organization.  The mission of Human Resources is to facilitate the company’s achievement of its business goals through maximizing the caliber and productivity of its

491

employees.  All human resource functions, including recruitment, training, employee relations, and compensation, focus on these goals.

Human Resources, in concert with management, promotes an awareness among all employees that they are individually and collectively critical to the company’s success and share in its rewards.  A sense of ownership is encouraged among employees—ownership of their own work as well as responsibility for the overall performance of the company.

Specialized human resource functions for the NPAC, such as job specification and recruitment, compensation, benefits administration, and employee relations, are provided for the NPAC through the Lockheed Martin IMS headquarters in Teaneck, New Jersey.  The NPAC training function draws upon the headquarters’ training department for additional resources and expertise.  NPAC human resource administration is a local responsibility of the Administrative Services Group.

Staffing Methodology.  The telecommunications industry requires an NPAC service that is highly reliable and competent and customer service-centered, and that handles information in a secure and protective manner.  Accordingly, we propose:

•A highly qualified staff for all key positions.  Our staff meets or exceeds the stated requirements in skills, competence, and experience.  Our staffing strategy is designed to ensure the highest levels of service. The staff will be augmented during startup and thereafter, as necessary, by specialists in industry and technical operations disciplines.

•A staff that has a proven track record within the Lockheed Martin Corporation.  All of the key management positions are being filled by Lockheed Martin IMS employees with solid, proven track records.

492

•A staff possessing more than the technical requirements for each position. Our staff embodies the qualities of customer sensitivity and friendly efficiency crucial to achieving a positive user reception to the NPAC.

•Lockheed Martin maintains an automated database with a skills inventory on current employees, as well as a candidate tracking system for prospective new hires.  These tools contribute to the expedient identification of required skills for even the most specialized positions.  When necessary, our recruiting department functions as an in-house search firm, using executive search techniques to identify and attract the best individuals for positions at all levels. In addition to technical skills, we recognize the need to screen for intangible qualities such as capacity to learn, motivation, and a customer-service orientation, all of which are keys to success.  The proposed initial staff of key personnel for the NPAC are current Lockheed Martin employees chosen because they are known to embody these characteristics.  Where the need for outside recruitment exists (due to geographic or cost considerations) and as it arises over time, candidates will be interviewed and tested to screen for these qualities.

For decades, Lockheed Martin has been entrusted with the nation’s vital secrets.  Our expertise in ensuring the security of top-secret classified information distinguishes our capability to protect the confidentiality of user-sensitive information.

Thorough investigations will be conducted to determine the background and character of any NPAC employee candidate.  We will verify employment and check references with prior employers, perform credit and criminal checks, and identify and explore any gaps in employment [R12-95].  Staff members

493

will be required to sign non-disclosure agreements to protect proprietary information for the NPAC and its customers.

Staff Motivation and Development. To retain and motivate the highest quality staff, we are providing a work environment that recognizes and awards achievement.  Lockheed Martin’s Continuous Quality Improvement philosophy stimulates high performance, first by communicating that quality is valued and recognized, and then by providing the tools necessary for success.

Not only are Lockheed Martin employees advised of their possible career paths, they are encouraged and supported in their efforts to advance within the organization.  Employees will be informed of and considered for opportunities within the NPAC, within the Tarrytown Data Center, and throughout Lockheed Martin.  Similarly, employees in other Lockheed Martin IMS operations will be considered for positions within the NPAC organization.  Professional advancement is directly tied to performance, with employees being made aware of their individual and collective achievements in relation to the performance measures established for the NPAC.

Staff and Training.  There are two components to training:  the initial training the NPAC staff requires to prepare for the initiation of services, and ongoing training required to sharpen, refine, and upgrade skills.

•Initial Staff Training.  The initial staff training effort consists of the following:

•Review of all existing procedure manuals, training material, and system documentation.  As part of our deliverables, we are responsible for developing and providing a training course that includes an instructor and student guides

494

•Attendance by all management and supervisors at the local portability application training program

•Subsequent attendance of the clerical and technical personnel at the NPAC/SMS application training program

•On-the-job training at the NPAC.  Members of the NPAC staff work under the close supervision of the training manager and user support supervision

•Introduction to continuous quality improvement.

•Ongoing Staff Training.  The ongoing staff training effort is focused on:

•Continuous quality improvement for all NPAC staff.  This training introduces widely-accepted improvement methods including problem identification and definition, processes, and tools to identify possible solutions

•Improving the skills of the personnel in the NPAC groups.  The quality assurance manager and the unit supervisors are responsible for monitoring performance against agreed-upon standards.  If it becomes apparent that an individual requires strengthening of skills, the appropriate vehicle (workshop, training program, peer or supervisory coaching) is identified and employed

•Upgrading of skills to enable individuals to enhance their career development and promote advancement

•Cross training, where feasible, within the NPAC groups.  To a certain extent, the staff is cross-trained in the tasks performed by other groups in the NPAC.  This promotes job interest and espirit-de-corps, allows for backup staffing, and provides a better overall understanding of the system.  For example, system support staff would be trained in user support functions, although the reciprocal training support might not always be appropriate.

495

Staffing Adjustments.  The staffing methodology subsection above outlines the sources of information that form the basis for our initial core staffing levels and the selection of the proposed individuals.  However, during the initial operations period we will review NPAC operations to assess the appropriateness of our staffing levels and skill sets.  We will then be in a position to make any adjustments in the proposed NPAC staffing that may be advisable. Adjustment could include the staff size or refinements to required technical skills.  The mechanisms for such reviews and procedures for any staff adjustments would be mutually agreed upon.

The criteria for making staffing level or skill mix changes relates to how well the units are meeting performance standards and customer satisfaction.  For example, the User Support Services Group might be held to a standard of resolving 92% of all telephone inquiries on a real-time basis.  If the standard is in jeopardy, potential remedies could include bringing additional skill types into the group, providing additional training, or recruiting additional personnel.

Additional factors that could affect staffing levels include:

•Growth of the local portability business with a resultant increase in the number of service providers

•Higher than anticipated portable number “churn” that would cause additional NPAC activity

•An increase in the complexity of the NPAC/SMS application software with additional features/services

•Significant increase in newly defined work that would also require an increase in management and/or administrative staff

•Expansion of the geographical area within which local portability is offered

•The introduction of local number administration responsibilities.

496

Performance standards are proposed for the overall NPAC organization, for each individual group, and for each staff member.  These NPAC performance standards, as described in Section 2.12.11, have been set at a uniformly effective level by Lockheed Martin IMS management.  Ensuring performance against these standards is the responsibility of the group managers, the NPAC director, and the quality assurance and control manager.  If performance is below standards, the unit is upgraded through additional training or supplemented with additional staff.

Proposed NPAC Staff.  We have assembled an outstanding team of professionals with the right blend of experience, technical capability, and customer service orientation to run the NPAC.

Recognizing the critical importance of a smooth and effective startup to the overall roll-out of local portability, we are augmenting our team with specialists in planning, operations, communications, and systems to ensure a successful implementation.  For added insurance, we are including during both implementation and ongoing operations a management review and oversight function and access to any additional company resources that may be required.

It is our experience that the one factor that has the highest correlation with the success of a project or a business is the quality of the management team.  Technology, size of staff, training, effective organization, and operational procedures are all important ingredients in a successful operation, but the essential component is effective management leadership that can successfully galvanize the other components.

In accordance with this management philosophy, we propose a highly competent and experienced management team that averages more than 10 years of successful and relevant experience for the NPAC

497

contract.  We are confident that the high quality of our key managers, each of whom is highlighted below, will be evident during the vendor interview process and through contact with the client references.

•NPAC Director Audrey Herrel, our proposed NPAC Director, brings to the project a unique background and experience that is especially well-suited to managing the NPAC.  Ms. Herrel, the current manager of User Support Services in the SMS/800 NASC, has more than 20 years of experience in the data processing, telecommunications, and customer service industries.  During her previous positions with CBS, Pepsico, and Prodigy, she held increasingly responsible positions in programming, system design, computer operations, and customer support.  While in the SMS/800 NASC, Ms. Herrel has been involved in all aspects of the functions described in Section 12 of the RFP.  As NPAC Director, she will have full operational responsibility for the NPAC, operating the organization as a profit center and focusing on client relations and the overall performance of the organization.  Ms. Herrel is committed full-time to management of the NPAC.

NPAC Management and Supervisors.  In addition to Ms. Herrel, the NPAC management team consists of one specialist as staff to the director and four line managers.  The staff position is the quality assurance and control manager, and the four supervising line positions are the user support services, system and software support, administrative services and facilities, and training and documentation services managers.  All employees in management team positions are exempt, key employees.  The total NPAC staff planned (23) during the first year of operation, including management personnel, is committed to the project on a full-time basis for a minimum period of one year, barring health problems or termination.  If key personnel are replaced, the replacements will have equal or better qualifications than the individuals they replace.  Our proposed management team that will support Ms. Herrel in the management of the NPAC includes:

498

•John Varley,  Quality Assurance and Control,  Manager, Quality Assurance, Lockheed Martin.  John has over 11 years of experience in establishing, implementing and enforcing quality assurance and control processes in high technology engineering environments.  John’s rigorous approach to quality management earned his division the New Jersey Malcolm Baldridge Award and an ISO 9001 certification.

•Cheryl Comitto, User Support Services Manager, has more than seven (7) years of experience as a manager in data center operations in the areas of production application and client support.  She possesses extensive experience in client and use problem resolution for missions critical applications.

•Richard Carter, NPAC/SMS Product Development Manager, has more than 13 years as a systems manager and engineer involved in design and trouble isolation and correction from the system level down to the component level in a wide array of electronic systems and devices.  Mr. Carter currently leads the development of Lockheed Martin’s NPAC SMS product.

•Louis Gammone, Network Engineering and Infrastructure, Telecommunications Manager for Lockheed Martin IMS.  Mr. Gammone is responsible for managing voice and data telecommunications engineers whose primary functions include:  designing, planning, purchasing, installing, testing and maintaining communications equipment for Lockheed Martin offices.

•Marie Kaczor, Administration Services and Facilities Manager, has more than six (6) years experience in office management and human resources and proven abilities to train, develop, and motivate a professional team dedicated to customer service and staff support.

499

•Nancy Kalanta, Training and Documentation Services Manager, has nearly seven (7) years of experience in training a wide variety of audiences, including representatives, supervisors, and managers on technical applications in a service environment.  She is thoroughly familiar with the number portability environment and service management systems.

The resumes of the management team are presented in Appendix B.

The Management Review Committee.  The Management Review Committee is responsible for reviewing the financial and operational performance of the NPAC. Members of this committee include:

•Richard Hartung, Executive Vice Presidentfor Lockheed Martin IMS, who chairs the committee, has been a member of the Lockheed Martin IMS management team since 1993 and reports to John Brophy, President of Lockheed Martin IMS.  As chairman of the Management Review Committee, Mr. Hartung ensures the presence of Senior Lockheed Martin IMS management attention to the NPAC/SMS services.

•Robert Castaldi, Chief Information Officer of Lockheed Martin IMS, has been a key member of the Lockheed Martin IMS management team since 1984 and also reports directly to John Brophy.  He has a broad base of technical, data processing, managerial, and information management systems experience, and will oversee NPAC/SMS implementation and operations from a technical standpoint.

•Jeffrey Ganek, Senior Vice President and Managing Director of Communications Industry Services, Lockheed Martin IMS.  Mr. Ganek recently joined the senior management team after devoting 20 years to the telecommunications industry.  He has held senior positions with AT&T, MCI, and GTE with experiences ranging from strategic planning, product development, marketing, and business

500

development.  Mr. Ganek will ensure that local number portability for NYCAC receives the resources and attention commensurate with the national attention it will garner.

•Duane Storms, SeniorVice President of International Marketing for Lockheed Martin IMS, has been a member of the Lockheed Martin IMS Management team since 1980, reporting directly to John Brophy. He will review and monitor operational issues pertinent to the NPAC/SMS.

•George Hallenbeck, CEO and Chairman of the Board of Evolving Systems, Inc., has more than 26 years of experience in the computer industry.  He has founded or co-founded several companies and is recognized in Colorado, where EBT is based,  as a prominent business leader with a long history of entrepreneurial success.  Mr. Hallenbeck will ensure that his company’s development of the local number portability application is an unqualified success.

NPAC/SMS Implementation Organization

Lockheed Martin has had extensive experience in the rapid, yet controlled, implementation of new applications and operations and transition from existing operations.  Typically, upon being awarded a contract for a new client, it is necessary to set up a new area office and be in operation within 90-120 days.  These operations often include procurement of space, equipment, personnel, training, user requirements analysis, communication equipment and lines, data conversion, testing, and system modifications.

In all such cases, we have deployed and staffed a start-up team with a unique set of skills, experience, and capabilities that ensured the smooth establishment of services.  The Implementation Team for the NPAC/SMS, headed by Ms. Herrel, consists of the key members of the NPAC management team, plus

501

specialists in a number of disciplines required for smooth implementation and cut-over.  These specialists include:

•Contract Administration.  Headed by Richard Ludwig, Vice President of Contracts for Lockheed Martin IMS and primarily responsibility for the legal aspects of Lockheed Martin IMS’ contract transactions, this group is responsible for contract negotiations.

•Communications Configuration.  John P. Posephney, Vice President, Integrated Services, is responsible for the acquisition and implementation of communications services and equipment for the NPAC, including the data communications network and interfaces to the NPAC/SMS computer system, voice communications equipment, and our internal LAN environment.

•NPAC SMS Product Development and Data Center Establishment. Robert Castaldi, CIO with extensive software development experience and responsibility for Lockheed Martin’s Data Center in Tarrytown, New York, is responsible for assuring that his organization supports the development of the NPAC/SMS application to the extent that his staff is involved in the configuration of requirements, functionality, and software specifications.  As a member of the Management Review Committee, Mr. Castaldi will be involved in design reviews and all major milestones during the product life cycle — especially the preparation and execution of test plans.  As the Lockheed Martin executive responsible for the Data Center, he will provide oversight guidance and direction in the location and establishment of both NYCAC NPAC facilities.

•Consultants. Mark Foster has contributed significantly to the advancement of local number portability throughout the United States and particularly in the Illinois LNP implementation.  He will continue his role as design consultant to Lockheed Martin and will play an important role during the implementation of the NPAC/SMS.  Similarly, Lisa Marie Maxson has assisted in the development

502

of the NPAC/SMS for Illinois.  She was the initial architect of the NPAC SMS Interoperable Interface Specification (IIS), and has been retained by Lockheed Martin to oversee and review NPAC SMS design requirements and NPAC SMS design, development, and testing.  Finally, John Shea has attended and will continue to attend meetings in states throughout the country, keeping Lockheed Martin and abreast of the latest industry developments.  His input has been invaluable in shaping NPAC SMS functionality and features.

The NPAC/SMS staffing during the implementation period before cut-over to NPAC operations will consist of the full-time NPAC team, growing to its full complement over time, plus the specialists noted above. Exhibit 2.12.10-3 illustrates the forecasted staffing levels in the categories described above, using a January 2, 1997 Letter of Intent for planning purposes.

2.12.11  Service Objectives (RFP Sect. 12.16)

Lockheed Martin’s experience and track record demonstrates that we consistently meet and often exceed established performance standards for the 800 NASC. We will apply this experience to assure total customer satisfaction of the NYCAC NPAC/SMS operational environment.

As the current 800 NASC contractor, we are familiar with the service objectives for NPAC-like services.  The directly applicable experience we have gained through our support of this program ensures that we will establish the proper and appropriate service levels and customer oriented performance standards required for the NYCAC NPAC and NPAC SMS.

One of the primary service objectives is 7x24 availability of NPAC staff to answer user questions or resolve problems.  As discussed in Section 2.12.9, our staff will be available 24 hours a day, 7 days a week, 365 days a year, and will be qualified to quickly respond to user needs [R12-96].

503

Additionally, every major facet of NPAC operations will be measured against service level standards.  By comparing NPAC services against predetermined standards and refining both operations and the performance standards over time, service to the user will continuously improve.  In this section, we discuss our quality assurance approach and use of performance standards to ensure that consistent, reliable, and timely services are provided.

504

2.12.11.1    NPAC Availability (RFP Sect. 12.16 and Page 92)

The complete array of NPAC services will be available around-the-clock to meet user needs.

We propose to provide customer assistance 24 hours a day, 7 days a week, 365 days a year.  Our service representatives will be available to assist clients from the NPAC site, Monday through Friday, from 9:00 a.m. to 6:00 p.m. Eastern Time.  During normal business hours, we are committed to respond to 90% of user calls within 10 seconds. Service representatives will continue to provide quality service and assistance to users during off-hours as well (6:00 p.m. - 9:00 a.m. Eastern Time the next morning on weekdays and on weekends and holidays).  Our off-hours hotline service is via voice messaging.  A system feature associated with our PBX enables service representatives to be paged, thereby initiating an immediate customer/user callback.  Data communication facilities are provided and properly maintained to ensure high levels of customer service at all hours throughout the week.  For off-hour user service requests, the NPAC service representative will call back the user within 30 minutes of notification, 99% of the time.

2.12.11.2    Quality of Service & Performance Standards (RFP Sect. 12.16 and Page 93)

We are committed to provide high quality NPAC SMS user support with consistent, reliable, and responsive service.

As NPAC contractor, we will be responsible for the delivery of consistent, reliable, and timely responses to meet NPAC users’ needs.  The quality of our service can be defined in terms of ongoing system performance, response time, and availability — all of which are measurable.  Our efforts in this area are twofold:

505

•Quality assurance and self-monitoring (continuing education and awareness training for all NPAC members)

•Quality control (monitoring of actual performance against established standards).

While performance standards can be established to measure efficiency, timeliness, reliability, accuracy, and accessibility, there is no substitute for customer satisfaction — is the most important measure in any service operation.  Our quality assurance plan and quality assessment processes are developed through focused and timely customer surveys.  Telephone surveys and/or written questionnaires are directed toward NPAC users who have generated a request or who have received reports, documentation, or training.  Thus, our customer surveys reflect current operations.

Quality Assurance and Self-Monitoring

To assure quality service, we employ a seven-step, self-monitoring process and refine our operations based on quantitative results.

To implement comprehensive quality assurance procedures, data is collected from our management team and aggregated on a daily, weekly, and monthly basis.  Reports are prepared to compare performance to previously established standards and variances or incidents of substandard performance are identified and corrective action begun.

Our daily seven-step quality assurance and self-monitoring procedures for the NPAC includes:

•Daily Activity Reports submitted by the staff to unit managers by the close of each scheduled shift

•Aggregated reports comparing a unit’s performance to established standards, prepared by the unit manager by 10:00 a.m. on the next business day

506

•Daily quality assurance reports and recommended corrective action plans, prepared by the quality assurance and control manager by 10:00 a.m. on the following business day

•Daily managerial meetings on planned corrective actions, convened by the NPAC director and management team members by 10:30 a.m. every business day

•Recap meetings held by unit managers and staff members at the start of each shift to review corrective actions planned and priority assignments that day

•Random, periodic monitoring of NPAC staff members’ job skills in the work environment and telephone interactions with NPAC users conducted throughout the day

•A weekly performance report in a mutually agreed-upon format submitted to NYCAC.

We will submit performance reports monthly to assure that NYCAC is kept abreast of the current service levels.  Exhibit 2.12.11-1 is a list of potential performance standards and the Lockheed Martin Team’s proposed service commitment for each.  We will assure that summary reports comparing actual performance to established standards are made available to NYCAC at least five days before all scheduled reviews.

NYCAC Performance Evaluation

We will encourage regular performance reviews by NYCAC.  Drawing on our experience in providing services comparable to the NPAC, we are proposing that the Committee use a monitoring and evaluation procedure that consists of:

507

Weekly performance review meetings during the implementation period of the NPAC and NPAC SMS operations.  This will ensure that NYCAC reviews the progress of the start-up, including any outstanding tasks and performance-related issues.

•Weekly reviews of performance against established NPAC and NPAC SMS performance standards, evaluating quantitative measures of actual performance of each business unit function.  We prepare reports highlighting performance and take corrective action statements as required.  These reviews provide the NYCAC with a timely and precise status on service levels achieved.

•Less frequent meetings after a six-month period.  Because most start-up operational issues will have been addressed by the time the NPAC and NPAC SMS are on-line for six months, the frequency of meetings may be reduced.  It is our experience that monthly meetings are adequate after the implementation period.

We are aware that the frequency of performance reviews will be determined by NYCAC and that they may take place several times a year.  We are prepared to meet the established performance review schedule.

Notification of Substandard Performance

We propose that substandard performance evaluations be communicated in writing within 15 days of the end of the monitoring period and that we provide a corrective action plan within 5 business days.  We consider this expedited response to be feasible since weekly reports to the NYCAC will have previously identified any potential for substandard service and approved corrective actions will have already been initiated.

508

Corrective action plans must meet the approval of NYCAC.  We propose implementing improvement steps within 15 days of NYCAC approval in those situations where steps previously approved have not already been initiated.

Proposed NPAC and NPAC SMS Service Commitments

Quality Assurance and Control Manager

Our approach to quality assurance/quality control is being emphasized by the addition of a Quality Assurance and Control function in our NPAC and NPAC SMS management team.  This position, independent of the other organizational units, is a key part of our NPAC management and has as its primary function responsibility for helping the NPAC director achieve continuous process improvement.

Quality Control Program

Internal self-monitoring and external monitoring assure that we improve our operations by incorporating feedback from many different groups and points of view.  Our quality control program consists of both internal self-monitoring and external monitoring activities.  These efforts begin with promoting and fostering quality as a goal and continue with measuring actual performance against standards.

Internal Self-Monitoring

We will continuously monitor our internal operations through daily management inspection and weekly reviews of the Key Service Indicator Report.

509

Management Monitoring

Our NPAC management team will closely monitor staff activities on a daily basis, including observing employee job skills in the work environment and monitoring telephone interaction with NPAC users.  It is the responsibility of all managers to measure each employee’s fulfillment of the established job performance standards and to utilize this information constructively in the staff review process.  We propose that our management personnel take the initiative to begin quality improvement activities and involve the Quality Assurance and Control and the Training and Documentation Services groups as necessary.  If job performance requires improvement in any of the performance areas, additional on-the-job training will be administered through our in-house training function.  Professional developmental training will also be provided to reinforce the importance of service quality.

Key Service Indicator Report

Each week, the quality assurance and control manager will receive a written report of each unit’s performance during the previous week.  This report, together with the quality assurance and control manager’s comments and recommendations, will be the basis of a discussion with the NPAC director.  It is the responsibility of the quality assurance and control manager to assist the unit managers in establishing meaningful and appropriate criteria against which to measure performance for each of the NPAC units.

External Monitoring

Our NPAC operations will undergo scrutiny from several external organizations, including the Management Review Committee.  Their suggestions for changes, combined with annual audits and user surveys, will assure that we refine our operations to meet both NYCAC and NPAC SMS user needs.  Descriptions of each of these external monitoring groups and activities are presented below.

510

Management Review Committee — We will support NPAC and NPAC SMS operations by placing key corporate management personnel on a Management Review Committee.  This group will review on a quarterly basis the business operation, level of customer satisfaction, and performance of the business unit

Lockheed Martin Audit —As a corporate policy, Lockheed Martin conducts internal audits of its operating units on a routine basis. Audits will subsequently be reviewed by the NPAC management team and corrective action implemented, where required. Both the Quality Assurance and Control Manager and Management Review Committee will subsequently track and review audit findings.

Annual User Surveys —Recognizing that the customer’s perception of the quality of NPAC/SMS service is the ultimate measure of the organization’s effectiveness, annual surveys of both internal (applications developers, network managers, contracting party, etc.) and external (NPAC/SMS users) customers will be undertaken and analyzed, and appropriate corrective action will be implemented.

Performance Standards

Use of performance standards will allow us to quantitatively measure business unit service levels for improving customer satisfaction.  We recognize that the successful operation of the NPAC and the NPAC SMS requires a high level of quality performance.  To satisfy this goal, we propose an approach that requires each employee to be aware of, committed to, and actively involved in the total quality improvement process.  Each Lockheed Martin Team employee will be held personally responsible and accountable (when measured against customer satisfaction) for the quality of his or her work.  To achieve this goal, we will ensure that, in addition to making a personal commitment to the quality process, our management will commit sufficient resources and training to their organizations.

511

The pursuit of quality is a continuous effort with measurable objectives.  The Lockheed Martin Team will operate the NPAC/SMS according to the following principles of quality:

•Quality, defined as conformance to established performance standards, is a direct measure of customer satisfaction

•The method for creating quality includes identifying customer needs and evaluating processes to ensure that each step adds value for the customer

•The standard of performance must target “zero defects” as measured against specific requirements.

We consider customer satisfaction to be the result of meeting or exceeding customer expectations for quality, timeliness, and cost.

Every member of our staff will have a responsibility to deliver the highest level of quality service possible to ensure customer satisfaction, reliability, and responsiveness in the most cost-effective manner.  Our management will be responsible for providing the resources and environment to achieve this end.  In our current operation of the 800 NASC, we have implemented the concept of Quality Improvement Teams.  These teams, comprising analysts from each functional organization and facilitated by either the quality assurance and control manager or the functional unit manager, have addressed and resolved such operational issues as:

•Improving the billing process

•Providing out-of-hours service

•Re-engineering the responsible organization change process

•Eliminating potentially redundant or conflicting procedures

•Flowing and improving the new resp org process

512

•Evaluating the hardware and software tools available to analysts

•Improving the trouble tracking system — LINCSS.

Our quality process includes retaining competent and experienced human resources, providing ongoing education, delivering service at or above expected standards of performance, and regularly measuring service against performance standards.

To establish and monitor the quality of the NPAC/SMS service being proposed, performance standards — integral parts of Lockheed Martin’s quality assurance and control program — will be applied to the full range of NPAC/SMS activities.  The performance standards will address service consistency, reliability, and response time for each NPAC and NPAC SMS task specified by the RFP [R12-97, R12-98, and R12-99].   As previously mentioned, proposed Lockheed Martin NPAC/SMS service commitments that address service consistency, reliability, and response time are presented above in Exhibit 2.12.11-1.  The specified standards will reflect our understanding of the high service level required for local number portability and our commitment to increasing service response to the user.  The standards are based on our extensive experience with similar tasks required by our administration of the 800 NASC.

Administration of the NPAC/SMS Performance Standards

We established an extensive list of aggressive performance standards that we are committed to meeting or exceeding. To qualitatively measure our service delivery:

•We will conduct telephone and written customer satisfaction surveys

•Daily progress reports will be prepared and, upon request, weekly reports provided to NYCAC

•Corrective action plans or response to substandard evaluations will be submitted within one week of acknowledgment.

513

We are also committed to meeting/exceeding the reporting and corrective action time frames specified in the RFP.

Example NPAC Operational Performance Standards

We have defined service performance threshold levels from which performance measures will be evaluated.  These levels are based on our experience in servicing the telecommunications industry via the 800 NASC.

We recognize that the NPAC/SMS will continually strive to optimize performance and maximize customer satisfaction and will support this objective.  The threshold levels selected provide for minimum levels of service and allow for process improvement consistent with our embraced principles of quality assurance and control.  Selected examples of enhanced service include:

•Processing 99.0% of approved logon ID requests within 12 business hours.  This is an annual measurement.

•Expanding and providing more definitive categories for customer notification of scheduled NPAC SMS system unavailability.

•Answering a minimum of 90.0% of offered calls within 10 seconds.

•Satisfying a minimum of 99.5% of customer commitments.  This is an annual measurement.

•Responding to off-hours requests within 30 minutes, 99.0% of the time.

514

•Precluding answer service degradation by limiting a customer abandoned call rate to a maximum of 2.0% in a service month.  This measure reinforces the requirement to provide service in a consistent manner.

•Notifying the user community a minimum of two weeks in advance should a delay be encountered in the general availability of a planned NPAC SMS software release.  This measure will enable service providers adequate time to adjust their force and coverage assignments.

•Notifying the user community at least two weeks in advance of the general availability or a software release.  The measure will provide adequate time for adjusting for workload and force assignments.

•Conducting weekly circuit continuity tests to the NPAC/SMS and backup/disaster recover site proposed by the Lockheed Martin Team.

•Annually maintaining system and interface availability at a minimum of 99.9%.

515

NYCAC NPAC/SMS PROPOSAL 2.13  Future Considerations

HIGHLIGHTS

•The Lockheed Martin NPAC/SMS architecture is a permanent NPAC/SMS solution that offers unlimited growth in capacity due to both functional and geographic jurisdictional factors with only incremental growth costs

•Modular NPAC/SMS software, hardware, and network architecture enables the development of future capabilities while retaining existing investment in NPAC functionality thereby reducing future costs

•Distributed, object-oriented, software architecture with highly modular implementation (C++, reusable objects, etc.) streamlines cost of developing future enhancements while leveraging maturity and stability of existing functionality

•Use of database-resident, rules-based, definitions of transaction processing steps enables the enhancement of existing process flows and addition of new flows with reduced effort and cost

•The Lockheed Martin team is committed to supporting ongoing definition and evolution of LNP capabilities, at the state and national levels, to ensure NPAC/SMS support of future LNP enhancements

2.13FUTURE CONSIDERATIONS (RFP Sect. 13)

Recognizing the inherent uncertainties in predicting future NPAC capacity and functional requirements, a substantial amount of flexibility, expandability, and extensibility is essential to provide continuous NPAC/SMS services.  One of our primary design goals for the NPAC/SMS is to design-in these attributes at every major level of the NPAC system, thereby meeting all future requirements with reduced cost and disruption.

To accommodate both planned and unplanned increases in system growth brought on by functional and/or geographic jurisdiction expansion, it is essential that the NPAC/SMS be extremely scalable.  The Lockheed Martin NPAC/SMS provides for processing capacity expansion in three dimensions:

•NPAC SMS server expansion.  The Stratus Continuum I fault tolerant system may be smoothly scaled up to two logical RISC SMP CPUs, 2GB of duplex RAM, 178 GB of duplex disk, and 84 I/O adapters, allowing up to 1,344 direct connect communications lines.  Further, upgrading the NPAC SMS may be performed on-line while the system is live, thus ensuring no disruption to operations

516

due to unanticipated system upgrades.  Exhibit 2.13-1 illustrates the expandability of a single Stratus Continuum system.

Exhibit 2.13-2 illustrates the performance increases of new planned processor technologies being developed by HP (PA-RISC) and HP/Intel (Merced).  Availability of new processor technologies from the two strongest technology companies with continuing performance enhancements and binary software compatibility ensure longevity NPAC/SMS facilities and continued scalability through the future of LNP deployment.

Exhibit 2.13-3 illustrates the future evolution of the Stratus Continuum I Family incorporating future HP RA-RISC processor enhancements (PA8000 to PA8xxxx), and increase SMP and memory capabilities.

[Graphic Omitted:  Graphic depicting server expansion]

Exhibit 2.13-1.  NPAC SMS server expansion

Exhibit 2.13-2.  Explosive Growth in future processor technology guarantees server scalability

[Graphic Omitted:  Chart depicting future HP processor availability]

Exhibit 2.13-4 illustrates the future Stratus Continuum II family, which will be based on the up-coming Merced processor technology being jointly developed by HP and Intel.  These system represent significant performance growth (more than 100x) over currently available technologies.  Enhancements include: higher levels of SMP (more logical CPUs), memory, and native PCI I/O bus technology.  They are also planned to feature 3DA, the future unified Unix operating system being jointly developed by HP and SCO, representing the integration of USL SVR4 Unix, HP/UX, and SCO UNIX.

[Graphic Omitted:  Stratus product roadmap]

517

Exhibit 2.13-3.  Ongoing growth in the Stratus Continuum I Series incorporating future HP Processor technology (PA8xxx)

Exhibit 2.13-5 illustrates the performance growth curve for Stratus systems based on the HP (PA-RISC) and HP/Intel (Merced) technologies.  This growth curve does not include performance enhancements due to additional distribution or clustering technologies (such as load sharing, parallel database servers, and shared-efficient message queuing) that will increase the effective performance of multi-system configurations.

[Graphic Omitted:  Stratus Continuum II product roadmap]

Exhibit 2.13-4.  New Continuum II Series based on HP/Intel Merced Processor provides over 100x 1996 performance

•NPAC SMS software distribution.  The NPAC SMS software processes are configured to operate in a distributed fashion across multiple servers, as illustrated in Exhibit 2.13-6.  The system configuration dictated by the capacity requirements in RFP Section 10.2, Capacity and Performance, calls for five (5) Stratus Continuum Model 428H systems operating cooperatively in a distributed fashion.  There are several functional boundaries across which software distribution may be performed — front-end communications processing, database storage, rules-based process execution out to one or more additional servers — depending upon the nature of the NPAC/SMS system growth and the need for increased system bandwidth.  This advanced architecture enables unprecedented flexibility and cost savings in future system growth, while retaining complete use and re-deployment of existing software and hardware.

518

[Graphic Omitted:  Chart depicting performance roadmap for HP]

Exhibit 2.13-5.  Performance roadmap for future HP and HP/Intel-based systems

[Graphic Omitted:  Chart depicting server scalability]

Exhibit 2.13-6.  NPAC SMS scalability through software distribution

•NPAC network expansion.  The NPAC network design is capable of significant functional, load, and geographic expansion while incrementally building on the existing infrastructure.  Use of cell-based fast hub (ATM-supportable) switching technologies ensures no upper limit on NPAC network capabilities and LAN/WAN technologies to support — in a highly cost effective yet fully available manner — expansion in POPs, data centers, NPAC personnel, service providers, and NPAC SMS servers.  Exhibit 2.13-7 illustrates the potential to expand NPAC/SMS services through the addition of NPAC/SMS service centers networked to accommodate the future increased capacity (e.g., location portability and number pooling) and functional requirements (trans-regional data interchange).

To accommodate future changes in NPAC SMS functionality with minimal/no re-engineering impact to existing functionality, it is necessary to build flexibility into the software design and implementation.  We are achieving this flexibility goal by employing the following strategy:

[Graphic Omitted:  SMS network map]

Exhibit 2.13-7.  NPAC SMS scalability through NPAC network expansion

•CMIP mechanized interface processing using automated CMIP agent interface development tools, e.g., DSET GDMO compiler and agent toolkit.  Changes in the mechanized interface information

519

model can be accommodated by re-compiling the revised GDMO information model definition of the interfaces, and revising the process flows rules set accordingly.

•Object-oriented design methodologies and language (C++).

•Use of ESI’s BACE product for flexible rules-based process implementation.  SMS process flows are executed by rules-based processing engines, where process steps may be readily changed or re-sequenced by modifying database-resident rules.  Lower-level processing steps are coded in C++ in the form of operations against object instances.

•Distributed protocol stack processing for SMP-scalability.  The Stratus UX operating system supports a Redundant Network Interface (RNI) feature that enables multiple LAN (fast-ethernet) ports to operate as a single logical entity at the IP level of the protocol stack.  Further, the Unix streams-based implementation of the IP stack supports high levels of parallelism (and therefore scalability) in addition to that achieved by RNI.  Also, the upper layers of the OSI stack (for ROSE, ACSE, and CMISE layers) are implemented within DSET’s Distributed Systems Generator (DSG) product that employs a multi-task, multi-process, execution model for further parallelism.

•Web-browser oriented generic GUI with Java provides a standard, secure, robust, and highly extensible GUI environment for all user support across arbitrary access and network methods and a wide variety of client workstation environments.  Screens and menus are ‘published’ using HTML editors and stored independently of any software.  Object embedding technology enables ease of extensibility with minimal impact to existing software.

520

•Use of Oracle for the RDBMS engine provides a highly extensible and robust DBMS environment with proven advanced replication and distribution capabilities.  It also helps to ensure scalability of back-end database server functions.  If future functionality and capacity needs should dictate, the database could be transparently distributed across more than one server using the Oracle Distributed Processing module.  Also, the Oracle Parallel Query module can be used to optimize queries, reports, audits, etc., in a distributed database implementation.  Consequently, even the back-end RDBMS engine provides cost effective functionality for initial requirements while enabling incremental enhancement to support future requirements without application software impacts.

We are committed to supporting NYCAC member carriers and the industry by contributing technical leadership of LNP administration.  We are also committed to enhancing the NPAC/SMS in a timely, cost efficient, and non-disruptive basis.  The discussion below highlights our familiarity with the potential future requirements and LNP in general, and discusses how the NPAC/SMS design considerations discussed above ameliorate the resulting impacts.

2.13.1   Expansion of Service Providers

Expansion of number of service providers is readily supported by NPAC/SMS with only incremental capacity and network communications upgrades required.

The NPAC/SMS readily expands to support more than 50 service providers, exceeding the requirements established by R10-15 and R10-17.  Additional service providers are supported via supplementary NPAC network WAN and dial-up ports as required to terminate the additional mechanized interface links.  The incremental load offered by the supplementary service providers might result in incremental upgrades to the NPAC SMS server in the form of additional CPUs or memory.  NPAC WAN port and SMS server expansion can be performed on-line without any disruption to ongoing operations.  Service provider-specific

521

database tables proportionally contribute a negligible amount to the total database storage requirements; consequently, additional database (disk) capacity will be driven by the number of subscription versions and archive data (history, audit, resource accounting, etc.).

2.13.2   Expansion to Other States (Regionalization)

Expansion of NPAC/SMS to other states is readily supported via capacity and service provider interface expansion, as well as functional extensibility (for regulatory state-specific process flow variations) and load firewalling.

In addition to an increase in the number of service providers (as discussed in 2.13.1 above), expanding NPAC operations to other states will require that overall NPAC capacity be increased to support the aggregate load resulting from increased transactions and database size.  Capacity expansion is addressed in the introduction to Section 2.13 in three areas: NPAC SMS server expansion, NPAC SMS software distribution, and NPAC network expansion.

It is clear from recent events that the industry is leaning heavily towards regionalization of NPAC services out-of-the-gate, especially in light of the recent FCC order.  The Lockheed Martin Team is committed to regionalized NPAC services.  Our proposed NPAC SMS Release 2 that we plan to deploy for NYCAC contains many features needed to support full regionalization.  Thus, our NPAC/SMS service can readily expand to other states outside New York without modification to the NPAC SMS software.

Additionally, we are proposing a NPAC SMS system and NPAC operations that are fully expandable and scaleable (additional NPAC office space, staff, Stratus server hardware, communications infrastructure,

522

etc.) to handle higher transaction volumes and additional service providers if NYCAC expands to other jurisdictions (states) outside New York.

2.13.3   Geographic Number Portability

Functional and capacity expansion capabilities enable the NPAC SMS to expand to gracefully support other forms of LNP, such as location portability and service portability, without re-implementing existing functionality.

The NPAC SMS design will support multiple forms for number portability beyond the initial rate center-coincident service provider number portability (SPNP) specified for the initial release.  Initial NPAC SMS functionality and IIS support both SPNP and location portability (intra-provider portability), which is presumed to be intra-rate center location portability.  Within the definition of SPNP functionality for the NPAC SMS is full life-cycle support for ported numbers, including: initial port, additional ports, port back to original switch, and disconnect.  Additional types or variations of LNP that can be supported in the future include:

•Non-coincident rate center SPNP.  When competing LSPs are no longer required to use rate centers coincident with each other or historical rating boundaries, additional parameters may be required in the NPAC SMS database to allow service providers to support switch or SCP-based call recording of these additional parameters.  While the New York SMS subcommittee requirements clearly anticipate these additional fields, the exact format and treatment of these parameters is not required until implementation of this functionality in the network is specified.  The eventual participation in LNP of service providers using non-wireline network technologies, such as wireless and cable-telco for example, will increase the need to revisit existing rate center concepts.

523

•Inter-rate center, intra-LATA, location portability.  Similar to the above without changing service providers.

•Inter-LATA, intra-NPAC administrator, location portability.  Location portability outside of the LATA but within the jurisdiction of a common NPAC administrator might require only minor additional call recording parameters to be provided, if any, from the general case of rate-center portability within the LATA.

•Inter-NPAC location portability.  Location portability, with or without an accompanying change in service provider where the new serving location is administered under the jurisdiction of another NPAC SMS or NPAC administrator, requires inter-NPAC coordination.  We anticipate that an additional CMIP-based mechanized interface to support NPAC-to-NPAC operations will be developed and standardized.  The choice of CMIP for mechanized interface technology will enable upward expandability within the framework of the initial NPAC/SMS deployed.  Given the criticality of building on appropriate technologies for both the short- and long-term, one member of the Lockheed Martin Team was the first to propose — at INC 14 in March 1995 — that CMIP-based TMN signaling technology be standardized for use in mechanized interfaces for LNP administration, both between service providers and their NPAC as well as between NPACs serving different jurisdictions.(2)  The new NPAC-to-NPAC interface will be modeled primarily on the SOA-to-NPAC SMS interface with extensions.  The addition of inter-NPAC functionality between two NPACs does not necessarily impact their service providers, since the inter-NPAC operations are transparent to the involved service providers.

(2) INC contribution PORT-59 by Stratus Computer, Inc.

524

•Service portability.  From an NPAC perspective, the various forms of service portability as they affect serving switch location and rate-center boundaries, is dealt with in one of the above types of location portability.  Albeit, the processing for a change in serving switch location, where the customer’s service location is the same, does not necessarily imply the same impacts, e.g., rating, that result from the customer physically changing geographic locations.

•Wireline-wireless and wireless-wireless SPNP.  Wireless service providers of all types, including those affiliated with currently participating wireline service providers, have a keen interest in participating in LNP.  Their network and switch technology, billing and rating, regulatory governance, and nature of services offered, e.g., terminal and subscriber mobility, adds significant complexity to implementing LNP.  The ultimate solution to implementing LNP with and between wireless service providers is likely to require enhancements to the mechanized interface information model and database, which can be readily supported.

Many of the above forms of portability have implications for service provider billing and settlement systems requiring enhancements to support the rating, billing, and inter-company settlement flows resulting from de-coupling the customer’s TN from its historical rate center and RAO.  The NPAC may be called upon to provide database information to service providers and other involved parties to enable their billing and settlement systems to properly bill and rate calls and route billing messages.

Our NPAC/SMS is designed to support the functional and capacity enhancements associated with these additional types of portability through the mechanisms discussed in this section.

525

2.13.4   Overlays of NPA-NXXs

Overlays can be supported in the NPAC SMS through addition of one or two database fields and corresponding attributes in the mechanized interface information model.

Overlays can readily be supported by the NPAC SMS through a minor enhancement to provide the overlay information, if any, associated with a subscription to the NPAC SMS via the SOA interface.  This information would also be included in the routing update broadcast to the LSMS interfaces, so that SCPs could create the appropriate additional routing records required, if any.  Impacts due to newly created overlays affecting existing subscriptions would be processed as a mass change.

2.13.5   Expansion for Use by Wireless Service Providers

Expansion to wireless service providers and the additional database fields potentially required can be accommodated by the NPAC/SMS.

As previously discussed in Section 2.13.3, wireless service provider participation may require additional database fields and associated mechanized interface attributes, especially to support wireless-to-wireless SPNP.  These can be supported as minor functional enhancements in addition to any required incremental capacity upgrades.  Additional routing attributes that may be required for wireless service providers include:  DPC and SSN for IS-41 messaging and a non-dialable 10-15 digit MSCID.  With the planned participation in LNP by wireless providers, any additional attributes, that may need to be supported within the NPAC SMS can readily be added through a minor enhancement to the IIS and database schema tables.

526

2.13.6   Expansion to Include Data Related to Resellers

The NPAC/SMS can be expanded to support both resale and direct resellers as a new class of directly or indirectly connected service providers, where appropriate.

We recognize the importance of resale in enabling new LSPs to offer ubiquitous service coverage without massively over-building their network infrastructure, as well as to support resellers of their network services.  NYCAC has anticipated this need by including a billing ID field as a part of the data needed for subscriptions (RFP Table 3-1, Subscription Data).  In addition, the service provider data tables and initial processing logic developed by the Lockheed Martin Team further anticipate requirements for identifying resellers and independently tracking the facilities-based service provider from the billing service provider (non-facilities based service provider, i.e., reseller).  However, the rules and process flows for authorizing get/modify/create/delete privileges for both-facilities and non-facilities-based service providers will need to be developed and agreed to by the service providers to specify the required functionality to include resellers.  Once the major processing flows and rules are determined, minor enhancements to the SOA interface can be made that would distinguish transactions where the SOA is the facilities or non-facilities-based service provider and to support the appropriate semantics for operations and notifications across both types of service providers.  This would enable authorized resellers to directly interface to the NPAC, as well as enabling facilities-based service providers to provide indirect access to the NPAC on their reseller’s behalf.

2.13.7   Pooled NXXs

The Lockheed Martin Team and our NPAC/SMS are uniquely positioned to support number pooling, which will require a significant increase in NPAC functionality and the capacity to provide pooled number administration.

527

Although the topic of pooled NXXs or “Number Pooling” is not specifically identified as an potential future consideration in the NYCAC NPAC/SMS RFP, is has been identified as such in other states’ activities and NPAC/SMS RFPs, as well as being of great interest to the FCC.  Thus, we thought it appropriate to discuss it as a possible future consideration for the NYCAC NPAC/SMS.  Number pooling aids number resource conservation by potentially improving fill rates of portable NXXs through shared use and allocation of numbers among all service providers in an area.  Number pooling requires the same call processing functionality as inter-rate center location portability, since number pooling within a rate center does not provide for additional number resource (borrowed from across the service area) within high demand areas.

Number pooling requires significant functional and capacity enhancements to the NPAC/SMS, which can be accommodated within the Lockheed Martin Team’s NPAC/SMS architecture through incremental NPAC SMS upgrades, enhanced mechanized interface specifications (to support number administration operations), and supporting software enhancements.  The NPAC SMS database size will increase significantly since subscription records will be created for newly allocated numbers out of pooled NXXs for new non-LNP related service requests.  Subscription storage for actual ported numbers also will increase database size.

Transaction loads will likely increase even more so than the database size, due primarily, to the added volumes of transactions required to perform the lifecycle state transitions of pooled numbers, e.g., vacant number search, allocation, assignment, activation, and disconnect.  Operationally, NPAC will be involved in administration of the 10-digit numbers in the designated portable NXXs that are to be pooled.  Consequently, the capacity growth, functional extensibility, and direct operating experience in number administration offered by the Lockheed Martin NPAC/SMS solution is of unique value in safeguarding

528

the initial investment in the NPAC and ensuring a smooth, reduced cost transition to new LNP capabilities, such as number pooling,  in the future.

This Page Intentionally Blank

529

3.0          COST AND PRICE

This Section Intentionally Blank.  Cost and Price information will be provided if Lockheed Martin is chosen as a “Short List” Primary Vendor.

This Page Intentionally Blank

530

EXHIBIT  E

PRICING SCHEDULES

NPAC/SMS SERVICES

EXHIBIT E - PRICING SCHEDULES

The following schedules set forth the prices at which Contractor will be compensated for rendering the Services under the Agreement.  A general description of these charges and the methods of billing therefor are set forth in Section 6 of the Agreement.  See Agreement for other applicable charges.

Schedule 1

Service Element Fees/Unit Pricing

Category	Service Element		Unit	Price
[* * *]
	[* * *]		[* * *]	$	[* * *]
	[* * *]	(1)	[* * *]	$	[* * *]
	[* * *]	(2)	[* * *]	$	[* * *]
	[* * *]		[* * *]	$	[* * *]
	[* * *]		[* * *]	$	[* * *]
[* * *]
	[* * *]		[* * *]	$	[* * *]	(3)
	[* * *]	(4)	[* * *]
				$	[* * *]
				$	[* * *]
				$	[* * *]
				$	[* * *]
				$	[* * *]
				$	[* * *]
	[* * *]		[* * *]	$	[* * *]
	[* * *]		[* * *]	$	[* * *]
[* * *]
	[* * *]	(5)	[* * *]	$	[* * *]
	[* * *]	(6)	[* * *]	$	[* * *]

(1)Monthly port charges [* * *] The specific cost elements include

⁽²⁾See Note 1 above.

⁽³⁾[* * *]

⁽⁴⁾The TN Porting Event [* * *]

The TN Porting Event [* * *]

⁽⁵⁾The one-time Log-on ID [* * *]

⁽⁶⁾The Mechanized Interface [* * *]

Schedule 2

Training Charges

Year	Cost Per Participant
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]

Schedule 3

Interoperability Testing

Category & Service Element	Unit	Price
[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]	[* * *]	$	[* * *]

Schedule 4

Schedule of Representative Hourly Labor Charges

Applicable to Statements of Work

For Contract Years 1 Through 5

Labor Category	Year 1		Year 2		Year 3		Year 4		Year 5
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]

Schedule 5

Schedule of Target Amounts

Target Options (1)

Monthly Targets for Nov/Dec 1997 (2)

Monthly Targets for 1Q 1998 (2)

Monthly Targets for 2Q 1998 thru 4Q 2001 (2)

Monthly Targets for 1Q 2002 thru 2Q 2002 (2)

Monthly Target for July 2002

Total Contract Targets

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

Notes:

(1)[* * *]

(2)[* * *]

Schedule 6

Sample Annual Target and Allocable Target Shortfall/Credit Calculation

The following is an example of how Allocable Target Shortfalls and Allocable Targets are determined in connection with the Quarterly Targets.  A description of the methodology (including defined terms used below) is set forth in Section 6.6 of the Agreement.

	[* * *]		[* * *]		[* * *]
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	[* * *]		$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]

* Note:

[* * *]

[* * *]

EXHIBIT  F

PROJECT PLAN AND TEST SCHEDULE

NPAC/SMS SERVICES

[Due to its length, this document is not attached. 
The Project Plan is available on the internet at
http://www.npac.com/secure/docs/timeline.mpp
and the Test Schedule is available on the internet at
http://www.npac.com/ne/docs/ne_schedule.htm
A copy is also

available upon request for the cost of copying and handling from
NECAC, by request made to the attention of Carville Collins]

[Information referred to in this exhibit immediately follows this page.]

Northeast Schedule Northeast Schedule (as of 9/29/97)

Bell Atlantic North (Nynex)

AT&T

MCI

TCG

Illuminet

Sprint

Worldcom - may be a late entrant

Time Warner - may be a late entrant

Release 1.1 Regression  09/22/97 - 09/28/97

SP to SP testing09/29/97 - 10/16/97

Database Clean-up10/17/97 - 10/24/97

NPAC Live10/25/97

Production Network Testing (Field Trial) 10/27/97 - 11/21/97

Field Trial Clean-up11/24/97 - 11/29/97

Live 13th and 50th Streets11/30/97

ID	Name	Duration	Start
1	1.0 PROPOSAL SUBMISSION AND CONTRACTS	80.d	10/25/1996 8:00
2	1.1 Submit Proposal	1.d	10/25/1996 8:00
3	1.2 Notice of Award	1.d	12/18/1996 8:00
4	1.3 Execute Letter of Intent	1.d	1/2/1997 8:00
5	1.4 Master Contract and Service Agreements	30.d	1/3/1997 8:00
6	1.4.1 Negotiate Contract	30.d	2/13/1997 17:00
7	1.4.2 Target Date to Execute Contract	.d	12/19/1996 8:00
8	2.0 PROJECT PLANNING	15.d	12/19/1996 8:00
9	2.1 Staffing Plan & Management Review	10.d	12/19/1996 8:00
10	2.2 Facility Plan & Management Review	15.d	12/19/1996 8:00
11	2.3 Equipment Plan & Management Review	15.d	12/19/1996 8:00
12	2.4 Software Development Plan & Management Review	15.d	12/19/1996 8:00
13	2.5 Quality Assurance Plan & Management Review	15.d	12/19/1996 8:00
14	2.6 Configuration Management Plan & Management Review	15.d	12/19/1996 8:00
15	2.7 Communications Plan & Management Review	15.d	12/19/1996 8:00
16	2.8 Training Plan & Management Review	15.d	12/19/1996 8:00
17	3.0 STAFF REQUIREMENTS & STAFFING	82.d	1/2/1997 8:00
18	3.1 Hire Staff	60.d	1/2/1997 8:00
19	3.2 Train Staff	60.d	2/3/1997 8:00
20	4.0 FACILITIES PREPARATION	40.d	1/9/1997 8:00
21	4.1 Tarrytown NPAC Buildout	20.d	1/9/1997 8:00
22	4.2.1 Buildout Office	20.d	1/9/1997 8:00
23	4.2.2 Buildout Complete	.d	2/5/1997 17:00
24	4.2 Order & Acquire Furniture/Infrastructure Items	40.d	1/9/1997 8:00
25	4.3 Production Computing Equipment	35.d	1/9/1997 8:00
26	4.3.1 Order & Acquire Production Computing Equipment	35.d	1/9/1997 8:00
27	4.3.2 Stratus Delivered	.d	2/26/1997 17:00
28	5.0 COMMUNICATIONS	70.d	1/9/1997 8:00
29	5.1 Order and Acquire Communications (WAN & LAN)	20.d	1/9/1997 8:00
30	5.2 Install Communications Equipment	15.d	2/6/1997 8:00
31	5.3 Install and Test Circuits	10.d	2/27/1997 8:00
32	5.4 Provision Communications Infrastructure	15.d	3/13/1997 8:00

33	5.5 Test Communications Infrastructure (WAN & LAN)	10.d	4/3/1997 8:00
34	6.0 ADMINISTRATIVE SYSTEMS	54.d	1/3/1997 8:00
35	6.1 Customize and Install LINCSS Problem Tracking System	30.d	2/6/1997 8:00
36	6.2 Customize Existing Administrative Processes	30.d	1/3/1997 8:00
37	7.0 OPERATIONS PROCEDURES	65.d	1/9/1997 8:00
38	7.1 Customize & Finalize Data Center Operations Procedures	30.d	2/27/1997 8:00
39	7.2 Customize & Finalize Performance Standards	30.d	1/9/1997 8:00
40	7.3 Customize & Finalize Security Standards and Procedures	30.d	2/6/1997 8:00
41	7.4 Customize & Finalize Quality Assurance and Control Procedures	30.d	1/9/1997 8:00
42	7.5 Customize & Finalize Configuration Management Procedures	30.d	1/9/1997 8:00
43	8.0 LSP USER AND NPAC OPERATIONS TRAINING	158.d	2/24/1997 8:00
44	8.1 Refine LSP User and NPAC Operations Training Materials	58.d	2/24/1997 8:00
45	8.2 Conduct Ongoing LSP User Training (Until End of Contract)	100.d	5/15/1997 8:00
46	9.0 NPAC SMS RELEASE 2 DEVELOPMENT FOR NYCAC	57.d	1/2/1997 8:00
47	9.1 NPAC SMS Release 2 Functional Requirements Verification	22.d	1/2/1997 8:00
48	9.1.1 Provide NPAC SMS Release 2 Functional Requirements Specification (R2-FRS)	1.d	1/2/1997 8:00
49	9.1.2 NPAC SMS R2-FRS Review by NYCAC	20.d	1/3/1997 8:00
50	9.1.3 NPAC SMS R2-FRS Acceptance by NYCAC	1.d	1/31/1997 8:00
51	9.2 NPAC SMS Release 2 External Design Verification	22.d	1/2/1997 8:00
52	9.2.1 Provide NPAC SMS Release 2 Extern Design Document (R2-ED)	1.d	1/2/1997 8:00
53	9.2.2 NPAC SMS R2-ED Review by NYCAC	20.d	1/3/1997 8:00
54	9.2.3 NPAC SMS R2-ED Acceptance by NYCAC	1.d	1/31/1997 :800
55	9.3 NPAC SMS Release 2 Detailed Design	15.d	1/31/1997 17:00
56	9.3.1 Begin NPAC SMS Release 2 Detailed Design	.d	1/31/1997 17:00
57	9.3.2 Perform NPAC SMS Release 2 Detailed Design	15.d	2/3/1997 8:00
58	9.3.3 Complete NPAC SMS Release 2 Detailed Design	.d	2/21/1997 17:00
59	9.4 NPAC SMS Release 2 Coding and Unit Testing	20.d	2/21/1997 17:00
60	9.4.1 Begin Code and Unit Test	.d	2/21/1997 17:00
61	9.4.2 Perform Code and Unit Test	20.d	2/24/1997 8:00
62	9.4.3 Complete Code and Unit Test	.d	3/21/1997 17:00
63	10.0 TESTING	209.d	12/13/1996 8:00
64	10.1 NPAC SMS Release 2 Test Plan Development	20.d	2/21/1997 17:00
65	10.1.1 NPAC SMS Release 2 Integration/System Test Plan Development	20.d	2/21/1997 17:00
66	10.1.1.1 Begin Integration Test Plan Development	.d	2/21/1997 17:00
67	10.1.1.2 Develop Integration Test Plan	20.d	2/24/1997 8:00
68	10.1.1.3 Complete Integration Test Plan Development	.d	3/21/1997 17:00
69	10.1.2 LM Internal NPAC SMS Release 2 Software Acceptance Test Plan (SATP) Development	20.d	2/21/1997 17:00
70	10.1.2.1 Begin LM Internal NPAC SMS Release 2 SATP Development	.d	2/21/1997 17:00
71	10.1.2.2 Develop LM Internal NPAC SMS Release 2 SATP	20.d	2/24/1997 8:00
72	10.1.2.3 Complete LM Internal NPAC SMS Release 2 SATP Development	.d	3/21/1997 17:00
73	10.2 Actual Testing	209.d	12/13/1996 8:00
74	10.2.1 NPAC SMS Release 2 Integration Testing	20.d	3/21/1997 8:00
75	10.2.1.1 Begin NPAC SMS Release 2 Integration Testing	.d	3/21/1997 8:00
76	10.2.1.2 Perform NPAC SMS Release 2 Integration Testing	20.d	3/21/1997 8:00
77	10.2.1.3 Complete NPAC SMS Release 2 Integration Testing	.d	4/17/1997 17:00
78	10.2.2 LM Internal NPAC SMS Release 2 Acceptance Testing	20.d	4/17/1997 17:00
79	10.2.2.1 Begin Software Acceptance Testing	.d	4/17/1997 17:00
80	10.2.2.2 Perform Software Acceptance Testing	20.d	4/18/1997 17:00
81	10.2.2.3 Complete Acceptance Testing	.d	5/15/1997 17:00

2

82	10.2.2.4 **NPAC OPERATIONAL**	.d	5/15/1997 17:00
83	10.2.3 NPAC SMS Interoperability Testing	208.d	12/13/1996 8:00
84	10.2.3.1 Ongoing NPAC SMS Interoperability Testing (Until End of Contract)	208.d	12/13/1996 8:00
85	10.2.3.2 NPAC SMS Interoperability Testing w/Initial carriers Complete	.d	7/15/1997 8:00
86	10.2.4 NYCAC NPAC SMS Initial Turnup (Live System to System) Testing	99.d	5/16/1997 8:00
87	10.2.4.1 Ongoing NPAC SMS Turnup Testing	99.d	5/16/1997 8:00
88	10.2.4.2 Turnup Testing w/Initial Carriers Complete	1.d	8/15/1997 8:00
89	11.0 LIVE PORTING OF NUMBERS	.d	10/1/1997 8:00
8108		1.d	10/25/1996 8:00
8109		1.d	10/25/1996 8:00

ID	Name	Initials	Type	Max Units	Standard Rate		Cost Per Use		Notes
1	Ganeck	G	Work	100%	$	0.00/hr	$	0.00
2	Franlin	F	Work	100%	$	0.00/hr	$	0.00
3	Roberts	R	Work	100%	$	0.00/hr	$	0.00
4	Foster	F	Work	100%	$	0.00/hr	$	0.00
5	Carter	C	Work	100%	$	0.00/hr	$	0.00
6	Hurrel	H	Work	100%	$	0.00/hr	$	0.00
7	Shea	S	Work	100%	$	0.00/hr	$	0.00
8	NPAC Director	N	Work	100%	$	0.00/hr	$	0.00
9	NPAC Quality Assurance Manager	N	Work	100%	$	0.00/hr	$	0.00
10	NPAC Network Manager	N	Work	100%	$	0.00/hr	$	0.00
11	ICC	I	Work	100%	$	0.00/hr	$	0.00
12	Sotell	S	Work	100%	$	0.00/hr	$	0.00
13	Stratus	S	Work	100%	$	0.00/hr	$	0.00
14	DSET	D	Work	100%	$	0.00/hr	$	0.00
15	ESI	E	Work	100%	$	2,000.00/hr	$	0.00
16	SMS Committee	S	Work	100%	$	0.00/hr	$	0.00
17	Stratus	S	Work	100%	$	0.00/hr	$	0.00
18	NPAC Operations Personnel	N	Work	100%	$	0.00/hr	$	0.00
19	NPAC User Support Manager	N	Work	100%	$	0.00/hr	$	0.00
20	Maxson	M	Work	100%	$	115.00/hr	$	0.00
21	Fostr	F	Work	100%	$	0.00/hr	$	0.00

Task Name	Resource Name	% Work Complete		Work	Units
	Ganeck	0	%	8 hrs	100%
	Franlin	0	%	8 hrs	100%
	Roberts	0	%	8 hrs	100%
	Foster	0	%	8 hrs	100%
	Carter	0	%	8 hrs	100%
	Hurrel	0	%	8 hrs	100%
	Shea	0	%	8 hrs	100%
	NPAC Director	0	%	8 hrs	100%
	NPAC Quality Assurance manager	0	%	8 hrs	100%
	NPAC Network Manager	0	%	8 hrs	100%

3

EXHIBIT  G

SERVICE LEVEL REQUIREMENTS

NPAC/SMS SERVICES

EXHIBIT G

SERVICE LEVEL REQUIREMENTS

The following is a schedule of Service Affecting and Non-Service Affecting Service Levels for the NPAC/SMS in the Service Area.  The  Service Levels below are subject to  change  from time to time as provided in the Agreement.

The following are definitions of certain of the terms used in the Service Level Requirements table set forth below in this Exhibit G:

(a)The term “Service Availability” shall mean the NPAC/SMS service is available if one or more Users are able to access and invoke all NPAC/SMS capabilities through their respective interfaces, to either the NPAC/SMS Production Computer System or the NPAC/SMS Disaster Recovery Computer System.  Service Availability measures the reliability of the services provided by the NPAC/SMS, and does not include time due to scheduled service downtime, if any.  The term “Service Unavailability” shall have the correlative meaning.

(b)The term “Interface Availability” shall mean an NPAC/SMS interface is available to each User that is able to establish, maintain, and utilize an association with the NPAC/SMS system designated as the “live” system (either the NPAC/SMS Production Computer System or the NPAC/SMS Disaster Recovery Computer System) at any point in time.  Interface Availability measures the reliability of the NPAC/SMS interfaces collectively, excluding interface outages resulting from Service Unavailability events and scheduled service downtime.

(c)The terms “Business Day,” “Normal Business Hours,” “NPAC/SMS Software,”  “Parties” and “Statement of Work” shall have the meanings ascribed to them in Section 1 of the Agreement.

SERVICE LEVEL REQUIREMENTS

NPAC/SMS

No.	Procedure	Service Commitment Level	Service Affecting/ Non-Service Affecting	Performance Credit	Report Frequency and Performance Credit Calculation Interval
1.	Service Availability (Customer)	Maintain a 99.9% minimum Service Availability	Service Affecting	>99.85% but <99.90%: $[* * *]; >99.80% but <99.85%: $[* * *]; >99.75% but <99.80%: $[* * *]; >99.70% but <99.75%: $[* * *]; >99.65% but <99.70%: $[* * *]; >99.60% but <99.65%: $[* * *]; <99.60%: $[* * *]	Monthly
2.	Scheduled Service Unavailability (Customer)	Scheduled Service Unavailability will be equal to or less than2 hours per month, or such longer period otherwise agreed to by the Parties	Service Affecting	$[* * *] for each hour or portion thereof in excess of 2 hours or such longer period ofherwise agreed to by the Parties	Monthly

No.	Procedure	Service Commitment Level	Service Affecting/ Non-Service Affecting	Performance Credit	Report Frequency and Performance Credit Calculation Interval
3.	SOA/LSMS Acknowledgement Response Times (Customer)	Response time (i.e., means NPAC processing time) for 95% of the responses will be equal to or less than 3 seconds, except for miscellaneous transactions, such as queries, audits and edits	Service Affecting	$[* * *]	Monthly
4.	LSMS Broadcast Time (Customer)	A mean time maximum of 60 seconds from activation to broadcast	Service Affecting	$[* * *]	Monthly
5.	SOA to NPAC Interface Transaction Rates (Customer)	Maintain a minimum of 2 transactions per second per User SOA for 95% of the transactions.	Service Affecting	$[* * *]	Monthly
6.	NPAC to LSMS Interface Transaction Rates (Customer)	Maintain a minimum of 25 transactions per second per User LSMS for 95% of the transactions (excluding the impact of delays caused by Users)	Service Affecting	$[* * *]	Monthly

No.	Procedure	Service Commitment Level	Service Affecting/ Non-Service Affecting	Performance Credit	Report Frequency and Performance Credit Calculation Interval
7.	SOA/LSMS Interface Availability (User)	Maintain an Interface Availability at a minimum of 99.9%	Service Affecting	>99.85% but <99.90%: $[* * *]; >99.80% but <99.85%: $[* * *]; >99.75% but <99.80%: $[* * *]; >99.70% but <99.75%: $[* * *]; >99.65% but <99.70%: $[* * *]; >99.60% but <99.65%: $[* * *]; <99.60%: $[* * *]	Monthly
8.	Unscheduled Backup Cutover time (Customer)	A maximum of 10 minutes to cutover to the backup site	Service Affecting	$[* * *]	Per Event
9.	NPAC/SMS Partial Disaster Restoral Interval (Customer)	Partial restoration will be equal to or less than 24 hours (Partial restoration meaning the capability of receiving, processing and broadcasting updates)	Service Affecting	$[* * *] for each day or portion thereof in excess of 24 hours	Per Event
10.	NPAC/SMS Full Disaster Restoral (Customer)	Full restoration will occur at a maximum of 48 hours	Service Affecting	$[* * *] for each day or portion thereof in excess of 24 hours	Per Event

No.	Procedure	Service Commitment Level	Service Affecting/ Non-Service Affecting	Performance Credit	Report Frequency and Performance Credit Calculation Interval
11.	Administration of any NPAC/SMS Tables (Customer)	99.5% error free updating	Service Affecting	$[* * *]	Monthly
12.	User Problem Resolution	Minimum 90% calls during Normal Business Hours answered by live operators within 10 seconds	Non-Service Affecting	[* * *]	Monthly
13.	User Problem Resolution	Less than 2.0% abandoned call rate	Non-Service Affecting	[* * *]	Monthly
14.	User Problem Resolution	99.0% callback within 30 minutes for requests made during other than Normal Business Hours	Non Service Affecting	[* * *]	Monthly
15.	User Problem Resolution	A minimum of 99.5% of all commitments to get back to the User after the initial contact will be met	Non-Service Affecting	[* * *]	Monthly
16.	Logon Administration	Process 99.0% of all approved requests within 12 business hours of receipt	Non-Service Affecting	[* * *]	Monthly
17.	Logon Administration	Assign User class correctly for 99.5% of all processing opportunities	Non-Service Affecting	[* * *]	Monthly
18.	System Security	Monitor and record unauthorized system access	Non-Service Affecting	[* * *]	Per Event

No.	Procedure	Service Commitment Level	Service Affecting/ Non-Service Affecting	Performance Credit	Report Frequency and Performance Credit Calculation Interval
19.	System Security	Remedy logon security permission errors immediately after User notification	Non-Service Affecting	[* * *]	Per Event
20.	NPA Split/Mass Changes	Notify Users within 10 business days of receipt of notification of the need for an NPA split/mass change	Non-Service Affecting	[* * *]	Per Event
21.	Scheduled Service Unavailability Notification	Notice of scheduled Service Unavailability for routine maintenance NPAC/SMS to be given a minimum of 2 weeks in advance. Notice of scheduled Service Unavailability for non-routine maintenance NPAC/SMS to be given as follows: •     During Normal Business Hours - a minimum of 7 days in advance •     During Non-Normal Business Hours - a minimum of 24 hours in advance	Non-Service Affecting	[* * *]	Per Event
22.	Unscheduled Service Unavailability Notification	Notify User within 15 minutes of detection of an occurrence of unscheduled Service Unavailability	Non-Service Affecting	[* * *]	Per Event

No.	Procedure	Service Commitment Level	Service Affecting/ Non-Service Affecting	Performance Credit	Report Frequency and Performance Credit Calculation Interval
23.	Unscheduled Service Unavailability Notification	Provide 30-minute updates of NPAC status following an occurrence of unscheduled Service Unavailability through recorded announcement and client bulletins	Non-Service Affecting	[* * *]	Per Event
24.	Software Release Notification	Notify Users of general availability of NPAC/SMS Software releases at least 30 calendar days in advance	Non-Service Affecting	[* * *]	Per Event
25.	Delayed Software Release Notification	Notify Users of delayed NPAC/SMS Software releases at least two weeks before the scheduled delivery date	Non-Service Affecting	[* * *]	Per Event
26.	Software Release Management	Provide documentation and training on schedule	Non-Service Affecting	[* * *]	Per Event
27.	Document Order Administration	Mail to requester within one (1) Business Day	Non-Service Affecting	[* * *]	Per Event

EXHIBIT  H

REPORTING AND MONITORING REQUIREMENTS

NPAC/SMS SERVICES

EXHIBIT H — REPORTING AND MONITORING REQUIREMENTS

Name of Report	Items Covered	Frequency of Issuance*	Pricing
Reports for Individual Service Provider/Users	Reports described in the following items in Section 9.2 of Exhibit B — NPAC/SMS Functional Requirement Specifications: •     RP9-1 Service and Network Data Reports •     RP9-2 Service Provider Reports •     RP9-3 Subscription Data Reports •     RP9-4 System Reports •     RP9-5 Security Reports •     RP9-6 Log File Reports •     RP9-7 Audit Reports •     RR9-1 Data Integrity Reports	R	[* * *]
Monthly and Quarterly Management and Performance Reports to Customer	As to the entire Service Area: •     Information and data covered by reports listed in “Reports for Individual Service Provider/Users” above •     Actual performance compared with Service Levels in Exhibit G •     Significant changes in or new installations of: •     System Software •     System hardware •     Communications Networks •     Application Software •     Key Personnel •     All Software/hardware problems (even if not impacting system availability) •     “Top 10” most frequent trouble reports	M, Q	[* * *]

Annual Management and Performance Reports Same as monthly/quarterly reports, and also including: •Summary of significant events and accomplishments of the year •Comparison of goals for previous period with actual performance •Plans/goals for following year A [* * *]

*KEY:

R =      Report Issued on Request of Service Provider or User

M =      Monthly (due by the 15th calendar day of each month following the month with respect to which the Report relates, except for the December Report which shall be due by the following February 1 — see key for Annual Report, below)

Q =      Quarterly (the Monthly Reports for March, June, September and December, which are due by the 15^th calendar day of each month following the close of each quarter, shall also serve as Quarterly Reports, and shall present information for the calendar quarter in which such month falls in addition to monthly information for said month)

A =      Annually (due by February 1 of each year for the immediately preceding January - December period; the December Monthly/Quarterly Report shall also serve as the Annual Report, and shall present information for the full year in addition to the monthly information for December and the quarterly information for the fourth calendar quarter of the year)

EXHIBIT  I

KEY PERSONNEL

NPAC/SMS SERVICES

EXHIBIT I
KEY PERSONNEL

1.INTRODUCTION

This Exhibit I identifies the initial Project Executives and Project Managers, as required under Section 11 - Project Staff.

2.PROJECT EXECUTIVES

The following Project Executives are identified:

•Lockheed Martin IMS

Contractor’s Project Executive

Name:	Jan Trout-Avery
Phone:	312-382-8092
Fax:	312-382-8080
E-mail:	Jan.trout-avery@npac.com
•     Mid-Atlantic Carrier Acquisition		LNP (Midwest) LLC
Customer Project Executive		Customer Project Executive
Name:	David Heath	Name:		Roger Marshall
Phone:	703-918-6892	Phone:		847-248-5482
Fax:	703-918-0756	Fax:		847-248-3970
E-mail:	davidh@mci.net
•     Northeast Carrier Acquisition		Southwest Region Portability
Customer Project Executive		Customer Project Executive
Name:	David Heath	Name:		Marilyn Murdock
Phone:	703-918-6892	Phone:		816-275-3990
Fax:	703-918-0756	Fax:		816-275-0683
E-mail:	davidh@mci.net	E-mail:	mm0771@kcmaill.sbc.com

2.PROJECT MANAGERS

The following Project Managers for the initial implementation of the NPAC/SMS are identified:

Customer’s Project Manager	Contractor’s Project Manager
Name:	Name:
Phone:	Phone:
Fax:	Fax:
E-mail:	E-mail:

THE ABOVE PROJECT EXECUTIVES AND PROJECT MANAGERS ARE SUBJECT TO CHANGE FROM TIME TO TIME AS DEFINED IN SECTION 11.1.  THE PROJECT EXECUTIVES AT THE TIME OF EXECUTION OF A USER AGREEMENT ARE IDENTIFIED IN ATTACHMENT D OF THE USER AGREEMENT.

EXHIBIT  J

FORM

OF

NPAC/SMS USER AGREEMENT

NPAC/SMS SERVICES

CONFIDENTIAL

EXHIBIT J

NPAC/SMS USER AGREEMENT FORM

THIS NUMBER PORTABILITY ADMINISTRATION CENTER/SERVICE MANAGEMENT SYSTEM (“NPAC/SMS”) USER AGREEMENT (“Agreement”) is made and entered into this       day of       ,               (“Effective Date”) by and between                                       (“User”) having offices at                                                          and Lockheed Martin IMS (“Contractor”), a New York corporation, having offices at 1200 K Street NW, 11th Floor, Washington, DC 20005.

WITNESSETH:

WHEREAS, the Contractor has entered into the Master Contract (as defined below) with the Northeast  Carrier Acquisition Company, L.L.C., a New York limited liability company (“Customer”) to provide the Number Portability Administration Center and Service Management System and Services to support the implementation and provision of local number portability in the Service Area (as defined in the Master Contract); and

WHEREAS, the User wishes to receive the Services (as defined below) of Contractor in the Service Area; and

WHEREAS, Contractor is willing to provide the Services to User and desires to do so for the compensation and in accordance with the terms and conditions herein and in the Master Contract; and

WHEREAS, the representatives of the Contractor and User possess proper and sufficient authority to agree.

NOW, THEREFORE, for and in consideration of the premises and the mutual promises and covenants contained herein, it is hereby agreed as follows:

ARTICLE 1 - DEFINITIONS

All capitalized terms used herein and not expressly defined herein shall have the respective meanings given to such terms in the Master Contract.  As used throughout this Agreement, the following shall have the meanings set forth below unless otherwise indicated:

1.1The term “Agreement” shall mean the terms and conditions contained herein and any other appendix, attachment, exhibit or documents made a part hereof or incorporated herein by reference (including the Application), including any and all amendments to this Agreement.

1.2The term “Application” shall mean the Application for Services submitted by User to Contractor in order to apply to receive Services in the Service Area, as the same may be

amended from time to time as provided in Section 7.4 hereof.  A copy of User’s completed Application is attached hereto as Attachment A.

1.3The term “Certified System” shall have the meaning set forth in Section 7.3(b) hereof.

1.4The term “Confidential Information” shall have the meaning set forth in Section 15.1 and 15.2 of the Master Contract.

1.5The term “Contractor” refers to Lockheed Martin IMS, a New York corporation, having offices at 1200 K Street NW, 11th Floor, Washington, DC 20005 and shall include its permitted successors or assigns pursuant to Article 22 of the Master Contract .

1.6The term “Customer” shall mean the Northeast Carrier Acquisition Company, L.L.C.

1.7The term “Effective Date” shall mean the date of  this Agreement, as set forth in the preamble to this Agreement.

1.8The term “Master Contract” shall mean that certain Agreement for Number Portability Administration Center / Service Management System dated November 7, 1997, between Contractor and Customer, including all Exhibits, appendices, attachments and other documents included in the definition of “Agreement” thereunder, as the same may be amended from time to time.  A copy of the Master Contract in effect as of the Effective Date is attached hereto as Attachment B.

1.9The term “Party” or “Parties” shall mean Contractor and/or Users.

1.10The term “Service Establishment Date” shall have the meaning set forth in Article 8 hereof.

1.11The term “Services” means the delivery of NPAC/SMS services in the manner provided under this Agreement and the Master Contract, and shall include Additional Services.

1.12The term “Statements of Work” shall have the meaning set forth in Section 7.12 hereof.

1.13The term “Test Schedule” shall have the meaning set forth in Section 6.3 hereof.

1.14The term “Third Party” shall mean any individual, corporation, partnership, association or other entity, other than the Parties to this Agreement or the Customer.

1.15The term “User Data” shall have the meaning set forth in Section 1.64 of the Master Contract.

ARTICLE 2 - MASTER CONTRACT TO GOVERN

2.1Incorporation of Master Contract

The Parties acknowledge and agree that this Agreement will be subject to all of the terms and conditions of the Master Contract.  This Agreement shall be interpreted subject to, and in a manner consistent with, the Master Contract.  If any term or condition of this Agreement is in conflict with a term or condition of the Master Contract, the term or condition of the Master Contract shall govern (and the inconsistent term or condition in this Agreement shall be of no force or effect).

2.2Amendments to the Master Contract

User acknowledges that (i) the Master Contract may be amended from time to time and (ii) that any such amendments may be material to User and may include amendments to, among other things, the rates and charges for the Services.  User hereby agrees to be bound by any such amendments to the Master Contract that affect this Agreement (including, without limitation, any changes to the above-referenced rates and charges), and to execute any amendments necessary to this Agreement in order to cause it to conform to the Master Contract, as amended.  Contractor  shall make a reasonable effort to keep User advised of any impending changes to the Master Contract, and shall furnish User with any amendments to the Master Contract.

ARTICLE 3 - TERM

This Agreement shall commence on the Effective Date and shall expire coincident with the expiration of the Master Contract (giving effect to any and all renewal(s) of the Master Contract as provided in Article 3 thereof), unless terminated earlier pursuant to Section 10.1 hereof.

ARTICLE 4 - COMPENSATION

The rates and charges for the Services, including a general discussion concerning the allocation thereof, are set forth in Article 6 and Exhibit E of the Master Contract.  In general, for any specific billing period, the amount that User will compensate Contractor for certain rates and charges pursuant to this Agreement will be an allocated amount of the aggregate of such rates and charges of all Users in the Service Area during such billing period.  The Allocation Model will be determined based upon an order of either the Federal Communications Commission (“FCC”), or the state public utilities commission (“State Commission”) having jurisdiction over the applicable rates and charges, and will be subject to change without notice to User pursuant to order of either the FCC or the State Commission.  Customer will determine and provide Contractor with the initial Allocation Model which shall apply pending a decision of either the FCC or applicable State Commission, and will thereafter provide Contractor with an updated Allocation Model based upon orders of the FCC or State Commissions.  Contractor’s invoice to User will indicate the User’s allocated amount of rates and charges, which shall be the amount due and owing Contractor pursuant to Section 7.1 hereof.

User hereby acknowledges that the Master Contract also provides that Contractor and Customer may agree to changes in the rates and charges for the Services under Statements of Work entered into thereunder, and otherwise under provisions of the Master Contract.  User hereby further

acknowledges and agrees that any such changes in the rates and charges may be made without prior advance notice to User hereunder, and User agrees to be bound thereby.

ARTICLE 5 - REPRESENTATIONS AND WARRANTIES OF THE PARTIES

5.1Representations and Warranties of Contractor

Contractor hereby represents and warrants to User as follows:

(a)Contractor has the full authority to enter into and perform all of its obligations under this Agreement.  Contractor has read this Agreement and the Master Contact, understands the same, and agrees to be bound by all the terms, conditions and provisions of this Agreement and, to the extent it affects this Agreement, the Master Contract.

(b)Contractor warrants that the NPAC/SMS Software will not contain, either now or in the future, any malicious code, program, or other internal component (e.g. software virus, software worm, software time bomb, Trojan Horse or similar component), which could damage, destroy, or alter Software or hardware of User, or which could, in any manner, reveal, damage, destroy, or alter any data or other information accessed through or processed by the NPAC/SMS Software in any manner or which could adversely affect the operation of a computer or its memory by User.  Contractor shall immediately advise User, in writing, upon reasonable suspicion or actual knowledge that the NPAC/SMS Software may result in the harm described above.

(c)Contractor warrants that the NPAC/SMS shall operate without Defects during the term of this Agreement.

5.2Representations and Warranties of User

User hereby represents and warrants to Contractor as follows:

(a)User has the full authority to enter into and perform all of its obligations under this Agreement.  User has read this Agreement and the Master Contract, understands the same, and agrees to be bound by all the terms, conditions and provisions of this Agreement and, to the extent it affects this Agreement, the Master Contract.

(b)All of the information provided by User in its Application for Services was true and correct as of the date initially provided to Contractor, and shall remain true and correct in all material respects throughout the term of this Agreement, giving effect to any amendments thereto pursuant to Section 7.4 hereof.

ARTICLE 6 - OBLIGATIONS OF CONTRACTOR

6.1Provision of Services

Except with respect to the training and testing referred to in Sections 6.2(c), 6.3, 7.3(b) and 7.5 below, beginning on the Service Establishment Date and throughout the term of this Agreement, Contractor shall provide the Services to User hereunder in accordance with its obligations under the Master Contract, including, without limitation, the following obligations generally described (with Article/Section references below in this Section 6.1 referring to Articles/Sections in the Master Contract):

(a)the obligation to provide the Services in accordance with the Service Levels, as provided under Section 8.3, and to do so with parity among Users, as provided under Section 27.3;

(b)the obligation to monitor compliance with the Service Levels and to report thereon, as provided under Section 8.4;

(c)the obligation to maintain safety and physical security at the NPAC/SMS Data Centers and to report events of Unauthorized Access of which it is aware, as provided under Section 8.5;

(d)the obligation to (i) pay the expenses of providing the NPAC/SMS and the costs of operating the NPAC/SMS Data Centers and (ii) provide appropriate staffing at the NPAC/SMS Data Centers, in each case, as provided in Section 8.6;

(e)the obligation to provide training courses for User personnel, as provided in Section 8.7;

(f)the obligation to indemnify User for any charges that may be levied against User as the result of Contractor’s failure to pay Contractor’s taxes, as provided in Section 8.8;

(g)the obligation to (i) obtain all licenses and authorizations required of Contractor (as provided in Section 8.9) and to comply with all laws (as provided in Sections 8.10 and 8.11), in each case, in order to perform its obligations hereunder, and (ii) pay all fines imposed on User for Contractor’s noncompliance;

(h)the obligation to provide high quality service to User and to measure and report thereon, as provided in Section 8.12;

(i)the obligation to (i) provide a “Hotline Service” to enable User to obtain answers to routine questions, resolve problems and report defects or failures in the NPAC/SMS (as provided in Section 10.1) and (ii) use its best efforts to correct problems caused by the NPAC/SMS (as provided in Section 10.2);

(j)the obligation to (i) provide system status reports to User in the event of a disaster at a NPAC/SMS Data Center (as provided in Section 12.4) and (ii) inform User of the database status after employing disaster recovery procedures (as provided in Section 12.5);

(k)the obligation to maintain the confidentiality of User Data as provided in Article 15;

(l)the obligation to indemnify Users pursuant to Section 18.1 and the obligation to pursue one (1) or more of the various alternatives set forth in Section 18.2 if use of the NPAC/SMS is prevented or likely to be prevented;

(m)the obligation to include User as an additional insured on its required insurance as provided in Section 20.1; and

(n)the obligation to correct any Defects in the NPAC/SMS, as provided in Section 21.3.

6.2Connectivity Consultation; Testing and Training Scheduling

(a)Contractor agrees to make itself available to consult with User, at User’s request, regarding the number and type of data circuits required by User to connect to the NPAC/SMS given the configuration of User’s system.

(b)Upon the request of User pursuant to Section 7.3(a) below, Contractor shall schedule the testing of User’s system (the date on which testing is scheduled to begin being referred to herein as the “Start Test Date”), taking into account, among other things, the date on which User’s Application was submitted in relation to the Applications of other Users, the expected date on which User’s System will be a Certified System (pursuant to Section 7.3(b) below), the date on which User anticipates its data circuits will be installed, and the availability of testing “slots,” given the scheduled testing of other Users.

(c)Upon the request of User pursuant to Section 7.5 below, Contractor shall use its best efforts, subject to its existing training commitments for the personnel of other Users, to schedule the training of User’s personnel such that the training is completed prior to User’s anticipated Service Establishment Date.

6.3Testing of User’s Certified System

Upon receipt of notice and proper evidence from User that it has a Certified System, Contractor shall test User’s Certified System beginning on the Start Test Date in accordance with the Turnup Test Plan referenced in Section 8.1 of the Master Contract.  On or prior to the Start Test Date, Contractor and User shall agree on an appropriate test events schedule for User’s Certified System, based on the activities required under the Turnup Test Plan, with such test events schedule then being attached hereto as Attachment C (the “Test Schedule”).  If User has completed Turnup Testing as of the Network Test Readiness Date, Contractor shall also include User’s Certified System in the Network Testing Contractor will perform pursuant to Section 8.1(b) of the Master Contract.

ARTICLE 7 - OBLIGATIONS OF USER

7.1Payment of Fees

User  agrees to pay Contractor for the Services it receives hereunder and all other amounts for which it is appropriately invoiced by Contractor pursuant to this Agreement or the Master Contract within forty-five (45) days of receipt of Contractor’s invoices therefor.  Late payments will be subject to a 1.25% interest charge per month or, if lower, the maximum rate permitted by law.

Contractor shall make commercially reasonable efforts to accommodate User’s requests for billing by Electronic Data Interexchange or other special billing formats.  Any requests for special formats which require a Statement of Work under Article 13 of the Master Contract must first be submitted to Customer for approval.

Except as otherwise required by a rule or order of the FCC or applicable State Commission, Contractor shall not back bill User for Contractor billing errors after more than six (6) months have passed since issuance of the invoice upon which the charges should have appeared; provided, however, that the foregoing limitation shall not apply with respect to taxes that are imposed by law on User but which are required by law to be collected and remitted by Contractor.

7.2Disputed Invoices

Any billing disputes shall be promptly presented to Contractor in reasonable detail, in writing.  Any requests for adjustment shall not be cause for delay in payment of the undisputed balance due.  User may withhold payment of any amounts which are subject to a bona fide dispute; provided it shall pay all undisputed amounts owing to Contractor that have been separately invoiced to User.  If re-invoice occurs following the forty-five (45) day payment schedule, such invoice for the undisputed amount shall be paid within ten (10) business days of receipt by User. User and Contractor shall seek to resolve any such disputes expeditiously, but in any event within less than thirty (30)  days after receipt of notice thereof.  If the Parties are unable to resolve a dispute within such period, then they may resort to the procedures set forth in Article 13 of this Agreement.  All disputed amounts ultimately paid or awarded to Contractor shall bear interest from the forty-fifth (45th) day following the original invoice therefor in accordance with Section 7.1.

Notwithstanding the foregoing, User may not withhold payment of any amounts invoiced by Contractor based solely upon a dispute concerning how User is  allocated charges under the Allocation Model.

7.3Schedule Testing; User System Certification; Delivery of User System for Testing

(a)Once User has determined the expected date on which its system will be a Certified System and the expected date on which User’s data circuits will be installed, it shall request

Contractor to schedule testing of its Certified System in accordance with Section 6.2(b) above.  User shall promptly notify Contractor upon becoming aware of any circumstances which make it unlikely that User’s Certified System will be available for testing on the scheduled Start Test Date, in which case, Contractor shall offer User an alternative Start Test Date, after reexamination of the factors referred to in Section 6.2(b) above.

(b)Prior to the Start Test Date in Section 6.2(b), above, User shall have its System Order Administration and Local Service Management System tested and certified that it meets the NPAC/SMS Interoperable Interface Specification set forth in Exhibit C to the Master Contract (the “Certified System”).  Once User has a Certified System, it shall (i) deliver written notice and proper evidence thereof to Contractor in order to begin testing on the Start Test Date and (ii) shall agree with Contractor on an appropriate Test Schedule.  The amount and timing of payment of testing charges is set forth in Article 6 and Exhibit E of the Master Contract.

7.4Update Application Information

User will immediately notify Contractor in writing of any changes that need to be made to the information in its Application in order to maintain the truth and accuracy of such Application information.  User’s notice of any such changes in information shall be attached to and become a part of User’s Application (Attachment A).

7.5Training of User Personnel

User shall request Contractor to schedule the training of its personnel with respect to the NPAC/SMS, which training, and User rights in connection therewith, will be consistent with the provisions of Section 8.7 in the Master Contract.  User may cancel a training course scheduled by Contractor at any time upon written notice to Contractor; provided, however, that User shall be liable to Contractor for all reasonable expenses incurred by Contractor in preparation for the course that are not otherwise recoverable by Contractor if such training course is canceled by User less than two (2) weeks prior to the start of such course.

User may have an individual trained in the operation of the NPAC/SMS train other employees of User; provided that, User must notify Contractor at the time the training course is scheduled if it desires the individual(s) being enrolled to be trained as trainers.  User agrees that all its employees trained as trainers will schedule and attend, at User’s expense, any additional training courses necessitated from time to time to maintain such individual’s expertise as a trainer with respect to any Enhancement or Maintenance Modification to the NPAC/SMS Software.  The amount and timing of  payment of training charges is set forth in Article 6 and Exhibit E of the Master Contract.

7.6Use of User Data

User shall treat User Data as Confidential Information of the other Users which have provided such information.  User Data shall not be:

(a)used by User other than for the purpose of routing, rating, or billing calls or performing network maintenance in connection with providing telecommunications services; or

(b)disclosed, sold, assigned, made available, leased or otherwise provided to any Third Party (other than the rightful owner of such data), except (i) as provided for in this Agreement or the Master Contract or (ii) as provided for by law or rule, regulation or order of the FCC or other regulatory agencies having jurisdiction over NPAC/SMS Service; or

(c)transferred or otherwise provided to a Third Party LSMS; or

(d)commercially exploited.

7.7Security, Unauthorized Access

User shall protect and limit access to any logon identification code password(s) to its employees who have a need for such access for uses permitted under this Agreement, and shall be responsible for all usage of its codes or any User Data.

7.8User Provided Data

User shall provide all User Data to Contractor in the manner agreed upon by the Parties.  User agrees that Contractor will not be responsible or liable for any loss, damage or inconvenience suffered by User or by any Third Party arising out of Contractor’s inability to perform the Services due to a failure of User to provide all of the necessary User Data when required or by reason of any deficiencies in the User Data furnished to Contractor by User.  All User Data shall remain the property of the User furnishing it, as specified in Article 15 of the Master Contract.

7.9Facilities Expenses; Contact with End-User Customer

(a)User shall be responsible for providing, and shall pay all expenses and costs of the procurement and provision of, all hardware, system software, telecommunications services, facilities and supplies required to access the NPAC/SMS from such User’s facilities up to the point of presence, including without limitation, all common carrier charges and all costs of telephone and terminal equipment.

(b)User shall have the sole obligation to interact with its end-user customers in all matters pertaining to its provision of services to such customers, including the placing and handling of service orders, service installation, operation and termination, dispute handling and resolution, and billing and collection matters.

7.10Compliance with Laws

User shall comply, at its expense, with all applicable laws regarding the provision of local number portability and all applicable rules, regulations and rules of the FCC, and the State Commission having appropriate jurisdiction over User or its business.  Contractor shall propose a

Statement of Work to cover the costs, if any, incurred by Contractor in taking any actions to comply with such laws, regulations or rules, but shall not undertake any of the work set forth in the Statement of Work without User’s agreement to the Statement of Work.

7.11Appointment of Project Representative

User shall (i) maintain a Project Representative who shall act as the primary interface between User and Contractor’s Project Executive with respect to matters arising under this Agreement and (ii) notify Contractor of any changes in the identity of such designee.  User’s initial Project Representative and Contractor’s Project Executive are identified in Attachment D to this Agreement.

7.12Statements of Work

User may order services from Contractor in connection with special, one-time situations that require additional staffing and resources to perform such services which lie outside the scope of the Services or require that work be performed on an over-time basis; provided, however, that User hereby agrees that any such requests of Contractor shall be made through Customer pursuant to Section 7.13 below.  Contractor’s rates and charges are referenced in Section 13.4(f) of the Master Contract.

7.13Interface with Customer on Master Contract Issues

User shall make any requests for Additional Services and Statements of Work (as described in Section 13.4 of the Master Contract) under the Master Contract and coordinate any other activities under the Master Contract through Customer’s Project Executive.  As of the date hereof, Customer’s Project Executive is identified in Attachment D to this Agreement.

ARTICLE 8 - CONDITIONS TO SERVICE ESTABLISHMENT

Contractor shall on or after the Acceptance Date provide the Services of uploading and downloading telephone numbers to User hereunder upon satisfaction by User of each of the following conditions, unless otherwise waived by Contractor in writing (the date on which such services are first provided hereunder being referred to herein as the “Service Establishment Date”):

(a)all of the information in the Application is true and correct in all material respects as of such date;

(b)successful completion of testing of User’s Certified System pursuant to the Turnup Test Plan (and, if applicable, Network Testing) and Section 6.3 hereof; and

(c)completion of training of User’s personnel pursuant to Section 7.5 hereof.

ARTICLE 9 - CONFIDENTIAL INFORMATION

During the term of this Agreement, either Party may receive or have access to Confidential Information of the other Party or of other Users.  Except as provided in Section 7.6 hereof, the Receiving Party shall not, without first receiving the Disclosing Party’s written consent, disclose to any Third Party, or use for any purpose other than the performance of its obligations under this Agreement, any Confidential Information, or information or materials developed by the receiving Party based on Confidential Information, that it has received or to which it has had access during the term of this Agreement. Each Party shall use no less than the same means (but in any event not less than reasonable means) it uses to protect its similar confidential and proprietary information to prevent the disclosure and to protect the confidentiality of the Confidential Information of the other Party and other Users.

ARTICLE 10 - TERMINATION; FORCE MAJEURE

10.1Termination

This Agreement shall terminate upon the occurrence of the following:

(a)immediately upon termination or expiration of the Master Contract in accordance with its terms (giving effect to any and all renewal(s) of the Master Contract as provided in Article 3 thereof); provided, however, that in the event Customer elects to extend the Master Contract pursuant to Section 24.2 thereof, then the Master Contract will not be deemed to have terminated for purposes of this Agreement until the end of the period of such extension;

(b)immediately, if User is not or ceases to qualify as a Service Provider or User in the Service Area, or was porting numbers and is no longer porting numbers in the Service Area, or if User violates any restrictions on use imposed under Section 7.6 hereof;

(c)upon written notice of termination to Contractor for Contractor’s chronic failure to provide the Services pursuant to Section 16.5 of the Master Contract; or

(d)upon written notice of termination by the non-breaching party to the breaching party following a breach by a party of its representations and warranties hereunder or a failure by a party to perform any of its material obligations hereunder (except, in the case of Contractor, the obligation referenced in Section 10.1(c) hereof), and where such breach or failure is continuing at the time of the termination and has continued for a period of at least thirty (30) days following receipt of written notice of such failure or breach from the non-breaching party; provided, however, that where such failure or breach (other than with respect to a payment obligation) cannot reasonably be cured within such thirty (30) day period, so long as the breaching party is diligently pursuing such cure, the time for curing such failure shall be extended for such period as may be necessary for the breaching party to complete such cure.

Subject to Section 6.1(k) hereof (and related Section 15.3. of the Master Contract), upon termination and regardless of any dispute between the Parties, all property, equipment, data, documents, or other material of User, excluding User Data necessary in the provision and operation of Services, pertaining to this Agreement in the possession of Contractor, its employees, agents or subcontractors, shall be returned to User within fifteen (15) days of the date of the notice of termination.

The termination rights provided to the Parties under this Article 10 are not intended to constitute an election of remedies, and the Party terminating this Agreement is entitled to any additional rights and remedies available to it at law or in equity, subject to the limitations and exclusions in this Agreement.  All rights and remedies of the Parties herein created or otherwise existing at law or in equity are cumulative, and the exercise of one (1) or more rights or remedies shall not be taken to exclude or waive the right to exercise any of the others.

10.2Force Majeure

Any failure or delay by User in the performance of its obligations under this Agreement shall not be a ground for termination hereunder to the extent such failure or delay was caused, directly or indirectly, by a Force Majeure Event, as defined in Section 16.6 of the Master Contract. If any Force Majeure Event occurs with respect to User, rendering the User unable to access the NPAC/SMS in any manner, the User delayed or unable to perform shall give immediate notice to Contractor, stating the nature of the Force Majeure Event and any action being taken to avoid or minimize its effect, and the User may elect to suspend charges and Services under this Agreement for the duration of the Force Majeure Event.  Once the Force Majeure Event ceases, User shall resume performance under this Agreement.

ARTICLE 11 - LIMITATIONS OF LIABILITY; INSURANCE

11.1Damages

Each Party’s liability for damages arising out of its breach of its obligations under this Agreement shall be limited to direct damages and neither Party shall have any liability whatsoever for consequential, incidental, special, punitive or indirect damages (including, without limitation, lost profits) of the other Party or any Third Party, even if a Party has been advised of the possibility of such damages; provided, however, that (i) for purposes of this Agreement, Contractor agrees that the direct damages of the nature listed in Section 19.1 of the Master Contract shall be “direct damages” hereunder with respect to Userand (ii) the Parties agree that the limitations and exculpation of liability set forth in this Article 11 (except for the limitation as to punitive damages) are not applicable to (a) indemnification claims hereunder, (b) liability resulting from the gross negligence or willful misconduct of a Party, or (c) any breach of a Party’s confidentiality obligations hereunder.

Notwithstanding the foregoing, with respect to breaches of a Party’s confidentiality obligations hereunder (a “Confidentiality Breach”), clause (c) of the foregoing sentence shall not be effective, and a Party’s liability shall be limited to direct damages, if the breaching Party (a) promptly documents to the other Party’s reasonable satisfaction, in a writing certified by an

officer of the breaching Party, that the Confidentiality Breach was inadvertent and not the result of any failure by such Party, its officers, employees, agents and independent contractors to use all reasonable efforts to comply with their confidentiality obligations pursuant to this Agreement (including without limitation compliance with such party’s internal confidentiality procedures) and (b) uses its best efforts to effect a prompt cure of such Confidentiality Breach and at its own expense takes all steps reasonably requested by the other Party to (i) identify the source or causes of the Confidentiality Breach, (ii) prevent any further such breaches, (iii) retrieve any Confidential Information which may have been disseminated in connection with the Confidentiality Breach, (iv) cooperate in the other Party’s pursuit of legal or equitable remedies against any Third Parties (including the breaching Party’s employees, agents and independent contractors) responsible for such breach, and (v) cooperate with the other party in its efforts to mitigate the effects of the Confidentiality Breach.  Nothing in this provision shall limit or be deemed a waiver of any other remedies available to the non-breaching Party under law, equity or contract with respect to any Confidentiality Breach.

11.2Insurance

User must maintain (i) Worker’s Compensation insurance as prescribed by the law of the applicable state, and (ii) commercial general liability insurance (including contractual liability and products liability coverage) with combined single limits of at least $2,000,000 for bodily injury and property damage and with limits of $2,000,000 in the general aggregate.  User’s policy with respect to the insurance referred to in (ii) above must be endorsed to name Contractor as an additional insured and state that “Lockheed Martin IMS is to be notified in writing at least thirty (30) days prior to any cancellation of, or change in, the coverage limits.”  User must furnish certificates evidencing the foregoing insurance coverage with its Application.

11.3Self Insurance

User may self insure the risks for which insurance is otherwise required under this Article 11 upon written request to and approval, in writing, by Contractor.  Approval by Contractor of self-insurance shall not be unreasonably withheld and shall be based upon Contractor’s reasonable assessment that User’s net worth, financial history and stability appear to be sufficient to satisfy any obligation User could reasonably be expected to incur during the term of this Agreement.

11.4Failure to Maintain Insurance

If User fails to maintain the insurance required by this Article 11 without having received Contractor’s approval to self insure pursuant to Section 11.3, Contractor may, but shall have no obligation to, procure such insurance.  In such event, Contractor shall invoice User directly for all premiums and other charges incurred in connection therewith and User shall promptly reimburse Contractor for all such premiums and other charges incurred by Contractor in obtaining such coverage.

ARTICLE 12 - INDEMNIFICATION AND LIMITATION OF LIABILITY

12.1Mutual Indemnification

Each Party shall defend against suits, claims and demands and shall indemnify and hold harmless the other, their officers, directors, employees, and agents and their successors and assigns against and from any and all losses, liabilities, damages, and expenses (including, without limitation, reasonable attorneys’ fees) included in a settlement (between the indemnifying Party and a Third Party) of such suits, claims or demands,or awarded to a Third Party by a court or appropriate administrative agency of competent jurisdiction, including without limitation, thosebased on contract or tort arising out of or in conjunction with, but only to the extent that such losses, liabilities, damages, claims, demands, and expenses result from or in connection with, (i) personal injury (including death) or damage to tangible property arising from the negligent or intentional acts or omissions of the indemnifying Party or its subcontractors, or the officers, directors, employees, agents, successors and assigns of any of them during the term of this Agreement, or (ii) assertions under Workers’ Compensation or similar laws made by persons furnished by the indemnifying Party during the term of this Agreement or any transition period as provided under Article 24 of the Master Contract.

12.2Contractor Indemnification

Contractor shall defend, indemnify and hold harmless User and User’s Affiliates and their officers, directors, employees, and agents and their successors and assigns against and from any and all losses, liabilities, suits, damages, claims, demands, and expenses (including, without limitation, reasonable attorneys’ fees) included in a settlement of such suits (between Contractor and a Third Party), claims or demands, or awarded to a Third Party by a court or appropriate administrative agency of competent jurisdiction, including, without limitation thosebased on contract or tort arising out of or in conjunction with, but only to the extent that such losses, liabilities, damages, claims, demands, and expenses arise out of, or in connection with, personal injury (including death) or damage to tangible personal property caused by defective or malfunctioning or improperly provided Software or Services provided by Contractor during the term of this Agreement or any transition period as provided under Article 24 of the Master Contract.  For the purposes of this Article, Third Party includes a regulatory agency having jurisdiction over Customer, Members, or Users.

12.3Procedures

The indemnified Party shall promptly notify the indemnifying Party of any written claim, loss, or demand for which the indemnifying Party is responsible under this Article and shall cooperate with the indemnifying Party as reasonably required. An indemnified Party shall be entitled, upon its request and at its expense, to participate in the defense of any lawsuit arising from an indemnifiable claim when and for so long as such Party is a named party to such lawsuit; provided, however, that the indemnified Party may not settle any such lawsuit without the indemnifying Party’s consent.

ARTICLE 13 - ARBITRATION

13.1Arbitration Procedures

Any dispute arising out of or related to this Agreement, which cannot be resolved by negotiation, shall be settled by binding arbitration in New York, New York in accordance with the J.A.M.S/Endispute Arbitration Rules and Procedures (“Endispute Rules”), as amended by this Agreement.  The costs of arbitration, including the fees and expenses of the arbitrator, shall be shared equally by the Parties unless the arbitration award provides otherwise.  Each Party shall bear the cost of preparing and presenting its case.  The Parties agree that this provision and the arbitrator’s authority to grant relief shall be subject to the United States Arbitration Act, 9 U.S.C. 1-16 et seq. (“USAA”), the provisions of this Agreement, substantive law, and the ABA-AAA Code of Ethics for Arbitrators in Commercial Disputes.  The Parties agree that the arbitrator shall have no power or authority to make awards or issue orders of any kind that provides for punitive or exemplary damages.  The arbitrator’s decision shall follow the plain meaning of this Agreement and the relevant documents, and shall be final and binding. The arbitrator shall render a written and reasoned opinion setting forth both findings of fact and conclusions of law.  The award may be confirmed and enforced in any court of competent jurisdiction.  All post proceedings shall be governed by the USAA.  Any Party may appeal a decision of the arbitrator to the FCC or a State Commission, if the matter is within the jurisdiction of the FCC or a State Commission.  Any Party aggrieved by a decision on appeal to the FCC or a State Commission may exercise the right to obtain judicial review thereof in accordance with applicable law.

13.2Exclusions from Arbitration

The following disputes shall not be subject to arbitration under this Article 13, but shall be subject to i) such recourse and remedies set forth herein or ii) where no specific recourse and remedies are set forth, such recourse and remedies as are available at law or in equity:

(a)disputes arising under this Agreement with respect to the delivery of Services consistent with the Service Levels and/or in conformity with the Specifications. Such disputes, if any, shall be referred by User to Customer for resolution with Contractor pursuant to the dispute resolution procedures set forth in Article 26 of the Master Contract; except that, User may bring an action regarding Customer’s resolution of such dispute before the FCC, NANC or any state regulatory agency having jurisdiction over the NPAC/SMS; or,

(b)disputes arising under this Agreement or the Master Contract concerning how Customer has allocated charges to Users under the Allocation Model, which disputes, if any, (i) may be referred to Customer for resolution and User may bring an action regarding Customer’s resolution of such dispute before the FCC, NANC or any state regulatory agency having jurisdiction over the NPAC/SMS, or (ii) may be brought before any regulatory agency having jurisdiction thereof; or,

(c)disputes in circumstances where the time required for arbitration would cause irreparable harm; or,

(d)any dispute between the owner of User Data and User regarding misuse of the subject User Data; or,

(e)any other disputes which the Parties agree in writing to exclude from arbitration.

13.3Joinder to Arbitration under Master Contract

Upon written notice to User, either Contractor, Customer, any other User or any arbitrator appointed under Section 26.2 of the Master Contract may join User to, or User may unilaterally join, any arbitration brought under the Master Contract where User’s presence in the arbitration is necessary for complete relief, and User hereby agrees to submit to the jurisdiction of the arbitrator in such instance.

ARTICLE 14 - ASSIGNMENT

(a)User may not assign or otherwise transfer all or a portion of its rights or obligations under this Agreement without the prior written consent of Contractor, which consent shall not be unreasonably withheld or delayed, except that User may, without the consent of Contractor, make such an assignment or transfer to an affiliate or subsidiary of User or a Third Party; provided that such affiliate, subsidiary or Third Party is a Service Provider or User that meets the criteria in the Application and User shall remain the ultimate obligor with respect to any assigned or transferred obligations; provided further, that such assignment is not prohibited by law, rule or order of the FCC or other regulatory agencies having jurisdiction over the Services.

(b)Contractor may not assign or otherwise transfer all or a portion of its rights or obligations under this Agreement, unless such assignment is to a party to whom Contractor has assigned its rights and obligations under the Master Contract in accordance with the terms and conditions of the Master Contract, in which case, no consent to such assignment is required from User.

(c)Except as otherwise expressly provided herein, this Agreement shall inure to the benefit of and shall bind the heirs, executors, personal representatives, administrators, successors and assigns of Contractor and User.

ARTICLE 15 - REGULATORY

Contractor expressly recognizes that User and the NPAC/SMS are or may be subject to certain federal and state statutes and rules and regulations promulgated thereunder, as well as rules, regulation, orders, opinions, decisions and possible approval of the FCC and other regulatory bodies having jurisdiction over User and the NPAC/SMS.  The Parties acknowledge that this Agreement is subject to changes and modifications required as a result of any of the foregoing; provided, however, that the Parties hereby agree that this Agreement shall remain in full force and effect in accordance with its terms and each of the Parties hereto shall continue to perform all of its respective obligations hereunder in accordance with the terms hereof until Contractor and

Customer can agree upon any amendment that may be required hereto as a result of any such regulatory change.  Notwithstanding the foregoing, User acknowledges that (i) certain regulatory changes could result in termination of the Master Contract by Customer (as discussed in Section 25.1 of the Master Contract) and, in turn, this Agreement (pursuant to Section 10.1(a) hereof), and (ii) that neither Customer nor Contractor shall have any liability to User at law or in equity as a result of such termination.  The Parties shall cooperate fully with each other and Customer in obtaining any necessary regulatory approvals of the NPAC/SMS and in any other regulatory proceedings regarding the NPAC/SMS or the Services hereunder.

ARTICLE 16 - NO CUSTOMER LIABILITY

USER ACKNOWLEDGES AND AGREES THAT CUSTOMER IS ENTITLED, IN ITS SOLE AND COMPLETE DISCRETION, TO EXERCISE OVERSIGHT OF CONTRACTOR’S COMPLIANCE WITH THE MASTER CONTRACT, TO NEGOTIATE AMENDMENTS TO THE MASTER CONTRACT AND TO TERMINATE THE MASTER CONTRACT IN ACCORDANCE WITH ITS TERMS.  NOTWITHSTANDING THE FOREGOING, IN EACH INSTANCE, USER AGREES THAT, EXCEPT AS PROVIDED IN SECTIONS 13.2(a) AND 13.2(b) HEREOF, IT HAS NO CAUSE OF ACTION OF ANY TYPE OR CHARACTER AGAINST CUSTOMER AND THAT IT SHALL MAKE NO CLAIM, UNDER ANY THEORY OF LIABILITY INCLUDING WITHOUT LIMITATION, ANY CONTRACT CLAIM, CLAIM FOR ANY CAUSE WHATSOEVER INCLUDING WITHOUT LIMITATION, INTERFERENCE WITH CONTRACTUAL RELATIONSHIPS OR ANY RELATED CAUSE OF ACTION AGAINST CUSTOMER FOR ITS ADMINISTRATION, NEGOTIATION OF ANY STATEMENT OF WORK, RENEGOTIATION OR TERMINATION OF THE MASTER CONTRACT.

ARTICLE 17 - NOTICES

17.1Any notice or demand which under the terms of this Agreement or under any statute must or may be given or made by Contractor or the User shall be in writing and shall be given or made by telegram, tested telex, confirmed facsimile, or similar communication or by certified or registered mail addressed to the respective parties as follows:

To the User:	(User’s billing address as set forth in User’s Application)
	Attn:
	Fax No.:
With a Copy to:
	Attn:
	Fax No.:

To Contractor:	To Contractor’s Project Executive at the address set forth on Exhibit I to the Master Contract
With a copy to:	Lockheed Martin IMS
	1200 K Street NW, 11th Floor
	Washington, DC 20005
	Attn: Mr. Joseph Franlin
	Fax No.: (202) 408-5922

17.2All notices or other communications shall be deemed effectively given: (a) when delivered, if personally delivered, including courier or overnight delivery (except that notices received after 3:00 p.m. local time will be deemed received on the following Business Day); (b) on the date of delivery (or, if refused, the refusal date shown on the return receipt) if mailed certified or registered mail, return receipt requested; or (c) four (4) days after mailing if mailed first class.

ARTICLE 18 - GENERAL

18.1Relationship of the Parties

Nothing contained in this Agreement shall be deemed or construed as creating a joint venture or partnership between Contractor and the User.  Neither Party is, by virtue of this Agreement, authorized as an agent, employee or legal representative of the other.  Except as specifically set forth herein, neither Party shall have power to control the activities and operations of the other and their status is, and at all times will continue to be, that of independent contractors.  Neither Party shall have any power or authority to bind or commit the other.

18.2Headings

The Article/Section headings contained herein are for purposes of convenience only and shall not be deemed to constitute a part of this Agreement or to affect the meaning or interpretation of this Agreement in any way.

18.3Third-Party Beneficiaries

(a)The Parties agree that Customer shall be a third party beneficiary under Article/Sections 7.6, 7.7, 9, 10.1, 13, and 16 of this Agreement.  Customer shall have the right to enforce such provisions in its own name; provided, however, any dispute between Customer and User shall be subject to the arbitration provisions of Article 13 as if Customer were the Contractor.

(b)The Parties agree that any owner of User Data shall be a third party beneficiary under Section 7.6 of this Agreement with respect to the misuse of such owner’s User Data by User hereunder.  Such owner shall have the right to enforce such provisions in its own name.  Any dispute between the owner of User Data and User regarding misuse of the such User Data, however, shall not be subject to the arbitration provisions of Article 13.

(c)Except as provided in Section 18.3(a) and (b) with respect to Customer, the Parties do not intend to create or vest any rights in any Third Parties, other than Customer.

18.4Compliance with Laws

Contractor and all persons furnished by Contractor shall comply at their own expense with all applicable federal, state, local and foreign laws, ordinances, regulations and codes, including identification and procurement of required permits, certificates, licenses, insurance, approvals and inspections in performance under this Agreement.  Contractor agrees to indemnify the User for any loss or damage that may be sustained by reason of any failure to do so.

18.5Severability

If any provision of this Agreement shall be held invalid or unenforceable, such provision shall be deemed deleted from the Agreement and replaced by a valid and enforceable provision which so far as possible achieves the Parties’ intent in agreeing to the original provision.  The remaining provisions of the Agreement shall continue in full force and effect.

18.6Survival

All obligations that by their nature survive the expiration or termination of this Agreement, including, but not limited to, Article 9 - Confidential Information, Section 11.1, Article 12 - Indemnification, Article 13 - Arbitration and Article 16 - No Customer Liability, shall remain in effect after its expiration or termination until such obligations expire according to their respective terms.

18.7No Releases Required

Neither Party shall require waivers or releases of any personal rights from representatives of the other in connection with visits to its premises and both Parties agree that no such releases or waivers shall be pleaded by them or third persons in any action or proceeding.

18.8Advertising or Publicity

Neither Party shall identify, either expressly or by implication, the other Party or its corporate affiliates or use any of their names, trade names, service marks, or other proprietary marks in any advertising, sales presentations, news releases, releases to any professional or trade publication, advertising, or other promotional materials without such other Party’s prior written consent, which shall not be unreasonably withheld or delayed, or for any other purpose.

18.9Governing Law

This Agreement, including all matters relating to the validity, construction, performance and enforcement thereof, shall be governed by the laws of the State of New York without giving reference to its principles of conflicts of law.

18.10Attorney’s Fees

The Party substantially prevailing in any legal action between the Parties concerning this Agreement shall receive reimbursement of its reasonable attorney’s fees and court costs incurred by the other Party.

ARTICLE 19 - ENTIRE AGREEMENT

This Agreement, together with the Master Contract, sets forth the entire understanding between the Parties with regard to the subject matter hereof and supersedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.  This Agreement may not be amended except by the mutual written agreement of the Parties, and the written consent of Customer

IN WITNESS WHEREOF, the Parties have caused this Agreement to be executed by their duly authorized representatives effective as of the Effective Date.

USER MARTIN IMS	LOCKHEED
By:	By:
Name:	Name:
Title:	Title:
Date:	Date:

ATTACHMENT A

Application for Services

[Copy of User’s Application for Services to be attached]

ATTACHMENT B

Master Contract for Services

[Copy of Master Contract for Services

is supplied contemporaneous with providing User this User Agreement]

ATTACHMENT C

Test Schedule for User Certified System

[Copy of Test Schedule pursuant to Sections 6.3 and 7.3(b) to be attached]

ATTACHMENT D

Key Personnel

1.INTRODUCTION

This Attachment identifies the current representatives of the companies.

2.CONTRACTOR

The following is the current Project Executive for Contractor:

Name:

Phone:

3.USER

The following is the current Project Representative for User:

Name:

Phone:

4.CUSTOMER

The following is the current Project Executive for Customer:

Name:

Phone:

EXHIBIT  K

EXTERNAL DESIGN

NPAC/SMS SERVICES

[Due to its length, this document is not attached.
The Response to the RFP is available on the internet at
http://www.npac.com/secure/docs/SPExtDesignV1_4.doc
A copy is also

available upon request for the cost of copying and handling from

NECAC, by request made to the attention of Carville Collins]

[Information referred to in this exhibit immediately follows this page.]

[Graphic Omitted: Title graphic]

NPAC SMS External

Design Specification

(SP Version)

Document Version 1.4

Covering NPAC Software Releases 1.0 and 1.1

September 19, 1997

Prepared by:

[Graphic Omitted:  Evolving Systems Logo]

Copyright © 1997 Lockheed Martin IMS Corporation.

This document contains information that is proprietary to Lockheed Martin IMS Corporation and Evolving Systems, Inc. Unauthorized reproduction or disclosure of this information in whole or in part is prohibited. Limit distribution accordingly.

Evolving Systems makes no representation as to the completeness, quality, or accuracy of this document.

Contents

Contents

[Graphic Omitted: Title Graphic]

NPAC SMS Error Messages

Table 1, “NPAC SMS Error Messages,” contains a full listing (arranged in numericalorder) of the error messages potentially returned to a user while interacting with the NPAC SMS. The

messages are divided into general functional ranges as shown below:

Message Range	Description
0000 - 0999	Run Time Environment Error Messages
1000 - 1499	Run Time Environment Warning Messages
1500 - 1999	Run Time Environment Informational Messages
2000 - 2499	GUI Error Messages
2500 - 2749	GUI Warning Messages
2750 - 2999	GUI Informational Messages
3000 - 3499	System Administration Error Messages
3500 - 3749	System Administration Warning Messages
3750 - 3999	System Administration Informational Messages
4000 - 4499	Security Administration Error Messages
4500 - 4749	Security Administration Warning Messages
4750 - 4999	Security Administration Informational Messages
5000 - 5499	Network Data Management Error Messages
5500 - 5749	Network Data Management Warning Messages
5750 - 5999	Network Data Management Informational Messages
6000 - 6499	NPAC Customer Management Error Messages
6500 - 6749	NPAC Customer Management Warning Messages
6750 - 6999	NPAC Customer Management Informational Messages
7000 - 7499	Subscription Version Management Error Messages
7500 - 7749	Subscription Version Management Warning Messages
7750 - 7999	Subscription Version Management Informational Messages
9000 - 9499	Audit Administration Error Messages
9500 - 9749	Audit Administration Warning Messages
9750 - 9999	Audit Administration Informational Messages
10000 - 10499	Report Administration Error Messages
10500 - 10749	Report Administration Warning Messages
10750 - 10999	Report Administration Informational Messages
11000 - 11499	Service Element Usage Management Error Messages
11500 - 11749	Service Element Usage Management Warning Messages
11750 - 11999	Service Element Usage Management Informational Messages
12000 - 12099	Database Error Messages
Note: For a listing of all CMIP errors, please see the NANC Interoperable Interface Specification.

Table 1 NPAC SMSError Messages

Error Number	Functional Area	Message Text
101	Run Time Environment	APE Error 101
102	Run Time Environment	APE Error 102
103	Run Time Environment	APE Error 103
200	Run Time Environment	Timer expected event that was missing, timer will be removed
201	Run Time Environment	Timer could not post event to queue due to database error
202	Run Time Environment	System call failed, PLEASE specify call in additional text.
203	Run Time Environment	operator new failed
204	Run Time Environment	Exception w/descriptive text thrown
205	Run Time Environment	Unknown Exception
206	Run Time Environment	Unable to access CurrentEvent
207	Run Time Environment	Unable to access Events Manager
208	Run Time Environment	Could not open a directory
209	Run Time Environment	Event retry limit reached
210	Run Time Environment	Can’t open a file
211	Run Time Environment	Event failed, unknown reason
212	Run Time Environment	Event failed, loaded with unknown reason
2000		Required data for TN field(s) missing.
2001		Required due date entry missing from the subscription version.
2002		Required Customer Disconnect Date missing from the subscription version.
2003		Required New Service Provider ID missing from the subscription version.
2004		Required Old Service Provider ID missing from the subscription version.
2005		Required LRN missing.
2006		Required CLASS DPC missing.

Error Number	Functional Area	Message Text
2007		Required CLASS SSN missing.
2008		Required CNAM DPC missing.
2009		Required CNAM SSN missing.
2010		Required ISVM DPC missing.
2011		Required ISVM SSN missing.
2012		Required LIDB DPC missing.
2013		Required LIDB SSN missing.
2014		Required value for Date is missing from Network Data.
2015		Required value for Time is missing from Network Data.
2016		Required value for NPAC Customer Name is missing.
2017		Required value for NPAC Customer Id is missing.
2018		Required value for Transmission Media is missing from Network Data.
2019		Required value for NPAC Customer Type is missing from NPAC Customer.
2020		Required value for Allowable Functions is missing from NPAC Customer.
2021		Required value for Download is missing from NPAC Customer.
2022		Required value for Maximum Query is missing from NPAC Customer.
2023		Required value for Contact Name is missing from NPAC Customer.
2024		Required value for Address Line 1 is missing from NPAC Customer.
2025		Required value for NPAC Customer City is missing from NPAC Customer.
2026		Required value for Repair Center City is missing from NPAC Customer.
2027		Required value for NPAC Customer State is missing from NPAC Customer.
2028		Required value for Repair Center State is missing from NPAC Customer.
2029		Required value for NPAC Customer Zip Code is missing from NPAC Customer.
2030		Required value for Repair Center Zip Code is missing from NPAC Customer.
2031		Required value for Pager is missing from NPAC Customer.
2032		Required value for Pager PIN is missing from NPAC Customer.
2033		Required value for Fax is missing from NPAC Customer.
2034		Required value for Email is missing from NPAC Customer.
2035		Required value for NSAP is missing from NPAC Customer.
2036		Required value for TSAP is missing from NPAC Customer.
2037		Required value for SSAP is missing from NPAC Customer.
2038		Required value for PSAP is missing from NPAC Customer.
2039		Required value for IP is missing from NPAC Customer.

Error Number	Functional Area	Message Text
2040		Invalid value for CLASS DPC entered.
2041		Invalid value for CLASS SSN entered.
2042		Invalid value for CNAM DPC entered.
2043		Invalid value for CNAM SSN entered.
2044		Invalid value for ISVM DPC entered.
2045		Invalid value for ISVM SSN entered.
2046		Invalid value for LIDB DPC entered.
2047		Invalid value for LIDB SSN entered.
2048		TN NPA contains invalid data.
2049		TN NXX contains invalid data.
2050		TN extension field contains invalid data.
2051		Month field contains invalid data.
2052		Day field contains invalid data.
2053		Year field contains invalid data.
2054		TN range ‘through’ field (ending extension value) contains invalid data.
2055		The entered due date must be greater than or equal to today’s date.
2056		Billing Service Provider ID contains invalid data.
2057		End-User Location Value contains invalid data.
2058		End-User Location Type contains invalid data.
2059		Invalid value for Time entered.
2060		Invalid value for NPAC Customer Name entered.
2061		Invalid value for NPAC Customer Id entered.
2062		Invalid value for LRN entered.
2063		Invalid value for Transmission Media entered.
2064		Invalid value for NPAC Customer Type entered.
2065		Invalid value for Allowable Functions entered.
2066		Invalid value for Download entered.
2067		Invalid value for Maximum Query entered.
2068		Invalid value for Contact Name entered.
2069		Invalid value for Address Line 1 entered.
2070		Invalid value for Address Line 2 entered.
2071		Invalid value for City entered.
2072		Invalid value for State entered.

Error Number	Functional Area	Message Text
2073		Invalid value for Zip Code entered.
2074		Invalid value for Pager entered.
2075		Invalid value for Pager PIN entered.
2076		Invalid value for Fax entered.
2077		Invalid value for Email entered.
2078		Invalid value for NSAP entered.
2079		Invalid value for TSAP entered.
2080		Invalid value for SSAP entered.
2081		Invalid value for PSAP entered.
2082		Invalid value for IP entered.
2083		Identical values must be entered into both PASSWORD fields.
2084		Password field must be non-null.
2085		Password must consist of at least 6 case-sensitive alphanumeric characters including at least 1 alphabetic and 1 numeric or punctuation character.
2086		Password may not contain the associated userid.
2087	GUI Messages	Input attribute not recognized
2088	GUI Messages	Required value for contact type is missing from NPAC Customer.
2089	GUI Messages	Required data for TN field(s) missing from contact list
3000		Value entered for system tunable is out of range.
3001		You entered an invalid logon name or password.
3002		The User Group and User Level have conflicting access levels.
3003		Non-unique userid was entered for this user.
3004		Your password has expired.
3005		The password entered was not acceptable
3006	System Administration	System was unable to add user
3007	System Administration	Not all user data needed was provided
3008	System Administration	Operation referenced a user that does not exist.
3009	System Administration	Update of a tunable failed.
3010	System Administration	Unable to load holiday collection from DB.
3011	System Administration	Unable to add a holiday to the collection
3012	System Administration	Unable to delete a holiday from the collection
3013	System Administration	Unable to find a holiday in the collection
3014	System Administration	Event has incorrect subtype

Error Number	Functional Area	Message Text
3500		Password will expire in <x> days.
3501		The user about to be deleted is currently logged on to the system.
3502		This action will affect the entire NPAC SMS.
3503		Your password has expired. NOTE - duplicate with 3004
3504	System Administration	The NPAC is not accepting logins at this time
4000		Key List creation failure.
4001		Mismatch of hash values for key in key list.
4002		Failure calculating checksum for key list.
4003		No keys available for this NPAC Customer in any active key list.
4004		Non-unique keys found in key list.
4005		No active key list available for this NPAC Customer.
4006		Invalid Key File Format.
4007		Key List generation is already in progress.
4008	Security Administration	Key List generation is already in progress.
4009	Security Administration	Missing required data in key management event
4010	Security Administration	Key File event failed to process correctly
4011	Security Administration	New key specified by service provider is not usable
4500		There are fewer than 100 keys remaining for this Service Provider.
4750		No match found in the database for the search criteria.
5000		Item being added already exists in the database.
5001	Network Data Management	One or more subscriptions will be affected by change. Change is denied.
5002	Network Data Management	One or more LRNs will be affected by change. Change/Delete is denied.
5003	Network Data Management	One or more NPA-NXXs will be affected by change. Change/Delete is denied.
5004		Subscriptions in either partial failed or sending state are associated with the change. Change/Delete is denied.
5005		GTT data is not equivalent across TN range specified. Modify the TN range.
5006	Network Data Management	Bulk Download - invalid criteria specified
5007	Network Data Management	Bulk Download - file error
5008	Network Data Management	Resync Data - invalid criteria specified
5009	Network Data Management	LrnId is required if no customer id, on delete lrn action.
5010	Network Data Management	The LRN to be deleted does not exist in the NPAC SMS system.
5011	Network Data Management	No network data match for search criteria in database.
5012	Network Data Management	Requestor doesnt own item being deleted.

Error Number	Functional Area	Message Text
5014	Network Data Management	Resync Data - Maximum records reached or exceeded.
5015	Network Data Management	Npa required for delete if no NpaNxxId.
5016	Network Data Management	Nxx required for delete if no NpaNxxId.
5017	Network Data Management	Lrn required for delete if no lrnId.
5018	Network Data Management	NpaNxx Accepted - invalid or missing npa
5019	Network Data Management	NpaNxx Accepted - invalid or missing nxx
5020	Network Data Management	NpaNxx Accepted - invalid or missing customer id
5021	Network Data Management	NpaNxx Accepted - invalid or missing accepted id
5022	Network Data Management	CustomerId and name passed in do not match those in database.
5023	Network Data Management	Starting npa/nxx doesnt exist in database.
5024	Network Data Management	Ending npa/nxx doesnt exist in database.
5025	Network Data Management	Starting npa/nxx doesnt have sub.
5026	Network Data Management	Ending npa/nxx doesnt have sub.
5027	Network Data Management	Npa required for npa split.
5028	Network Data Management	New Npa required for npa split.
5029	Network Data Management	Starting Nxx required for npa split.
5030	Network Data Management	Ending Nxx required for npa split.
5031	Network Data Management	PDP Start required for npa split.
5032	Network Data Management	PDP End required for npa split.
5033	Network Data Management	Resync Type required for resync.
5034	Network Data Management	Resync Start TS required for resync.
5035	Network Data Management	Npa required for resync of type npa range.
5036	Network Data Management	Ending Npa required for resync of type npa range.
5037	Network Data Management	Nxx required for resync of type npa range.
5038	Network Data Management	Ending Nxx required for resync of type npa range.
5039	Network Data Management	Lrn required for resync of type lrn range.
5040	Network Data Management	End Lrn required for resync of type lrn range.
5041	Network Data Management	No NpaNxx is available from the NPANXX::SelectRandom() method.
5042	Network Data Management	Request failed on previous npaNxx.
5043	Network Data Management	Request failed on previous lrn.
5044	Network Data Management	There are no npanxx’s in the specified range
5045	Network Data Management	Supplied customer id does not match any npanxx’s in range

Error Number	Functional Area	Message Text
5500		One or more subscriptions will be affected by change. Require user acknowledgment to proceed.
6000		Item being added already exists in the database.
6001		One or more subscriptions will be affected by change. Change is denied.
6002	NPAC Customer Management	One or more npa-nxxs are associated with this customer, Delete is denied.
6003	NPAC Customer Management	One or more lrns are associated with this customer, Delete is denied.
6004		Management
6005		The NPAC Customer being modified does not exist in the database.
6006		The NPAC Customer being deleted does not exist in the database, or has already been deleted.
6007	NPAC Customer Management	Invalid contact type for NPAC Customer
6008	NPAC Customer Management	The contact info array is missing from the Customer.
6009	NPAC Customer Management	The network address list array is missing from the Customer.
6010	NPAC Customer Management	The network address type is missing from the Customer.
6011	NPAC Customer Management	The npac customer contact is missing from the Customer.
6012	NPAC Customer Management	The billing contact is missing from the Customer.
6013	NPAC Customer Management	The security contact is missing from the Customer.
6014	NPAC Customer Management	The repair contact is missing from the Customer.
6015	NPAC Customer Management	At least one network address is required for Customer.
6016	NPAC Customer Management	Required value for Contact Name is missing from Billing Contact.
6017	NPAC Customer Management	Required value for Address Line 1 is missing from Billing Contact.
6018	NPAC Customer Management	Required value for NPAC Customer City is missing from Billing Contact.
6019	NPAC Customer Management	Required value for NPAC Customer State is missing from Billing Contact.
6020	NPAC Customer Management	Required value for NPAC Customer Zip Code is missing from Billing Contact.
6021	NPAC Customer Management	Required value for Contact Name is missing from Repair Contact.
6022	NPAC Customer Management	Required value for Address Line 1 is missing from Repair Contact.
6023	NPAC Customer Management	Required value for Contact Name is missing from Security Contact.
6024	NPAC Customer Management	Required value for Address Line 1 is missing from Security Contact.
6025	NPAC Customer Management	Required value for NPAC Customer City is missing from Security Contact.
6026	NPAC Customer Management	Required value for NPAC Customer State is missing from Security Contact.
6027	NPAC Customer Management	Required value for NPAC Customer Zip Code is missing from Security Contact.
6028	NPAC Customer Management	Event subtype not reqcognized
6029	NPAC Customer Management	Invalid operation for this NPAC Customer
6030	NPAC Customer Management	SP User cannot modify Customer Name on modify.

Error Number	Functional Area	Message Text
6031	NPAC Customer Management	SP User cannot modify allowable functions mask on modify.
6032	NPAC Customer Management	Required value for country is missing from contact data.
6500		One or more subscriptions will be affected by change. Require user acknowledgment to proceed.
6750		No match found in the database for the search criteria.
6751		<x> Subscriptions found: exceed maximum query limit.
6752		No subscription versions found for the given input search criteria.
7000		The NPA-NXX of the TN to be ported does not exist in the NPAC SMS system.
7001		Service Provider ID does not exist in the NPAC SMS system.
7002		The Service Provider issuing this subscription version request is not the Service Provider identified as the New Service Provider ID or the Old Service Provider ID on the subscription version
7003		This Service Provider has already issued a create for the subscription version.
7004		The entered LRN is not associated with the New Service Provider in the NPAC SMS system.
7005		The Old Service Provider ID in the subscription version does not match the current Service Provider ID on an existing active subscription version for this TN.
7006		The New Service Provider ID input data does not match the new Service Provider ID in an existing pending subscription version for this TN.
7007		The Old Service Provider ID input data does not match the new Service Provider ID in an existing pending subscription version for this TN.
7008		Releasing a subscription version for an Intra-Service Provider port does not apply.
7009		The Old Service Provider ID must match the New Service Provider ID for an Intra-Service Port.
7010		The New and Old Service Provider Due Dates must match.
7011		An active subscription version must exist for an Intra-SP port.
7012		A subscription version with sending status cannot be modified.
7013		A subscription version with failed status cannot be modified.
7014		A subscription version with partial failure status cannot be modified.
7015		A subscription version with canceled status cannot be modified.
7016		A subscription version with old status cannot be modified.
7017		A subscription version with disconnect pending status cannot be modified.
7018		A subscription version with cancel pending status cannot be modified.
7019		A subscription version must be in pending status to be activated.
7020		The Old Service Provider ID is not equal to the New Service Provider ID on the active subscription version, as required for an Intra-Service Provider port.

Error Number	Functional Area	Message Text
7021		The Service Provider originating the modification request is not the current Service Provider.
7022		The subscription version cannot be put in conflict because its current status is not pending, or cancel pending.
7023		The subscription version cannot be disconnected because there is no current subscription version in active status.
7024		This active subscription version cannot be disconnected until a sending subscription version successfully completes.
7025		This active subscription version cannot be disconnected until a failed or partial failure subscription version is re-sent and successfully completes.
7026		The subscription version cannot be canceled because its current status is not pending, conflict or disconnect pending.
7027		The subscription version cannot be resent because its current status is not partial failure, failure, disconnect pending, old or active.
7028		Active subscription version may not be modified because a related subscription version for this TN has been activated.
7029		Pending subscription version may not be activated until a related subscription version in sending status becomes active.
7030		Deferred disconnect request is not allowed because a pending subscription version exists for this TN.
7031		This subscription version may not be activated because authorization for transfer of service has not been received from the New SP.
7032		The due date of a subscription version with active status cannot be modified.
7033	Subscription Version Management	Porting To Original must be false for inter-service ports.
7034	Subscription Version Management	Required Port Type is missing from input data.
7035	Subscription Version Management	Required TN data (NPA) is missing from input data.
7036	Subscription Version Management	Required TN data (NXX) is missing from input data.
7037	Subscription Version Management	Required TN data (starting station) is missing from input data.
7038	Subscription Version Management	Required TN data (ending station) is missing from input data.
7039	Subscription Version Management	Required Old Service Provider Authorization Flag missing from the subscription version.
7040	Subscription Version Management	Required Porting To Original Flag is missing from input data.
7041	Subscription Version Management	NPAC SMS allows only one of pending, cancel pending, conflict, disconnect pending, failed or parital failure Subscription Version per subscription.

Error Number	Functional Area	Message Text
7042	Subscription Version Management	Porting To Original Flag is not allowed for Intra-Service Provider ports.
7043	Subscription Version Management	LIDB SSN is not allowed for Porting-to-Original ports.
7044	Subscription Version Management	LIDB SSN is not allowed for old service provider input.
7045	Subscription Version Management	LIDB DPC is not allowed for old service provider input.
7046	Subscription Version Management	LIDB DPC is not allowed for Porting-to-Original ports.
7047	Subscription Version Management	ISVM SSN is not allowed for Porting-to-Original ports.
7048	Subscription Version Management	ISVM SSN is not allowed for old service provider input.
7049	Subscription Version Management	ISVM DPC is not allowed for old service provider input.
7050	Subscription Version Management	ISVM DPC is not allowed for Porting-to-Original ports.
7051	Subscription Version Management	CNAM SSN is not allowed for Porting-to-Original ports.
7052	Subscription Version Management	CNAM SSN is not allowed for old service provider input.
7053	Subscription Version Management	CNAM DPC is not allowed for old service provider input.
7054	Subscription Version Management	CNAM DPC is not allowed for Porting-to-Original ports.
7055	Subscription Version Management	CLASS SSN is not allowed for Porting-to-Original ports.
7056	Subscription Version Management	CLASS SSN is not allowed for old service provider input.
7057	Subscription Version Management	CLASS DPC is not allowed for old service provider input.
7058	Subscription Version Management	CLASS DPC is not allowed for Porting-to-Original ports.
7059	Subscription Version Management	LRN is not allowed for Porting-to-Original ports.
7060	Subscription Version Management	LRN is not allowed for old service provider input.
7061	Subscription Version Management	New Service Provider due date is not allowed for Old Service Provider input.
7062	Subscription Version Management	Old Service Provider due date is not allowed for New Service Provider input.

Error Number	Functional Area	Message Text
7063	Subscription Version Management	Old Service Provider Authorization Flag is not allowed for New Service Provider input.
7064	Subscription Version Management	Old Service Provider Authorization Flag is not allowed for Intra-Service Ports.
7065	Subscription Version Management	Billing Service Provider ID is not allowed for Old Service Provder input.
7066	Subscription Version Management	End User Location is not allowed for Old Service Provder input.
7067	Subscription Version Management	End User Location Type is not allowed for Old Service Provder input.
7068	Subscription Version Management	Either the Ported Telephone Number or the Subscription Version ID is required to activate a subscription version.
7069	Subscription Version Management	The Old Service Provider cannot modify an intra-service port.
7070	Subscription Version Management	Only the Current Service Provider can disconnect a subscription version.
7071	Subscription Version Management	The subscription version cannot be disconnected until a pending subscription version is canceled.
7072	Subscription Version Management	The subscription version cannot be put in conflict resolution because its current status is not conflict.
7073	Subscription Version Management	Only the Current Service Provider can activate a subscription version.
7074	Subscription Version Management	A pending subscription version cannot be activated before its npa_nxx’s effective date.
7075	Subscription Version Management	NPAC SMS allows only one sending Subscription Version per subscription.
7076	Subscription Version Management	NPAC SMS allows only one active Subscription Version per subscription.
7077	Subscription Version Management	Request failed on previous subscription version.
7078	Subscription Version Management	Required subscription version ID is missing from input data.
7079	Subscription Version Management	Required TimerId is missing from input data.
7080	Subscription Version Management	Required ConflictDate is missing from input data.
7081	Subscription Version Management	Required PendingDate is missing from input data.
7082	Subscription Version Management	The Service Provider requesting this cancel did not create the subscription version.
7083	Subscription Version Management	There is no subscription version with the requested status.

Error Number	Functional Area	Message Text
7084	Subscription Version Management	The subscription version status is required to modify a subscription version.
7085	Subscription Version Management	The action ID field is required for LsmsSvNotifyResponseEvent event type.
7086	Subscription Version Management	The old service provider cannot request conflict resolution.
7087	Subscription Version Management	Mass Update requires at least one of the following as input: LRN, a gtt data item, billing id, end user location, end user location type.
7088	Subscription Version Management	Active subscription versions cannot be modified via CMIP set.
7089	Subscription Version Management	The Old Service Provider has already put this subscription version into conflict the maximum number of times.
7090	Subscription Version Management	It is too close to the New Service Provider due date for the Old Service Provider to place the subscription version into conflict.
7091	Subscription Version Management	This subscription version may not be activated because the Old Service Provider’s concurrence window has not yet expired.
7092	Subscription Version Management	Required originating SPID is missing from input data.
7093	Subscription Version Management	SV - Notification SV_MODIFIED missing response.
7094	Subscription Version Management	Either the Ported Telephone Number or the Subscription Version ID is required to modify a subscription version.
7095	Subscription Version Management	Required Resync Type is missing from input data.
7096	Subscription Version Management	Required Resync Start Timestamp is missing from input data.
7097	Subscription Version Management	Either the Ported Telephone Number or the Subscription Version ID is required to cancel a subscription version.
7098	Subscription Version Management	Either the Ported Telephone Number or the Subscription Version ID is required to resolve a conflicted subscription version.
7099	Subscription Version Management	Either the Ported Telephone Number or the Subscription Version ID is required to disconnect a subscription version.
7100	Subscription Version Management	Either the Ported Telephone Number or the Subscription Version ID is required to create a subscription version.
7101	Subscription Version Management	The NPA-NXX of the TN has been split. The entered TN is the old NPA-NXX.
7102	Subscription Version Management	Either the subscription version ID or TN is required for concurrence.
7103	Subscription Version Management	A TN range is not allowed for concurrence.
7104	Subscription Version Management	The Status Change Cause Code is required if the authorization flag is false.

Error Number	Functional Area	Message Text
7105	Subscription Version Management	The Status Change Cause Code cannot be set if the authorization flag is true.
7106	Subscription Version Management	The Status Change Cause Code cannot be set if the new service provider is the originator.
7107	Subscription Version Management	Invalid Status Change Cause Code.
7108	Subscription Version Management	A pending subscription version cannot be activated before its due date.
7109	Subscription Version Management	The Old Service Provider cannot cancel this subscription version which is in conflict because the New Service Provider did not concur with a prior cancellation.
7110	Subscription Version Management	The New Service Provider cannot resolve this conflict until the tunable period of time has passed since the Old Service Provider moved it into conflict.
7111	Subscription Version Management	Porting To Original Flag is not allowed for old service provider input.
7112	Subscription Version Management	At least one of the following is required as input for subscription version modification: LRN, a gtt data item, billing id, end user location, end user location type.
7113	Subscription Version Management	LSMS did not respond in allotted time.
7114	Subscription Version Management	Missing SV Tunable value.
7115	Subscription Version Management	The Status Change Cause Code is required if the old service provider is the originator.
7116	Subscription Version Management	The subscription version cannot be resent because it does not have a failed LSMS list.
7117	Subscription Version Management	Either the due date or the authorization flag is required to modify a subscription version by the old Service Provider.
7118	Subscription Version Management	On a modify by new/current Service Provider, one of the GTT input data fields, lrn, billing data, or due date is required.
7119	Subscription Version Management	A Disconnect request for an active subscription version for this TN previously failed. This failure must be resolved before a create is allowed.
7120	Subscription Version Management	The LNP Type input in the event does not match the LNP type of a pending SV for this TN.
7121	Subscription Version Management	A subscription version with cancel pending status exists. A new one cannot be created for this TN.
7122	Subscription Version Management	A pending subscription version for the TN exists.
7123	Subscription Version Management	A subscription version with disconnect pending status exists. A new one cannot be created for this TN.
7124	Subscription Version Management	The old authorization flag of a subscription version with active status cannot be modified.
7125	Subscription Version Management	The change cause code of a subscription version with active status cannot be modified.

Error Number	Functional Area	Message Text
7126	Subscription Version Management	A Failed subscription version for the TN exists. This failure must be resolved before a modify is allowed.
7127	Subscription Version Management	There is no subscription version matching the query filter data.
7128	Subscription Version Management	The Service Provider requesting this modify did not create the subscription version.
7129	Subscription Version Management	The Ending Station must be a number greater than the Starting Station.
7130	Subscription Version Management	The LNP Type must be either LISP or LSPP.
7131	Subscription Version Management	The Old Service Provider cannot cancel a disconnect pending subscription version.
7132	Subscription Version Management	A subscription version with sending status exists. A new one cannot be created for this TN.
7133	Subscription Version Management	The Service Provider requesting this conflict did not create the subscription version.
7134	Subscription Version Management	Waiting on New SP concurrence. The Service Provider issuing this cancel already cancelled the subscription version.
7135	Subscription Version Management	Waiting on Old SP concurrence. The Service Provider issuing this cancel already cancelled the subscription version.
7136	Subscription Version Management	There must be an active SV for a porting to original port.
7137	Subscription Version Management	The requested subscription version does not exist.
7138	Subscription Version Management	A subscription version with pending status exists. A new one cannot be created for this TN.
7139	Subscription Version Management	The Service Provider requesting this conflict resolution did not create the subscription version.
7140	Subscription Version Management	The Old Service Provider ID must not match the New Service Provider ID for an Inter-Service Port.
7141	Subscription Version Management	Subscription version must be in cancel pending state for concurrence.
7500		The entered due date differs from the due date entered by the other Service Provider.
7750		No subscription versions found for the given input search criteria.
7751		Subscriptions found exceed maximum query limit.
7752	Subscription Version Management	Subscription version must be in pending or conflict state for create timeout.
7753	Subscription Version Management	Subscription version must be in cancel pending state for cancel timeout.
7800	Subscription Version Management	The old customer id on the create does not match the owner of the associated npanxx.

Error Number	Functional Area	Message Text
9000		Invalid date entered.
9001		Invalid time entered.
9002		Audit Profile name too long.
9003		Invalid TN data entered.
9004		Audit Profile name is not unique.
9005	Audit Administration	No audits match the entered criteria.
9006	Audit Administration	Could not cancel specified Audit(s)
9007	Audit Administration	Audit validation failed.
9008	Audit Administration	No SPs to audit.
9009	Audit Administration	Need required event input data
9010	Audit Administration	Failed to generate a unique name for a periodic audit.
9011	Audit Administration	Failed to generate a discrepancy for an SV mismatch.
9012	Audit Administration	Failed to issue query events.
9013	Audit Administration	Starting Station > Ending Station Error
9014	Audit Administration	CMIP bounced, which killed our query.
9015	Audit Administration	We can’t use input data that conflicts with itself
9016	Audit Administration	Failed to issue SP Notification events.
9017	Audit Administration	Failed to retrieve allowable function mask
9018	Audit Administration	Event Process failed
9019	Audit Administration	Discrepancy created with invalid reason code.
9500		NPA does not exist in the NPAC SMS data.
9501		NPA-NXX combination does not exist in the NPAC SMS data.
9750		No TNs found within the range entered.
9751		No results have yet been reported for the selected audit.
10000		Invalid NPA data entered.
10001		Invalid NXX data entered.
10002		Invalid LRN data entered.
10003		Invalid range for NXXs (second must be greater than first).
10004		Invalid range for LRNs (second must be greater than first).
10005		Invalid printer name entered.
10006		Too many characters entered in printer field.
10007		Invalid TN entered in fax field.
10008		Too many characters entered in file name field.

Error Number	Functional Area	Message Text
10009		Invalid file name entered.
10010		No generated file name entered.
10011		No destination designated for report.
10012		Invalid date entered.
10013		Invalid parameters detected in Report Parameters.
10014		End date occurs before the start date.
10015		Requester does not have privileges to generate this report.
10016		Event missing customer ID
10017	Report Administration	No existing report or incorrect permissions
10018	Report Administration	Failure scanning existing report directory
10019	Report Administration	Failure opening existing report directory
10020	Report Administration	Failure retrieving originator information
10021	Report Administration	Failure printing report file
10022	Report Administration	Failure emailing report file
10023	Report Administration	Failure faxing report file
10024	Report Administration	Failure moving report file
10025	Report Administration	Failure renaming report file
10026	Report Administration	Failure running report
10750		No billing data exists for the entered criteria.
11000		Invalid date entered.
11001		Invalid printer name entered.
11002		Too many characters entered in printer field.
11003		Invalid TN entered in fax field.
11004		Too many characters entered in file name field.
11005		End date occurs before the start date.
11006		You cannot post-date service element collection changes.
11007		Invalid file name entered.
11008		Incomplete Request Parameter Set.
11009	Service Element Usage Management	Invalid category for billing
11010	Service Element Usage Management	Invalid Multiplier Specified.
11011	Service Element Usage Management	Unable To Read Multiplier.

Error Number	Functional Area	Message Text
11500		Unable to connect to entered fax number.
12000		Oracle RDBMS has reported the following Database Server Error: ORA-nnnnn
12001		Oracle RDBMS has reported the following SQL Execution Error: ORA-nnnnn
12002		Oracle RDBMS has reported the following Stored Procedure/Trigger Error: ORAnnnnn
12003		Oracle RDBMS has reported the following Database Networking (SQL*NET) Error: ORA-nnnnn
12004		Oracle RDBMS has reported the following Replication Server Error ORA-nnnnn
12005		Oracle RDBMS has reported the following Report Writer Error: ORA-nnnnn
12006	Database	Oracle RDBMS database has been disconnected.
13000	Housekeeping	Housekeeping error
13001	Housekeeping	Housekeeping tuna value error
13002	Housekeeping	Invalid event subtype
13003	Housekeeping	Tunable Not Found
13004	Housekeeping	InvalidPurgeAction
14000		No Desc
14001		No Desc
14002		No Desc
14003		No Desc
14004		No Desc
14005		No Desc
14006		No Desc
14007		No Desc
14008		No Desc
14009		No Desc
14010		No Desc
14011		No Desc
14012		No Desc
14013		No Desc
14014		No Desc
14015		No Desc
14016	CMIP	CMIP process restarted
14017		No Desc
14018		No Desc

Error Number	Functional Area	Message Text
14019		No Desc
14020		No Desc
14021		No Desc
14022		No Desc
14023		No Desc
14024		No Desc
14025		No Desc
14026		No Desc
14027		No Desc
14028		No Desc
14029		No Desc
14030		No Desc
14031		No Desc
14032		No Desc
14033		No Desc
14034		No Desc

[Graphic Omitted:  Title graphic – Terms and Acronyms]

Terms and
Acronyms

Following are the acronyms associated with the NPAC SMS.

Term	Definition
APDU	Application Protocol Data Unit
ASN.1	Abstract Syntax Notation 1
BER	Basic Encoding Rules
CARE	Customer Account Record Exchange
CER	Canonical Encoding Rules
CLASS	Custom Local Area Signaling Services.
CME	Conformance Management Entity
CMIP	Common Management Information Protocol
CMISE	Common Management Information Service Element
CNAM	Caller Id with Name
DER	Distinguished Encoding Rules
DES	Data Encryption Standard
DPC	Destination Point Code
FR	Frame Relay
FTP	File Transfer Protocol
GDMO	Generalized Definitions of Managed Objects
GMT	Greenwich Mean Time
GTT	Global Title Translation
GUI	Graphical User Interface
HTML	Hypertext Markup Language
ICC	Illinois Commerce Commission
IEC	International Electrotechnical Commission
IIS	Interoperable Interface Specification
IP	Internet Protocol
ISO	International Organization of Standardization
ISVM	Inter-Switch Voice Mail
KEK	Key Encryption Key
LIDB	Line Information Database
LISP	Local Intra-Service Provider Port
LNP	Local Number Portability
LRN	Location Routing Number
LSMS	Local Service Management System
LSPP	Local Service Provider Portability
MAC	Media Access Control
MD5	Message Digest (Version 5)
NANP	North American Numbering Plan.
NE	Network Element
NMF	Network Management Forum
NPA	Numbering Plan Area
NPAC	Number Portability Administration Center
NPAC SMS	Number Portability Administration Center and Service Management System

NSAP	Network Layer Service Access Point
NXX	Exchange
OCN	Operating Company Number
OSI	Open Systems Interconnect
OpGUI	Operational GUI
PIN	Personal Identification Number
PKCS	Public Key Crypto System
POP	Point-Of-Presence.
PPP	Point-To-Point Protocol
PSAP	Presentation Layer Service Access Point
RFP	Request for Proposal
RSA	Rivest, Shamir, and Adelman (encryption algorithm)
SCP	Service Control Point
SMS	Service Management System
SOA	Service Order Activation
SP	Service Provider
SPID	Service Provider ID
SSAP	Session Layer Service Access Point
SSN	Subsystem Number
STP	Signal Transfer Point.
SV	Subscription Version
TCAP	Transaction Capabilities Action Part.
TMN	Telecommunications Management Network
TN	Telephone Number
September 19, 1997	Lockheed Martin IMS Corporation Confidential	Page 22

TSAP Transport Layer Service Access Point WWW World Wide Web

[Graphic Omitted:  Title graphic – NPAC SMS Reports]

NPAC SMS Reports

This section contains samples of the reports that are produced by the NPAC SMS.

Note: Please note that all times are reported in GMT.  All reports are sorted in ascending order.

Note: All Activation Date or Activation Timestamp columns in the reports refer to the Activation Broadcast Complete Timestamp.

[Graphic Omitted:  Screen shot of sample audit summary report for NPAC SMS]

Figure 1 Audit Summary Report (NPAC and SP) Figure 2 Encryption Keys Report (NPAC Only) Figure 3 Error Log Report (NPAC Only) Figure 4 History Report (NPAC Only) Figure 5 LRN Report (NPAC and SP) Figure 6 Notification Log Report (NPAC Only) Figure 7 NPA Split Report (NPAC and SP) Figure 8 NPAC Customer Report (NPAC and SP)

[Graphics Omitted (Series of 7):  Screen shots of sample reports generated by NPAC SMS]

Note: SP versions of this report contain the requesting SP’s specific information only.

[Graphic Omitted:  Screen shot of sample report generated by NPAC SMS]

Figure 9 Open NPA-NXX Report (NPAC and SP)

[Graphics Omitted (Series of 16):  Screen shots of sample reports generated by NPAC SMS]

September 19, 1997 Lockheed Martin IMS Corporation Confidential Page 50

[Graphics Omitted (Series of 5):  Screen shots of sample reports generated by NPAC SMS]

07/23/1996 Downloads Performance Report Page 1 of 1

07:00

Report of average number of downloads for date/time range

From 07/22/1996 18:00 to 07/22/1996 19:30

SERVICE PROVIDER TELEPHONE NUMBERS

PER SECOND

Ameritech 25.1
	AT&T 23.1
	MCI Metro 22.1
	MFS 22.4
	Sprint 23.3
	TCG 26.3

Figure 31 System Statistics - Download Performance Report (NPAC Only)

07/22/1996 Transaction Performance Report Page 1 of 1

16:00

Report of average number of CMISE transactions for date/time range

From 07/22/1996 13:30 to 07/22/1996 15:30

  SERVICE PROVIDER CMISE TRANSACTIONS

	PER SECOND
Ameritech 25.1
	AT&T 23.1
	MCI Metro 22.1
	MFS 22.4
	Sprint 23.3
	TCG 26.5

Figure 32 System Statistics - Transaction Performance Report (NPAC Only)

[Graphics Omitted (Series of 6):  Screen shots of sample reports generated by NPAC SMS]

[Graphic Omitted:  Title graphic – Download File Examples]

Download File Examples

Subscription Download File

Note: All fields within files discussed in the following section are variable length.

The following table describes each field of the sample subscription download file. This download file example contains data for three subscriptions, with three lines for each subscription. Each subscription is one record in the file, pipe delimited, with a carriage return(CR) between each subscription. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.

Table 2 describes the entries for subscription 1: The “Value in Example” column directly correlates to the values for subscription 1 in the download file example, as seen in Figure 39.

The file name for the Subscriptions download file will be in the format:

NPANXX - NPANXX.DD-MM-YYYYHHMMSS

The Subscriptions file given in the example would be named:

303123-303125.13-10-1996081122

Note: The files available for LSMS compares will be defined as one NPA-NXX per file.

Table 2  Explanation of the Fields in the Subscription Download File

Field Number	Field Name	Value in Example
1	Version Id	0000000001
2	Version TN	3031231000
3	LRN	1234567890
4	New Current Service Provider Id	0001
5	Activation Timestamp	19960916152337 (yyyymmddhhmmss)
7	CLASS DPC	123456789
8	CLASS SSN	123
9	LIDB DPC	123456789
10	LIDB SSN	123
11	ISVM DPC	123456789
12	ISVM SSN	123
13	CNAM DPC	123456789
14	CNAM SSN	123
15	End user Location Value	123456789012
16	End User Location Type	12
17	Billing Id	0001
18	LNP Type	0
19	Download Reason	0

[Graphic Omitted:  Sample download file]

Network Download File

The following tables describe each field of the network download files.This series of download file examples contain data for one Service Provider that has three NPA-NXXs and three LRNs.

The Service Provider block contains one record in the file, individual fields are pipe delimited, with a carriage return(CR) after the Service Provider Id/Name.The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.

The “Value in Example” column in Table 2 directly correlates to the values for the Service Provider in the download file example, as seen in Figure 40.

The file name for the Service Provider download file will be in the format:

SPID.DD-MM-YYYYHHMMSS

The Service Provider file given in the example would be named:

SPID.13-10-1996081122

Table 3  Explanation of the Fields in the Network Service Provider Download File

Field Number	Field Name	Value in Example
1	Service Provider Id	0001
2	Service Provider Name	AMERITECH

0001|AMERITECH(CR)(Service Provider Id/Name)

Figure 40 Service Provider Download File Example

The NPA/NXX download block contains three records in the file, individual fields are pipe delimited, with a carriage return(CR) after each NPA-NXX record. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.

The “Value in Example” column in Table 2 directly correlates to the values for the first NPA/NXX in the download file example, as seen in Figure 41.

The file name for the NPA-NXX download file will be in the format:

NPANXX.DD-MM-YYYYHHMMSS

The NPA-NXX file given in the example would be named:

NPANXX.13-10-1996081122

Table 4  Explanation of the Fields in the Network NPA/NXX Download File

Field Number	Field Name	Value in Example
1	Service Provider Id	0001
2	NPA-NXX Id	2853
3	NPA-NXX Value	303-123
4	Creation TimeStamp	19960101155555
5	Effective TimeStamp	19960105000000
6	Download Reason	0

0001|2853|303-123|19960101155555|19960105000000|0|(NPA-NXX	1)
0001|2864|303-124|19960101155556|19960105000000|0|(NPA-NXX	2)
0001|2870|303-125|19960101155557|19960105000000|0(CR)(NPA-NXX	3)

Figure 41 NPA-NXX Download File Example

The LRN download block contains three records in the file, individual fields are pipe delimited, with a carriage return(CR) after each LRN record. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.

The “Value in Example” column in Table 2 directly correlates to the values for the first LRN in the download file example, as seen in Figure42.

The file name for the LRN download file will be in the format:

LRN.DD-MM-YYYYHHMMSS

The LRN file given in the example would be named:

LRN.13-10-1996081122

Table 5  Explanation of the Fields in the Network LRN Download File

Field Number	Field Name	Value in Example
1	Service Provider Id	0001
2	LRN Id	1624
3	LRN Value	1234567890
4	Creation TimeStamp	19960101155559
5	Download Reason	0

0001|1624|1234567890|19960101155559|0|(LRN 1)

0001|1633|1234567891|1996010115570010|0|(LRN 2)

0001|1650|1234567892|1996010115580505|0(CR)(LRN 3)

Figure 42 Network LRN Download FIle Example

[Graphic Omitted:  Title graphic – Encryption Key Exchange]

Encryption Key Exchange

The mechanized interface to NPAC SMS requires an exchange of the encryption keys used to verify digital signatures. This exchange will consist of a file containing the 1000 key list, and an acknowledgment of receipt of the list will consist of a file containing the MD5 checksum value of each key in the list. The formats for these files is described here.

Key Exchange File

The following table shows the format of the encryption key exchange file. This file consists of some header information, followed by 1000 instances of key information. There are no separators of any kind between the individual fields, between the header and key data, or between each set of key data.

Table 6  Encryption Key Exchange File Format

Field #	Field Name	Type	Size (bytes)	Format
1	NPAC Customer Id	ASCII	4	Character String
2	File Creation Date	ASCII	14	MMDDYYYYHHmmSS
3	List Id	Binary	2	16 bit integer
4	Key Size (in bits)	Binary	4	32 bit integer
5	Key Id	Binary	2	16 bit integer
6	public exponent size	Binary	2	16 bit integer
7	public exponent	Binary	variable(a)	integer
8	public modulus	Binary	variable(b)	integer
9	Key Id	Binary	2	16 bit integer
10	public exponent size	Binary	2	16 bit integer
11	public exponent	Binary	variable	integer
12	public modulus	Binary	variable	integer
. . .	. . .	. . .	. . .	. . .
4001	Key Id	Binary	2	16 bit integer
4002	public exponent size	Binary	2	16 bit integer
4003	public exponent	Binary	variable	integer
4004	public modulus	Binary	variable	integer

(a)  The size of the public exponent is determined by the previous field of the key data, public exponent size.

(b)  The size of the public modulus is determined by the key size field in the header data. The number of bytes for each modulus is equal to the number of bits divided by 8, rounded up.

Key Acknowledgment File

Before a key list may be used, the sender must receive a key acknowledgment file. The key acknowledgment file serves two purposes:

1.             1. Verify that the key list has been received by the intended recipient.

2.             2. Verify the correctness of each key in the list.

Furthermore, the need for an acknowledgment of this kind is specified in requirement R7-108.2. Once this file has been received, the sender of the key list can put the list into active use.

Table 7 below shows the format of the encryption key acknowledgment file. This file consists of some header information, followed by 1000 instances of key hash information. There are no separators of any kind between the individual fields, between the header and key hash data, or between each set of key hash data. The MD5 hash value will be calculated from the public modulus value of the key.

Table 7  Encryption Key acknowledgment File Format

Field #	Field Name	Type	Size (bytes)	Format
1	NPAC Customer Id	ASCII	4	Character String
2	File Creation Date	ASCII	14	MMDDYYYYHHmmSS
3	List Id	Binary	2	16 bit integer
4	Key Id	Binary	2	16 bit integer
5	Key’s MD5 hash	Binary	16	128 bit integer
6	Key Id	Binary	2	16 bit integer
7	Key’s MD5 hash	Binary	16	128 bit integer
. . .	. . .	. . .	. . .	. . .
2002	Key Id	Binary	2	16 bit integer
2003	Key’s MD5 hash	Binary	16	128 bit integer

Key Exchange using PGP

LNP Key exchange can be accomplished via email, ftp or an exchange of physical media using

PGP for security. Using PGP, a Service Provider will generate a pair of keys, one private and one public. The Service Provider will transmit the public key to the NPAC. This may be done via email or ftp, or any other mechanism of exchanging files. The key in this file is then saved by the NPAC’s PGP program. This key can now be used to encrypt files that only the Service Provider may decrypt, even if the key is intercepted by someone, it will not matter, they cannot use it to do anything other than encrypt messages for the Service Provider.

At this point, the NPAC can encrypt a file containing the keys for the Service Provider. This file may be emailed, put on the ftp site, or put on a disk for the Service Provider.

For LNP key lists that the Service Provider must provide to the NPAC, the reverse procedure would apply. First the NPAC would send a public key to the Service Provider. The Service Provider then encrypts their key list using the public key, and somehow gets the encrypted file to the NPAC.

[Graphic Omitted:  Title graphic – Service Element Usage Export File]

Service Element
Usage Export File

This section contains a sample export file for a third party billing system.

Note: The format and contents of the export file is open for change, depending on the capabilities and requirements of the third party billing system (to be selected.)

Table 8  Sample Export File Field Formats

Field #	Field Name	Type	Length	Format
1	Event Identifier	Numeric	10	Character String
2	Start Date of Usage	YYMMDD	6	Character String
3	Start Time of Usage	HHMM	4	Character String
4	End Date of Usage	YYMMDD	6	Character String
5	End Time of Usage	HHMM	4	Character String
6	Actual Usage Date	YYMMDD	6	Character String
7	Actual Usage Time	HHMM	4	Character String
8	Service Element Type	One of: • Storage • SV transactions • Report generation • Service activation • Login session • Add User • Audit	Variable	Character String
9	Service Element Subtype	For SV Transactions: • SV create • SV activate • SV modify • SV disconnect • SV conflict • SV conflict resolution • SV cancel For Storage: • Disk • LRN • NPA-NXX • SV	Variable	Character String
10	Quantity	Numeric	10	Character String
11	TN	For SV transactions only: • NPANXX Station	2	Character String
12	NPAC Customer	Alphanumeric	Variable	Character String
13	Audit Originator	For audits only: • Audit originator	Variable	Character String

# Checksum: 1010715438 9700
# Record Count: 83
# Regional Identifier: Midwest Regional NPAC SMS
#
# NOTE: To verify checksum, use the following command,
# replacing <datafile> with the name of this file.
# grep -v ‘^#’ | cksum <datafile>

#
1641,091797,0000,091797,2359,091797,1642,Storage,Disk,0,,Ameritech,
1642,091797,0000,091797,2359,091797,1217,Storage,SV,6500,,Ameritech,
1643,091797,0000,091797,2359,091797,2359,Storage,LRN,259,,Ameritech,
1644,091797,0000,091797,2359,091797,2359,Storage,NPANXX,6656,,Ameritech,
1645,091797,0000,091797,2359,091797,2359,SvcActivation,,0,,Ameritech,
1646,091797,0000,091797,2359,091797,2359,AddUser,,0,,Ameritech,
1647,091797,0000,091797,2359,091797,1802,SVTxn,Create,1,6145791090,Ameritech,
1648,091797,0000,091797,2359,091797,1802,SVTxn,Create,1,6145791091,Ameritech,
1649,091797,0000,091797,2359,091797,1802,SVTxn,Create,1,6145791092,Ameritech,
1650,091797,0000,091797,2359,091797,1802,SVTxn,Create,1,6145791093,Ameritech,
1651,091797,0000,091797,2359,091797,1802,SVTxn,Create,1,6145791095,Ameritech,
1652,091797,0000,091797,2359,091797,1802,SVTxn,Create,1,6145791096,Ameritech,
1653,091797,0000,091797,2359,091797,1802,SVTxn,Create,1,6145791097,Ameritech,
1654,091797,0000,091797,2359,091797,1802,SVTxn,Create,1,6145791098,Ameritech,
1655,091797,0000,091797,2359,091797,1802,SVTxn,Create,1,6145791099,Ameritech,
1656,091797,0000,091797,2359,091797,2017,SVTxn,Activation,1,6145791095,Ameritech,
1657,091797,0000,091797,2359,091797,2017,SVTxn,Activation,1,6145791095,Ameritech,
1658,091797,0000,091797,2359,091797,2017,SVTxn,Activation,1,6145791096,Ameritech,
1659,091797,0000,091797,2359,091797,2017,SVTxn,Activation,1,6145791096,Ameritech,
1660,091797,0000,091797,2359,091797,2017,SVTxn,Activation,1,6145791097,Ameritech,
1661,091797,0000,091797,2359,091797,2017,SVTxn,Activation,1,6145791097,Ameritech,
1662,091797,0000,091797,2359,091797,2017,SVTxn,Activation,1,6145791098,Ameritech,
1663,091797,0000,091797,2359,091797,2017,SVTxn,Activation,1,6145791098,Ameritech,
1664,091797,0000,091797,2359,091797,2017,SVTxn,Activation,1,6145791099,Ameritech,
1665,091697,0000,091797,2359,091797,2017,SVTxn,Activation,1,6145791099,Ameritech,
1666,091797,0000,091797,2359,091797,2120,Login,,8,,Ameritech,
1667,091797,0000,091797,2359,091797,2359,Storage,Disk,0,,Customer SPID 0288,
1668,091797,0000,091797,2359,091797,2359,Storage,SV,66000,,Customer SPID 0288,
1672,091797,0000,091797,2359,091797,0642,AddUser,,0,,Customer SPID 0288,
1682,091697,0000,091797,2359,091797,0700,Login,,2,,Customer SPID 0288,
1683,091697,0000,091797,2359,091797,2359,Storage,Disk,0,,MFS Worldcom,
1684,091697,0000,091797,2359,091797,2359,Storage,SV,8000,,MFS Worldcom,
1685,091697,0000,091797,2359,091797,2359,Storage,LRN,37,,MFS Worldcom,
1686,091697,0000,091797,2359,091797,2359,Storage,NPANXX,576,,MFS Worldcom,
1687,091697,0000,091797,2359,091797,2359,SvcActivation,,0,,MFS Worldcom,
1688,091697,0000,091797,2359,091797,2359,AddUser,,0,,MFS Worldcom,
1709,091697,0000,091797,2359,091797,2217,SVTxn,Activation,1,6145791091,MFS Worldcom,
1710,091697,0000,091797,2359,091797,2217,SVTxn,Activation,1,6145791093,MFS Worldcom,
1711,091697,0000,091797,2359,091797,2217,SVTxn,Activation,1,6145791095,MFS Worldcom,
1712,091697,0000,091797,2359,091797,2217,SVTxn,Activation,1,6145791096,MFS Worldcom,
1713,091697,0000,091797,2359,091797,2217,SVTxn,Activation,1,6145791097,MFS Worldcom,

1714,091697,0000,091797,2359,091797,2217,SVTxn,Activation,1,6145791098,MFS Worldcom,
1715,091697,0000,091797,2359,091797,2217,Audit,,1,,MFS Worldcom,MFS Woldcom
# END-OF-EXPORT-FILE

Figure 43 Sample Export FIle for a Third Party Billing System

September 19, 1997 Lockheed Martin IMS Corporation Confidential Page 77

[Graphic Omitted:  Title graphic – NPAC SMS Web Site]

NPAC SMS Web Site

The NPAC SMS will provide the NPAC Customer Information, Open LRN information, the Open NPA-NXX information from the LNP Web site home page.

Open NPA-NXX Data

Figure 45 , “Open NPA-NXX Window,” on page 81 , shows the set of NPA-NXXs, per NPAC Customer, that are available for porting.

An NPA-NXX entry followed by a parenthesized date will become available for porting on the indicated date.

Open LRN Window

Figure 46, “Open LRN Window,” shows the set of LRNs, per NPAC Customer, used for LNP switch identification.

NPAC Customer Information Window

Figure 47, “NPAC Customer Information Window,” shows the Service Provider ID and repair contact information within the NPAC SMS that will be posted to the Web site:

[Graphic Omitted: Screen shot of NPAC Customer Information Window]

Figure 44 LNP Web Main Window Figure 45 Open NPA-NXX Window Figure 46 Open LRN Window Figure 47 NPAC Customer Information WIndow

[Graphics Omitted (Series of 3):  NPAC SMS web site screen shots]

[Graphic Omitted:  Title graphic – NPAC SMS External Design Specification]

NPAC SMS External Design Specification

NPAC SMS External Design Specification has been prepared for Lockheed Martin IMS Corporation by:

Evolving Systems, Inc. 9777 Mt. Pyramid Court Englewood, Colorado 80112 (303) 802-1000 FAX (303) 802-1420

[Graphic Omitted: Evolving Systems Logo]

EXHIBIT  L

ADDITIONAL TERMS AND CONDITIONS OF SOFTWARE LICENSE

EXHIBIT L

ADDITIONAL TERMS AND CONDITIONS OF LICENSE

In addition to the terms and conditions set forth in Section 9.2 or 9.3 of the Agreement, as applicable, the license of the Object Code and Source Code for the NPAC/SMS Software granted to Customer under Section 9.2 or 9.3 shall include the following terms and conditions:

(a)The licensee shall be Customer (or its permitted successors or assigns), and is non-transferable and non-exclusive.

(b)The license shall be for use only in connection with providing services similar to the Services to the Users or to any other entity performing a function similar to that of Customer for use in creating, managing and operating a data center similar to the NPAC/SMS Data Center for the Service Area as it exists at the time of the grant of the license.  In addition to the above, at the time of the grant of the license, Contractor shall deliver to Customer a current copy of the NPAC/SMS data base records in machine readable format as well as in a format compatible with the current version of the NPAC/SMS Software.

(c)The license shall authorize Customer to use, modify, enhance and copy the NPAC/SMS Software to the extent necessary or appropriate under the rights granted in paragraph (b) above.  All other rights shall be reserved to Contractor.

(d)The license shall be subject to a confidentiality agreement that incorporates the same confidentiality provisions set forth in Article 15 of the Agreement.  All persons accessing the Object Code or Source Code (including any subcontractor or Successor Contractor personnel) shall be required to sign such confidentiality agreement directly in favor of Contractor (a copy of which shall be delivered to Contractor).

(e)Any sublicense shall be conditioned on the sublicensee’s written acceptance of all of the terms and conditions of the license to provide Customer the services set forth in paragraph (b) above and acknowledgment that Contractor is an intended third party beneficiary of sublicensee’s acknowledgment.

(f)The license shall be terminable at will by Customer, and by Contractor for a material breach of license terms by Customer, its representatives, agents or sublicensees, which breach cannot be cured within thirty (30) days; provided, however, that where such breach (other than with respect to a payment obligation) cannot be reasonably cured within such thirty (30) day period, so long as Customer is diligently pursuing such cure, the time for curing such breach shall be extended for such period as may be reasonably necessary for Customer to complete such cure.  Notwithstanding the foregoing, with respect to breaches of the obligations with respect to maintaining the confidentiality of the Software (a

“Confidentiality Breach”), Contractor may not terminate this license solely on the basis of a Confidentiality Breach (a) which does not create a material adverse effect to Contractor’s business and (b) where Customer has promptly documented to Contractor’s reasonable satisfaction, in a writing certified by an officer of Customer, that the Confidentiality Breach was inadverte nt and not the result of any failure by Customer, its officers, employees, agents and independent contractors to use all reasonable efforts to comply with their confidentiality obligations to Contractor pursuant to this Agreement (including without limitation compliance with internal Customer confidentiality procedures).

In the event of any Confidentiality Breach, Customer shall use its best efforts to effect prompt cure of such Confidentiality Breach and shall at its own expense take all steps reasonably requested by Contractor to (a) identify the source or causes of the Confidentiality Breach, (b) to prevent any further such breaches, (c) to retrieve any Contractor materials which may have been disseminated in connection with the Confidentiality Breach, (d) to cooperate in Contractor’s pursuit of legal or equitable remedies against any third parties (including Customer’s employees, agents and independent contractors) responsible for such breach, and (e) to cooperate with Contractor’s efforts to mitigate the effects of the Confidentiality Breach.  Customer’s compliance with this subparagraph shall be a condition for Contractor’s obligation to limit its termination rights hereunder.

Nothing in this clause (f) shall limit or be deemed a waiver of any other remedies available to Contractor under law, equity or contract with respect to any Confidentiality Breach or other breach by Customer of this Agreement.

(g)Contractor will not cause the NPAC/SMS Software to contain any feature which would render inaccessible or materially impair in any way the operation of the Object Code and Source Code (including, but not limited to, software locks or drop-dead devices).  Contractor warrants that the NPAC/SMS Software in the form licensed will substantially perform in compliance with the specifications for ninety (90) days from the date of delivery.  Except in circumstances where the license is granted following a termination of the Agreement as a result of a breach caused by failure of the NPAC/SMS Software to perform in accordance with the Specifications (a “Software Failure License”), Contractor warrants that the NPAC/SMS Software in the form licensed is accurate and complete as to the software run on the NPAC/SMS Production Computer System at the time of delivery.  Except with respect to a Software Failure License, Contractor warrants that the NPAC/SMS Software in the form licensed can be compiled and run by a programmer reasonably expert in the field and using software tools, libraries, compilers, etc. that are commercially available as of the date of the last release of the NPAC/SMS Software.  Otherwise the license provided herein shall be “as is”.  Contractor shall only be obligated to provide support, maintenance and training if the parties reach mutual agreement therefor, including providing for payment for such services.

(h)Contractor’s indemnification for infringement shall be as set forth in Article 18 of the Agreement.  However, such indemnification for infringement shall not apply to the extent the infringement would not have occurred absent modifications, enhancements, combinations or other actions taken by Customer or its sulicensee or any of their representatives, agents or subcontractors.

(i)Customer shall covenant to cooperate with Contractor in connection with any breaches of license terms by Customer representatives, agents and sublicensees, including former employees of such representatives, agents and sublicensees who are given Source Code access and subsequently leave such employ.

(j)Notwithstanding the license, Contractor shall retain ownership of and all rights in the Source Code and Object Code, subject only to license to Customer (and rights granted others by Contractor).  Customer shall own modifications it makes pursuant to the license, subject to Contractor’s ownership of underlying code and documentation. Customer shall not transfer or license its modifications of Source Code to the extent such transfer or license would include or reveal any portion of the Source Code or any of Contractor’s Confidential Information.

(k)Upon termination of the license: (i) Customer shall return or destroy, at Contractor’s option, all copies of the Source Code and Object Code in all media and any other materials containing part or all of the Source Code, except for Customer owned modifications, enhancements and related work product; (ii) Customer shall provide Contractor with a complete copy of all Source Code release/access records with respect to the Source Code, as well as any fee or royalty-related records requested by Contractor in connection with a final royalty audit; and (iii) Customer obligations of confidentiality survive any termination.

(l)The insurance requirements set forth in Article 20 shall remain in full force during the term of the license.

(m)The royalty for use of the NPAC/SMS Software and related Documentation (the “Royalty”) shall be paid monthly in advance in an amount equal to one-sixtieth of the Unrecovered Software Cost (as determined below).

(n)Defined Terms for Royalty.

Contractor shall, upon request for a license at the time of termination of the NPAC/SMS Agreement, calculate the amount of the Royalty.  For purposes of determining the Royalty, the following terms shall have the meanings specified:

“Unrecovered Software Costs” shall equal one quarter of (i) the product of the total Development Costs multiplied by the Applicable Margin Factor, less (ii) aggregate Software Revenue.

“Development Costs” shall mean the aggregate amount of all costs incurred by Contractor in designing, coding, developing, testing, implementing, maintaining and enhancing the NPAC/SMS Software and related Documentation before or during the term of this Agreement, but excluding Statements of Work Development Costs.

“Statements of Work Development Costs” shall mean reimbursable Development Costs incurred by Contractor in the performance of its obligations under Statements of Work for one or more Centralized NPAC LLCs or any user of the NPAC/SMS Software for whom a Centralized NPAC LLC is a liaison to Contractor.

“Applicable Margin Factor” shall be the quotient of (i) one (1) divided by (ii) the remainder of one (1) minus the Reasonable Margin (expressed as a decimal equivalent of the percentage, i.e., for a Reasonable Margin of 6%, use .06).

“Reasonable Margin” shall mean the quotient (expressed as a percentage) of (i) Total LNP Revenue, less the sum of all direct costs of providing the Services to all Centralized NPAC LLCs for the period for which Total LNP Revenue was calculated, divided by (ii) Total LNP Revenue.  For purposes of this calculation, “direct costs” shall be calculated in accordance with generally accepted accounting principles applied on a consistent basis throughout the term of the NPAC/SMS Agreement.

“Total LNP Revenue” shall mean all revenue of Contractor under Article 6 of any NPAC/SMS Agreement with any Centralized NPAC LLC (such agreements, the “Centralized NPAC Agreements”) related to the provision of Services by Contractor to the Centralized NPAC LLCs during the twelve months ended on the last day of the last fiscal quarter ending prior to termination of the NPAC/SMS Agreement.

“Software Revenue” shall mean the dollar amount which is the product of (i) the Software Cost Percentage multiplied by (ii) the sum of (A) the aggregate of (x) all TN Porting Event charge revenue received by Contractor under any of the Centralized NPAC Agreements and (y) the aggregate amount of any and all Allocable Target Shortfall Amounts (as defined in Section 6.6 of each Centralized NPAC Agreement) received by Contractor under a Centralized NPAC Agreement.

“Software Cost Percentage” shall be the quotient (expressed in terms of a percentage) of the aggregate amount of Development Costs divided by the aggregate costs, excluding Reimbursed Development Costs, incurred by Contractor (before or during the term of the NPAC/SMS Agreement) in providing that portion of the Services (as defined in each of the Centralized NPAC Agreements) that is billed for via the TN Porting Event charge.

(o)Customer may, upon request made within 30 days of receiving Contractor’s determination of the Aggregate Royalty, have Contractor’s determination of the Royalty reviewed by a neutral Third Party.  Upon Customer’s request, Contractor and Customer shall mutually determine a Third Party to review Contractor’s determination of the Royalty.  Either Party shall have reasonable grounds to oppose the selection of the Third Party nominated by the other on the basis of ongoing relationships between the Party, or its members or affiliates,

and the nominated Third Party, and each Party shall, and shall require the nominee to, disclose to the other Party any such ongoing relationships.  Once such Third Party is selected and upon receipt by Contractor of an executed confidentiality agreement from such Third Party, Contractor shall provide the Third Party access to the books and records of Contractor and supporting materials as is reasonably necessary to audit Contractor’s determination of the Royalty.  If the Third Party concludes that Contractor’s determination of the Royalty is incorrect the Royalty shall be the lesser of the amounts determined by the Contractor and the Third Party, retroactive to the granting of the license.

(p)All disputes between Contractor and Customer with respect to the license herein or matters relating hereto shall be resolved in accordance with the dispute resolution mechanism provided in the Agreement.

EXHIBIT  M

SOFTWARE ESCROW AGREEMENT

NPAC/SMS SERVICES

Preferred Agreement

The Preferred Agreement caters to those customers who demand more sophisticated escrow arrangements.  It is a three-party contract that involves constant administration by DSI and frequent correspondence between DSI, the depositor and the beneficiary.  The depositor and beneficiary will receive signed confirmations from DSI that every deposit has been inspected; an account history report every six months to notify them of  the status of the escrow; and ongoing monitoring services to ensure compliance of contract terms.

Purpose

DSI’s Preferred Agreement is generally used when:

•Both parties agree that a high level of escrow protection is needed.

•The beneficiary wants to sign the agreement.

•The beneficiary wants the option to request a release of deposit materials directly from DSI.

•The beneficiary wants to negotiate unique release conditions, such as loss of support.

Features

Preferred customers benefit from these unique features:

•Tailored release conditions.

•Modification of terms for unique requirements.

•Written notification detailing the contents of the initial deposit and each update.

•Semi-annual account histories listing all deposit activity.

•DSI direct billing to beneficiary.

•Technical verification options.

•Audit rights to both parties.

•Audit trail of deposit created through inspection, and date stamping of all deposit materials.

•Deposit inspection with signed receipt for both the depositor and beneficiary.

•Grant of use rights and deposit content definition.

Customers who want DSI’s premier escrow service should choose the Comprehensive Preferred Agreement which provides these additional features:

•Basic verification of deposit materials. This includes documentation of the hardware and software environments needed to read the computer media, maintain the source code, and compile the source code.

•Continual deposit maintenance in which DSI notifies the depositor semi-annually to make updates.  DSI then notifies the beneficiary of any update activity.

•Unlimited deposit updates and/or replacements, plus one additional storage unit.

San Francisco • Boston • New York • Chicago • Dallas • Atlanta • San Diego • Los Angeles • Toronto • London

For More Information Call: (800) 962-0652 or Visit Us At www.dsiescrow.com

EXHIBIT  M

SOFTWARE ESCROW AGREEMENT

Account Number               

THIS SOFTWARE ESCROW AGREEMENT (“Agreement”) is made and entered into this         day of            ,               (“Effective Date”) by and among DSI Technology Escrow Services Inc., a Delaware corporation, having offices at 2100 Norcross Parkway, Suite 150, Norcross, Georgia 30071 (“Escrow Agent”), NeuStar, Inc., a Delaware corporation, having its principal offices at 46000 Center Oak Plaza, Sterling, VA 20166, USA (“Contractor”), and North American Portability Management, L.L.C., an Illinois limited liability company, having offices at                                  (“Customer”).

RECITALS

A.Contractor and Customer have entered into that certain amended and restated Agreement for Number Portability Administration Center/Service Management System dated as of November, 7, 1997 (as it may be amended from time to time, the “NPAC/SMS Agreement”; all capitalized terms used herein shall have the meanings ascribed therein).

B.Under certain circumstances following the termination of the NPAC/SMS Agreement, Customer is entitled to receive a copy of and a limited license to use the NPAC/SMS Software in accordance with Sections 9.2 and 9.3 of the NPAC/SMS Agreement.

C.Contractor and Customer agree and hereby establish an escrow with Escrow Agent to provide for the retention and administration of the Escrow Materials (described below) pursuant to the following terms and conditions.

AGREEMENT

1.Deposits

Section 1.1Obligation to Make Deposit.  Upon the signing of this Agreement by the parties, Contractor shall deliver to Escrow Agent copies of the NPAC/SMS Software and all NPAC/SMS Software related documentation (the “Escrow Materials”) as required by Section 9.4 of the NPAC/SMS Agreement.  The Escrow Materials shall include at least those materials described in Exhibit A attached hereto.

Section 1.2Identification of Tangible Media.  Prior to the delivery of the Escrow Materials to Escrow Agent, Contractor shall conspicuously label for identification each document, schematic, magnetic tape, disk, or other tangible media comprising the Escrow Materials.  Additionally, Contractor shall complete Exhibit B, which shall identify Escrow Materials by the item label description, the type of media and the quantity.  At the time of

deposit, Exhibit B must be completed and signed by Contractor and delivered to Escrow Agent with the Escrow Materials.  Unless and until Contractor makes the initial deposit with Escrow Agent, Escrow Agent shall have no obligation with respect to this Agreement, except the obligation to notify the parties regarding the status of the deposit account as required in Section 2.2 below.

Section 1.3Deposit Inspection.  When Escrow Agent receives the Escrow Materials and Exhibit B, Escrow Agent will conduct a deposit inspection by visually matching the labeling of the tangible media containing the Escrow Materials to the item descriptions and quantity listed on the Exhibit B. In addition to the deposit inspection, Customer may elect to cause a verification of the Escrow Materials in accordance with Section 1.6 below.

Section 1.4Acceptance of Deposit.  At completion of the deposit inspection, if Escrow Agent determines that the labeling of the tangible media matches the item descriptions and quantity on Exhibit B, Escrow Agent will sign Exhibit B and mail a copy thereof to Contractor and Customer.  If Escrow Agent determines the labeling does not match the item descriptions or quantity on Exhibit B, Escrow Agent will (a) note the discrepancies in writing on Exhibit B; (b) sign Exhibit B with the exceptions noted; and (c) provide a copy of Exhibit B to Contractor and Customer.  Escrow Agent’s acceptance of the deposit occurs upon the signing of Exhibit B by Escrow Agent.  Delivery of the signed Exhibit B to Customer is Customer’s notice that the Escrow Materials have been received and accepted by Escrow Agent.

Section 1.5Contractor’s Representations.  Contractor represents and warrants as follows as to each deposit of the Escrow Materials:

a.Contractor lawfully possesses all title, rights, and interest in and to all of the Escrow Materials deposited with Escrow Agent;

b.With respect to all of the Escrow Materials, Contractor has the right and authority to grant to Escrow Agent and Customer the rights as provided in this Agreement;

c.The Escrow Materials are not subject to any lien or other encumbrance as of the date hereof,

d.The Escrow Materials consist of all materials required by the NPAC/SMS Agreement to be deposited with Escrow Agent; and

e.The Escrow Materials are readable and useable in their current form or, if any portion of the Escrow Materials are encrypted, the decryption tools and decryption keys have also been deposited.

Section 1.6Verification.  Customer shall have the right at any time, at Customer’s expense, to verify itself, or if the Escrow Materials have been delivered to Escrow Agent, cause a verification by Escrow Agent of, any Escrow Materials, including inspection and testing of the Escrow Materials.  A verification determines, in different levels of detail, the accuracy, completeness and sufficiency of the Escrow Materials and quality of the media.  Customer shall

notify Contractor and Escrow Agent in writing of Customer’s request for verification no less than twenty one (21)  days prior to such verification.  Contractor shall have the right to be present at the verification.

Section 1.7Deposit Updates.  Unless otherwise provided by the NPAC/SMS Agreement, Contractor shall update the Escrow Materials within sixty (60) days of each release of a new version of the product, which is subject to the NPAC/SMS Agreement.  Such updates will be added to the existing deposit.  Contractor shall update the Escrow Materials (e.g., Enhancements and Maintenance Modifications to any Escrow Materials previously deposited), within sixty (60) days after each release of a new version (i.e., when change is placed in production), which is subject to the NPAC/SMS Agreement.  Such updates will be added to the existing deposit. The information provided on Exhibit A and Exhibit B shall be revised to reflect any updates.  The processing of all deposit updates shall be in accordance with Section 1.2 through Section 1.6 above.  All references in this Agreement to the Escrow Materials shall include the initial Escrow Materials and any updates made pursuant to this Section 1.7.

Section 1.8Removal of Escrow Materials.  The Escrow Materials may be removed, exchanged and/or destroyed only on written instructions signed by Contractor and Customer, or as otherwise provided in this Agreement.

2.Confidentiality and Record Keeping

Section 2.1Confidentiality.  Escrow Agent shall maintain the Escrow Materials in a secure, environmentally safe, locked facility which is accessible only to authorized employees of Escrow Agent. Escrow Agent shall exercise at least the same degree of care in holding the Escrow Materials as it would exercise in holding its own similar materials, but in any event no less care than is customary in the industry.  Except as provided in this Agreement, Escrow Agent shall not disclose, transfer, make available, or use the Escrow Materials or other information disclosed to it pursuant to this Agreement.  Escrow Agent shall not disclose the content of this Agreement to any third party.  Escrow Agent shall maintain complete written records of all Escrow Materials deposited with Escrow Agent and all other documents and records relating to this Agreement.  If Escrow Agent receives a subpoena or other order of a court or other judicial tribunal pertaining to the disclosure or release of the Escrow Materials, Escrow Agent will immediately notify the parties to this Agreement.  It shall be the responsibility of Contractor and/or Customer to challenge any such order; provided, however, that Escrow Agent does not waive its rights to present its position with respect to any such order.  Escrow Agent will not be required to disobey any court or other judicial tribunal order.

Section 2.2Status Reports.  Escrow Agent will issue to Contractor and Customer a report profiling the history of the deposit account created hereunder at least semi-annually.  Escrow Agent may provide copies of the account history pertaining to this Agreement upon the request of any party to this Agreement.

Section 2.3Audit Rights.  During the term of this Agreement, Contractor and Customer shall each have the right to inspect the written records of Escrow Agent pertaining to

this Agreement.  Any inspection shall be held during normal business hours and following reasonable prior notice.

3.Grant of Rights to Escrow Agent

Section 3.1Title to Media.  Contractor hereby transfers to Escrow Agent the title to the media upon which the proprietary technology and materials are written or stored.  However, this transfer does not include the ownership of the proprietary technology and materials contained on the media such as any copyright, trade secret, patent or other intellectual property rights.

Section 3.2Right to Make Copies.  Escrow Agent shall have the right to make copies of the Escrow Materials as reasonably necessary to perform this Agreement.  Escrow Agent shall copy all copyright, nondisclosure, and other proprietary notices and titles contained on the original Escrow Materials onto any copies made by Escrow Agent.  With all Escrow Materials submitted to Escrow Agent, Contractor shall provide any and all instructions as may be necessary to duplicate the Escrow Materials including but not limited to the hardware and/or software needed.

Section 3.3Right to Release.  As of the Effective Date of this Agreement, Contractor hereby grants to Escrow Agent the right to release the Escrow Materials to Customer in accordance with Section 4, below.  Except upon such a release, Escrow Agent is not authorized to, and shall not sublicense, assign or otherwise transfer or release the Escrow Materials.

4.Release of Deposit

Section 4.1Filing For Release.  Customer may request that the Escrow Materials be released by providing to Escrow Agent (i) a duly executed certificate of an officer of Customer certifying that the NPAC/SMS Agreement has been terminated under the circumstances where Customer is entitled to receive a license to the NPAC/SMS Software as set forth in Sections 9.2 and 9.3 of the NPAC/SMS Agreement (the “Release Condition”) and (ii) a written request for the release of the Escrow Materials.  Customer shall also provide a copy of each to Contractor, which shall be forwarded by fax and recognized overnight commercial courier to the addresses then in effect as provided in the NPAC/SMS Agreement.  Upon receipt of such certificate and request, Escrow Agent shall provide a copy of both to Contractor by fax or recognized same day or overnight commercial courier.

Section 4.2Release of Escrow Materials.  If Escrow Agent does not receive Contrary Instructions (as defined below) within ten (10) days following Escrow Agent’s mailing of a copy of the request for release to Contractor, Escrow Agent shall deliver the Escrow Materials to Customer within thirteen (13) days of the date of Escrow Agent’s mailing of Customer’s original request for release; provided, however, that Escrow Agent is entitled to receive any fees due Escrow Agent before making such release; and provided further that Escrow Agent mails a copy of the request for release to Contractor via a recognized overnight commercial carrier.  This Agreement will terminate upon the release of the Escrow Materials held by Escrow Agent.  “Contrary Instructions” for the purposes of this Article 4 shall mean the filing with Escrow Agent of a duly executed certificate of an officer of Contractor, stating that the Release Condition has

not occurred or has been cured in accordance with the terms of the NPAC/SMS Agreement.  On delivery of Contrary Instructions to Escrow Agent, Contractor shall also provide a copy of each to Customer, which shall be forwarded by fax and recognized overnight commercial courier to the addresses then in effect as provided in the NPAC/SMS Agreement.  Upon receipt of Contrary Instructions, Escrow Agent shall provide a copy thereof to Customer by fax or recognized same-day or overnight commercial courier.

Section 4.3Escrow Agent’s Retention in the Event of a Dispute.If Escrow Agent timely receives Contrary Instructions, Escrow Agent shall not release the Escrow Materials and subject to Section 5.2 of this Agreement, shall continue to store the Escrow Materials until (i) Escrow Agent is delivered a copy of joint written instructions from Contractor and Customer dated after the date of Contrary Instructions, or (ii) Escrow Agent is delivered a copy of an order of the arbitration panel selected by the parties certified by the delivering party to be the final order of such arbitration panel, in either case directing the Escrow Agent as to the disposition of the Escrow Materials.  If the provisions of either Section 4.1 or this Section are satisfied, Escrow Agent shall have no right or obligation to evaluate the merits of the demand or refuse to deliver the Escrow Materials to Customer.

Section 4.4Resolution of Specific Dispute Regarding Release.Contractor shall only dispute the release of the Escrow Materials on the basis that a Release Condition has not occurred or has been cured in accordance with the terms of the NPAC/SMS Agreement.  Any dispute regarding the occurrence and continuation of a Release Condition shall be resolved in accordance with the provisions of the NPAC/SMS Agreement, subject to any arbitration being expedited as provided herein.  Within seven (7) days of Contractor’s delivery of Contrary Instructions, Contractor and Customer shall each identify to the other (and Escrow Agent) its nominee as arbitrator.  Each party shall instruct its nominee to select a third arbitrator jointly with the nominee of the other party within seven (7) days of the selection of the latter of the two (2) arbitrators.  The arbitrators nominated by the parties shall also be instructed to notify the parties (and Escrow Agent) of the identity of the third arbitrator within two (2) days after the naming of the third arbitrator and the arbitration panel shall have authority only to determine whether or not Escrow Agent shall release the Escrow Materials.  Contractor shall submit its memorandum of fact and law to the arbitrators and Customer within four (4) days of notice of the completion of the arbitration panel.  Customer shall have four (4) days thereafter to submit its memorandum of fact and law to the arbitrators.  Thereafter, Contractor shall have three (3) days to submit its reply to Customer’s memorandum.  The arbitration panel shall be instructed to commence a hearing on the points at issue five (5) days following the submission of Customer’s papers, which hearing shall continue day to day until complete.  If such hearing is not commenced within thirty-four (34) days from the delivery of the certificate as described in Section 4.1(i) due to substantial delays demonstrably caused directly and solely by Contractor without a reasonable basis, then the Escrow Materials shall be immediately released by Escrow Agent.  Each of Contractor and Customer shall be allotted not more than four (4) days to present its principal case at the hearing and Contractor shall be allotted one (1) day for rebuttal.  In preparing for the hearing each party agrees to cooperate with the other in allowing expedited depositions of relevant key witnesses.  The arbitration panel shall be instructed to rule on the release of the Escrow Materials at the close of the hearing.  Any other dispute or disagreement between Contractor and Customer relating to this Escrow Agreement shall be resolved by arbitration as more fully set forth in Article 26 of the

NPAC/SMS Agreement, and subject to Contractor’s right to petition a court of competent jurisdiction for injunctive relief or a temporary restraining order in connection with an alleged violation of Contractor’s intellectual property rights, as provided in the NPAC/SMS Agreement.

Section 4.5Effect of Release.If (i) the Escrow Materials are released to Customer by the Escrow Agent, and (ii) Contractor thereafter obtains a final judgment of a court in accordance with the NPAC/SMS Agreement concluding that termination was wrongful or did not occur or that the Release Condition did not occur or was cured such that Customer has no right to be in possession of the Escrow Materials, then Customer shall cause all copies of any of the Escrow Materials to be promptly delivered to the Contractor.  Customer shall also ensure that all of Customer’s agreements with third parties to which it discloses the Escrow Materials include provisions implementing the foregoing return and protective provisions.

5.Term and Termination

Section 5.1Term of Agreement.  The term of this Agreement is year to year, renewing automatically from year to year until such time as (a) Contractor and Customer jointly instruct Escrow Agent in writing as to the disposition of the Escrow Materials or (b) this Agreement is terminated by Escrow Agent for nonpayment in accordance with Section 5.2 or by resignation in accordance with Section 5.3 of this Agreement.  The parties acknowledge that a termination of the NPAC/SMS Agreement shall not cause a termination of this Agreement.

Section 5.2Termination for Nonpayment.  In the event of the nonpayment of fees owed to Escrow Agent, Escrow Agent shall promptly provide written notice of delinquency to Customer and Contractor.   Any party to this Agreement shall have the right to make the payment to Escrow Agent to cure the default.  If the past-due payment is not received in full by Escrow Agent within one month of the date of such notice, then Escrow Agent shall have the right to terminate this Agreement ten (10) days thereafter by sending written notice of termination to all parties, unless the past-due payment is made during such ten (10) day period.  Escrow Agent shall have no obligation to take any other action under this Agreement so long as any payment due to Escrow Agent remains unpaid.

Section 5.3Termination by Resignation.  Escrow Agent reserves the right to terminate this Agreement, for any reason, by providing Contractor and Customer with 60-days’ written notice of its intent to terminate this Agreement.  Upon such termination, Contractor has the right to request and receive a refund form DSI for all prorated charges.  Within the 60-day period, the Contractor and Customer may provide Escrow Agent with joint written instructions authorizing Escrow Agent to forward the Escrow Materials to another escrow company and/or agent or other designated recipient.  If Escrow Agent does not receive said joint written instructions within 60 days of the date of Escrow Agent’s written termination notice, then Escrow Agent shall destroy, return or otherwise deliver the Escrow Materials in accordance with Section 5.4.

Section 5.4Disposition of Escrow Materials Upon Termination.  Subject to the foregoing termination provisions, and upon termination of this Agreement, Escrow Agent shall destroy, return, or otherwise deliver the Escrow Materials in accordance with Contractor’s

instructions.  If there are no instructions, Escrow Agent may, at its sole discretion, destroy the Escrow Materials or return them to Contractor.

Section 5.5Survival of Terms Following Termination.  Upon any termination of this Agreement, the following provisions of this Agreement shall survive:

a.Contractor’s Representations (Section 1.5).

b.The obligations of confidentiality set forth in Section 2.1.

c.The obligation to pay Escrow Agent any fees and expenses due.

d.The provisions of Section 7.

e.Any provisions in this Agreement which specifically state they survive the termination or expiration of this Agreement.

6.Escrow Agent Fees

Contractor shall solely be responsible for and shall pay Escrow Agent its standard

fees and expenses applicable to the services provided, as set forth on Exhibit D.  The fees shall be the standard fees charged by Escrow Agent from time to time.  Escrow Agent shall notify the parties at least sixty (60) days prior to any increase in fees.  For any service not listed on Escrow Agent’s standard fee schedule, Escrow Agent will provide a quote prior to rendering the service, if requested.  Escrow Agent shall not be required to perform any service unless the payment for such service and any outstanding balances owed to Escrow Agent are paid in full.  Fees are due upon receipt of a signed contract or receipt of the Escrow Materials whichever is earliest.  If invoiced fees are not paid, Escrow Agent may terminate this Agreement in accordance with Section 5.2.

7.Liability and Disputes

Section 7.1Right to Rely on Instructions.  Escrow Agent may act in reliance upon any instruction, instrument, or signature reasonably believed by Escrow Agent to be genuine.  Escrow Agent may assume that only the Customer Chairperson, designated contact or officer of Contractor and/or Customer who gives any written notice, request, or instruction has the authority to do so.  Escrow Agent will not be required to inquire into the truth or evaluate the merit of any statement or representation contained in any notice or document.  Escrow Agent shall not be responsible for failure to act as a result of causes beyond the reasonable control of Escrow Agent.

Section 7.2Indemnification.  Escrow Agent shall be responsible to perform its obligations under this Agreement and to act in a reasonable and prudent manner consistent with best practices and industry standards with regard to this escrow arrangement.  Provided Escrow Agent has acted in the manner stated in the preceding sentence, Contractor and Customer each agree to indemnify, defend and hold harmless Escrow Agent from any and all claims, actions,

damages, arbitration fees and expenses, costs, attorneys’ fees and other liabilities incurred by Escrow Agent relating in any way to this escrow arrangement.

Section 7.3Dispute Resolution.  Any dispute relating to or arising from this Agreement shall be brought in, and shall be subject to the jurisdiction of, the appropriate state or federal court located in Chicago, Illinois.

Section 7.4Controlling Law.  This Agreement is to be governed and construed in accordance with the laws of the State of Illinois without regard to its conflict of law provisions.

Section 7.5Notice of Requested Order.  If any party intends to obtain an order from any court of competent jurisdiction which may direct Escrow Agent to take, or refrain from taking, any action, that party shall:

a.Give Escrow Agent at least two (2) business days prior notice of the hearing;

b.Include in any such order that, as a precondition to Escrow Agent’s obligation, Escrow Agent be paid in full for any past-due fees and be paid for the reasonable value of the services to be rendered pursuant to such order; and

c.Ensure that Escrow Agent not be required to deliver the original (as opposed to a copy) of the Escrow Materials if Escrow Agent may need to retain the original in its possession to fulfill any of its other escrow duties.

8.General Provisions

Section 8.1Entire Agreement.  This Agreement, which includes the Exhibits described herein, embodies the entire understanding between all of the parties with respect to its subject matter and supersedes all previous communications, representations or understandings, either oral or written.  Escrow Agent is not a party to the NPAC/SMS Agreement between Contractor and Customer and has no knowledge of any of the terms or provisions of any such Agreement.  Escrow Agent’s only obligations to Contractor and Customer are as set forth in this Agreement.  No amendment or modification of this Agreement shall be valid or binding unless signed by all parties hereto, except Exhibit A need not be signed by Escrow Agent and Exhibit B need not be signed by Customer and Exhibit C and D need not be signed.

Section 8.2Notices.  Except as provided otherwise herein, all notices, invoices, payments, deposits and other documents and communications shall be given to the parties at the addresses specified in the attached Exhibit C. It shall be the responsibility of the parties to notify each other as provided in this Section in the event of a change of address.  The parties shall have the right to rely on the last known address and facsimile number of the other parties.  Any notice provided for or permitted under this Agreement shall be in writing and will be treated as having been given (i) when delivered personally, (ii) when sent by confirmed facsimile, (iii) three days after it’s sent by a recognized commercial courier with written verification of receipt, or (iv) one week after mailed postage prepaid by certified or registered mail, return receipt requested, to the party to be notified, at the address and to the person set forth in Exhibit C, or at such other place of which,

and to the attention of such person of whom, the other party has been notified in accordance with the provisions of this Section.  All documents and communications may be delivered by First Class mail. Any correctly addressed notice that is refused, unclaimed, or undeliverable because of an act or omission of the party to be notified shall be deemed effective as of the first date that said notice was refused, unclaimed, or deemed undeliverable by the postal authorities, messenger, or overnight delivery service.

Section 8.3Severability.  In the event any provision of this Agreement is found to be invalid, voidable or unenforceable, the parties agree that unless it materially affects the entire intent and purpose of this Agreement, such invalidity, voidability or unenforceability shall affect neither the validity of this Agreement nor the remaining provisions herein, and the provision in question shall be deemed to be replaced with a valid and enforceable provision most closely reflecting the intent and purpose of the original provision.

Section 8.4Successors.  This Agreement shall be binding upon and shall inure to the benefit of the successors and assigns of the parties.  However, Escrow Agent shall have no obligation in performing this Agreement to recognize any successor or assignee of Contractor or Customer unless Escrow Agent receives clear, authoritative and conclusive written evidence of the change of parties.

Section 8.5Bankruptcy.  Contractor and Customer acknowledge that this Agreement is an “agreement supplementary to” the NPAC/SMS Agreement as provided in Section 365(n) of Title 11, United States Code (the “Bankruptcy Code”).  Contractor acknowledges that if either Contractor (as a debtor in possession) or a trustee in Bankruptcy in a case under the Bankruptcy Code rejects the NPAC/SMS Agreement or this Agreement, Customer may elect to retain its rights under the NPAC/SMS Agreement and this Agreement as provided in Section 365(n) of the Bankruptcy Code.  Upon written request of Customer to Contractor or the Bankruptcy Trustee, Contractor or such Bankruptcy Trustee shall not interfere with the rights of Customer as provided in the NPAC/SMS Agreement and this Agreement, including the right to obtain a copy of the Escrow Materials from Escrow Agent.

Section 8.6Regulations.  Contractor and Customer are responsible for and warrant compliance with all applicable laws, rules and regulations, including but not limited to customs laws, import, export, and re-export laws and government regulations of any country from or to which the Escrow Materials may be delivered in accordance with the provisions of this Agreement.

Section 8.7Waiver.  No failure or delay on the part of the Contractor, Customer or Escrow Agent in exercising any right, power or remedy provided herein may be, or may be deemed to be, a waiver thereof; nor any single or partial exercise of any right, power or remedy preclude any other or further exercise of such right, power or remedy or any other right, power or remedy.

Section 8.8Assignment. No party to this Agreement shall assign any right or interest under this Agreement without the prior written consent of the other parties.

NeuStar, Inc.,
a Delaware corporation

By:

Name:

Title:

Date:

North American Portability Management, LLC
an Illinois limited liability company

By:

Name:

Title:

Date:

DSI Technology Escrow Services, Inc.
a Delaware corporation

By:

Name:

Title:

Date:

EXHIBIT A

MATERIALS TO BE DEPOSITED

Account Number                   

Contractor represents to Customer that Escrow Materials delivered to Escrow Agent shall consist of the following:

Contractor	Customer
By:	By:
Name:	Name:
Title:	Title:
Date:	Date:

EXHIBIT B

DESCRIPTION OF DEPOSIT MATERIALS

Contractor Company Name                                                                                                                                                                     

Account Number                                                                                                                                                                                      

Product Name                                                                                                                          Version                                                     

(Product Name will appear as the Exhibit B Name on Account History report)

ESCROW MATERIAL DESCRIPTION:

Quantity	Media Type & Size	Label Description of Each Separate Item
	Disk 3.5” or
	DAT tape          mm
	CD-ROM
	Data cartridge tape
	TK 70 or           tape
	Magnetic tape
	Documentation
	Other

PRODUCT DESCRIPTION:

Environment                                                                                                                                                                                                   

ESCROW MATERIAL INFORMATION:

Is the media encrypted?  Yes / No   If yes, please include any passwords and the decryption tools.

Encryption tool name                                                                                                                Version                                                        

Hardware required                                                                                                                                                                                         

Software required                                                                                                                                                                                           

Other required information                                                                                                                                                                            

I certify for Contractor that the above described Deposit Materials have been transmitted to DSI:	DSI has inspected and accepted the above materials (any exceptions are noted above):
Signature	Signature
Print Name	Print Name
Date	Date Accepted
	Exhibit B#

Send materials to: DSI, 2100 Norcross Parkway, Suite 150, Norcross, GA 30071

(770) 239-9200

EXHIBIT C

DESIGNATED CONTACT

Account Number                               

Notices, deposit material returns and communications to Contractor should be addressed to:	Invoices to Contractor should be Addressed to:
Company Name:
Address:
Designated Contact:	Contact:
Telephone:
Facsimile:	P.O.#,  if required:
Notices and communications to Customer should be addressed to:	Invoices to Customer should be addressed to:
Company Name:
Address:
Designated Contact:	Contact:
Telephone:
Facsimile:	P.O.#,  if required:

Requests from Contractor or Customer to change the designated contact should be given in writing by the designated contact or an authorized employee of Contractor or Customer.

Contracts, deposit materials and notices to Escrow Agent should be addressed to:	Invoice inquiries and fee remittances to Escrow Agent should be addressed to:
DSI Technology Escrow Services, Inc.	DSI Technology Escrow Services, Inc.
Contract Administration	2100 Norcross Parkway
Suite 150	Suite 150
2100 Norcross Parkway	Norcross, GA 30071
Norcross, GA 30071
Telephone:  (770) 239-9200	(770) 239-9200
Facsimile:    (770) 239-9201	(770) 239-9201
E-mail:  ca@dsiescrow.com
Date:

EXHIBIT D

Fee & Services Schedule

NEW ESCROW AGREEMENT	ANNUAL FEE		SETUP FEE
Comprehensive Preferred	$	2,650	$	1,050
Master Preferred	$	1,350	$	2,050
Reseller	$	1,350	$	2,050
Preferred	$	1,350	$	1,050
FlexSAFE	$	1,250	$	350
SAFE	$	1,250	$	350
Technology Protection	$	700	No Fee
Web Content Protection	$	1,000	$	1,050
ADDITIONAL BENEFICIARY
Preferred	$	650/ea.	$	1,050
Master Preferred	$	650/ea.	No Fee
FlexSAFE	$	200/ea.	No Fee
SAFE	$	50/ea.	No Fee
ADDITIONAL DEPOSIT ACCOUNT
Master Preferred	$	700	No Fee

SERVICE OPTIONS	FEES
Unlimited deposit or replacement, plus one additional storage unit	$	300/yr.
Individual deposit updates or replacements	$	200/ea.
Electronic depositing using SecurEmail or Escrow Direct: Unlimited deposits, updates or replacements, plus one additional storage unit	$	500/yr.
DeposiTrack updates	$	300/ea.
Remote vaulting	$	500/yr.
Release filing fee	No Fee		(1)
Custom contracts	No Fee		(2)
Additional storage units	$	100/ea.
Technical verification: DSI offers three different levels of verification. Please contact your DSI Verification Sales Representative for help on understanding which level of verification would best meet your intellectual property protection requirements.	Pricing is quoted based on client specifications.

(1) Copying expenses in excess of $300 will be chargeable.

(2) An annual fee of $500 may be assessed for contract modifications that change DSI’s standard processes or risk, specifically deposit handling, release or termination procedures and general indemnity issues.

SYSTEM PERFORMANCE PLAN
FOR NPAC/SMS SERVICES

EXHIBIT  N

THIS SYSTEM PERFORMANCE PLAN FOR NPAC/SMS SERVICES (this “Performance Plan”) is entered into as of May     , 1998 by and between LOCKHEED MARTIN IMS, a New York corporation (“Contractor”), and the limited liability company executing this Performance Plan on the signature page hereof (“Customer”) with reference to the Contractor Services Agreement between the parties hereto (the “Master Contract”).  Capitalized terms used herein without definition shall have the same meaning herein as when used in the Master Contract.

1.Purpose of Plan.  In accordance with Article 31 of the Master Contract, this Performance Plan specifies the requirements relating to transaction throughput performance of the NPAC/SMS.  The Functional Requirements Specification included as Exhibit B to the Master Contract (the “FRS”) and the Interoperable Interface Specification included as Exhibit C to the Master Contract (the “IIS”) provide for certain throughput performance requirements of the NPAC/SMS that are based on CMIP operations per second by the NPAC/SMS (the “FRS/IIS Specs”).  The FRS/IIS Specs include in the FRS at section 6.4.2 (Interface Performance Requirements), Requirements R6-29.1 and R6.29.2 (business objective to activate 25 TNs per second) and Requirements R6-28.1 and R6-28.2 (maximum SOA transaction rates), which requirements are internally inconsistent.

2.NPAC Throughput.  The throughput performance of the NPAC/SMS (the “NPAC Throughput”) shall be stated in telephone numbers (“TNs”) per second.

2.1  Measurement and Reporting.  NPAC Throughput for any software release or other improvement at implementation shall be a number calculated by timing a run consisting of activations for 336 ported TNs, following the range usage assumptions in the FRS, and dividing the number of TNs (336) by the number of seconds to complete the run.  This includes the time to receive, process and complete activation requests over the SOA and the associated downloads to the LSMSs.  Since each LSMS receives the same 336 TNs, the number of TNs per second represents the number downloaded simultaneously to each LSMS.  Seven LSMSs are currently employed in Contractor’s test scenario.  This test scenario is subject to periodic update, based on evolving industry requirements, agreeable by Customer and Contractor.

Reporting of performance metrics shall be done in accordance with the Reporting Requirements documented in Exhibit H.

2.2  User System Congestion.  User System Congestion is defined as a state of degraded system performance resulting if any of the following conditions occur:

CONFIDENTIAL

N-1

(a)  If the NPAC/SMS receives an indication from a User SOA/LSMS that it is unable to receive any more messages;

(b)  If the NPAC/SMS’s retry timer expires for an outstanding operation (download or other message) previously transmitted to a User SOA/LSMS.

(c)  If a User SOA/LSMS causes substantial latencies in message flows from the NPAC/SMS as a result of chronic delays in sending responses to the NPAC/SMS that are nevertheless sent in such time as the timers in the NPAC/SMS do not expire.  (For example, congestion must address the effect of chronic slow SOA/LSMS responses which are expected on a 3 second basis but for which the timer doesn’t go off until 2 minutes have passed.)

2.3Verification of Throughput Measurement.  The NPAC Throughput achievement of any software release or other improvement shall be tested in two phases.  First, Contractor will test the NPAC Throughput in the laboratory environment prior to each new release of the NPAC/SMS Software.  Thereafter, following completion of regression testing in Chicago, performance would again be tested based on communication with actual LSMSs and SOAs in a lab-to-lab laboratory test.  Contractor shall promptly research and document any material discrepancies from the Contractor’s lab results.  Users shall cooperate in such investigation and in any appropriate re-testing.  If the discrepancy is the result of User System Congestion and such User System Congestion is not relieved, Contractor’s laboratory testing results shall control.  The Contractor’s test scenario document is incorporated herein and attached as Exhibit N-1.

3.Requirement to Avoid Chronic Congestion Slowdown.  The ability of the NPAC/SMS to meet the required NPAC Throughput is dependent on User LSMS and SOA systems meeting the implied standards of this performance plan implemented consistently with the IIS for download capacity.  Consequently, where NPAC Throughput is compromised by slowdowns resulting from the failure of Users’ LSMSs and SOAs connected to the NPAC/SMS to achieve the download capacity necessary to support the NPAC Throughput generated by the NPAC/SMS, Contractor shall not be deemed to have failed to reach the NPAC Throughput required hereunder.

4.Dynamic Throughput Milestones.  The minimum required NPAC Throughput (the “Minimum NPAC Throughput”) shall initially be as provided in the following section and shall be revised from time to time as provided below.  The Customer intends, initially, to use the methodology set forth within section 4.2.  This methodology, including demand forecasting set forth in Section 4.2, may be revised by Customer in consultation with Contractor, periodically, in whole or in part, to more accurately reflect actual experience and projected business needs of the industry, including to account for changing industry conditions (e.g., number pooling, inclusion of wireless services).  The Contractor may request changes to the methodology, including demand forecasting set forth in section 4.2, but the changes shall be subject to the approval of the Customer.

N-2

4.1Initial NPAC Throughput Milestones.  The required Minimum NPAC Throughput shall be 2.9 TNs per second for all quarters during the period through and including December 31, 1998.  Commencing with the quarter beginning January 1, 1999, Minimum NPAC Throughput shall be the number of TNs per second as set forth below, beneath the corresponding calendar quarter (starting with the first day of each January, April, July and October and continuing through the last day prior to the beginning of the next calendar quarter). Nothing in the Master Contract shall prevent the Customer from modifying these initial Minimum NPAC Throughput milestones in accordance with Section 4.2 of this Exhibit N.

Initial NPAC Throughput Milestones

1Q99	2Q99	3Q99	4Q99	1Q00	2Q00	3Q00	4Q00
2.9	2.9	2.9	3.26	3.75	4.23	4.72	5.33
1Q01	2Q01	3Q01	4Q01	1Q02	2Q02	3Q02	4Q02
5.94	6.55	7.16	7.88	8.61	9.34	10.07	10.80
1Q03	2Q03
11.53	12.26

4.1.1  Maximum Value for Minimum NPAC Throughput.   The maximum value of a Minimum NPAC Throughput milestone is 25 TNs/sec.  Any adjustments to the Minimum NPAC Throughput up to, and including 25 TNs/sec, will be provided by the Contractor at no additional cost to the Customer.

4.2  Demand Forecasting .  The Minimum NPAC Throughput shall be adjusted from time to time based on system demand trend experience and current industry intelligence.  System demand stated in TNs per second (“Projected Demand”) shall be forecasted on a quarterly basis using data for activity through the most recently completed calendar quarter, and shall be determined, initially, by the industry demand model provided below.

N-3

For purposes of demand trending and forecasting the following terms shall have the following meanings:

4.2.1  Available TNs  (TN) means number of working and reserved TNs resident in LNP-capable switches (those switches that are currently LNP capable or that are planned to become LNP capable during the calendar year of the calculation) in the region.  An assumption of an NPA-NXX fill rate of 50 % was used in the initial calculation of Projected Demand.  This assumption will be adjusted periodically when more accurate data is available.

Two known pending significant impacts to the number of Available TNs include the implementation of Number Pooling and the inclusion of Wireless services to the NPAC/SMS.

4.2.2  Incremental Penetration Rate (IPR) means the percentage of available TNs which actually port for the first time (i.e. move outside of their donor network) during the forecast period, forecasted quarterly on the basis of the four consecutive quarters just ended and current industry projections (e.g. SBC Warburg).

4.2.3  Incremental new TNs ported this year (INTN) means available TNs multiplied by incremental penetration rate.

INTN = TN * IPR

4.2.4  Cumulative new TNs ported by mid-year (CNTN) shall be calculated on an annual basis at the close of the calendar year, and means cumulative TNs first ported (not including subsequent ports of the same number) through the end of the all calendar years then ended plus one-half of incremental new TNs first ported during the calendar year just ended.  This number shall then established for the third quarter of the current year with all other quarter determined by linear interpolation.

CNTN = å^{curr yr -1} INTN + ½ INTN_{curr yr}

4.2.5  Churn Rate (CR) means a percentage equal to the number of TNs that are ported for a second or subsequent time during the forecast period.   Churn Rate shall be forecasted on a quarterly basis.

4.2.6  Annual TNs ported due to churn (CRTN) means churn rate multiplied bycumulative new TNs ported by mid-year.

CRTN = CR * CNTN

4.2.7  Total TNs ported this year (TTN) means incremental new TNs first ported this year plus the product of (a) annual TNs ported due to churn divided by 12, times (b) the number of months completed in the calendar year through the end of the most recent calendar quarter.  This shall be calculated on a quarterly basis.

TTNs = INTN + (Current Month*CRTN/12)

N-4

4.2.8  TNs ported per month (MTN) means total TNs ported this year divided bythe number of months elapsed in the calendar year through the close of the most recent calendar quarter.  This shall be calculated on a quarterly basis.

MTN = TTN / Current Month

4.2.9  Number of busy days per month (BDM) means the number of busy days shall equal the smallest number of days necessary to account for 75% of all porting activations.  This number will be forecasted on a quarterly basis.  The initial estimate of this parameter is 8.

4.2.10  TNs ported per busy day (BDTN) means TNs ported per month divided bythe number of busy days per month.

BDTN = MTN / BDM

4.2.11  Percentage of day’s traffic per busy hour (BH%) means with respect to busy days, the percentage of the entire day’s porting activations which take place in the busiest one-hour period on that day. This number will be forecasted on a quarterly basis.  The initial estimate of this parameter is 36%.

4.2.12  TNs ported per busy hour (BHTN) means TNs ported per busy day multiplied by percentage of day’s traffic per busy hour.

BHTN = BDTN * BH%

4.2.13  Projected Demand (or Demand TNs per second) (PD) means TNs ported per busy hour divided by 3600 seconds/hour

PD = BHTN / 3600

N-5

The initial milestone values reflected in section 4.1, were derived from the initial iteration of the Projected Demand model depicted below.  These numbers are derived from the West Coast region.  The italicized lines reflect the five (5) input parameters of the model.

Industry Demand Model

TN Download Rates Required to Support Number Porting

Contract YEAR (mid-point)	1998		1999		2000		2001		2002
Available TNs (50% NPA-NXX fill rate)	19,450,000		40,689,400		42,582,274		44,585,710		46,707,326
Penetration *	2.9	%	5.5	%	8.0	%	10.6	%	13.2	%
New Ported TNs	564,050		2,237,917		3,406,582		4,726,085		6,165,367
Cum Ported TNs (mid-yr avg)	282,025		1,683,009		4,505,258		8,571,592		14,017,318
Churn Rate	25	%	25	%	25	%	25	%	25	%
Churn Ports	70,506		420,752		1,126,314		2,142,898		3,504,329
Total Ports (Annual)	634,556		2,658,669		4,532,896		6,868,983		9,669,696
Monthly Ports	52,880		221,556		377,741		572,415		805,808
Busy Days/Month	8		8		8		8		8
Busy Hour	36	%	36	%	36	%	36	%	36	%
TNs/sec Required (to each SP)	0.7		2.8		4.72		7.16		10.07

‘* SBC Warburg Dillon Read Industry Report, Sept. 16, 1997

4.3Revision of Minimum NPAC Throughput.  Projected Demand as calculated quarterly, beginning 7/1/98, shall be compared to the Minimum NPAC Throughput for the calendar quarter (the “Adjustment Quarter”) commencing on the first day of the seventh month following the close of the quarter on which the Projected Demand calculation is based.  If the difference between the Projected Demand and the Minimum NPAC Throughput for the Adjustment Quarter is at least 10% of the Minimum NPAC Throughput then in effect for the Adjustment Quarter, the Minimum NPAC Throughput for the Adjustment Quarter shall be revised to equal the Projected Demand, but in no event shall the adjustment result in a Minimum NPAC Throughput that is (a) less than 2.9 TNs/sec, (b) less than the previous quarter’s milestone, or (c) greater than the lesser of (i) two times the Minimum NPAC Throughput as in effect at the close of the calendar quarter on which the Projected Demand calculation is based or (ii) 25 TNs/sec.

4.4Efforts to Attain Projected Demand.  Notwithstanding that the revision of Minimum NPAC Throughput provided for in the foregoing Section applies to the Adjustment Quarter and is limited in absolute terms to a one hundred percent increase, if the Minimum NPAC Throughput would otherwise be increased beyond such 100%

N-6

increase, Contractor shall use all commercially reasonable efforts to attain the Projected Demand level as soon as is reasonably practicable (both as to time for attainment and level projected).

5.  Performance Credits.  The Minimum NPAC Throughput as in effect from time to time shall be a Service Level Requirement of the NPAC/SMS.  Actual throughput rates experienced in operation of the NPAC/SMS shall be monitored in fifteen minute intervals based on actual offered rate of activations generated by the Users’ systems and actual download activations, and shall be stored in the NPAC/SMS for comparison with Minimum NPAC Throughput.  (a) If during any fifteen minute recording interval, the actual download activation rate does not at least equal the lesser of the offered activation rate (i.e., the combined rate of upload activation messages from all User systems) or the Minimum NPAC Throughput, and such failure continues for any two consecutive fifteen minute recording interval during the calendar month (a “Throughput Deficiency Event”), Contractor shall pay to Customer for that month as a Performance Credit Amount under Section 16.3 of the Master Contract and Exhibit G thereto, and in lieu of any Performance Credit that would be applicable in the absence of this Performance Plan, $5,000.  Notwithstanding the foregoing, if during any fifteen minute recording interval the NPAC/SMS records any User System Congestion events, the fifteen minute recording interval shall be disregarded for purposes of this calculation.  (b) If, prior to the first day of any calendar quarter, Contractor has not demonstrated achievement in the laboratory environment of the Minimum NPAC Throughput milestone for that quarter, there shall be established a daily credit (“Missed Milestone Credit”) for each day thereafter until the date that Contractor demonstrates achievement of such milestone in laboratory testing.  The Missed Milestone Credit shall be equal to $500 per day accruing up to a maximum of $10,000 per month.  The aggregate amount for Missed Milestone Credits and the above credit for Throughput Deficiency Events shall not exceed $60,000 in any calendar year.  With respect to any month in which a Throughput Deficiency Event occurs and there is an accrued Missed Milestone Credit, the Performance Credit shall equal the greater of the Missed Milestone Credit or $5,000.  The Missed Milestone Credit shall be paid by Contractor to Customer if a Throughput Deficiency Event occurs prior to demonstration of achievement of such milestone.  If no Throughput Deficiency Event occurs prior to demonstration of achievement of such milestone, any Missed Milestone Credit previously established with respect thereto shall be eliminated.  Any Missed Milestone Credit paid shall be a Performance Credit in lieu of the Performance Credit for Throughput Deficiency Events referenced in (a) above.  Any Missed Milestone Credit previously established but not required to be paid prior to the end of the term of the Master Agreement shall be eliminated.

6.  The suspension of the Service Commitment Level #3 (response time) of the Service Level Requirements (Exhibit G), imposed in Article 31 is hereby lifted.

In connection with this Performance Plan, the Specification requiring achievement by the NPAC/SMS of specified throughput capacity levels and the Service Commitment Levels for the Service Levels set forth in number 6 on Exhibit G – Service Level Requirements are suspended until the NPAC/SMS achieves the requirements of this Performance Plan.

N-7

During such suspension, the NPAC/SMS shall perform at the requirements of this Performance Plan as in effect from time to time.  To the extent Contractor fails to meet the requirements of this Performance Plan, Contractor shall be subject to the rights, remedies and provisions of the Master Contract until Contractor meets such requirements.

N-8

IN WITNESS WHEREOF, Contractor and Customer have executed this System Performance Plan as of the date first set forth above.

			Customer:
LOCKHEED MARTIN IMS					, LLC
By:			By:
	(Signature)			(Signature)
(Name & Title Typed or Printed)			(Name & Title Typed or Printed)
		, 1998			, 1998
(Date)			(Date)

N-9

SOW 15

|LOCKHEED MARTIN

STATEMENT OF WORK
FOR

NATIONAL NUMBER POOLING, RELEASE 3.0

STATEMENT OF WORK
NATIONAL NUMBER POOLING
(under Agreement for NPAC/SMS Services)

1.INTRODUCTION; PARTIES.  This Statement of Work (this “SOW’) is entered into pursuant to Article 13 of, and on execution shall be a part of, the respective Agreement for Number Portability Administration Center / Service Management System (each, a “Master Agreement”) between Lockheed Martin IMS. (“Contractor”) and the respective limited liability company indicated below (the “Subscribing Customers”):

LNP, LLC (Midwest)

Southwest Region Portability Company, LLC

Northeast Carrier Acquisition Company, LLC

Western Region Telephone Number Portability, LLC

Southeast Number Portability Administration Company, LLC

This SOW shall be effective only on execution by Contractor and at least one of the Subscribing Customers.  The number set forth in the upper right hand comer hereof may be used to reference this SOW.  Capitalized terms used herein without definition shall have the meanings as defined in the Master Agreements.

2.SCOPE OF ADDITIONAL SERVICES.  The Additional Services contemplated under this SOW are an Enhancement to the NP AC/SMS as defined under the Master Agreement.  The Additional Services to be undertaken by Contractor are generally described as set forth below.  Additional clarifications to requested requirements are listed in Exhibit B to this document.

Key Terms and Guidelines

Allocated Charges – TN Porting Event Fees, Targets (including Shortfalls and Credits), Regional/National SOWs (including future SOWs), report(s) requested by the LLCs, insurance as defined in the Master Agreement Section 20.6 and NANC 1.0 Flow charges.

Prior to the FCC’s Third Report and Order, Telephone Number Portability, CC Docket No.95-116, FCC 98-82 (“Cost Recovery Order”) all Allocated Charges were invoiced to Users based on an Allocation Model determined by their regional LLC.  Subsequent to the FCC’s Third Report and Order all telecommunications carriers operating within a Subscribing Customer’s Service Area (“Carriers”) are to be invoiced a portion of the Allocated Charges, as determined by the allocation percentage based on end-user revenue, provided that Carriers with no end-user revenue, i.e. wholesalers, are to be invoiced $[* * *] per region per year.  As a result of the Third Report and Order, all Carriers share these charges.

This SOW covers the work (“Work”) defined collectively as — NPAC/SMS requirements definition, NP AC/SMS system design, NP AC/SMS code and unit test, NP AC/SMS system integration test, NP AC/SMS system and regression test, program management, quality assurance, configuration control, documentation management, maintenance and warranty – to deliver Release 3.0 of the Contractor’s NPAC/SMS software.  NPAC/SMS Release 3.0 is planned to implement the following change orders:

•NANC 109 National Number Pooling

•NANC 243 Removal of NPA-NXX or LRN from NPAC

•NANC 244 NPA Splits – Deletion of Old NPA-NXX at end of PDP

NANC 109 National Number Pooling

This change order encompasses the entire set of changes required to support national standards for number pooling.  It includes EDR, 1K block activations via SOA interface, deferred block activation, new alarmable error messages from NPAC, a new bulk data download format, OpGUI specifications and routable error reports.  The complete set of changes are listed in the IIS and FRS.

NANC 243 Removal of NPA-NXX or LRN from NPAC

The NPAC SMS shall disallow removal of an NPA-NXX or an LRN if a subscription version exists with a status of old and a failed SP list.

NANC 243 Note from NANC Change Management:

The NPAC SMS and the FRS need to be updated to further define the condition where NPA-NXXs or LRNs can be deleted from the NPAC SMS.

The current NPAC SMS functionality and the FRS states, “shall allow the removal...only if no Subscription Versions, except for Old or Cancelled Subscription Versions exist...”.

The correct behavior should be “...except for Old with NO failed SP List or Cancelled...”.

NANC 244 NPA Spilts – Deletion of Old NPA-NXX at end of PDP

NPAC SMS shall automatically delete the old NPA-NXX from the Portable NPA-NXX Information in the NPAC, upon reaching the end of the permissive dialing period for the old NPA-NXX involved in an NPA Split.

OUT OF SCOPE SERVICES

This SOW contains the agreed upon terms and conditions that shall govern Contractor’s performance of the services described herein.  The services provided for in this SOW and for which Contractor shall be compensated in accordance with Section 6, herein, shall not be interpreted, implied, or assumed to include any other service(s), including additional or changed services, not specifically described in this Section 2, Scope of Additional Services.  Any and all requested or .required services or change orders (hereinafter “Out of Scope Services”) may be provided in accordance with the Master Agreement and, specifically, Section 13, Additional Services.

3.PROJECT SCHEDULE; DELIVERABLES.  The schedule set forth in the following table is a summary of tasks and time frames for implementation:

Phase	Summary Milestones	Interval
Phase 0.0	Statement of Work Effective	Week 0
Phase 1.0	SOW Project Plan	Week 5
Phase 2.0	System and Functional Design	Weeks 1 to 11
Phase 3.0	Development	Weeks 12 to 30
Phase 4.0	System and Integration Testing	Weeks 39 to 47
Phase 5.0	Install on NPAC/SMS for Industry Regression Testing	End of Week 47

Phase 0.0This phase marks agreement between the parties for the implementation of the Additional Services as described in the Schedule Notes.

Phase 1.0This phase involves creating a work breakdown structure project plan.  The project plan will detail each phase of the project showing the milestones for completion of the phase and scheduled delivery data for deliverables.  The actual “Scheduled Delivery Date” for this SOW will be identified in the project plan.

Phase 2.0This phase involves detailed analysis of the requirements,

Phase 3.0This phase involves developing the Enhancement as well as any testing or implementation tools and procedures.

Phase 4.0This phase involves internal contractor acceptance and regression testing of the Enhancement.  All completion and acceptance criteria established by the Contractor for this purpose must be met for satisfactory completion of this phase.

Phase 5.0This phase marks the implementation of the Enhancement on the NPAC/SMS and will be made available to the Users for the industry regression testing.  Installation of Release 3.0 will require an Extended Maintenance Window.  The specific duration and date of the window will be identified in the project plan.  The completion of this phase constitutes “Final Delivery” of the Additional Services.

Schedule Notes:

1.The Project Schedule above is expressed in elapsed time intervals from the Effective Start Date of this SOW, e.g. Phase 1.0 is slated to be completed 5 weeks after Phase 0.0 (Effective Start Date).

2.The Effective Start Date of this SOW is scheduled subsequent to receiving an Authorization to Proceed from Subscribing Customer(s) for this SOW after the SOW has been properly executed as defined above.  The Schedule of Deliverables commences upon the Effective Start Date of this SOW.

3.The Effective Start Date is determined by the Contractor based on an assessment of the current work-in-progress resulting from previously authorized and committed SOWs.  The current work-in-progress is due to other factors such as: 1) Contractor-initiated Work (e.g., resulting from Subscribing Customers, other customers or duly authorized industry direction), 2) total system development and testing capacity and dependencies.  The Effective Start Date will initially be determined by Contractor and, prior to establishing a firm Effective Start Date for this SOW, may be subject to modification as determined by the Contractor based upon discussion between Contractor and Subscribing Customers and other customers.

4.The Phase 5.0 deliverable is the availability of the NPAC/SMS software release generated by this SOW in preparation for Industry Regression Testing.  The extent of this testing will be jointly defined prior to Phase 5.0.  General availability to all Users will not be complete until after the completion of industry regression testing and the deployment of this NPAC/SMS software release, all of which are jointly scheduled between Contractor, Subscribing Customer and Users.  General availability of the Enhancement will not be made until all Users have either completed regression testing or submitted a written waiver of their desire to test.

4.COMPLETION AND ACCEPTANCE CRITERIA.  The following internal documents are applicable to the Additional Services contemplated under this SOW:

        Functional Requirements Specifications

        Requirements Traceability Matrix

        External Design

        System Design

        Detailed Design

        Integration Test Plan

        System Test Plan

        Software Quality Assurance Program Report

        User Documentation

        Software Configuration Management Plan

N/A Standards and Metrics

Effective on the acceptance date of the Software release subject hereof, the term Specifications as used in the Master Agreement shall mean the Specifications as defined therein and as modified and amended pursuant to Statements of Work under the Master Agreement through and including the Software release contemplated by this Statement of Work.

5.IMPACTS ON MASTER AGREEMENT (INCLUDING EXISTING SPECIFICATIONS).

None Master Agreement

         Exhibit B Functional Requirements Specification

         Exhibit C Interoperable Interface Specification

None Exhibit E Pricing Schedules

None Exhibit F Project Plan and Test Schedule

None Exhibit G Service Level Requirements

None Exhibit H Reporting and Monitoring Requirements

None Exhibit J User Agreement Form

None Exhibit K External Design

None Exhibit L Infrastructure/Hardware

None Exhibit N System Performance Plan for NP AC/SMS Services

Contractor agrees to be bound by the terms and conditions of Exhibit N with respect to future performance improvements as required.

6.0COMPENSATION AND PAYMENT

6.1Compensation

Upon execution of this SOW, Subscribing Customer(s) agrees to be obligated in full for payment of the Additional Services described herein, in accordance with the amount and terms provided below.  For the purposes of and in accordance with Section 23.3 (“Users’ Liability for Payments”) of the Master Agreement and Cost Recovery Order, these Additional Services shall be considered by all Carriers to be services performed prior to any effective date of termination.  Accordingly and notwithstanding any other provisions to the contrary in the Master Agreement or any exhibit attached thereto, in the event any amounts owed pursuant to this SOW remain outstanding upon any termination or expiration of the Master Agreement or this SOW, such amounts shall be immediately due and payable by the charged Subscribing Customer as provided for herein.

Billing for the Additional Services described within this SOW will begin sooner of either a) the third complete billing cycle after the completion of Phase 5 (as defined in Section 3 – Project Schedule: Deliverables) in any region or b) the completion of industry regression testing by two Users within a region.

The Payment options for the Additional Services of this SOW are:

•Price without Financing

•Price with Financing (over 24 months)

This quote is valid for 90 days from the original date shown in the header of this SOW.

National Number Pooling Pricing	Monthly Price Per Region*		Total Price Per Region*		Total Price for US
Lump-Sum Payment Option	[* * *]		$	[* * *]	$	[* * *]
Financing Option	$	[* * *]	$	[* * *]	$	[* * *]
Financing @13% (24 Monthly Payments)

•Assumes seven regions are participating.  Lump-sum Payment Option price per region would be the Total Price for US divided by number of participating regions.  Under the Financing option the actual number of regions participating will determine the Monthly Price per Region (table shown below).

•Total Price for US contains $[* * *] rebate to LNP, LLC.

Number of Regions participating	Monthly Price Per Region
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]

Pricing for the Change Orders

Change Order	Amount
NANC 109	$	[* * *]
NANC 243	$	[* * *]
NANC 244	$	[* * *]

The major components of this price by Phase/Function are shown in the chart below.

Phase/Function	Amount		Percent of Total
[* * *]	$	[* * *]	[* * *]	%
[* * *]	$	[* * *]	[* * *]	%
[* * *]	$	[* * *]	[* * *]	%
[* * *]	$	[* * *]	[* * *]	%
[* * *]	$	[* * *]	[* * *]	%
[* * *]	$	[* * *]	[* * *]	%
[* * *]	$	[* * *]	[* * *]	%

Notes:Release 1.4 code is 90% utilized as part of Release 3.0.

6.1.1Interim Funding

In order to allow Subscribing Customers time to complete their due diligence and secure a delivery date, an Interim Funding Period has been created.  This interim period covers Phase 1, 2 and approximately [* * *]% of Phase 3 of the project.  The Interim Funding Project, based on an Aug 6, 1999 execution, extends until Oct 15, 1999 at which point at least one Subscribing Customer must elect one of three options.  Those options and their consequence on payment of the Interim Funding Amount are described below.  The Interim Funding Amount is $[* * *] and would be divided equally amongst the Subscribing Customers and allocated to Carriers based on the allocation model then in effect.

SOW	Weeks	Interim funding		Percentage
SOW 15R1B	[* * *]	$	[* * *]	[* * *]	%

Option 1 – Continue Project

If selected, under this option the interim funding agreement would cease to exist and the terms and the conditions regarding payment and invoicing within this SOW would take effect.

Option 2 – Suspend Project

If selected, the project would immediately be placed on hold.  If the suspension is less than one week the project could be resumed as if no suspension had occurred.  If the suspension is over one week the project would have to be assessed and a new SOW generated.  The Interim Funding Amount would be invoiced  in the first billing cycle following the date of suspension and expiration of the one week grace period.  any interim funding amount paid by Carriers and associated with recoverable or usable work product would be credited to Carriers.

Option 3 – Cancel Project

If selected, the project would immediately be cancelled.  The Interim Funding Amount would become due and invoiced in the first billing cycle following the cancellation date.

One or more Subscribing Customer(s) must notify Contractor, in writing, of their intent on or before Oct 15, 1999.  Failure to provide written notification on or before Oct 15, 1999 will result in automatic selection of Option 1.  In Options 2 and 3 the Interim Funding Amount is a lump-sum payment and is payable under the Invoicing terms defined within this SOW.  If a decision were made by one or more Subscribing Customer(s) to proceed with the SOW on or before Oct 15, those Subscribing Customer(s) would be liable, on a pro-rata basis, for the entire SOW price.

6.1.2Penalty

If Contractor fails to meet Phase 5 summary milestone of 47 weeks (outlined in Section 3 – Project Schedule) contractor will pay Subscribing customers a delay penalty.  The penalty will be [* * *]$[* * *]

dollars per business day for each business day delayed past the scheduled completion of Phase 5.  The penalty will be capped at 60 days ($[* * *]).

1.2Testing Prices

6.2.1Industry Regression and Interoperability Testing

Industry regression Testing will be tracked by User and by region.  Industry Regression Testing will be billed on a 4-hour block basis at the rate of $[* * *] per 4-hour block.  The $[* * *] rate is valid through the Final Delivery Date as determined during the development of the Project Plan.

Due to the scope of this release and changes to the interface interoperability testing will be required.  Interoperability testing will be performed at the rate of $[* * *] per day.

Advanced reservation of Industry Regression and Interoperability Testing blocks is required.  Reservations must be made at least 14 days in advance of the start of testing.  Industry Regression Testing blocks will be reserved and billed in 4-hour blocks only.  Interoperability testing blocks will be reserved and billed in 8-hour (1-day) blocks only.  Dedicated test support personnel will be provided for each reservation.  Reservation for multiple testing blocks is allowed.  Partial block reservations willnot be allowed.

Reservations for Industry Regression and Interoperability Testing blocks must be canceled at least two and one-half workdays prior to the reserved date and time.  Cancellations made less than two and one-half workdays prior to the reserved test date will incur a cancellation fee for the full amount of time reserved.  For Industry Regression test blocks a cancellation fee of $[* * *] will be billed  for cancellations made less than two and one-half workdays prior to the reserved test date.  Contractor will issue a cancellation credit of $[* * *] to a User for cancellation of an Industry Regression test block, where a Contractor notice of at least two and one-half workdays was not provided prior to the reserved test date and time.  For Interoperability test blocks a cancellation fee of $[* * *] will be billed for cancellations made less than two and one-half workdays prior to the reserved test date.  Contractor will issue a cancellation credit of $[* * *] to a User for cancellation of an Interoperability test block, where a Contractor notice of at least two and one-half workdays was not provided prior to the reserved test date and time.

1.1.2LTI Testing

LTI testing is done on an ad hoc basis using existing support staff.  The charge for LTI testing is billed in 4-hour blocks at a rate of $[* * *] per block.  Since there is no requirement to reserve testing blocks there is no reservation deadline or cancellation fee as with Industry Regression and Interoperability Testing.

6.3Payment Terms

Invoicing:

Contractor shall prepare invoices (separate from Master Contract invoicing, but which may include invoicing for other SOW charges) on the last day of a calendar month and send to each User for the amount of its User Charges.  Contractor shall also prepare and deliver to Customer a report (the

“Monthly Summary of Charges”) setting forth the billing calculation above for each User in the Service Area, and for all Users within the Service Area.  All invoices shall be due and payable within Thirty (30) days of the date of invoice.  Late payments will be subject to a 1.25% interest charge per month, or, if lower, the maximum rate permitted by law.

With respect to telecom carriers that are not Users Contractor shall prepare invoices (separate from Master Contract invoicing, but which may include invoicing for other SOW charges) on the last day of a calendar quarter and send to each telecom carrier for the amount of its charges.  Contractor shall also prepare and deliver to Customer a report (the “Monthly Summary of Charges”) setting forth the billing calculation above for each telecom carrier in the Service Area, and for all telecom carriers within the Service Area.  All invoices shall be due and payable within Thirty (30) days of the date of the invoice.  Late payments will be subject to a 1.25% interest charge per month, or, if lower, the maximum rate permitted by law.

Notwithstanding the foregoing, User may not withhold payment of any amounts invoiced by Contractor based solely upon a dispute  between Customer and User concerning how User is allocated charges under the Allocation Model.

The payments provided for in this Section shall not be applied against the Annual Target Amounts referred to in the Master Agreement.

Taxes:

User is to remit to or reimburse Contractor for any taxes that a User is obligated to pay by law, rule or regulation or under this Agreement or its respective NPAC/SMS User Agreement.

Assignment of Monies Due:

As provided in Section 22.2 of the Master Agreement, Contractor may, upon written notice to Customer, assign monies due or that are to become due under a Statement of Work, provided that no such assignment may impose upon Customer or Users any obligations in addition to or different than those set forth in this Agreement or the subject Statement of Work, or preclude Customer or Users from dealing solely and directly with Contractor in all matters pertaining to this Agreement or the subject Statement of Work, including the negotiation of amendments and the settlement of disputed invoices.

7.PROJECT MANAGEMENT.  When deemed appropriate by User and Contractor, Project Managers will be assigned to produce and verify a delivery schedule, to coordinate logistics and delivery of all deliverables and to conduct project quality review meetings.  Assigned Project Managers are:

Contractor Project Manager	Martin Breen
User Project Manager
Other key personnel assigned by Contractor to the project (attach resume information):

8.CONTINUATION OF MASTER AGREEMENT AND USER AGREEMENT.  Except as specifically modified and amended hereby (including by the SOW Specifications where applicable), all the provisions of the Master Agreement and the User Agreements entered into with respect thereto shall remain unaltered and in full force and effect in accordance with their terms.  From and after the date hereof, any reference in either the Master Agreement to itself or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the date hereof, shall be deemed to be a reference to such agreement as modified and amended by this SOW.  Notwithstanding the foregoing, with respect to User Enhancements, (i) the Master Agreement shall be modified and amended only to the extent necessary to give effect to the terms of this SOW and without affecting those Users or their User Agreements that are not Subscribing Users, and (ii) only those User Agreements that have been entered into with the Subscribing Users shall be modified and amended hereby.  From and after the effectiveness of this SOW, this SOW shall be a part of the Master Agreement and, as such, shall be subject to the terms and conditions therein.

9.JOINDER.  If at any time hereafter a Customer, other than a Subscribing Customer desires to become a Subscribing Customer or, with respect to User Enhancements, a User, other than a Subscribing User, desires to become a Subscribing User, Such Customer or User may become a Subscribing Customer or Subscribing User, respectively, by executing a joinder agreeing to be bound by the terms and conditions of this SOW, as modified from time to time.  A Customer or User executing such a joinder shall share in the payment of the price of the- Additional Services provided for herein in a fair and equitable manner, and in no event in excess of the payments which would have been incurred had such Customer or User been a Subscribing Customer or Subscribing User at the time of effectiveness of this SOW, excluding any incremental work, such as Industry Regression Testing, borne by the Contractor in order to properly implement the Additional Services provided herein.

10.COUNTERPARTS.  This SOW may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed the same document.  All such counterparts shall be deemed an original, shall be construed together and shall Constitute one and the same instrument.

IN WITNESS WHEREOF, the undersigned have executed this Statement of Work:

CONTRACTOR:

LOCKHEED MARTIN IMS

By:

Its:

Date:

SUBSCRIBING CUSTOMERS:

LNP, LLC.

By:

Its:

Date:

MID-ATLANTIC CARRIER ACQUISITION COMPANY, LLC

By:

Its:

Date:

SOUTHEAST NUMBER PORTABILITY COMPANY, LLC

By:

Its:

Date:

NORTHEAST CARRIER ACQUISITION COMPANY, LLC

By:

Its:

Date:

SOUTHWEST REGION PORTABILITY COMPANY, LLC

By:

Its:

Date:

WEST COAST PORTABILITY SERVICES, LLC

By:

Its:

Date:

WESTERN REGION TELEPHONE NUMBER PORTABILITY, LLC

By:

Its:

Date:

EXHIBIT A

Proposed Collection Policy

Schedule for PAST DUE Bills

Days Past Due	Amount of Invoice(s)	Action
3	>$50K	Follow up call to carrier
10	>$5K	Follow-up call to carrier
20	ALL	Send letter to carrier
40	ALL	Escalate: Send certified letter to carrier, List of Delinquent carriers to NANC and FCC for 208 process
60	ALL	Write-off overdue amount and send to Collection Agency(1)

All late payments are subject to a 1.25% interest charge per month.

(1)Any overdue accounts referred to a collection agency will be written off, including bankruptcies.  Any amount collected net of the collection agency charges will be credited to the carrier per the allocation in effect.  LMIMS will seek LLC approval for write-off greater than $10,000, but in no case will approval be unreasonably withheld for accounts 180 days past due.

(2)Contractor, as part of its normal business practice, will maintain a collection history file for all accounts.  the collection history fill will contain invoice dates, dates of letter and phone contacts and responses (or non-responses) to those contacts from the carriers.  this information will be provided to Subscribing Customer(s) or any regulatory agency in support of the 208 process, if required.

EXHIBIT B

Definitions

1. Clarification.Update that removes ambiguity concerning how to implement a requirement that has been previously stated.  for examples: 1) The specification of the error to be generated in the case where an error condition was already indicated or 2) The value of a data field for a record that was already specified.

2. Change.Update which introduces new functionality, or alters/removes previously existing functionality.  For example: 1) The addition or removal of a field to a previously defined record or 2) The specification of validation or processing not previously included in a requirement.

Those items marked as “change” are considered out of scope for this sow.

Review Summary

1. Clarification:Overview – Glossary- “Schedule/Re-Schedule of Block Create Event” addition

2. Clarification:FRS section 3.1.2, page 15 (NPAC Customer Data Model) - The following attributes have been added: NPAC New Functionality Support, Port in Timer Type, Port Out Timer Type, Business Hour/Days.

3. Clarification: Page 25,Section 3 Attribute Names:

Was NPA-NXX-X Holder SPID, now NPAC Customer ID.

Was Effective Date, now NPA-NXX-X Effective Date.

Was Creation Date, Now Creation Time Stamp.

Was Last Modified Date, now Last Modified Stamp.

4. Clarification: Page 28, N-70:Adds the phrase “or the addition of an NPA Split” to the actions affected by a validation error.  Also adds reference to requirement N-225 and N-301.

5. Clarification: Page 29, N-72.1:Default value now made dependent on current date/time.

6. Clarification: Page 29, N-73:Additional specification of field value.

7. Clarification: Page 29, N-74:specification to enter block routing data.

8. Clarification: Page 29, N-75.1:Additional specification of field validation.

9. Clarification: Page 30, N-76.1, N-76.3, N-77.1, N-77.2, N-77.3, N-78.1, N-78.2, N-78.3, N-79.1, N-79.2, N-79.3, N-79.4.

10. Clarification: Page 32, N-100:Addition of cause for request rejection.

11. Clarification: Page 34, N-160:Definition of scope for validation.

12. Clarification: Page 35, N-225:Requirement for additional verification.

13. Clarification: Page 37, N-297:Cleanup associated with deletion of other information.

14. Clarification: Page 38, N-302:Specification for field values.

15. Clarification: Page 39-40, N-320.2, N-320.3, N-321.1, N-321.2, N-321.3, N-322.1, N-322.2, N-322.3.

16. Clarification: Page 40, N-325:Specification of data to be broadcast.

17. Clarification: Page 41, N-365.

18. Clarification: Page 59, B-280, B-290, B-300, B-302, B-304, B-306, B-308:      Removal of requirements.

19. Clarification: Page 69, B-654.2: Specification of which value for field.

20. Clarification: Page 74, SV-2: List of notifications to suppress.

21. Change: Page 80, SV-240, SV-270, SV-280: Conditions for status update.  Remove “partial falure/failed” from SV-230, SV-240, SV-270 and SV-280 (to be added to existing change order NANC 227)

22. Clarification: Page 86, SV-430: Rewording.

23. Clarification: Page 89, SV-540, SV-550, SV-560, SV-570: Statement of non-dependency on status.

24. Clarification: Page 91, A-2-A-36: Regrouping of specifications and clarification of SVs handled by audit request.

25. Clarification: Page 93, A-110: Additional constraint.

26. Clarification: Page 94, RR9-7: Rewording of generality.

27. Clarification: Page 94, R-25, R-26: Additional report format and specification.

28. Clarification: Page 94, R-30, R-40: Title clarification and report constraint.

29. Clarification: Appendices C and E: Additions of tables and examples.

30. Change: Page 100: Modification of filename for block download. (Will be included in Release 3.0)

31. Clarification: Appendix G: Title nomenclature changes.

32. Add: N-266: The NPAC/SMS shall reject a request to delete (de-pool) an NPA-NXX-X if there is an SV with a status of sending as a result of a disconnect request.

33. Add: SV-249: The NPAC/SMS shall ensure that upon completion of an NPA-NXX-X delete (de-pool) there are no SVs of LNP type of POOL remaining in the 1k block.

34. Added test to N-365: NPAC/SMS shall provide to NPAC personnel only, an indicator on the NPAC Administrative Interface only after a query if an associated Block Create Scheduled Event, that has not been executed exists in the NPAC/SMS.

SOW 19NAPM

STATEMENT OF WORK
FOR

PORTING IN ERROR
AND
FAILURE TO PORT

1

PROPOSED STATEMENT OF WORK
PORTING IN ERROR AND FAILURE TO PORT
(under Agreement for NPAC/SMS Services)

1.INTRODUCTION; PARTIES.  This Statement of Work (this “SOW”) is entered into pursuant to Article 13 of, and on execution shall be a partof, the respective Agreement for Number Portability Administration Center / Service Management System, as amended as of the date hereto by all previous Statements of Work, including, but not limited to Statement of Work 25, for TN Price Reduction and Contract Update and Extension (collectively referred to for each of the respective limited liability companies listed below for the respective Service Areas, as a “Master Agreement”) between NeuStar (“Contractor”) and the respective limited liability companies listed below for the separate Service Areas (referred to individually as a “Subscribing Customer” and collectively as the “Subscribing Customers”):

North American Portability Management, LLC, on behalf of and as successor to the Subscribing Customers named therein:

LNP, LLC (Midwest)

Southwest Region Portability Company, LLC

Northeast Carrier Acquisition Company, LLC

Western Region Telephone Number Portability, LLC

Southeast Number Portability Administration Company, LLC

Mid-Atlantic Carrier Acquisition Company, LLC

West Coast Portability Services, LLC

This SOW shall be effective upon execution by Contractor and Subscribing Customer.  The number in the upper right hand corner refers to this SOW.  Capitalized terms used herein without definition shall have the meanings as defined in the Master Agreements.

The Additional Services contemplated under this SOW are not an Enhancement to the NPAC SMS as defined under the Master Agreement.

2.SCOPE OF ADDITIONAL SERVICES.  This SOW describes the work to be performed by Contractor during either of the two situations described below.

Situation # 1 – Porting in Error

Situation #1 shall be referred to in this SOW as the “Porting in Error Situation”.  In the Porting in Error Situation, a TN is ported from one Service Provider to another when it should not have been ported.  NPAC related activity has occurred to port the telephone number but there has been no network activity to actually move the customer’s service.

2

Situation # 2 – Failure to Port

Situation #2 shall be referred to in this SOW as the “Failure to Port Situation”.  In the Failure to Port Situation, a TN is not ported from one Service Provider to another Service Provider (referred to as the “New SP,” as defined below) when the TN should have been ported.  Network activity has been accomplished to move the customer’s service but there has been no NPAC related activity to port the telephone number.

3.KEY TERMS.

Initiating Service Provider (“Initiating SP”) –

•Porting in Error Situation – The Service Provider that is a User who contacts the NPAC and who either

1.Received the inadvertently ported TN; or

2.Gave the inadvertently ported TN.

•Failure to Port Situation – The Service Provider that is a User to whom the TN should have been ported (referred to as the “New SP”) who contacts the NPAC when the TN was  not ported.

Only Initiating SPs, as defined above, may request NPAC assistance, as set forth in this SOW.  Therefore, only the New SP in the Failure to Port Situation can request NPAC assistance, but either the Service Provider who received the inadvertently ported TN or gave the inadvertently ported TN may request NPAC assistance in the Porting in Error Situation.

Absent Service Provider (“Absent SP”) – The SP that is the Initiating SP and/or the NPAC attempt to contact in order to correct the Porting in Error Situation or the Failure to Port Situation.

Successful Contact of Absent SP –

•NPAC representative contacts and talks to Absent SP employee who, based upon NPAC records, is LNP knowledgeable and is capable of correcting  either the relevant Porting in Error Situation or the Failure to Port Situation.

Unsuccessful Contact of Absent SP – Any contact which is not a Successful Contact, including, but not limited to the following:

•NPAC representative reaches only voicemail;

•NPAC representative obtains a busy signal and there is no Successful Contact after 3 additional successive attempts as set forth below; or

•NPAC representative receives no answer and there is no Successful Contact after 3 additional successive attempts as set forth below.

•NPAC representative fails to contact the Absent SP after following the attempts described above, or during such attempts to contact the Absent SP contacts a Service Provider person who is not LNP knowledgeable and/or whom NPAC determines is incapable of correcting the Porting in Error Situation or the Failure to Port Situation.

3

NOTE:If NPAC representative contacts Absent SP, but such Absent SP refuses to correct the relevant Porting in Error Situation or Failure to Port Situation, then NPAC representative will NOT act upon the relevant Porting in Error Situation or the Failure to Port Situation.

4.PROCESS.

The process to be followed in the Porting in Error Situation or in the Failure to Port Situation is set forth in detail in the NeuStar Methods and Procedures for Porting in Error and Failure to Port (the “M&P”), attached hereto as Attachment B and expressly incorporated into this SOW in full.  The listing below in this SOW is intended as a guideline only and as a summary of the M&P.  In the event of any discrepancy or conflict between the listing below and the M&P, the terms of the M&P shall govern.  If the M&P is subsequently amended or revised in any way, such amendment or revision shall not automatically be incorporated into this SOW for any Service Area and shall not be applicable with respect to this SOW for that Service Area, unless Contractor and the Subscribing Customer for that Service Area agree in writing expressly to incorporate the terms of such amended or revised M&P into this SOW; otherwise, in the absence of such writing, the terms of the M&P prior to such amendment or revision shall continue to govern and to be applicable to this SOW.

1)Initiating SP will first attempt to contact Absent SP using the LNP Emergency Contact information.

2)If the Initiating SP is unable to contact the Absent SP, or if there is no emergency contact information available, the Initiating SP will contact the NPAC.  The Initiating SP must fill out the Emergency Action Form  (EAF), which is located on the Secure Web (www.npac.com/secure).  When the EAF is completed, the Initiating SP will provide it to the NPAC, via the Secure Web.  The EAF provides the NPAC with all relevant contact information, except in the event the Initiating SP asserts that there is no emergency contact information available.  In all cases, the NPAC will attempt to determine the Absent SP based upon both the EAF and the NPAC records.  The EAF will also identify the Initiating SP for purposes of this SOW.  A copy of the EAF is included in this SOW as Attachment A.

3)NPAC representative will attempt to contact the Absent SP based upon both the emergency contact information provided by the Initiating SP and any other NPAC internal records.  If a Successful Contact is made, NPAC representative will advise the Absent SP to contact the Initiating SP within 30 minutes and will notify the Initiating SP of the contact status.  NPAC representative will also advise the Absent SP of subsequent action (as set forth in Section 4, part (6) herein) that will be taken by the NPAC without further notice if the Initiating SP does not receive a response from the Absent SP within 30 minutes.

4)If NPAC representative is unable to make a Successful Contact  within 30 minutes following the first attempt, or if the Absent SP fails to contact the Initiating SP within 30 minutes after Successful Contact and the Initiating SP advises the NPAC of such failure,  without the need

4

to verify such failure of the Absent SP to contact the Initiating SP and in reliance upon such notice from the Initiating SP, the NPAC will do one of the following:

a)Porting in Error Situation/ Initiating SP is old SP (SP who lost the TN in error) – NPAC does “Disconnect” or “old SP Create (concur)”

b)Porting in Error Situation/ Initiating SP is New SP (SP who received the TN in error) – NPAC does “new SP Create”

c)Failure to Port Situation/ Initiating SP is New SP (SP who failed to receive the TN) – NPAC does “old SP Create (concur)”

* NPAC may, in its sole discretion, determine whether a “Disconnect”, “old SP Create (concur)” or “new SP Create” is appropriate.

5)NPAC representative will notify the Absent SP of the action taken (voice mail, e-mail, or other method.).  NPAC representative will provide a copy of the completed EAF to both the Initiating SP and the Absent SP and NPAC will maintain a copy in its own records for a period of not less than one year.

This process only addresses conditions when an Initiating SP is unable to contact an Absent SP to undo an inadvertent port or to complete a failed port.  The NPAC will only be contacted after all other avenues fail.  Service Providers must first make a concerted effort to contact each other during either of these conditions.

The Contractor will not be considered to be acting under this SOW as a representative for any Service Provider but merely to be performing those Additional Services as requested by a Service Provider in accordance with this SOW.

This process requires all Service Providers to use the same identification method when interfacing with the NPAC.  This requires the Initiating SP and the Absent SP to supply their SPID numbers, caller name and Authorization PIN for their company.  The NPAC representative will then verify this information.  If the Initiating SP’s name is not on the Authorization list or does not have the correct matching PIN, the NPAC will not assist the Initiating SP to perform the process as set forth in this SOW.

Unless specifically stated within this SOW (e.g., the Emergency Action Form – EAF), all notices and other communications shall be in accordance with Section 27.6 of the Master Agreement, as amended by SOW 25 – T/N Price Reduction And Contract Update And Extension.

5.OUT OF SCOPE SERVICES.

This SOW contains the agreed upon terms and conditions that shall govern Contractor’s performance of the Services described herein.  The Services provided for in this SOW and for which Contractor shall be compensated in accordance with Section 9, herein, shall not be interpreted, implied, or assumed to include any other Service(s), including additional or changed services, not specifically described in this Section 2, Scope of Additional Services.  Any and all requested or required services or change orders (hereinafter “Out of Scope Services”) may be provided in accordance with the Master Agreement and, specifically, Section 13, Additional Services.

5

6.PROJECT SCHEDULE.  These changes will become effective upon execution of this SOW by Contractor and all Subscribing Customers.No other schedule is required or applicable.

7.COMPLETION AND ACCEPTANCE CRITERIA.  The following internal documents are applicable to the Additional Services contemplated under this SOW:

N/A	Functional Requirements Specifications
N/A	Requirements Traceability Matrix
N/A	External Design
N/A	System Design
N/A	Detailed Design
N/A	Integration Test Plan
N/A	System Test Plan
N/A	Software Quality Assurance Program Report
N/A	User Documentation
N/A	Software Configuration Management Plan
N/A	Standards and Metrics

8.IMPACTS ON MASTER AGREEMENT (INCLUDES EXISTING SPECIFICATIONS).

None	Master Agreement
None	Exhibit B Functional Requirements Specification
None	Exhibit C Interoperable Interface Specification
	Exhibit E Pricing Schedules
None	Exhibit F Project Plan and Test Schedule
None	Exhibit G ServiceLevel Requirements
None	Exhibit H Reporting and Monitoring Requirements
None	Exhibit J User Agreement Form
None	Exhibit K External Design
None	Exhibit L Infrastructure/Hardware
None	Exhibit N System Performance Plan for NPAC/SMS Services

9.PRICING

9.1Obligation.  Upon execution of this SOW, Contractor shall be entitled to full compensation for Additional Services described herein in the amounts and on the terms and conditions described below.  For the purposes of and in accordance with Section 23.3 (“Users’ Liability for Payments”) of the Master Agreement, these Additional Services shall be considered by all Users to be services performed prior to any effective date of termination. Accordingly and notwithstanding any other provisions to the contrary in the Master Agreement or any exhibit attached thereto, in the event any amounts owed pursuant to this SOW remain outstanding upon

6

any termination or expiration of the Master Agreement or this SOW, such amounts shall be immediately due and payable by the charged User(s) as provided for herein.

This quote is valid for 60 days from the date shown in the header of this SOW.

9.2Price for Recurring Items.

The price for the recurring portion of this SOW is outlined in the table below as a flat fee, referred to as the Recurring Price.  This flat fee is separate and apart from any compensation and payment terms within the Master Agreements or any attachments thereto, including Exhibit E to the Master Agreements, as amended.  Specifically, the payments provided for in this SOW shall not be applied against the Annual Target Amounts referred to in the Master Agreement.  The price does not include any non-recurring items.  Payment for the recurring portion will commence upon execution of this SOW and will continue throughout the duration of the Master Agreement.

Contractor will bill all End-Users for the Recurring Price, and neither the Subscribing Customers nor any one of them shall be liable or responsible for payment of any amount of the Recurring Price.  As used under this SOW, “End-Users” shall mean all telecommunications carrier that are subject to local number portability contribution requirements and file Telecommunications Worksheets, FCC Form 499-A.

Comparison of Recurring Price Charges based upon possible 1 Region versus 8 Regions participation

	If only One Region				If All Eight Regions (including Canada)
	Per month		Per year		Per month		Per year
Recurring Price	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]

Number of Regions participating	Monthly Recurring Price Per Region
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]

7

9.3Price for Non-Recurring Items.

The price for the non-recurring portion of this SOW (referred to as Non-Recurring Price”) is listed below.  This is a per User per Event specific charge for each Porting in Error Situation or each Failure to Port Situation to which the NPAC responds pursuant to this SOW.  For purposes of this SOW, an “Event” shall be considered the submission of an EAF.  Each EAF submission shall be for only one Absent SP.  Each single EAF submission may include up to 15 items and still be considered a single Event for purposes of the Non-Recurring Price; whereas a single item shall be considered either an individual TN or a range of TNs.  Notwithstanding anything to the contrary, no Billable NPAC User Support Manual Requests or NPAC User Contacts shall be considered to apply or to have occurred and no charges other than the Non-Recurring Price shall be imposed or chargeable therefor with respect to the submission of an EAF.  The Initiating SP is responsible to pay the Non-Recurring Price to Contractor.

	Per Event
Non-Recurring Price	$	[* * *]

9.4Payment Terms

Invoicing:

Contractor shall prepare invoices (separate from Master Contract invoicing, but which may include invoicing for other SOW charges) on the last day of a calendar month and send to each User for the amount of its User Charges.  Contractor shall also prepare and deliver to Customer a report (the “Monthly Summary of Charges”) setting forth the billing calculation for Recurring Price and Non-Recurring Price under this SOW for each User in the Service Area, and for all Users within the Service Area.  All invoices shall be due and payable within Thirty (30) days of the date of the invoice.   Late payments will be subject to a 1.25% interest charge per month, or, if lower, the maximum rate permitted by law.

With respect to End-Users that are not Users (individually a “Non-User” and collectively, “Non-Users”), Contractor shall prepare invoices (separate from Master Contract invoicing, but which may include invoicing for other SOW charges) on the last day of a calendar quarter and send to each Non-User for the amount of its charges.  Contractor shall also prepare and deliver to Customer a report (the “Monthly Summary of Charges”) setting forth the billing calculation above for each Non-User in the Service Area, and for all Non-Users within the Service Area.  All invoices shall be due and payable within thirty (30) days of the date of the invoice.  Late

8

payments will be subject to a 1.25% interest charge per month, or, if lower, the maximum rate permitted by law.

Collections and remedies for those carriers and other entities that are Users (including without limitation that disputes be resolved by arbitration as specified in Article 13 of the User Agreement) will be as defined in their User Agreement.

Any billing disputes shall be promptly presented to Contractor in reasonable detail, in writing.  Any requests for adjustment shall not be cause for delay in payment of the undisputed balance due, except that a User may withhold payment of any amounts which are subject to a bona fide dispute; provided it shall pay all undisputed amounts owing to Contractor that have been separately invoiced to User.  If re-invoice occurs following the thirty (30) day payment schedule, such invoice for the undisputed amount shall be paid within ten (10) business days of receipt by User.  User and Contractor shall seek to resolve any such disputes expeditiously, but in any event within less than thirty (30) days after receipt of notice thereof.  All disputed amounts ultimately paid or awarded to Contractor shall bear interest from the thirtieth (30^th) day following the original invoice.

Notwithstanding the foregoing, User may not withhold payment of any amounts invoiced by Contractor based solely upon a dispute between Customer and User concerning how User is allocated charges under the Allocation Model.

The payments provided for in this Section shall not be applied against the Annual Target Amounts referred to in the Master Agreement.

Taxes:

User is to remit to or reimburse Contractor for any taxes that a User is obligated to pay by law, rule or regulation or under this Agreement or its respective NPAC/SMS User Agreement.

Assignment of Monies Due:

As provided in Section 22.2 of the Master Agreement, Contractor may, upon written notice to Customer, assign monies due or that are to become due under a Statement of Work, provided that no such assignment may impose upon Customer or Users any obligations in addition to or different than those set forth in the Master Agreement, this SOW or the other Statements of Work, or preclude Customer or Users from dealing solely and directly with Contractor in all matters pertaining to the Master Agreements, this SOW or other Statements of Work, including the negotiation of amendments and the settlement of disputed invoices.

10.CONTINUATION OF MASTER AGREEMENT AND USER AGREEMENT.  Except as specifically modified and amended hereby (including by the SOW Specifications where applicable), all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms.  From and after the date hereof, any reference in either the Master Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to

9

any time from and after the date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit as modified and amended by this SOW.  From and after the effectiveness of this SOW, this SOW shall be a part of the Master Agreement and, as such, shall be subject to the terms and conditions therein.

11.TERMINATION.

NOTWITHSTANDING ANYTHING TO THE CONTRARY, EACH SUBSCRIBING CUSTOMER MAY TERMINATE THIS SOW WITH RESPECT TO SUCH SUBSCRIBING CUSTOMER’S SERVICE AREA FOR ANY OR NO REASON BY PROVIDING CONTRACTOR A NINETY (90) DAY PRIOR WRITTEN NOTICE.

12.LIABILITY.

CONTRACTOR SHALL NOT BE LIABLE TO ANY USER OR SUBSCRIBING CUSTOMER FOR ANY DIRECT DAMAGES ARISING OUT OF OR RELATING TO A BREACH OF ITS OBLIGATIONS WHILE PERFORMING UNDER THE PROCESS DEFINED IN THIS SOW, EXCEPT FOR INTENTIONAL MISCONDUCT.  IN ADDITION, NO USER OR SUBSCRIBING CUSTOMER MAY ASSERT OR CLAIM A VIOLATION OF NEUTRALITY AS DEFINED IN THE MASTER AGREEMENT RELATED TO THIS SOW, PROVIDED THAT CONTRACTOR’S CONDUCT IS IN MATERIAL COMPLIANCE WITH THE PROCESS DEFINED IN THIS SOW.

IN ADDITION TO ANY DIRECT DAMAGES UNDER THE IMMEDIATELY PRECEDING PARAGRAPH, CONTRACTOR SHALL ISSUE THE INITIATING SP A REFUND EQUAL TO THE NON-RECURRING EVENT CHARGE, AS DESCRIBED IN SECTION 9.3 OF THIS SOW. IN THE EVENT CONTRACTOR IS GROSSLY NEGLIGENT OR ENGAGES IN INTENTIONAL MISCONDUCT THAT RESULTS IN CONTRACTOR FAILING TO PERFORM A REQUEST FROM THE INITIATING SP PURSUANT TO THE TERMS SET FORTH IN THIS SOW.

UPON EXECUTION OF THIS SOW, ALL ACTIONS TAKEN BY CONTRACTOR ON BEHALF OF THE INITIATING SP OR ABSENT SP WILL BE DEEMED TO HAVE NO IMPACT ON CONTRACTOR’S STATUS AS A NEUTRAL THIRD PARTY UNDER THE MASTER AGREEMENT NOR WILL SUCH ACTIONS BE CONSIDERED TO VIOLATE THE CONTRACTOR’S CODE OF CONDUCT UNDER THE MASTER AGREEMENT, SO LONG AS SUCH ACTIONS ARE IN MATERIAL COMPLIANCE WITH THE PROCESS SET FORTH IN THIS SOW.

13.ENTIRE AGREEMENT.  This SOW sets forth the entire understanding between the Parties with regard to the subject matter hereof and supercedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.

10

14.JOINDER.  If at any time hereafter a Customer, other than a Subscribing Customer desires to become a Subscribing Customer such Customer may become a Subscribing Customer by executing a joinder agreeing to be bound by the terms and conditions of this SOW, as modified from time to time.  A Customer executing such a joinder shall share in the payment of the price of the Additional Services provided for herein in a fair and equitable manner, and in no event in excess of the payments which would have been incurred had such Customer been a Subscribing Customer at the time of effectiveness of this SOW, excluding any incremental work borne by the Contractor in order to properly implement the Additional Services provided herein.

15.COUNTERPARTS.  This SOW may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed thesame document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

IN WITNESS WHEREOF, the undersigned have executed this Statement of Work 19 – Porting in Error and Failure to Port as of                            , 2002.

Contractor:

NeuStar, Inc.

By:

Name:

Title:

Customer:

North American Portability Management, LLC

By:

Name:

Title:

By:

Name:

Title:

11

Attachment A

Emergency Action Form (EAF)

1

EMERGENCY ACTION FORM

Initiating SP must complete items 1 through 5
on this EAF for the process to continue

BY SUBMITTING THIS FORM, THE INITIATING SP (I) UNDERSTANDS THIS IS CONSIDERED AN EVENT AND THEREFORE INITIATING SP SHALL BE RESPONSIBLE TO PAY NEUSTAR, INC. (“CONTRACTOR”) THE NON-RECURRING PRICE OF $[* * *] PER FORM SUBMITTED UP TO 15 TN’S, 15 RANGES OF TN’S, OR ANY COMBINATION THERE OF.

IN ADDITION, IN CONSIDERATION OF CONTRACTOR PERFORMING THE SERVICES HEREUNDER, INITIATING SP AGREES TO THE FOLLOWING:

CONTRACTOR SHALL NOT BE LIABLE TO INITIATING SP FOR ANY DIRECT DAMAGES ARISING OUT OF OR RELATING TO A BREACH OF ITS OBLIGATIONS WHILE PERFORMING UNDER THE PROCESS DEFINED IN SOW 19, EXCEPT FOR INTENTIONAL MISCONDUCT.  IN ADDITION, INITIATING SP MAY NOT ASSERT OR CLAIM A VIOLATION OF NEUTRALITY AS DEFINED IN THE MASTER AGREEMENT  RELATED TO THIS SOW, PROVIDED THAT CONTRACTOR’S CONDUCT IS IN MATERIAL COMPLIANCE WITH THE PROCESS DEFINED IN SOW 19.

IN ADDITION TO ANY DIRECT DAMAGES UNDER THE IMMEDIATELY PRECEDING PARAGRAPH, CONTRACTOR SHALL ISSUE THE INITIATING SP A REFUND EQUAL TO THE NON-RECURRING EVENT CHARGE AS DESCRIBED IN SECTION 9.3 OF THIS SOW IN THE EVENT CONTRACTOR IS GROSSLY NEGLIGENT OR ENGAGES IN INTENTIONAL MISCONDUCT THAT RESULTS IN CONTRACTOR FAILING TO PERFORM A REQUEST FROM USER PURSUANT TO THE TERMS SET FORTH IN SOW 19.

ALL ACTIONS TAKEN BY CONTRACTOR ON BEHALF OF THE INITIATING SP OR ABSENT SP WILL BE DEEMED TO HAVE NO IMPACT ON CONTRACTOR’S STATUS AS A NEUTRAL THIRD PARTY UNDER THE MASTER AGREEMENT NOR WILL SUCH ACTIONS BE CONSIDERED TO VIOLATE THE CONTRACTOR’S CODE OF CONDUCT UNDER THE MASTER AGREEMENT, SO LONG AS SUCH ACTIONS ARE IN MATERIAL COMPLIANCE WITH THE PROCESS SET FORTH IN SOW 19.

INITIATING SP SHALL DEFEND, INDEMNIFY AND HOLD HARMLESS CONTRACTOR, ITS DIRECTORS, OFFICERS, EMPLOYEES AND AFFILIATES FROM ANY AND ALL CLAIMS, DEMANDS, SUITS, ACTIONS, CAUSES OF ACTION, DAMAGES, LIABILITIES, JUDGMENT, FINES, PENALTIES, EXPENSES AND REASONABLE FEES FOR ATTORNEYS (INCLUDING ALLOCATED IN-HOUSE

COSTS), INCLUDING THOSE BASED ON CONTRACT OR TORT, ARISING OUT OF, RELATING TO OR IN CONNECTION WITH THE INTENTIONAL MISCONDUCT OR GROSS NEGLIGENCE OF THE INITIATING SP IN THE DISCHARGE OF ITS  OBLIGATIONS UNDER SOW 19.

1.	Date:
2.	Initiating SP:
	SPID
	SP Person Name
	SP Person Phone
	SP Authorization PIN
3.	Initiating SP First Contact Attempt:			Date
				Time
	Initiating SP Second Contact Attempt:			Date
				Time
4.	Errant TN(s)		(1)		(6)	(11)
	or Range(s)		(2)		(7)	(12)
			(3)		(8)	(13)
			(4)		(9)	(14)
			(5)		(10)	(15)
		Initiating SP
		Absent SP

5.	Absent SP Contact Info:			Name
				TN
				Pager
6.	NPAC Contact Attempt:			Date
				Time (1)
				Time (2)
				Time (3)
7.	Contact Successful			Yes		No
	SPID
	SP Person Name
	SP Authorization PIN
8.	If No -
		NPAC Create	Date		Time
		SV Activate	Date		Time
9.	Absent SP Notification
		email address:
		Date:
		Time:
10.	Trouble Ticket Number

11. Comments:

NOTES:

1.Date – date of request

2.Initiating SP – SPID of the SP making this emergency request and required NPAC identification information.

3.Initiating SP Contact Attempts – details of Initiating SP contacts attempted prior to contacting NPAC.

4.TN –

Porting in Error Condition – the subscription version(s)/telephone number(s) in question.  This would be reflected in the NPAC database as active/partial failed records with the Absent SP SPID.

Failure to Port Condition: - only TN required.

5.Absent SP Contact Info – Initiating SP must provide the contact info used in their efforts to reach the Absent SP.

6.NPAC contact – NPAC representative should validate that Initiating SP has current/valid contact data for the Absent SP.

7.Contact Successful - Note: SOW 19 defines “successful” contact.  If NPAC representative is able to contact someone that person must be LNP knowledgeable, i.e. they must be able to make requested change ASAP.  The LNP knowledgeable person must also be able to provide their SPID number, Name and Authorization PIN for their company.  If NPAC representative contacts Service Provider person who is LNP knowledgeable and is capable of correcting the port condition but refuses to correct the condition, then NPAC representative will NOT correct the port condition in this situation.

8.Contact Unsuccessful – Note: SOW 19 defines “unsuccessful” contact.  NPAC representative creates SV in lieu of Absent SP action unless the NPAC contacts an LNP knowledgeable person who refuses to correct the port condition.  The transaction date and time will be noted on the form.

9.Absent SP Notification – NPAC representative will notify the Absent SP of actions taken.  This notification will be by email or fax depending on the contact info the SP has provided.  This data will be noted on the form.

10.Trouble Ticket Number - NPAC will create a Trouble Ticket during this process.  The Ticket number will be used for reference on subsequent calls regarding the same issue.

11.Comments – Include any other pertinent information to thoroughly document process.

* NPAC will retain the completed EAF for a period of no less than 12 months.

Attachment B

Methods and Procedures (M&P)

STATEMENT OF WORK

FOR

CONTINUING CERTIFICATION PROCESS
(CCP)

UNDER AGREEMENT NPAC/SMS

STATEMENT OF WORK
FOR
Continuing Certification Process (CCP)
Under Agreement for NPAC/SMS

1.PARTIES & EFFECTIVITY.

This Statement of Work (this “SOW”) is entered into pursuant to Article 13 of, and on execution shall be a part of, the respective Agreement for Number Portability Administration Center/Service Management System (each, a “Master Agreement”) by and between NeuStar, Inc. (“Contractor”) and the respective limited liability companies indicated below (the “Subscribing Customers”):

North American Portability Management, LLC (“NAPM”), as successor to each of:

•LNP, LLC (Midwest)

•Southwest Region Portability Company, LLC

•Northeast Carrier Acquisition Company, LLC

•Western Region Telephone Number Portability, LLC

•Southeast Number Portability Administration Company, LLC

•Mid-Atlantic Carrier Acquisition Company, LLC

•West Coast Portability Services, LLC

This SOW shall be effective only upon execution by Contractor and all of the Subscribing Customers.  The number in the upper right hand corner refers to this SOW.  Capitalized terms used herein without definition shall have the meanings as defined in the Master Agreements.

2.SCOPE OF ADDITIONAL SERVICES.

2.1 No Enhancements.

The Additional Services set forth in this SOW are not an Enhancement to the NPAC/ SMS as defined under the Master Agreement.

2.2 Purpose.

The Additional Services ensure that all Users are maintaining a system that does not impact the NPAC/SMS and other providers when the NPAC software application is changed or modified as required under any other statement of work.  Users’ systems must support new NPAC/SMS Software releases agreed to by the NANCand the NAPM.  User systems that do not meet these requirements may be a significant inhibitor of systems operations and efficiency for local number portability across the industry.  This Article defines the requirements for ensuring that all Users are maintaining a system that does not adversely impact the NPAC/SMS and other providers when the NPAC software application is changed.  This SOW defines the process to ensure certification for NPAC/SMS Software releases agreed

to by the Subscribing Customers and as implemented by Contractor, including but not limited to SOW 15 - Release 3.0.

2.3 Continuing Certification Testing.

Each User shall satisfactorily complete User Continuing Certification Testing (“CCT”) provided for in each SOW.  A User shall not establish or maintain an active association with the NPAC following the production release of a software version subject to each SOW, unless and until User shall have satisfactorily completed the CCT.

2.4 Initial Suspension.

If a User does not satisfactorily complete such CCT at least five (5) days prior to a new production release of the NPAC/SMS Software, as defined by the NPAC/SMS Release project plan, and such User has not voluntarily agreed to suspend its association with the NPAC/SMS at least one (1) day prior to the new production release date, then the Contractor may suspend the User’s association and User shall not be allowed to re-establish its association unless or until User has completed CCT (the “Initial Suspension”).  Contractor shall notify the appropriate Subscribing Customer or Project Executive of the date such Initial Suspension occurred.  During any suspension of User’s association in accordance with this SOW, User shall remain obligated with respect to all charges as would otherwise be charged under the Master Agreement and User Agreement.

If a User fails to complete CCT within the time allotted, as per the NPAC/SMS Release project plan, and Contractor has suspended such User’s association, then Contractor shall notify User that User has thirty (30) calendar days (the “Initial Suspension Period”), from receipt of such notification in which to complete CCT.  During the Initial Suspension Contractor shall furnish one (1) bulk data download (“BDD”) per applicable NPAC region per day without charge and User shall accept and install such BDD.  Upon expiration of the Initial Suspension period, Contractor shall have the right to exercise one (1) of the following options (Contractor may consult with Subscribing Customers on a case-by-case basis about which option is selected.):

Option 1 - Continued Suspension

After the Initial Suspension period Contractor may elect to continue the User Agreement by providing notice no later than the end of the Initial Suspension Period, and thus continue providing User with BDDs (the “Continued Suspension Period”).  In such a case, Contractor shall provide one (1) BDD per applicable NPAC region per day for a fee (see Exhibit E, attached, for pricing) and User shall accept and install such BDD.

Option 2 - Termination

The User Agreement shall terminate if Contractor (a) does not elect during the Initial Suspension Period to continue the User Agreement or (b) provides notice of termination during any Continued Suspension Period.  User shall be charged and be liable for all fees associated with subsequently establishing service as a new User in accordance with the requirements of the then extant User Agreement.

2.5 Amendment to Section 10.1(e) of User Agreement

The User Agreement is hereby amended to add a new paragraph (e) to Subsection 10.1 (“Termination”), reading, in its entirety, as follows:

(e)immediately, upon  the expiration of a thirty (30) day period following receipt of written notice from Contractor that the User has not satisfactorily completed Continuing Certification Testing, unless Contractor elects, at its option, to continue the User Agreement, notice of which must be provided to the User no later than the end of the forgoing thirty (30) day period, until Contractor otherwise terminate the User Agreement upon written notice..

2.6 Requirements for Interoperability Testing.

ITP must be performed on a SOA/LSMS Developer’s software anytime that a change is made to the interface (GDMO or ASN.1) of either the NPAC SMS or the Developer’s SOA/LSMS.  In the event that the interface change is initiated by the NPAC SMS, the SOA/LSMS Developers shall perform ITP on each version of SOA/LSMS software that may potentially be used by Users with the new NPAC SMS interface.

The following outlines the required level of testing for specific scenarios:

(a)When a local product (SOA/LSMS) is compiled with the current interface model, and a new local feature (SOA/LSMS feature) is implemented that does NOT involve a change in the use of the interface model, and the NPAC SMS is compiled with the current model, then no ITP testing is required.

(b)When a local product is compiled with the current interface model, and no new local features implemented, and the NPAC SMS is compiled with the new interface model, then ITP testing is required [standard regression test cases].

(c)When a local product is compiled with the new interface model, and no new local features implemented, and the NPAC SMS is compiled with the new interface model, then ITP testing is required [standard regression test cases].

(d)When a local product is compiled with the new interface model, and new local features are implemented that involve the interface, and the NPAC SMS is compiled with the new interface model, then ITP testing is required [standard regression test cases and new functionality test cases].

(e)When a local product is compiled with the current interface model, and new local features are implemented that involve the interface, and the NPAC SMS is compiled with the current model, then ITP testing is required [new functionality test cases].  Note: the regression test cases would have been addressed when the vendor upgraded the local product to the current version of the interface model.

2.7 Requirements for Turn-Up Testing.

Turn-Up Testing, which includes new NPAC SMS software release functionality testing and regression testing, must be performed on a Service Provider’s SOA/LSMS software anytime that a change is made

to the interface (GDMO or ASN.1) of the NPAC SMS.  In the event that the interface change is initiated by the NPAC SMS, the Users shall perform Turn-Up Testing on each version of SOA/LSMS software that may potentially be used with the new NPAC SMS interface.

If any of the following scenarios apply, Turn-Up Testing is required by Users.  The following outlines the required level of testing for specific scenarios:

(a)When a local product (SOA/LSMS) is compiled with the current interface model, and a new local feature (SOA/LSMS feature) is implemented that does NOT involve a change in the use of the interface model, and the NPAC SMS is compiled with the current model, then Turn-Up Testing is optional.  Test cases to be performed at the discretion of User. [standard regression test cases].

(b)When a local product is compiled with the current interface model, and no new local features are implemented that involve the interface, and the NPAC SMS is compiled with the new interface model, then Turn-Up Testing is required [standard regression test cases].

(c)When a local product is compiled with the new interface model, and no new local features are implemented that involve the interface, and the NPAC SMS is compiled with the new interface model, then Turn-Up Testing is required [standard regression test cases].

(d)When a local product is compiled with the new interface model, and new local features are implemented that involve the interface, and the NPAC SMS is compiled with the new interface model, then Turn-Up Testing is required [standard regression test cases and new functionality test cases].

(e)When a local product is compiled with the current interface model, and new local features are implemented that involve the interface, and the NPAC SMS is compiled with the current model, then Turn-Up Testing is required [standard regression test cases and new functionality test cases].

3.OUT OF SCOPE SERVICES.

This SOW contains the agreed upon terms and conditions that shall govern Contractor’s performance of the services described herein.  The services provided for in this SOW and for which Contractor shall be compensated in accordance with Section 6, herein, shall not be interpreted, implied, or assumed to include any other service(s), including additional or changed services, not specifically described in Section 2, Scope of Additional Services.  Any and all requested or required services or change orders (hereinafter “Out of Scope Services”) may be provided in accordance with the Master Agreement and, specifically, Section 13, Additional Services.

4.PROJECT SCHEDULE.

The schedule set forth in the following table is a summary of tasks and time frames for implementation:

Phase	Summary Milestone	Interval
Phase 0.0	Statement of Work Effective	Week 0
Phase 1.0	Develop Communication and Education Plan	Week 1
Phase 2.0	Notify Subscribing Customers of CCP Procedures	Week 2

5.COMPLETION AND ACCEPTANCE CRITERIA.

The following internal documents are applicable to the Additional Services contemplated under this SOW:

N/A	Functional Requirements Specifications
N/A	Requirements Traceability Matrix
N/A	External Design
N/A	System Design
N/A	Detailed Design
N/A	Integration Test Plan
N/A	System Test Plan
N/A	Software Quality Assurance Program Report
N/A	User Documentation
N/A	Software Configuration Management Plan
N/A	Standards and Metrics

6.IMPACTS ON MASTER AGREEMENT (INCLUDES EXISTING SPECIFICATIONS).

None	Master Agreement
None	Exhibit B Functional Requirements Specification
None	Exhibit C Interoperable Interface Specification
	Exhibit E Pricing Schedules
None	Exhibit F Project Plan and Test Schedule
None	Exhibit G ServiceLevel Requirements
None	Exhibit H Reporting and Monitoring Requirements
	Exhibit J User Agreement Form
None	Exhibit K External Design
None	Exhibit L Infrastructure/Hardware
None	Exhibit N System Performance Plan for NPAC/SMS Services

7.PRICING.

7.1 Obligation.

Upon execution of this SOW, Contractor shall be entitled to full compensation for Additional Services described herein in the amount and on the terms and conditions described below. Such compensation

shall be the obligation of each User.  For the purposes of and in accordance with Section 23.3 (“Users’ Liability for Payments”) of the Master Agreement, these Additional Services shall be considered by all Users to be services performed prior to any effective date of termination. Accordingly and notwithstanding any other provisions to the contrary in the Master Agreement or any exhibit attached thereto, in the event any amounts owed pursuant to this SOW remain outstanding upon any termination or expiration of the Master Agreement or this SOW, such amounts shall be immediately due and payable by the charged User(s) as provided for herein.

7.2 CCP Option Pricing.

Pricing under this SOW is set forth in the Pricing Exhibit, which amends Exhibit E, Schedule 1, Category 2 of the Master Agreement.

7.3 Payment.

Contractor shall prepare invoices (separate from Master Agreement invoicing, but which may include invoicing for other SOW charges) on the last day of a calendar month and send to each User for the amount of its User Charges.  Contractor shall also prepare and deliver to Customer a report (the “Monthly Summary of Charges”) setting forth the billing calculation above for each User in the Service Area, and for all Users within the Service Area.  All invoices shall be due and payable within thirty (30) days of the date of the invoice.   Late payments will be subject to a one and one quarter percent (1.25%) interest charge per month, or, if lower, the maximum rate permitted by law.

7.4 Collections & Remedies.

Collections and remedies for those carriers and other entities that are Users (including without limitation that disputes be resolved by arbitration as specified in Article 13 of the User Agreement) will be governed by the User Agreement.

7.5 Disputes. Any billing disputes shall be promptly presented to Contractor in reasonable detail, in writing.  Any requests for adjustment shall not be cause for delay in payment of the undisputed balance due. User may withhold payment of any amounts which are subject to a bona fide dispute; provided it shall pay all undisputed amounts owing to Contractor that have been separately invoiced to User.  If re-invoice occurs following the thirty (30) day payment schedule, then such invoice for the undisputed amount shall be paid within ten (10) business days of receipt by User.  User and Contractor shall seek to resolve any such disputes expeditiously, but in any event within less than thirty (30) days after receipt of notice thereof.  All disputed amounts ultimately paid or awarded to Contractor shall bear interest from the thirtieth (30^th) day following the original invoice

7.6 No Withholding.

Notwithstanding the foregoing, User may not withhold payment of any amounts invoiced by Contractor based solely upon a dispute between Customer and User concerning how User is allocated charges under the Allocation Model.

7.7 Annual Target Amounts.

The payments provided for in this Section shall not be applied against the Annual Target Amounts referred to in the Master Agreement.

7.8 Taxes.

User is to remit to or reimburse Contractor for any taxes that a User is obligated to pay by law, rule or regulation or under this Agreement or its respective NPAC/SMS User Agreement.

7.9 Assignment of Monies Due.

As provided in Section 22.2 of the Master Agreement, Contractor may, upon written notice to Customer, assign monies due or that are to become due under a Statement of Work, provided that no such assignment may impose upon Customer or Users any obligations in addition to or different than those set forth in this Agreement or the subject Statement of Work, or preclude Customer or Users from dealing solely and directly with Contractor in all matters pertaining to this Agreement or the subject Statement of Work, including the negotiation of amendments and the settlement of disputed invoices.

8.CONTINUATION OF MASTER AGREEMENT AND USER AGREEMENT.

Except as specifically modified and amended hereby (including by the SOW Specifications where applicable), all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms.  From and after the date hereof, any reference in either the Master Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit as modified and amended by this SOW.  From and after the effectiveness of this SOW, this SOW shall be a part of the Master Agreement and, as such, shall be subject to the terms and conditions therein.

9.JOINDER.

If at any time hereafter a Customer, other than a Subscribing Customer desires to become a Subscribing Customer such Customer may become a Subscribing Customer by executing a joinder agreeing to be bound by the terms and conditions of this SOW, as modified from time to time.  A Customer executing such a joinder shall share in the payment of the price of the Additional Services provided for herein in a fair and equitable manner, and in no event in excess of the payments which would have been incurred had such Customer been a Subscribing Customer at the time of effectiveness of this SOW, excluding any incremental work borne by the Contractor in order to properly implement the Additional Services provided herein.

10.COUNTERPARTS.

This SOW may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed thesame document.  All such counterparts

shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

11.ENTIRE AGREEMENT.

This SOW sets forth the entire understanding between the Parties with regard to the subject matter hereof and supercedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.

IN WITNESS WHEREOF, the undersigned have executed this Statement of Work:

CONTRACTOR:

NEUSTAR

By:

Its:

Date:

SUBSCRIBING CUSTOMERS:

NORTH AMERICAN PORTABILITY MANAGEMENT, LLC

By:

Its:

Date:

By:

Its:

Date:

PRICING EXHIBIT

AMENDING SCHEDULE 1, CATEGORY 2 OF EXHBIT E OF THE MASTER AGREEMENT

Category	Service Element	Unit	Price
	[* * *]	[* * *]	[* * *]
	[* * *]	[* * *]	$	[* * *]

STATEMENT OF WORK
FORT/N PRICE REDUCTION AND CONTRACT UPDATE AND EXTENSION

December 1, 2000 SOW 25NE

STATEMENT OF WORK
(Northeast Region Service Area)

1.  INTRODUCTION; PARTIES.  This Statement of Work (referred to herein as “this SOW” and referred to in the Master Agreement, as defined below, as “SOW 25NE”) is entered into pursuant to Article 13 and Article 30 of, and on execution shall be a part of, the Agreement for Number Portability Administration Center / Service Management System (the “Master Agreement”) between NeuStar, Inc., a Delaware corporation (“Contractor”), and the North American Portability Management LLC, a Delaware limited liability company (the “Customer”), as the successor to the Northeast Carrier Acquisition Company, LLC, a New York limited liability company.

2.  SOW EFFECTIVE DATE.  This SOW shall be effective with respect to the Contractor and the Customer only on execution by Contractor and Customer in accordance with Article 30 of the Master Agreement, and the date this SOW becomes effective shall be the “SOW Effective Date.”  Except as otherwise specified herein, the provisions of this SOW shall be effective as of the SOW Effective Date.  The number in the upper right hand corner refers to this SOW.  Unless otherwise explicitly defined herein, capitalized terms used herein shall have the meanings as defined in the Master Agreement.

3.  CONSIDERATION RECITAL.  In consideration of the terms and conditions set forth in this SOW, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, the parties agree as set forth in this SOW. Except for the resolution of the Dispute (as defined below), the modifications and amendments made herein were negotiated together, and each is made in consideration of all of the other terms herein.  All such modifications and amendments are interrelated and are dependent on each other.  No separate, additional or different consideration is contemplated with respect to the modifications and amendments herein.

4.MODIFICATION OF AND AMENDMENT TO THE MASTER AGREEMENT.

4.1  Extension of Initial Term.  Article 3 of the Master Agreement hereby is amended in its entirety to read as follows:

This Agreement shall commence as of the Effective Date of this Agreement and continue for an initial term ending on May 31, 2006 (the “Initial Term”), unless terminated earlier under the terms of this Agreement.

After the Initial Term, this Agreement automatically shall be renewed without further action by either Contractor or Customer for one additional year, ending on May 31, 2007

2

December 1, 2000 SOW 25NE

(the “Automatic One-Year Renewal Term”) if and only if both of the following two requirements are satisfied:  (1) Exhibit N was amended in accordance with Section 4.10 of that certain SOW 25NE; and (2) Contractor has not received any “Failure” for any “GEP Element” (as defined in Section 32.2 of this Agreement) in any of the two Evaluation Periods (as defined in Section 32.1 of this Agreement) immediately preceding May 31, 2006; provided, however, that for purposes of determining satisfaction with respect to the Automatic One-Year Renewal Term of the second requirement set forth above, a “Failure” for GEP Elements 5 and 6 shall be as expressly defined in Sections 32.6f(2)(B) and 32.6g(2)(B), respectively.

If Contractor disputes the asserted failure of Contractor to satisfy either one or both of the requirements set forth in the preceding sentence, Contractor may seek resolution of the dispute in accordance with Article 26 of this Agreement, but all parties agree that pending a final and binding determination, regarding whether Contractor failed to satisfy either or both of the requirements, rendered on or before May 31, 2006, there shall be no Automatic One-Year Renewal Term, subject to all rights and remedies available to Contractor in arbitration pursuant to Section 26.2 of the Agreement, including, if the Contractor prevails, but not limited to, the award of damages from the date the Customer failed to give effect to the Automatic One-Year Renewal Term.

Notwithstanding the foregoing, even in the event that Contractor fails to satisfy the requirements for an Automatic One-Year Renewal Term, after the expiration of the Initial Term or after the expiration of the Automatic One-Year Renewal Term, if in effect, this Agreement shall automatically renew for consecutive one year terms (one year at a time) unless an election not to renew is made either (i) by Customer, by providing at least ninety (90) days written notice to Contractor prior to the end of the Initial Term or any subsequent term in which the Agreement is in effect, including, the Automatic One-Year Renewal Term if it is in effect, or (ii) by Contractor, by providing at least one hundred and eighty (180) days written notice to Customer prior to the end of the Initial Term or any subsequent term in which the Agreement is in effect, including, the Automatic One-Year Renewal Term if it is in effect.

4.2  Revision to Exhibit E and Pricing Schedules.  The parties agree that effective on the SOW Effective Date, Exhibit E shall be amended and restated in its entirety as set forth on Attachment 1, attached hereto and made a part hereof.

4.3  Revision to NPAC User Support Contacts; NPAC/SMS Hotline Calls.

4.3.1Amendment to Section 6.2.

4.3.1.1Hotline M&P Document.  Effective upon the date which is the later of the date that (i) Contractor and Customer have agreed (subject to the requirements of Section 4.3.1.3 below) to the contents of the “Hotline M&P Document” (as defined below in Section 4.3.2 of this SOW) and (ii) Contractor has published and implemented the Hotline M&P Document (the “Hotline M&P Document Effective Date”), Section 6.2(b)(i) of the Master Agreement shall be amended in its entirety to read as follows:

3

December 1, 2000 SOW 25NE

(i)NPAC User Support Contacts: NPAC/SMS Hotline Calls.  A per-”contact” charge set forth in Category 2 of Schedule 1 to the Pricing Schedules will be assessed by Contractor for “contacts” received by Contractor from a User for “Billable NPAC User Support Manual Requests,” as defined in Footnote 3 to Schedule 1 of the Pricing Schedules, commencing one (1) month after the date such new User completes initial Turn-up Testing.  An initial phone call, e-mail message, facsimile transmission, or any other form of written or oral communication from a User, and all follow-up communications relating directly to the subject matter of the initial communication, shall constitute a single “contact” hereunder.  Contractor will report the respective User charges to Customer in the Monthly Summary of Charges.  Contractor will invoice such charges to the respective Users that requested and received such services.

4.3.1.2Charges Prior to M&P Hotline Effective Date.  Until the Hotline M&P Document Effective Date, all the per contact charges set forth in Category 2 of Schedule 1 to the Pricing Schedules (prior to the SOW Effective Date) shall remain as in effect, as implemented by that certain letter dated September 23, 1999, titled, User Support Manual Request Charge Policy (Revised), from David Heath to the LLC Presidents, Chairs and Project Executives.

4.3.1.3Customer Determination. In exercising its power to make any determination to approve the Hotline M&P Document, Customer shall be required to make such determination in good faith and in the exercise of commercial reasonableness for similar industries and for similar purposes.  In addition, for purposes of such determination, Customer shall be presumed to have approved the Hotline M&P Document unless on or before the 7^th calendar day following delivery by Contractor of the proposed Hotline M&P Document, Customer has (i) delivered to Contractor written notification of non-approval and (ii) specified the proposed revisions required by Customer.

4.3.2  Amendment to Section 10.1.  Section 10.1 of the Master Agreement is amended by adding the following language after the last sentence thereof:

On or before the 46^th day after the SOW Effective Date of that certain SOW 25NE, Contractor shall prepare, issue, and implement a Methods and Procedures Document expressly dealing with the Hotline Service and charges thereof (the “Hotline M&P Document”). Thereafter, Contractor will periodically update, as needed, in consultation with the Project Executives of the Customer and upon approval of the Project Executives, the Hotline M&P Document and operate the Hotline Service in accordance with such Hotline M&P Document.  The Hotline M&P Document shall include in reasonably adequate detail the following minimum elements:

4

December 1, 2000 SOW 25NE

(1)Description and plan for implementation of a procedure for the publication of the list of Billable NPAC User Support Manual Requests, the process for charging for such Billable NPAC User Support Manual Requests via various media, including direct mail, electronic mail, public and private meeting announcements, Web posting, bill inserts, publication in the Contractor’s  newsletter and in the Contractor’s  training materials.

(2)Description and implementation of an automatic Voice Response Unit (VRU) greeting that in summary fashion does or allows the following:

(a) Describes the billing process for Hotline Service and warns the caller that a contact with Hotline Service personnel may result in the imposition of a charge, depending on the category of the contact, and permitting contact termination without charge.

(b) Offers certain limited dial out options or prompts (if available) to direct call traffic, for example to the IVR, at no charge.

(3)Preparation and use of standardized Hotline Service scripts and protocols.

(4)Description and implementation of a protocol and procedure requiring Hotline Service personnel contacted to collect certain information from the caller and then to announce (the “Billable Warning”) that based upon that information (A) the contact constitutes a Billable NPAC User Support Manual Request, (B) continuation of the contact will result in a charge and (C) that termination of the contact at this point, at the caller’s option, will avoid any charge.

In exercising the power to make any determination to approve updates to the Hotline M&P Document proposed by Contractor, Customer shall be required to make such determination in good faith and in the exercise of commercial reasonableness for similar industries and for similar purposes.  In addition, for purposes of such determination, Customer shall be presumed to have approved each proposed update to the Hotline M&P Document unless on or before the 7^th calendar day following delivery by Contractor of the proposed update to the Hotline M&P Document, Customer has (i) delivered to Contractor written notification of non-approval and (ii) specified the proposed revisions required by Customer.

4.4   Revision to Exhibit H. The parties agree that Exhibit H hereby is amended and restated in its entirety as set forth on Attachment 2, attached hereto and made a part hereof.

4.5   Temporary Modification of SLR-2 Service Level.  In accordance with the authority reserved to the parties under Section 8.3 of the Master Agreement to agree on adjustments to

5

December 1, 2000 SOW 25NE

Service Levels that do not or would not involve or necessitate a change to or modification of the NPAC/SMS, Contractor and Customer (a) have prior to the SOW Effective Date entered into a letter agreement (the “SLR-2 Letter Agreement”) that temporarily modified the “Service Commitment Level” and the “Performance Credit” for SLR-2 shown on Exhibit G to the Master Agreement and (b) hereby agree, effective as of the SOW Effective Date, to modify both the (1) ”Service Commitment Level” and the “Performance Credit” for SLR-2 shown on Exhibit G to the Master Agreement and (2) the operation of GEP Element No. 3 under Article 32 of the Master Agreement (as added by this SOW), both in accordance with Attachment 3 (“Temporary SLR-2 Modification”), incorporated by reference herein and made a part hereof.  The SLR-2 Letter Agreement (in accordance with its terms, including but not limited to its expiration) and Attachment 3 are incorporated by reference herein and made a part hereof.  Unless the Contractor and Customer otherwise agree in writing on or before April 30, 2001, in accordance with Section 8.3 of the Master Agreement to extend the Temporary SLR-2 Modification or otherwise to change or to modify SLR-2, all aspects of SLR-2, including the “Service Commitment Level” and the “Performance Credit” shall on May 1, 2001, immediately and without further action by any party, revert to those shown on Exhibit G to the Master Contract prior to the SOW Effective Date, and without modification by the SLR-2 Letter Agreement.  This agreement of the parties to the Temporary SLR-2 Modification is not intended by itself to in any way constitute an agreement or waiver of the Performance Credits, if any, referenced in Exhibit G (except as modified by the SLR-2 Letter Agreement, until its expiration by its terms) for any time prior to the SOW Effective Date or for any time following expiration the Temporary SLR-2 Modification.

4.6   Root Cause and Problem Escalation Provisions.  The parties agree that Article 10 of the Master Agreement hereby is amended by adding the following sections at the end thereof:

10.3  Root Cause Analysis and Reports.

In addition to any of the other requirements of Contractor under Section 10.2 the following reports (referred to collectively as “Root Cause Reports”) shall be delivered by Contractor within the following time periods following detection by Contractor of a Material Defect that affects more than one User (referred to herein as an “Outage”):

(a)Preliminary Root Cause Analysis Report.  Within 24 hours following detection of the Outage, a preliminary root cause analysis report (the “Preliminary Root Cause Analysis Report”) will be prepared and delivered to the Customer, setting forth the following (at a minimum):

(1)Contractor’s best determination at that point in time of the root cause for the Outage, based upon exercise of commercially reasonable and industry accepted techniques and practices to determine such root cause;

(2)A brief description of the techniques and practices actually employed by Contractor to make the determination; and

6

December 1, 2000 SOW 25NE

(3)A summary of the reason or basis for Contractor’s determination.

(b)Definitive Root Cause Analysis Report.  Within the earlier of 5 business days following issuance of the Preliminary Root Cause Analysis Report or 5 business days plus 25 hours following detection of the Outage, a “Definitive Root Cause Analysis Report” will be prepared and delivered to the Customer, setting forth the following (at a minimum), subject to the further requirement summarized below, in the event Contractor is unable definitively to determine the root cause in this time period:

(1)Either:

(A)  Contractor’s best and definitive determination at that point in time of the root cause for the outage, based upon exercise of commercially reasonable and industry-accepted techniques and practices to determine such root cause and a statement that Contractor believes this determined cause to be the definitive root cause for the Outage; or

(B)  Contractor’s best determination at that point in time of the root cause for the outage, based upon exercise of commercially reasonable and industry accepted techniques and practices to determine such root cause and a statement of why Contractor in unable at that time to conclude that that cause is the definitive root cause for the Outage;

(2)A brief description of the techniques and practices actually employed by Contractor to make the determination;

(3)A summary of the reason or basis for Contractor’s determination; and

(4)Either:

(A)  If the root cause identified in this Definitive Root Cause Analysis Report is different than the root cause identified in the Preliminary Root Cause Analysis Report, a summary of the reasons for the difference in determinations; or

(B)  If the root cause identified in this report is not identified as the definitive root cause for the Outage, a summary of the steps Contractor will follow to continue its investigation into determining the definitive root cause.

(c)Root Cause Follow-up Reports.  If Contractor is unable in the first Definitive Root Cause Analysis Report described above definitively to determine the root cause for the Outage, Contractor shall prepare and deliver periodic “Definitive Root Cause Analysis Follow-up Reports” having the following minimum requirements:

(1)Initiation.  The Definitive Root Cause Analysis Follow-up Reports shall commence being issued 5 business days following the earlier to occur of the date

7

December 1, 2000 SOW 25NE

the Definitive Root Cause Analysis Report should have been issued (even if not issued) or the issuance of the Definitive Root Cause Analysis Report.

(2)Interim.  Subsequent Definitive Root Cause Analysis Follow-up Reports shall continue to be prepared and issued every 5 business days following the date the first Definitive Root Cause Analysis Follow-up Report should have been issued (even if not issued).

(3)Termination. Definitive Root Cause Analysis Follow-up Reports shall not be issued for an Outage if either:

(A)  Contractor prepares and issues a Definitive Root Cause Analysis

Report setting forth Contractor’s best and definitive determination at that point in time of the root cause for the Outage, based upon exercise of commercially reasonable and industry accepted techniques and practices to determine such root cause and a statement that Contractor believes this determined cause to be the definitive root cause for the Outage, and otherwise satisfying the requirements for a Definitive Root Cause Analysis Report summarized above; or

(B)  Contractor prepares and issues a Root Cause Analysis Termination Report setting forth the following (at a minimum):

(i)A statement that Contractor is unable definitively to determine the root cause for the Outage, based upon exercise of commercially reasonable and industry accepted techniques and practices;

(ii)A statement that Contractor has exhausted all commercially reasonable and industry accepted techniques and practices for attempting to determine the definitive root cause for the Outage;

(iii)A statement that Contractor believes, based upon commercially reasonable and industry accepted techniques and practices that even without definitively determining the root cause for the Outage, that the corrective action set forth in the Corrective Action Plan described below adequately will prevent a reoccurrence of the Outage; and

(iv)A summary of the reasons for Contractor’s belief that the corrective action set forth in the Corrective Action Plan described below adequately will prevent a reoccurrence of the Outage.

(d)Corrective Action Plan.

(1)Timing.  Within the 10 business days after the date the Preliminary Root Cause Analysis Report should have been issued (even if not issued), Contractor shall prepare and issue a Corrective Action Plan setting forth a summary of the

8

December 1, 2000 SOW 25NE

corrective action to be taken and the schedule for implementation of the corrective action to avoid a reoccurrence of an Outage, based upon the definitive root cause determined by Contractor to have caused the Outage; provided, however, that even if Contractor has been unable at the time of the issuance of the Corrective Action Plan definitively to have determined the root cause, the Corrective Action Plan shall nonetheless be required as set forth herein based upon the root cause as then determined by Contractor (even if not definitive), but shall also include “work around” plans, if available and commercially practicable, in the event the root cause as then determined is not correct. The Corrective Action Plan shall also summarize the reasons for the recommended corrective action, based upon commercially reasonable and industry accepted techniques and practices.

(2)Final Plan.  Within 10 business days following the issuance of either (i) a Definitive Root Cause Analysis Report or (ii) if, in the Definition Root Cause Analysis Report Contractor is unable definitively to determine the root cause of the Outage, a Root Cause Analysis Termination Report, Contractor shall issue a Definitive Correction Action Plan, setting forth the corrective action and the schedule for implementation of the corrective action determined to be taken to avoid a reoccurrence of an Outage.  The Definitive Corrective Action Plan shall also summarize the reasons for the recommended corrective action, based upon commercially reasonable and industry accepted techniques and practices.

10.4  Problem Escalation and Substantiation.

(a)Timeframes and Hierarchy for Escalation.  If an Outage is not resolved then Contractor agrees that primary management and direct responsibility for its resolution will be escalated to successively higher levels of supervisory personnel within Contractor, as follows:

•  Manager Level, within 30 minutes following detection, if not resolved.

•  Director Level, within 60 minutes following detection, if not resolved.

•  Vice President Level, within 120 minutes following detection, if not resolved.

For purposes of the foregoing, “resolved” and “resolution” with respect to any Outage shall mean that the Outage has been ended and Service Availability has been restored.  If the internal management structure of Contractor or the nomenclature used to describe Contractor’s management structure change, then escalation shall occur in accordance with this provision to those levels of supervisory personnel within Contractor that have duties and responsibilities substantially equivalent to or greater than those identified in this provision as of the SOW Effective Date of that certain SOW 25NE.

(b)Substantiation of Escalation.  Escalation in accordance with the above-summarized schedule and hierarchy will be documented and substantiated by delivery of electronic mail communications showing both a date and time stamp, with a hard-copy of

9

December 1, 2000 SOW 25NE

such electronic mail communications printed and stored by Contractor during the entire term of the Agreement, for later retrieval and review.

10.5  Detection Defined.

For purposes of this Article 10, the terms “detection,” “detect” or “detected” with respect to an Outage shall be considered to mean that point in time which corresponds to the commencement of the occurrence of that event which constitutes the beginning time of Service Unavailability as defined in Exhibit G.

4.7  Deletion of Commercial General Liability Insurance Requirement.  Section 20.4 of the Master Agreement is hereby amended by deleting subsection (iii) thereof.

4.8 Addition of Gateway Evaluation Process. The Master Agreement is hereby amended as of the SOW Effective Date by the addition of Article 32, which will read in it entirety as follows:

ARTICLE 32 – GATEWAY EVALUATION PROCESS

32.1  Gateway Evaluation Process Overview.

The Gateway Evaluation Process (the “GEP”) shall measure Contractor’s satisfaction of seven separate elements (collectively, the “GEP Elements”) set forth in this Article 32, during specific 12 consecutive calendar month periods described in this Article 32 (each period referred to as an “Evaluation Period” or “EP”).  The GEP for each respective EP shall, pursuant to the Audit Plan (as defined below), be measured by Contractor and audited (the “GEP Audit”) by an auditor selected and compensated in accordance with the requirements of Section 32.4 of this Agreement (the “GEP Auditor”).

The GEP and the GEP Audit, including the results thereof, for any EP will be used solely for purposes of (a) determining whether a “Reduced TN Porting Price” (defined in Section 32.5 hereof) shall apply for an “Applicable Reduction Period” (defined in Section 32.5 hereof) and (b) determining whether Contractor qualifies for an Automatic One-year Renewal Term pursuant to Article 3 of this Agreement.

The GEP is independent of any of the requirements in the Agreement for Contractor to provide Services in accordance with the Agreement.  Further, nothing in this Article 32 shall limit or otherwise restrict the rights of the Customer or any User under any other provision of the Agreement or any User Agreement.  The parties acknowledge that the implementation of the GEP during the entire term of this Agreement is a material obligation under this Agreement for purposes of Section 16.5 of this Agreement, and the parties expressly acknowledge and agree that the failure of Contractor to implement the GEP during any time during the entire term of this Agreement shall entitle Customer to reductions to the Base TN Porting Price in accordance with Section 32.5(f) of this Agreement.

10

December 1, 2000 SOW 25NE

Notwithstanding the foregoing, the parties expressly acknowledge and agree that the GEP does not obligate Contractor to perform any of the GEP Elements specified under this Article 32, and the “Failure” of any GEP Element, in whole or in part, will not constitute a failure by Contractor to perform a “material obligation” under Section 16.5 hereof, unless the events that constitute such “Failure,” under provisions other than Article 32, would give rise to rights or remedies under other provisions of this Agreement.  The parties also expressly acknowledge and agree that the only right or remedy available to Customer for the failure of Contractor to perform any of the GEP Elements under this Article 32 or the “Failure” of any GEP Element, in whole or in part, is the applicability of the Reduced TN Porting Price in accordance with the terms of this Article 32 and the qualification for the Automatic One-Year Renewal Term under Article 3, unless the events that constitute such “Failure,” under provisions other than Article 32, would give rise to rights or remedies under other provisions of this Agreement.

32.2                Gateway Elements Overview.

Each GEP Audit shall consist of the measurement of the Contractor’s satisfaction of the following GEP Elements:

a.Service Performance Elements:

(1)Element No. 1:  Service Availability satisfaction, consisting of the following sub-elements

(a)Element No. 1a:  SLR-1 satisfaction pursuant to Section 32.6(a) of this Agreement.

(b)Element No. 1b:  SLR-7 satisfaction pursuant to Section 32.6(b) of this Agreement.

(2)Element No. 2:  Report satisfaction, pursuant to Section 32.6(c) of this Agreement.

(3)Element No. 3:  Scheduled Service Unavailability satisfaction, pursuant to Section 32.6(d) of this Agreement.

(4)Element No. 4:  Benchmarking satisfaction, pursuant to Section 32.6(e) of this Agreement.

11

December 1, 2000 SOW 25NE

b.Customer-Oriented Elements

(5)Element No. 5:  Root Cause Analysis and Reporting satisfaction, pursuant to Section 32.6(f) of this Agreement.

(6)Element No. 6:  Problem Escalation satisfaction, pursuant to Section 32.6(g) of this Agreement.

(7)Element No. 7:  Billing satisfaction, consisting of the following sub-elements:

(a)Element No. 7a:  Timeliness of Delivery Satisfaction, pursuant to Section 32.6(h) of this Agreement.

(b)           Element No.7b:  Accuracy satisfaction, pursuant to Section 32.6(i) of this Agreement.

32.3Frequency

The first Evaluation Period (the “First EP”) will commence on the first day of the calendar month that is six months after the SOW Effective Date of that certain SOW 25NE (the “First EP Commencement Date”).  A GEP Audit will be initiated after the commencement of each EP, commencing with the first GEP Audit (the “First GEP Audit”) for the First EP.  Thereafter, a GEP Audit will commence on the date which is 12 calendar months after the date of the commencement of the immediately preceding EP.  The commencement date of each EP and each GEP Audit shall be the same date for all Service Areas within the United States.

32.4GEP Audit Mechanics

Prior to the commencement of the First GEP Audit, Contractor and Customer will consult to determine definitively those aspects of the GEP set forth in this Section 32.4.  The GEP Audit mechanics will include the following elements:

(a)Selection of a GEP Auditor.  Subject to the limitations and terms set forth herein, the qualifications of the GEP Auditor shall be determined jointly by Contractor and Customer, and a GEP Auditor (and any successor GEP Auditor if the originally selected GEP Auditor fails to act for any reason, including but not limited to termination of such GEP Auditor’s contract, as set forth below) shall be selected jointly by Contractor and Customer.  The compensation paid to and expense of the GEP Auditor shall be solely negotiated and paid for by the Contractor.  The GEP Auditor shall be an independent, neutral third party, which is an affiliate of neither the Contractor or the Customer.

Contractor shall enter into a contract with the GEP Auditor for the provision of services to perform the GEP Audit, which contract shall clearly state and provide that the Customer shall not be liable for any costs or expenses incurred by the GEP Auditor or for any compensation or other payments of any nature to the GEP Auditor, and which contract further (1) shall specify that Customer shall make the final determination with respect to all issues for which Customer and the Contractor cannot agree and (2) shall specify certain criteria, the failure of

12

December 1, 2000 SOW 25NE

which shall require termination of the contract by the Contractor (“Automatic Termination Criteria”).

The qualifications of the GEP Auditor, the scope of the services to be provided by the GEP Auditor and the Automatic Termination Criteria shall be determined jointly by Contractor and Customer. If Contractor and the Customer cannot agree upon the qualifications of the GEP Auditor, upon the scope of the services to be provided by the GEP Auditor or upon the Automatic Termination Criteria on or before the date which is 4 months before the commencement date for the First EP, the Customer shall make the relevant determination with respect to which the Customer and Contractor could not agree, and Contractor shall be required to enter into a contract one month prior to the commencement of the first EP with the GEP Auditor which shall include the provisions set forth above.  In making any such determination upon the failure of the Contractor and the Customer to agree within the time period set forth above, Customer shall be bound by the requirements of Section 32.4(f) below.

(b)Audit Metrics.  The specific criteria, metrics and methods and techniques for obtaining data (including, but not limited to, the determination of comprehensive data collection or specific statistical sampling techniques), and the required contents of the GEP audit report (“GEP Audit Report”) to be issued by the GEP Auditor for the purpose of measuring Contractor’s satisfaction of each GEP Element (“Audit Metrics”) shall be determined jointly by Contractor and Customer, in consultation with the GEP Auditor.  If Contractor and Customer cannot agree on any aspect of the Audit Metrics on or before the date which is 3 months before the commencement date for the First EP, the Customer alone shall make such determination. In making any such determination upon the failure of the Contractor and the Customer to agree within the time period set forth above, Customer shall be bound by the requirements of Section 32.4(f) below.

(c)Audit Plan.  The specific plan and schedule for the accomplishment of the required GEP Audit and incorporating the Audit Metrics, including, but not limited to, collection of data, consideration of data, evaluation of results, initial validation process and the preparation of a GEP Audit Report (collectively referred to as the “Audit Plan”) shall be determined jointly by Customer and Contractor in consultation with the potential GEP Auditor(s).  If the Contractor and the Customer cannot agree on any aspect of the Audit Plan before the date which is 2 months before the commencement date for the First EP, the Customer alone shall make such determination, and Contractor shall be required to adhere to and to incorporate such determination, into the Audit Plan and to issue the Audit Plan on or before the date which is 1 month and 2 weeks before the commencement date for the First EP. In making any such determination upon the failure of the Contractor and the Customer to agree within the time period set forth above, Customer shall be bound by the requirements of Section 32.4(f) below.

(d)Validation Process.  A trial sampling and collection of data to validate the Audit Plan (the “Validation Process”) shall be commenced on or before the date which is 1 month prior to the commencement date for the First EP. During the Validation Process, the GEP

13

December 1, 2000 SOW 25NE

Auditor(s) shall perform a trial audit and produce a trial report within two months after the commencement of the first EP.

Based upon the results of the Validation Process, aspects of the Audit Plan may be changed to more accurately measure compliance with the GEP Elements.  If Contractor and Customer cannot agree on any aspect of the revised Audit Plan before the date which is 1 month after the delivery of the trial report by the GEP Auditor, the Customer shall make such determination. In making any such determination upon the failure of the Contractor and the Customer to agree within the time period set forth above, Customer shall be bound by the requirements of Section 32.4(f) below.

(e)GEP Audit Report.  The GEP Auditor will prepare and issue a GEP Audit Report to the Contractor and to the Customer for the applicable EP within 30 days following the conclusion the EP for which the GEP Audit Report covers.  In the event the GEP Auditor requires more than such thirty day period to issue the GEP Audit Report, such period shall be extended by the amount requested by the GEP Auditor, provided that the GEP Auditor has requested such extension in writing and has provided the reasons therefor, and Customer has, subject to the requirements of Section 32.4(f) hereof, agreed to such extension.  Such GEP Audit Report shall include, at a minimum, the following:  (1) a determination for each GEP Element whether Contractor has “Failed” or “Missed” such GEP Element and (2) adequate substantiation in support of the preceding determinations.

(f)Customer’s Standard.  In exercising its power to make any determination under this Section 32.4 upon the failure of the Customer and the Contractor to agree within the applicable time period set forth therein, Customer shall be required to make such determination in good faith and in the exercise of commercial reasonableness for similar industries and for similar purposes (measured with respect to attempting to fulfill the purposes of the GEP as set forth in this Article 32) and shall deliver the result of such determination in writing to Contractor.  Notwithstanding anything to the contrary in this Agreement, in the event Customer has not delivered any determination to be made by Customer under Article 32 hereof within three business days after the applicable date that Customer had the right to make the relevant determination because of the failure of the Customer and Contractor to agree, Contractor shall have the right to make such determination.

If Contractor disputes any determination made by Customer upon the failure of the Customer and the Contractor to agree within an applicable time period set forth in this Section 32.4, Contractor may seek resolution of the dispute in accordance with Article 26 of this Agreement, but all parties agree that pending a final and binding determination regarding whether Customer improperly exercised its power to make such determination under this Section 32.4, Contractor shall be bound by such determination of Customer and shall proceed with the GEP based upon such determination.

14

December 1, 2000 SOW 25NE

32.5TN Porting Price Reduction

The base price per TN Porting Event set forth on Schedule 1 of Exhibit E (the “Base TN Porting Price”) will be reduced, as set forth in Section 32.5(b) and Section 32.5(f).  Reductions under Section 32.5(b) will be based upon the number and identification of “Failures” or “Misses” of the GEP Elements reported for an applicable EP in the GEP Audit Report.  Reductions under Section 32.5(f) will be based upon Contractor’s failure to implement the GEP at any time during the term of this Agreement in accordance with the terms and conditions of Section 32.5(f).  The parties expressly agree and acknowledge that any reduction in the Base TN Porting Price shall be determined and applied only with respect to the Service Area which is the subject of this Agreement, based upon the GEP Audit Report for such particular Service Area.

(a)Period for Price Reduction and Defined Terms.  Reductions to the Base TN Porting Price as computed pursuant to Section 32.5(b), if any, shall apply to the 12 successive calendar month period (“Applicable Reduction Period”) commencing with the first day of the first full month following the month in which the GEP Audit Report was issued and which measured satisfaction of the GEP Elements for the immediately preceding EP (the “Associated EP”).  Any reduction in the TN Porting Price in accordance with 32.5(b) will be referred to as the “Reduced TN Porting Price” for that Applicable Reduction Period, and the reductions to the Base TN Porting Price resulting from “Failures” or “Misses” of the GEP Elements for the Associated EP will be referred to as the “GEP Reductions.”   The first Applicable Reduction Period associated with the GEP Audit results for the first Associated EP will be referred to as the “First Applicable Reduction Period,” even if no Reduced TN Porting Price results from the GEP Audit for the first Associated EP.  Successive Applicable Reduction Periods will be referred to successively as the “Second Applicable Reduction Period,” the “Third Applicable Reduction Period” and so on.

(b)Computation of Reduced TN Porting Prices.  Subject to the limitations set forth in Section 32.5(d) below, the Reduced TN Porting Price for the Applicable Reduction Period will be equal to the amount computed in accordance with the following formula:

(1)Base TN Porting Price

MINUS

(2)GEP Reductions for the Associated EP

MINUS

(3)Carryover GEP Failure Reductions (defined below) for the Applicable Reduction Period.

(c)Pricing Following any Termination Event or Non-Renewal.  The parties expressly agree that after the occurrence of any Termination Event or Non-Renewal (as defined in this Agreement), if the Customer elects to extend the term of the Agreement to receive Services thereunder, the charge per TN Porting Event for such Services and during the period under which the term of this Agreement has been extended upon such election shall be the Reduced TN Porting Price for the last preceding completed Associated EP.

15

December 1, 2000 SOW 25NE

(d)Limitations on Reduced TN Porting Prices.  Notwithstanding anything to the contrary in this Agreement, including, without limitation, the results of any computation of the Reduced TN Porting Price for any Applicable Reduction Period set forth in Section 32.5(b) or any reduction to the Base TN Porting Price under Section 32.5(f) resulting from the failure of Contractor to implement the GEP any time during the term of this Agreement, under no circumstances shall the cumulative reductions to the Base TN Porting Price at any instant in time under this Agreement exceed (i) $[* * *] for any time ending before the commencement of the Fourth Applicable Reduction Period and (ii) $[* * *] for any time commencing on or after the Fourth Applicable Reduction Period.

(e)Definitions of GEP Reductions and Carryover GEP Failure Reductions.

(1)GEP Reductions.  For the purpose of calculating the Reduced TN Porting Price for the Applicable Reduction Period under Section 32.5(b), the GEP Reduction for each “Failure” or “Miss” (as such terms explicitly are defined in Section 32.6 for each respective GEP Element) reported on the GEP Audit Report to have occurred for an Associated EP shall be the amount shown on the chart below, entitled “GEP Reduction Chart.”  The amount shown in the column under the GEP Reduction is the maximum reduction of the Base TN Porting Price that will be given effect for the applicable GEP Element for the Associated EP.  The parties expressly acknowledge and agree that the application of a GEP Reduction constitutes liquidated damages and not a penalty.

GEP Reduction Chart

GEP Element	GEP Reduction
Element No. 1a: SLR-1 “Failure”	$	[* * *]
Element No. 1b: SLR-7 “Failure”	$	[* * *]
Element No. 2: Report “Failure”	$	[* * *]
Element No. 3: Scheduled Service Unavailability “Failure”	$	[* * *]
Element No. 4: Benchmarking “Failure”	$	[* * *]
Element No. 5: Root Cause Analysis and Reporting “Miss”	Multiple “Misses” can result in multiple GEP Reductions for this GEP Element as set forth below: For each “Miss” of this GEP Element, a GEP Reduction of $[* * *] shall apply. Notwithstanding the foregoing, no matter how many “Misses” occur with respect to this GEP Element, the maximum GEP Reduction that can apply as a result of “Misses” of this GEP Element during a single EP is $[* * *]
Element No. 6: Problem Escalation “Miss”	Multiple “Misses” can result in multiple GEP Reductions for this GEP Element as set forth below: For each “Miss” of this GEP Element, a GEP Reduction of $[* * *] shall apply. Notwithstanding the foregoing, no matter how many

16

December 1, 2000 SOW 25NE

	“Misses” occur with respect to this GEP Element, the maximum GEP Reduction that can apply as a result of “Misses” of this GEP Element during a single EP is $[* * *]
Element No. 7a: Billing Timeliness of Delivery “Failure”	$	[* * *]
Element No. 7b: Billing Accuracy “Failure”	$	[* * *]

(2)Carryover GEP Failure Reductions. For the purpose of calculating the Reduced TN Porting Price for the Applicable Reduction Period under Section 32.5(b), the “Carryover GEP Failure Reduction” for a particular GEP Element reported on the GEP Audit Report to have occurred for an Associated EP shall be an amount equal to either (i) zero, if there was no “Failure” for the GEP Element for the Associated EP or (ii) if there was a “Failure” for the GEP Element for the Associated EP the sum of the GEP Reductions for consecutive “Failures” of the same GEP Element reported on previous GEP Audit Reports starting with the immediately preceding Associated EP.

(f)GEP Reductions Upon Contractor’s Failure to Implement the GEP.  In the event that Contractor fails to implement the GEP at any time during the term of this Agreement, Customer may elect with respect to such specific failure to implement the GEP (and without waiver of or prejudice to any other remedies and rights that may be available as a result of prior or subsequent specific failures of Contractor to implement the GEP) the specific remedies of reduction of the Base TN Porting Price set forth in, and subject to the following terms  and conditions of, this Section 32.5(f) as liquidated damages therefor.

(1)Failure to Commence First GEP by Commencement of First EP.  In the event that the First GEP does not commence by the First EP Commencement Date, Customer shall have the right to deliver a written notice of failure to Contractor on or before the date which is 30 days after the First EP Commencement Date, that the Base TN Porting Price shall be reduced by $[* * *] commencing upon the 30^th day after the First EP Commencement Date, and Contractor shall be required (without further demand or notice from the Customer) to implement such reduction, unless Contractor satisfactorily cures such failure and commences the First GEP on or before the 30^th day after the First EP Commencement Date. Such written notice must identify in reasonably adequate and sufficient detail the specific failures that require cure. If Contractor thereafter does not satisfactorily cure such failure and commence the First GEP, such $[* * *] reduction in the Base TN Porting Price shall remain in effect for three full calendar months from the First EP Commencement Date, and, commencing with the fourth calendar month after the First EP Commencement Date, Contractor (and without further demand or notice from the Customer) shall reduce the Base TN Porting Price by a total of $[* * *].  Following Contractor’s failure to commence the First GEP on or before the date which is 30 days after the First EP Commencement Date, if Contractor subsequently cures such failure and commences the First GEP, for administrative convenience, Contractor shall nonetheless

17

December 1, 2000 SOW 25NE

continue to give effect to any reduction to the Base TN Porting Price then in effect pursuant to this Section 32.5(f) until the first day of the first full calendar month following such cure.

(2)Contractor’s Failure to Implement GEP Other Than Commencement of First GEP.  If Contractor fails to implement the GEP during any time during the term of this Agreement, other than by reason of Contractor’s failure to commence the First GEP on or before the date which is 30 days after the First EP Commencement Date, upon written notice of such failure by Customer identifying in reasonably adequate and sufficient detail the failures that require cure, Customer and Contractor shall meet to discuss such failure identified in the notice and if such failure is not cured within thirty (30) days of such notice Contractor shall, from the date of such notice until Contractor cures such failure, (without further demand or notice from Customer) reduce the Base TN Porting Price by either (a) $[* * *] for any time ending before the commencement of the Fourth Applicable Reduction Period or (b) $[* * *] for any time commencing on or after the commencement of the Fourth Applicable Reduction Period; provided, however, that for administrative convenience (i) Contractor shall not be required to reduce the Base TN Porting Price as set forth above until the first day of the first full calendar month following delivery of notice by Customer of such failure, and (ii) following such failure by Contractor to implement the GEP as set forth above, if Contractor subsequently cures such failure, for administrative convenience, Contractor shall nonetheless continue to give effect to any reduction to the Base TN Porting Price then in effect pursuant to this Section 32.5(f) until the first day of the first full calendar month following such cure.

(3)Relationship with Reduced TN Porting Prices for Applicable Reduction Periods and Limitations on Reductions to Base TN Porting Price.  Because there exists the possibility during the term of this Agreement that both (a) the provisions of Section 32.5(b) regarding the computation of the Reduced TN Porting Price for an Applicable Reduction Period and (b) the provisions of Section 32.5(f)(1) or Section 32.5(f)(2) regarding the reduction to the Base TN Porting Price due to Contractor’s failure to implement the GEP, may apply as a result of the time period during which Contractor has failed to implement the GEP and has not cured such failure is contained within an Applicable Reduction Period, the parties expressly agree and acknowledge each of the following:

(A)Notwithstanding anything to the contrary in this Agreement, under no circumstances, and at no time during the term of this Agreement shall the cumulative price reductions to the Base TN Porting Price required under this Agreement, including reductions to the Base TN Porting Price made as a result of the application of Section 32.5(b), Section 32.5(f)(1) or Section 32.3(f)(2), for any instant in time, exceed either (I) $[* * *] at any time ending before the commencement of the Fourth Applicable Reduction Period, and (II) $[* * *] for any time commencing on or after the commencement of the Fourth Applicable Reduction Period.

(B)Notwithstanding anything to the contrary in this Agreement, if for any instant in time, both (a) the provisions of Section 32.5(b) regarding the computation of the Reduced TN Porting Price for an Applicable Reduction Period and (b) the provisions of

18

December 1, 2000 SOW 25NE

Section 32.5(f)(1) or Section 32.5(f)(2) regarding the reduction to the Base TN Porting Price due to Contractor’s failure to implement the GEP, apply, then that provision which results in the greatest reduction to the Base TN Portion Price shall govern and be applicable with respect to that instant in time.

(C)Notwithstanding anything to the contrary in this Agreement, if Contractor cures any failure to implement the GEP which had caused the reduction to the Base TN Porting Price under preceding provisions of this Agreement to apply, upon the elimination of any such reduction to the Base TN Porting Price in accordance with the provisions of Section 32.5(f)(1) or 32.5(f)(2), whichever may be applicable, upon the first day of the first full calendar month following such cure the Base TN Porting Price shall nonetheless continue to remain subject to any other reductions set forth in this Section 32.5, including, the computation of the Reduced TN Porting Price for the remaining balance of any Applicable Reduction Period.

(4)Resolution of Disputes Regarding Failure to Implement and Cure. The parties expressly agree that if Customer and Contractor disagree on the existence of any failure to implement the GEP or of any cure of such failure, that the Customer’s determination shall govern, and Contractor shall be required to reduce the Base TN Porting Price as set forth in this Section 32.5(f).  Notwithstanding the foregoing, in exercising its power to make any determination under this Section 32.5(f), Customer shall be required to make such determination in good faith and in the exercise of commercial reasonableness for similar industries and for similar purposes (measured with respect to attempting to fulfill the purposes of the GEP as set forth in this Article 32).  If Contractor disputes any determination made by Customer upon the failure of the Customer and the Contractor to agree as set forth in this Section 32.5(f), Contractor may seek resolution of the dispute in accordance with Article 26 of this Agreement, and Contractor shall be entitled to all rights and remedies available in arbitration, including, but not limited to, if appropriate, the retroactive repricing of the TN Porting Event charge to the price that would have otherwise been in effect had the reduction to the Base TN Porting Price under Section 32.5(f) not been applied.  Notwithstanding the foregoing, all parties agree that pending a final and binding determination regarding whether Customer improperly exercised its power to make such determination under this Section 32.5(f), Contractor shall be bound by such determination of Customer and shall proceed with the GEP, including but not limited to, proceeding to apply any reductions to the Base TN Porting Price based upon such determination.

19

December 1, 2000 SOW 25NE

32.6Specific GEP Elements and Determination of Failure for Each GEP Element

(a)GEP Element No. 1a:  SLR-1 Satisfaction.

(1)GEP Element Description.  This GEP Element measures satisfaction of the Service Commitment Level associated with SLR-1 set forth on Exhibit G to this Agreement for the Service Area.

(2)Definition of Failure.  A “Failure” of this GEP Element as reported on a GEP Audit Report shall be considered to occur when the monthly measurement of Service Availability (as defined in Exhibit G to this Agreement) during the Associated EP fails to satisfy the Service Commitment Level associated with SLR-1 set forth on Exhibit G for either: (a) any 2 consecutive months in the Associated EP, or (b) any 3 or more months (even if not consecutive) during the Associated EP. Only one “Failure” of this GEP Element shall be given effect for any one EP.

(b)GEP Element No. 1b:  SLR-7 Satisfaction.

(1)GEP Element Description.  This GEP Element measures satisfaction of the Service Commitment Level for all Interfaces associated with SLR-7 set forth on Exhibit G to this Agreement for the Service Area.

(2)Definition of Failure.  A “Failure” of this GEP Element as reported on a GEP Audit Report shall be considered to occur when the monthly measurement of Interface Availability (as defined in Exhibit G to this Agreement) for each of the months comprising the Associated EP for more than 5% of all Users’ mechanized interfaces fail to satisfy the Service Commitment Level associated with SLR-7 set forth on Exhibit G either: (a) any 2 consecutive months in the Associated EP, or (b) any 3 or more months (even if not consecutive) during the Associated EP. Only one “Failure” of this GEP Element shall be given effect for any one EP.

(c)GEP Element No. 2:  Report Satisfaction.

(1)GEP Element Description.  This GEP Element measures satisfaction of the following two requirements for those specific reports listed on Exhibit H (referred to for purposes of this GEP Element as “Periodic Reports”):

•“On- Time Delivery” Requirement; and

•“Accuracy” Requirement

For purposes of the foregoing, “On-Time Delivery” shall be measured as the actual delivery of each specific Periodic Report specified on Exhibit H on the date specified for delivery of that specific Periodic Report.  For the purposes of the foregoing, the “Key” included on Exhibit H to the Agreement shall provide the schedule for the delivery of all Periodic Reports.

20

December 1, 2000 SOW 25NE

For purposes of the foregoing, “Accuracy” or “Accurate” shall be defined as the absence of the need to make corrections to report data for any such Periodic Report; provided, however, that recalculations-based changes agreed to by Customer and Contractor in previously believed correct calculations methods and/or formulae shall not affect “Accuracy” for purposes of this GEP Element.

(2)Definition of Failure.  A “Failure” of this GEP Element as reported in the GEP Audit Report shall be considered to occur if any Periodic Report obtains one “Failure” of either the “On-Time Delivery” Requirement or the “Accuracy” Requirement during the Associated EP, as such “Failure” is defined below.  Only one “Failure” of this GEP Element shall be given effect for any one EP.

•“On-Time Delivery” Requirement Failure: A “Failure” of the “On-Time Delivery” Requirement shall be considered to have occurred if any Periodic Report during the Associated EP fails to be delivered on or before the date and on or before the time scheduled for delivery of the specific Periodic Report either  (a) any 2 consecutive months in the EP, or (b) any 3 or more months (even if not consecutive) during the Associated EP.

•“Accuracy” Requirement Failure.  A “Failure” of the “Accuracy” Requirement shall be considered to have occurred if a Periodic Report is not Accurate either (a) any 2 consecutive months in the Associated EP, or (b) any 3 or more months (even if not consecutive) during the Associated EP.

(d)           GEP Element No. 3: Scheduled Service Unavailability Satisfaction.

(1)GEP Element Description.  This GEP Element measures satisfaction of the monthly Service Commitment Level associated with SLR-2 set forth on Exhibit G to this Agreement for the Service Area which is the subject of this Agreement, as such Service Commitment Level may be amended or otherwise changed or as such measurement for purposes of this GEP Element may be amended or changed by agreement of the parties in accordance with this Agreement.

(2)Definition of Failure.  A “Failure” of this GEP Element as reported in the GEP Audit Report shall be considered to occur when Scheduled Service Unavailability for any month during the Associated EP exceeds the time period set forth in the Service Commitment Level for SLR-2 either (a) any 2 consecutive months in the applicable EP, or (b) any 3 or more months (even if not consecutive) during the applicable EP.  Only one “Failure” of this GEP Element shall be given effect for any one EP.

21

December 1, 2000 SOW 25NE

(e)GEP Element No. 4: Benchmarking Satisfaction.

(1)GEP Element Description. GEP Element No. 4 is separate and distinct from the requirements for a Benchmarking under Article 7 of this Agreement.  The parties agree and acknowledge that the Benchmarking under this GEP Element No. 4 (“EP Benchmarking”) is solely with respect to determining whether a “Failure” occurred during an Associated EP for a specific EP Benchmarking Plan (defined below) and is for the purpose of ensuring that Contractor provides “technology and service level standards equal to or greater than other organizations receiving similar services.”

(2)Phases of EP Benchmarking. EP Benchmarking consists of the following “Phases,” the purpose of which is to identify measurable tasks from which to determine whether or not a “Failure” of this GEP Element has occurred during an EP:

•Phase 1:  EP Benchmarking Plan Development Phase

•Phase 2:  Benchmarking Data Collection and Report Phase

•Phase 3.  Benchmarking Evaluation Phase

•Phase 4.  Benchmark Implementation Phase

There shall be no requirement that for every EP all Phases must either be commenced or concluded; instead, the parties agree and acknowledge that the EP Benchmarking Plan will specify and determine when each Phase begins and ends and which Phases, the beginning or ending of which, shall be required in any EP to avoid a determination of a “Failure” of this GEP Element No. 4. Unless Contractor and Customer otherwise agree, no Implementation Phase shall be commenced before the completion of all prior Implementation Phases. Unless Contractor and Customer otherwise agree, no new EP Benchmarking may be commenced until a previously commenced EP Benchmarking has completed Phase 3; provided, however, that Customer may initiate a new EP Benchmarking (the “Priority EP Benchmarking”) prior to the completion of  Phase 3 of an EP Benchmarking that is already in progress.  In such event, Contractor shall have the right to temporarily stop the activities relating to the EP Benchmarking that is already in progress, and the time frames set forth herein under which the Phases for the EP Benchmarking were required to be completed shall be tolled, until the Priority EP Benchmarking has completed Phase 3.

(3)Description of Phases.

(A)EP Benchmarking Plan Development Phase.

Overview.  This Phase includes development of a plan identifying those particular items identified solely by Customer that will be evaluated, what similar industries or companies will be used as a comparison, the specific criteria, metrics and methods and techniques for obtaining data (including, but not limited to, the determination of comprehensive data collection or specific statistical sampling techniques), the required contents of the EP Benchmarking Report and the specific timeframes for data collection and evaluation.  The parties agree and acknowledge that it is anticipated and expected that an EP Benchmarking Plan may, but need not, include those items listed on Attachment 4, attached hereto and made a part hereof.

22

December 1, 2000 SOW 25NE

EP Benchmarking Plan Development Requirements.  For the purpose of specifying discrete and identifiable tasks toward completion of the EP Benchmarking Plan Development Phase, the following steps are established:

(1)Commencement.  The EP Benchmarking Plan Development Phase is deemed to commence with Contractor’s attendance at a meeting with Customer’s representatives on or before 14 days following delivery by Customer of written notification that Customer wishes Contractor to initiate EP Benchmarking under this Section 32.6(e). All notifications by Customer must comply with Article 29 of the Agreement.  This initial meeting shall be on the date, at a time and at a place determined by Customer, and may be changed by Customer in its discretion if Customer notifies Contractor in writing at least 14 days prior to the scheduled date of an irreconcilable conflict.

(2)Follow-Through. Within 20 days after the Customer delivers written notification to the Contractor identifying those items that Customer wishes to be evaluated and included in the EP Benchmarking Plan, Contractor shall attend a meeting with Customer’s representatives for the purpose of jointly discussing and developing the details of the EP Benchmarking Plan, and Contractor shall attend additional meetings with Customer’s representatives as reasonably requested by Customer at the initial meeting. Each of these meetings shall be on a date, at a time and at a place determined by Customer, and may be changed by Customer in its discretion if Customer notifies Contractor in writing at least 14 days prior to the scheduled date of an irreconcilable conflict.

(3)Task Completion.  After either (i) joint agreement between Customer and Contractor or (ii) Customer’s determination of the contents of the EP Benchmarking Plan with respect to those items for which joint agreement was not reached, within 20 days following written notification by Customer that it desires Contractor to prepare an initial draft EP Benchmarking Plan, Contractor shall deliver such initial draft to Customer.  The parties anticipate and expect that an EP Benchmarking Plan may, but need not, include those items listed on Attachment 4, attached hereto and made a part hereof. Within 20 days following delivery of the draft EP Benchmarking Plan, Contractor shall be required to attend a meeting with Customer’s representatives for the purpose of jointly discussing revisions or comments to the draft EP Benchmarking Plan. If Contractor and the Customer cannot agree on any aspect of the EP Benchmarking Plan within 30 days following delivery of the initial draft of the EP Benchmarking Plan (or 30 days following the date such initial draft should have been delivered even if it was not delivered on such date), the Customer shall make all such determinations with respect to the EP Benchmarking Plan, and Contractor shall be required to adhere to and to incorporate such determination into the final EP Benchmarking Plan and to issue the final EP Benchmarking Plan within 30 days after notification by the Customer of such final determinations.  In making any such determination upon the failure of the Contractor and the Customer to agree within the time period set forth above, Customer shall be bound by the requirements of Section 32.4(f) below.

23

December 1, 2000 SOW 25NE

The EP Benchmarking Plan Development Phase is deemed to be complete upon issuance of the final EP Benchmarking Plan as set forth in paragraph (3) above.

(B)Benchmarking Data Collection and Report Phase.  This Phase commences immediately upon completion of the EP Benchmarking Plan Development Phase and involves the collection and analysis of data.  The Benchmarking Data Collection and Report Phase is completed upon the issuance of an EP Benchmarking Report, which must be issued on or before the date set forth in the respective EP Benchmarking Plan and in accordance with the requirements of the respective EP Benchmarking Plan.

(C)Benchmarking Evaluation Phase.

For the purpose of specifying discrete and identifiable tasks toward the completion of the EP Benchmarking Evaluation Phase, the following steps are established:

(1)Commencement and Initial Evaluation Report.  The Benchmarking Evaluation Phase is deemed to commence immediately following issuance by Contractor of the EP Benchmarking Report (or upon the date such EP Benchmarking Report should have been issued, even if not issued on such date).  Within 30 days thereafter, Contractor shall prepare and deliver to Customer an Evaluation Report setting forth recommendations regarding whether corrective action is needed, and if needed, whether the corrective action can be implemented via the Statement Of Work process set forth in Article 13 or via an Action Plan (as defined below) without a Statement Of Work, and otherwise satisfying the requirements for an Evaluation Report set forth in the EP Benchmarking Plan.

(2)Consultation and Discussion. Within 20 days after the delivery of the Evaluation Report (or upon the date such EP Benchmarking Report should have been issued, even if not issued on such date), Contractor shall be required to attend a meeting with Customer’s representatives for the purpose of jointly discussing the Evaluation Report and the recommendations for corrective action, if any, and Contractor shall further be required to attend additional meetings with Customer’s representatives as reasonably requested by Customer. Each of these meetings shall be on a date, at a time and at a place determined by Customer, and may be changed by Customer in its discretion if Customer notifies Contractor in writing at least 14 days prior to the scheduled date of an irreconcilable conflict.

(3)Determination of System Change. If Contractor and the Customer cannot agree within 20 days following delivery of the Evaluation Report on any aspect thereof, the Customer shall make all such determinations with respect to those items for which Customer and Contractor cannot agree.  Thereafter, within 90 days following agreement of Contractor and Customer with respect to the corrective action required, or in the absence of such agreement, upon written notice by the Customer to Contractor of its determination of the correction action required, Contractor shall deliver a proposed Statement of Work pursuant to the requirements of Article 13 of this Agreement, or if no Statement of Work is required, Contractor shall deliver a proposed action plan, providing for the implementation of the corrective action required (“Action Plan”). In making any such

24

December 1, 2000 SOW 25NE

determination upon the failure of the Contractor and the Customer to agree within the time period set forth above, Customer shall be bound by the requirements of Section 32.4(f) below.

(4)The Benchmarking Evaluation Phase is deemed to be completed upon delivery of a proposed Statement of Work, or proposed Action Plan, as the case may be.

(D)Implementation Phase. The Implementation Phase shall commence upon execution of a Statement Of Work or agreement on the terms of an Action Plan if no Statement Of Work is determined to be required. The Implementation Phase ends in accordance with the timeline and schedule of the project plan set forth in the Statement Of Work, if a Statement Of Work is required, or otherwise in accordance with the timeline and schedule established by the parties in the Action Plan, if a Statement Of Work is not required. Notwithstanding the foregoing, unless Contractor and Customer agree, no Implementation Phase for any EP shall be commenced before the completion of all prior Implementation Phases.

(E)Customer’s Standard.  In exercising its power to make any determination under this Section 32.6(e) upon the failure of the Customer and the Contractor to agree within the applicable time period set forth therein, Customer shall be required to make such determination in good faith and in the exercise of commercial reasonableness for similar industries and for similar purposes (measured with respect to attempting to fulfill the purposes of the GEP as set forth in this Article 32.6(e)).

If Contractor disputes any determination made by Customer upon the failure of the Customer and the Contractor to agree within an applicable time period set forth in this Section 32.6(e), Contractor may seek resolution of the dispute in accordance with Article 26 of this Agreement, but all parties agree that pending a final and binding determination regarding whether Customer improperly exercised its power to make such determination under this Section 32.6(e), Contractor shall be bound by such determination of Customer and shall proceed with the GEP, including but not limited to, proceeding to apply any Reduced TN Porting Price for an Applicable Reduction Period (as those terms are defined in Section 32.5(a), based upon such determination.

(F)Attendance of Personnel.  For all purposes of this Section 32.6(e), if attendance is required at meetings between Contractor and Customer, appropriate personnel from each party must attend.

(4)Definition of Failure.  A “Failure” of this GEP Element as reported on a GEP Audit Report shall be considered to occur whenever during an Associated EP Contractor does not complete any of the following Phases by issuance of the required deliverable within the required time frame set forth in this Section 32.6(e):

•EP Benchmarking Plan Development Phase:

•Issuance of final EP Benchmarking Plan

•Benchmarking Data Collection and Report Phase:

25

December 1, 2000 SOW 25NE

•Issuance of the EP Benchmarking Report

•Benchmarking Evaluation Phase

•Issuance of proposed SOW or Action Plan, as case may be.

•Implementation Phase

•Completion of SOW or Action Plan

(f)GEP Element No. 5: Root Cause Analysis and Reporting Satisfaction.

(1)GEP Element Description. This GEP Elements measures satisfaction during an EP of the Contractor’s obligation to prepare and to deliver the Root Cause Reports in accordance with the requirements of Section 10.3 of the Agreement.

(2)Definition of “Miss” and “Failure”.

(A)“Miss”.  A “Miss” of this GEP Element as reported in a GEP Audit Report shall be considered to occur for purposes of determining a GEP Reduction if for any single Outage that occurs within the Associated EP, any one or more of the Root Cause Reports (satisfying the requirements of Section 10.3 of the Agreement) for that specific Outage is not delivered within the specific time period for its delivery under Section 10.3 of this Agreement.  For purposes of the foregoing, only one “Miss” shall be given effect and considered to have occurred with respect to any single Outage no matter how many Root Cause Reports with respect to that Outage were not delivered within the specific time periods specified for their delivery.

(B)“Failure”. Notwithstanding the foregoing, a “Failure” of this GEP Element No. 5 as reported in a GEP Audit Report for purposes of determining the Carryover GEP Failure Reduction and for purposes of determining qualification for the Automatic One-Year Renewal Term shall be considered to occur if for any two or more Outages that occurred within the Associated EP, any one or more of the Root Cause Reports (satisfying the requirements of Section 10.3 of the Agreement) for those specific Outages were not delivered within the specific time periods for their delivery under Section 10.3 of this Agreement.

(g)GEP Element No. 6: Problem Escalation Satisfaction.

(1)GEP Element Description. This GEP Element measures satisfaction during an EP of the Contractor’s obligation for all Outages that occur during an EP to escalate management and supervisory responsibility to resolve the Outage though the appropriate management hierarchy and within the time periods established for such escalation until resolution of the Outage in accordance with the requirements of Section 10.4 of the Agreement.

(2)Definition of “Miss” and “Failure”.

(A)“Miss”.  A “Miss” of this GEP Element as reported in the GEP Audit Report shall be considered to occur for purposes of determining a GEP Reduction if for any single Outage that occurred within the Associated EP management and supervisory responsibility for resolving the Outage is not escalated through the appropriate management hierarchy or within

26

December 1, 2000 SOW 25NE

the required time periods under Section 10.4 of this Agreement.  For purposes of the foregoing, only one “Miss” shall be given effect and considered to have occurred with respect to any single Outage no matter how times during such Outage Contractor did not escalate the matter to the appropriate personnel or within the specific time periods specified.

(B)“Failure”.  A “Failure” of this GEP Element No. 6 as reported in a GEP Audit Report for purposes of determining the Carryover GEP Failure Reduction and for purposes of determining qualification for the Automatic One-Year Renewal Term shall be considered to occur if for any two or more Outages that occurred within the Associated EP the specific requirements of Section 10.4 of this Agreement are not satisfied.

(h)GEP Element No. 7a:  Billing Timeliness of Delivery Satisfaction.

(1)GEP Element Description.  This GEP Element measures whether Contractor has mailed all monthly invoices required pursuant to Section 6.6(c) of this Agreement (for purposes of this GEP Element, “Monthly Invoices”) on or before the 11th business day following the last day of Billing Cycle (the “Mailing Due Date”).

(2)Definition of Failure.  A “Failure” of this GEP Element as reported in the GEP Audit Report shall be considered to occur if any Monthly Invoice for any User is not mailed during the Associated EP on or before the Mailing Due Date either: (a) any 2 consecutive months in the Associated EP, or (b) any 3 or more months (even if not consecutive) during the Associated EP.

(i)GEP Element No. 7b: Billing Accuracy Satisfaction.

(1)GEP Element Description.  This GEP Element measures satisfaction of an element for purposes of the GEP which is intended to constitute the minimum requirements of “accuracy” of Monthly Invoices.  For purposes of this GEP Element No. 7b, “accuracy” of Monthly Invoices shall based upon the GEP Auditor’s determination of the elements that constitute measurable accuracy.

(2)Definition of Failure.  A “Failure” of this GEP Element as reported in the GEP Audit Report shall be considered to occur when based upon a measurement technique determined by the GEP Auditor as set forth in the Audit Plan to fairly measure Accuracy, including statistical sampling, on a monthly basis, fewer than that percentage of Monthly Invoices listed below for the applicable Associated EP are accurate:

•First and Second EP:  95%

•Subsequent EPs:  98%

4.9   GTA and Related Testing Agreements provisions.  On or before 30 days after the SOW Effective Date, Contractor shall submit to Customer an SOW with respect to the implementation of a test platform and associated services based upon the requirements submitted to Contractor on June 27, 2000.

27

December 1, 2000 SOW 25NE

4.10  Exhibit N Revisions.The parties agree that Exhibit N to the Master Agreement will be amended to revise the test scenario provided for in Section 2.1 thereof to reasonably accurately reflect the production environment.  Such amendment to Exhibit N to effect the foregoing shall be proposed and prepared by Contractor in consultation with the Customer.  If Contractor and Customer fail to agree in writing on the specific revision to Exhibit N to effect the foregoing on or before July 1, 2001, then for purposes of Article 3 of the Master Agreement, Contractor shall be unable to qualify for an Automatic One-Year Renewal Term due to failure to satisfy one of the two requirements set forth in such Article 3 for qualifying for the Automatic One-Year Renewal Term.  The parties agree to use reasonable commercial efforts to hold the necessary meetings and consultations expeditiously to discuss the revisions to Exhibit N.

4.11   Notices.  Article 27.6 of the Master Agreement is amended in its entirety to read as follows:

27.6Notices

(a)All notices or other communications required or permitted to be given under this Agreement shall be considered to be in writing (unless otherwise specifically provided herein) if delivered and addressed as follows:

(i)by electronic mail delivery to the electronic mail address given and as set forth below, without the necessity of verification of receipt of such transmission;

(ii)by personal delivery to the person to whom the same is directed, at such address given and maintained as set forth below;

(iii)by registered or certified mail, postage and charges prepaid, or by a recognized overnight delivery service, addressed to the person to whom the same is directed, at such address given and maintained as set forth below; or

(iv)by facsimile transmission to the facsimile number of the person to whom the same is directed, at such address given and maintained as set forth below.

For purposes of the foregoing, notices and other communications shall be sent to the following persons on behalf of the Customer and the Contractor respectively:

If to Customer:To the then current chair (or if more than one chair, all co-chairs) of the Customer and to all Project Executives for the Customer

If to Contractor:To the Contractor’s Project Executive

With a copies to:NeuStar, Inc.

Attn:  Mr. Joseph Franlin

          Mr. Steve Cory

          Mr. David Heath

28

December 1, 2000 SOW 25NE

(b)Any notice or communications under this Agreement shall be deemed to have been given and delivered for purposes of this Agreement as follows:

(i)For notice by electronic mail, when an electronic mail message is transmitted to the electronic address given and maintained as set forth below, regardless of whether or not actually received by the intended recipient;

(ii)For notice by personal delivery, upon delivery (even without signed receipt) to the address given and maintained as set forth below;

(iii)For notice by either mail or overnight delivery on two business days after mailing or one business day after delivery by the overnight delivery service, regardless of whether or not actually received by such Member; or

(iv)For notice by facsimile, upon completion of the facsimile transmission to the facsimile number given and maintained as set forth below, substantiated by a print out of the log verifying transmission, regardless of whether or not actually received by such Member.

(c)For purposes of the foregoing, each party shall provide to the other the following current information for each of the representatives identified above:  (i) address of such representative which is sufficient for registered or certified mail deliveries and deliveries by overnight delivery services; (ii) facsimile number for such representative; and (iii) telephone number for such representative during Normal Business Hours.  At any time, by written notice by facsimile or regular mail only, any party may change or amend any of the information set forth above, and upon receipt of such change or amendment, the other party shall confirm such change or amendment by any of the methods of notice set forth above, and shall thereafter maintain such information unless otherwise changed in accordance with the foregoing method.

(d)Notwithstanding the forgoing, all notices or other communications required or permitted to be given under Articles 3, 9, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25 and 26 and Section 10.3 that are delivered by the method of notice under 4.11(a)(i) shall be confirmed by any of the methods of notice set forth in 4.11(a)(ii), (iii) and (iv) and a copy shall be provided to Customer’s current legal counsel.

5.Miscellaneous:

5.1The parties have disagreed as to whether porting transactions associated with “pooling” activities constitute Services under the Master Agreement, and whether the charges under Section 6.1 of the Master Agreement at the prices set forth in the Pricing Schedules are applicable to such pooling activities (the “Dispute”).   The parties agree and acknowledge that “Services” under the Master Agreement shall include for all purposes of the Master Agreement pooling activities, and Users shall be charged for pooling activities under

29

December 1, 2000 SOW 25NE

Article 6.1 of the Master Agreement at the prices set forth in the Pricing Schedules, as amended by this SOW.  For purposes of the preceding sentence, the parties agree and acknowledge that each pooling occurrence shall be subject to a charge equal to the product of the number of TNs comprising the block to be pooled times the price per TN Porting Event shown on Schedule 1 of Exhibit E, as amended by this SOW.  Notwithstanding anything to the contrary contained in this SOW, the parties expressly and explicitly agree and acknowledge that the only consideration for the compromise and settlement of the Dispute is the agreement of the parties to the resolution of the Dispute hereunder, and that no other consideration, express or implied, was involved in such resolution, including the modifications and amendments to the Master Agreement made herein which were negotiated separate and apart from the resolution of the Dispute.  Except as specifically agreed to in the foregoing regarding compromise and settlement of the Dispute, both parties expressly and explicitly state that nothing contained herein is intended to constitute nor shall it be implied to constitute an acceptance or acknowledgment of, or an acquiescence to, the contentions or positions of the other party regarding the Dispute.  Further, nothing contained in this SOW is intended nor shall it be implied to constitute any change or any acknowledgment, with respect to the inclusion, treatment or charges for operations or processes other than pooling occurrences, and the parties expressly and explicitly do not waive, release or otherwise alter their rights or remedies with respect to such other operations or processes.

5.2The parties agree and acknowledge that Article 29 of the Master Agreement shall not apply with respect to the execution and delivery of this SOW 25NE.

5.3The following are the impacts on the Master Agreement:

	Master Agreement
None	Exhibit B Functional Requirements Specification
None	Exhibit C Interoperable Interface Specification
	Exhibit E Pricing Schedules
None	Exhibit F Project Plan and Test Schedule
	Exhibit G ServiceLevel Requirements
	Exhibit H Reporting and Monitoring Requirements
None	Exhibit J User Agreement Form
None	Exhibit K External Design
None	Exhibit L Infrastructure/Hardware
	Exhibit N System Performance Plan for NPAC/SMS Services
None	Disaster Recovery
None	Back-up Plans

5.4Except as specifically modified and amended hereby, all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms.  From and after the SOW Effective Date hereof, any reference in the Master Agreement to itself and any Article, Section or subsections thereof or to any

30

December 1, 2000 SOW 25NE

Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the SOW Effective Date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit, as modified and amended by this.  From and after the SOW Effective Date, this SOW  shall be a part of the Master Agreement, including its Exhibits, and, as such, shall be subject to the terms and conditions therein.  Each of the respective Master Agreements with respect to separate Service Areas remains an independent agreement regarding the rights and obligations of each of the Parties thereto with respect to such Service Area, and neither this SOW  nor any other instrument shall join or merge any Master Agreement with any other, except by the express written agreement of the Parties thereto.

5.5           Except for the SLR-2 Letter Agreement, this SOW sets forth the entire understanding between the Parties with regard to the subject matter hereof and supersedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.

5.6           If any provision of this SOW  is held invalid or unenforceable the remaining provision of this SOW shall become null and void and be of no further force or effect.  If by rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this SOW or the Master Agreement, this SOW is required to be rescinded or is declared ineffective or void in whole or in part, whether temporarily, permanently or ab initio (an “Ineffectiveness Determination”), immediately upon such Ineffectiveness Determination and without any requirement on any party to appeal, protest or otherwise seek clarification of such Ineffectiveness Determination, this SOW shall be rescinded and of no further force or effect retroactively to the SOW Effective Date.  Consequently, the Master Agreement in effect immediately prior to the SOW Effective Date shall continue in full force and effect in accordance with its terms, unchanged or modified in any way by this SOW.  In the event of an Ineffectiveness Determination, any amounts that would have otherwise been due and payable under the terms and conditions of the Master Agreement, in effect immediately prior to the SOW Effective Date (including, but not limited to any adjustments necessary to retroactively reprice TN Porting Events under Schedule E from the SOW Effective Date through the date of the Ineffectiveness Determination, or other amounts or credits, to any party hereunder), shall be invoiced by Contractor at the earliest practical billing cycle in accordance with the Master Agreement and shall be due and payable in accordance with the applicable invoice therewith or shall be credited or applied for the benefit of the Customer or any User in accordance with the Master Agreement.

5.7If at any time hereafter a Customer, other than a Customer which is a party hereto desires to become a party hereto, such Customer may become a party hereto by executing a joinder agreeing to be bound by the terms and conditions of this SOW, as modified from time to time.

31

December 1, 2000 SOW 25NE

5.8           This SOW may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed thesame document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

5.9This SOW is the joint work product of representatives of Customer and Contractor; accordingly, in the event of ambiguities, no inferences will be drawn against either Party, including the Party that drafted the Agreement in its final form.

IN WITNESS WHEREOF, the undersigned have executed this Statement of Work 25NE as of the date first written above.

Contractor:

NeuStar, Inc.

By:

Name:

Title:

Customer:

North American Portability Management LLC
as successor to Northeast Carrier Acquisition Company, LLC

By:

Name:

Title:

32

December 1, 2000 SOW 25NE

ATTACHMENT 1 TO SOW 25NE

EXHIBIT E

PRICING SCHEDULES

NPAC/SMS SERVICES

33

December 1, 2000 SOW 25NE

EXHIBIT E - PRICING SCHEDULES

The following schedules set forth the prices at which Contractor will be compensated for rendering the Services under the Agreement.  A general description of these charges and the methods of billing therefor are set forth in Section 6 of the Agreement.  See Agreement for other applicable charges.

Schedule 1

Service Element Fees/Unit Pricing

Category	Service Element	Unit	Price
[* * *]
	[* * *]	[* * *]	$		[* * *]
	[* * *](1)	[* * *]	$		[* * *]
	[* * *](2)	[* * *]	$		[* * *]
	[* * *]	[* * *]	$		[* * *]
	[* * *]	[* * *]	$		[* * *]
[* * *]
	[* * *](3)	[* * *]	$		[* * *]
	[* * *](3)	[* * *]	$	-[* * *]
			$	-[* * *]
	[* * *](4)	[* * *]
			$		[* * *]
			$		[* * *]
			$		[* * *]
			$		[* * *]
			$		[* * *]
			$		[* * *]
	[* * *]	[* * *]	$		[* * *]
	[* * *]	[* * *]	$		[* * *]
[* * *]
	[* * *](5)	[* * *]	$		[* * *]
	[* * *](6)	[* * *]	$		[* * *]

(1)Monthly port charges [* * *] The specific cost elements include

(2)See Note 1 above.

(3)[* * *]

34

December 1, 2000 SOW 25NE

Billable NPAC User Support Manual Request Table

Category	Description of Request
Create SV	New SP asks Help Desk to issue new SP Create, for single TN or range of TNs
Create SV	Old SP asks Help Desk to issue old SP Create, for single TN or range of TNs
Prevent SV Activation	Old SP asks Help Desk to change concur flag to “false” on pending SV (or SVs, for range of TNs)
Activate SV	New SP asks Help Desk to activate a pending SV for a single TN (or SVs, for a range of TNs)
Remove Prevention of SV Activation	Old SP (or New SP, after due date or t2 timer’s expiration) asks Help Desk to change concur flag to “true” on pending SV (or SVs, for range of TNs)
Modify Pending SV	New SP asks Help Desk to modify single SV (or SVs, for a range of TNs)
Disconnect TN	Current SP asks Help Desk to issue disconnect for TN (or range of TNs)
Cancel Pending SV	Old SP or New SP asks Help Desk to issue its cancel for pending SV (or SVs, for range of TNs)
Look Up SV	SP asks Help Desk to look up active SV for a TN (or SVs for range of TNs)
Modify Active SV	Current SP asks Help Desk to modify single active SV
Audit SV	SP asks Help Desk to issue audit request for a TN, or range of TNs, with SV(s) in active state
Look Up Network Data	SP asks Help Desk to look up NPA-NXX, NPA-NXX ID, LRN, or LRN ID to determine associated SPID and/or ID
Change Network Data	SP asks Help Desk to add, modify, or delete an NPA-NXX or LRN in its network data
Key Exchange	(SP not in the “new customer turn-up” process.) SP asks Help Desk to perform key exchange when any keys are unused or uncompromised except where SP request is due to “NPAC-initiated responsible incident”
Change GUI Password	SP asks Help Desk to change its GUI Password
Re-enter GUI Logon	SP asks Help Desk to re-enter its GUI Logon which SP has allowed to expire

(4)The TN Porting Event [* * *]

The TN Porting Event [* * *]

(5)The one-time Log-on ID [* * *]

(6)The Mechanized Interface [* * *]

35

December 1, 2000 SOW 25NE

Schedule 2

Training Charges

Year	Cost Per Participant
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]
[* * *]	$	[* * *]

* [* * *]

Schedule 3

Interoperability Testing

Category & Service Element	Unit	Price
[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]	[* * *]	$	[* * *]

Schedule 4

Schedule of Representative Hourly Labor Charges

Applicable to Statements of Work

For Contract Years 1 Through End

Labor Category	Year 1		Year 2		Year 3		Year 4		Year 5*
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]

36

December 1, 2000 SOW 25NE

*Amounts after Year 5 for each Labor Category shall be increased by 5% annually from the prior year.

Schedule 5

Schedule of Target Amounts

Target Options

Monthly Targets for Nov/Dec 1997  (2)

Monthly Targets for 1Q 1998 (2)

Monthly Targets for 2Q 1998 through 4Q 2001 (2)

Monthly Targets for 1Q 2002 through 2Q 2002 (2)

Monthly Target for July 2002

Total Contract Targets

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

Notes:

(1)The target schedule depends on the service term selected by the Customer.  If the service term begins on 10/1/97, then Option A applies.  Likewise, if the service term begins on 1/1/98, then Option B applies.

(2)The targets are listed in monthly amounts for each of the respective calendar periods outlined above.  The targets are calculated and applied on a monthly basis as described in Section 6.6 of the Agreement.

37

December 1, 2000 SOW 25NE

Schedule 6

Sample Annual Target and Allocable Target Shortfall/Credit Calculation

The following is an example of how Allocable Target Shortfalls and Allocable Targets are determined in connection with the Quarterly Targets.  A description of the methodology (including defined terms used below) is set forth in Section 6.6 of the Agreement.

	Jan-98		Feb-98		Mar-98
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *] [* * *]	[* * *]		$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	([* * *]	$	([* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]

* Note:

[* * *]

[* * *]

38

December 1, 2000 SOW 25NE

ATTACHMENT 2 TO SOW 25NE

EXHIBIT  H

REPORTING AND MONITORING REQUIREMENTS

NPAC/SMS SERVICES

39

December 1, 2000 SOW 25NE

EXHIBIT H — REPORTING AND MONITORING REQUIREMENTS

Name of Report	Items Covered	Frequency of Issuance*	Pricing
Reports for Individual Service Provider/Users	Reports described in the following items in Section 9.2 of Exhibit B — NPAC/SMS Functional Requirement Specifications: •RP9-1 Service and Network Data Reports •RP9-2 Service Provider Reports •RP9-3 Subscription Data Reports •RP9-4 System Reports •RP9-5 Security Reports •RP9-6 Log File Reports •RP9-7 Audit Reports •RR9-1 Data Integrity Reports NOTE:  The set of reports listed above (Reports of Individual Service Providers/Users) is not the entire set of Standard Reports available to Users.  For a complete list, Users should reference the applicable FRS or by using the procedures outlined in the Methods and Procedures, via the LTI.	R	[***]
Monthly and Quarterly Management and Performance Reports to Customer	As to the entire Service Area: •Information and data covered by reports listed in “Reports for Individual Service Provider/Users” above •Actual performance compared with Service Levels in Exhibit G •Significant changes in or new installations of: •System Software •System hardware •Communications Networks	M, Q	[***]

40

December 1, 2000 SOW 25NE

•Application Software

•Key Personnel

•All Software/hardware problems (even if not impacting system availability)

•“Top 10” most frequent trouble reports

•Pooling Reports:

1.1K Block Administration Report: A report that shows when the 1K Block information is received from the Pool Administrator and when it is entered into the NPAC.

2.NPAC Activation Report: A report that shows when the 1K Block was scheduled for Activation and when it was Activated and when the NPAC Personal notified the appropriate parties that the Activation was accomplished, such as Pool Administrator, Block Holder, Code Holder, as per INC Guidelines.

3.1K Block Modification report: A report that shows when the Modification request of a 1K Block was received, entered and processed.

4.De Pooling/Reclamation Report: A report that shows when the De Pooling/Reclamation request of a 1K Block was received, entered and processed. The report also needs to show when the NPAC Personnel notified the appropriate parties that the De Pooling / Reclamation was accomplished, such as Pool

41

December 1, 2000 SOW 25NE

	Administrator, Block Holder, Code Holder, as per INC Guidelines.
	5.Ported Pooled Report: A report that shows the Volume of Pooled TN’s ( aggregate number of Pooled Blocks) and the Volume of Ported TN’s aggregated for the Service Area.
Annual Management and Performance Reports	Same as monthly/quarterly reports, and also including: •Summary of significant events and accomplishments of the year •Comparison of goals for previous period with actual performance •Plans/goals for following year	A	[***]

*KEY:

R =Report Issued on Request of Service Provider or User

M =Monthly (due by 11:59 P.M. (Central Time) of the 15th calendar day of each month following the month with respect to which the Report relates, except for the December Report which shall be due by 11:59 P.M. (Central Time) of the following February 1 – see key for Annual Report, below)

Q =Quarterly (the Monthly Reports for March, June, September and December, which are due by 11:59 P.M. (Central Time) of the 15^th calendar day of each month following the close of each quarter, shall also serve as Quarterly Reports, and shall present information for the calendar quarter in which such month falls in addition to monthly information for said month)

A =Annually (due by 11:59 P.M. (Central Time) on February 1 of each year for the immediately preceding January - December period; the December Monthly/Quarterly Report shall also serve as the Annual Report, and shall present information for the full year in addition to the monthly information for December and the quarterly information for the fourth calendar quarter of the year)

42

December 1, 2000 SOW 25NE

ATTACHMENT 3 TO SOW 25NE

1)Amendment to Exhibit G:  The parties agree that SLR-2 is temporarily changed as follows:

SLR No.	Procedure	Service Commitment Level	Service Affecting/ Non-Service Affecting	Performance Credit	Report Frequency and Performance Credit Calculation Interval
2.	Scheduled Service Unavailability (Customer)	Scheduled Service Unavailability time shall not exceed any of the following: (1)   15 hours during  the Two Month Period (the “15 Hour Requirement”) or 20 hours during the Three Month Period (the “20 Hour Requirement”) (2)   0 hours for any day other than the first Sunday of any month (the “Sunday Requirement”) (3)   10 hours for any single event of Scheduled Service Unavailability (the “Single Event Requirement”) and (4)   any task resulting in Scheduled Service Unavailability must commence after 6 am CST (the “6 am Requirement”)	Service Affecting	$[* * *] for each hour or portion thereof  of Scheduled Service Unavailability time which exceeds or fails to satisfy any of the following: (1)   During the Two Month Period, the 15 Hour Requirement or during the Three Month Period, the 20 Hour Requirement. (2)   During any month, the Sunday Requirement (3)   For any single event of Scheduled Service Unavailability, the Single Event Requirement (4)   For any single event of Scheduled Service Unavailability, the 6 am Requirement

For purposes of this Attachment 3 to SOW 25NE, the Two Month Period shall commence on December 1, 2000 and end on January 31, 2001, and the Three Month Period shall commence on February 1, 2001 and end on April 30, 2001.

43

December 1, 2000 SOW 25NE

2)Operation with Respect to GEP Element No. 3.  In the event that the parties agree to extend the terms of the Temporary SLR-2 Modification upon the same terms of paragraph 1 of this Attachment 3 beyond April 30, 2001, for one or more three month periods (a “Subsequent Three Month Period”) for purposes of measuring satisfaction of GEP Element No. 3 pursuant to Section 32.6d. of the Master Agreement, a “Failure” of GEP Element No. 3 shall be considered to occur when the applicable Scheduled Service Unavailability time exceeds or fails to satisfy any of the following:

a)The 20 Hour Requirement more than once during any Subsequent Three Month Period.

b)The Sunday Requirement either (1) any 2 consecutive times in the Associated EP, or (2) any 3 or more times (even if not consecutive) during the Associated EP.

c)The Single Event Requirement either (1) any 2 consecutive times in the Associated EP, or (2) any 3 or more times (even if not consecutive) during the Associated EP.

d)The 6 am Requirement either (1) any 2 consecutive times in the Associated EP, or (2) any 3 or more times (even if not consecutive) during the Associated EP.

3)Additional Obligations.  In addition to the foregoing and as a continuing obligation during the time of the Temporary SLR-2 Modification, and any extension thereof, Contractor shall be required to provide an Advance Notification and a Post Mortem Report of all activity/functions performed during each NPAC Scheduled Service Unavailability time.

a)The Advance Notification is to be provided to each respective of the Customer’s Project Executive at least 10 business days in advance of the date the Schedule Service Unavailability event is to be performed.

b)The Post Mortem report is to be provided to the Customer’s Project Executive on or before the close of four business days following the performance of each NPAC Scheduled Service Unavailable time.

c)Each Notification and/or Report shall report the required data under the following category descriptions: a Task by Task Description, Planned Down Time (Start and End Time), Actual Down Time (Start and End Time), and Duration.

4)Agreement to Consider Actual History.  Subject to the preceding provisions of this Attachment 3, from this SOW Effective Date through the end of the Three Month Period, Customer and Contractor shall jointly evaluate the prior results of NPAC Scheduled Service Unavailability time activity/functions actuals, i.e., actual Scheduled Service Unavailability required each month.

5)  Express Continuing Reservation. The agreement set forth herein is not intended by itself to in any way constitute an agreement or waiver of the Performance Credits referenced in Exhibit G  (as modified by the SLR-2 Letter Agreement) for any period other than the period commencing with the SOW Effective Date and concluding with the expiration of the Three Month Period, unless sooner ended pursuant to the previous provisions of this Attachment 3.

44

December 1, 2000 SOW 25NE

ATTACHMENT 4 TO SOW 25NE

•Items to be Benchmarked

•Methodology to be used

•What industries will be used to compare to

•Metrics to be used for comparison and ranges or delineation of metrics (including round off conventions and related measurement and representation conventions)

•Timeframes for initiation and completion of steps in methodology

•Conventions or rules of ordering for interpretation and data collection disputes or disagreements (i.e. Who the field boss is and who has the ultimate say on disagreements) and in-field revisions

•Criteria for selection of Benchmarker

•Requirements for data collection, compilation and reporting, including in-field audits and accompaniment by LLC representatives

•Delineation of line of authority and reporting for Benchmarker

•Requirements for Benchmarking Report and back-up substantiation, including date of delivery in final form and requirements of draft preparation, LLC review and NeuStar revisions for final delivery, and including specifically the scope and detail required for Conclusions and Recommendations.

•Requirements for data authentication, verification and substantiation

•Requirements for peer review

•Requirements for determining sufficiency of any data collection, metric satisfaction or criteria satisfaction

•Requirements for specific timeframes and elements of the Evaluation Phase related to this particular EP Benchmarking, including the substantive content requirements for an Evaluation Report by NeuStar

•Format for an Action Plan if no SOW is determined to be needed

45

STATEMENT OF WORK

SOW 30 NE

STATEMENT OF WORK

(Northeast Region Service Area)

1.INTRODUCTION; PARTIES.  This Statement of Work (referred to herein as “this SOW” and referred to in the Master Agreement, as defined below, as “SOW 30NE”) is entered into pursuant to Article 13 and Article 30 of, and on execution shall be a part of, the Agreement for Number Portability Administration Center / Service Management System (the “Master Agreement”) between NeuStar, Inc., a Delaware corporation (“Contractor”), and the North American Portability Management LLC, a Delaware limited liability company (the “Customer”), as the successor to the Northeast Carrier Acquisition Contractor, LLC, a New York limited liability company.

2.  SOW EFFECTIVE DATE.  This SOW shall be effective with respect to the Contractor and the Customer only on execution by Contractor and Customer in accordance with Article 30 of the Master Agreement, and the date this SOW becomes effective shall be the “SOW Effective Date.”  Except as otherwise specified herein, the provisions of this SOW shall be effective as of the SOW Effective Date.  The number in the upper right hand corner refers to this SOW.

3.  CONSIDERATION RECITAL.  In consideration of the terms and conditions set forth in this SOW, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, the parties agree as set forth in this SOW. The modifications and amendments made herein were negotiated together, and each is made in consideration of all of the other terms herein.  All such modifications and amendments are interrelated and are dependent on each other.  No separate, additional or different consideration is contemplated with respect to the modifications and amendments herein.

4.  LOAN AGREEMENT.  As set forth in greater detail herein, an affiliate of Contractor (the “Borrower”) and certain lenders (the “Lenders”) will enter in a loan agreement (the “Loan Agreement”) pursuant to which the Lenders will establish for the Borrower a secured loan facility for the purpose of making the Loans set forth in the Loan Agreement.  Unless otherwise explicitly defined herein, capitalized terms used herein shall have the meanings as defined in the Master Agreement, the Loan Agreement or the Trust Agreement referred to below, as the case may be.

5.  MODIFICATION OF AND AMENDMENT TO THE MASTER AGREEMENT.

5.1SOW Secured Financing.

(a)Acknowledgement.  The Customer hereby acknowledges that (i) all of the Contractor’s right, title and interest in and to all SOW Receivables and LNP Receivables (each as defined in the Trust Agreement referred to below), including any SOW Receivables and LNP Receivables arising in the future, will be transferred and assigned to NeuStar Funding LLC (the

2

SOW 30 NE

“Borrower”), a newly formed, bankruptcy remote special purpose subsidiary of the Contractor pursuant to the terms and conditions of that certain Receivables Transfer Agreement (the “Transfer Agreement”); (ii) the Borrower will enter into a loan agreement (the “Loan Agreement”) with certain lenders (the “Lenders”) pursuant to which the Lenders will establish for the Borrower a secured loan facility for the purposes of making the Loans described in the Loan Agreement (the “Loan Facility”); and (iii) the Borrower will enter into the NeuStar Master Trust Agreement (the “Trust Agreement”) and convey all of its right, title and interest in and to all SOW Receivables and LNP Receivables, including any SOW Receivables and LNP Receivables arising in the future, to the NeuStar Master Trust (the “Trust”), in exchange for the Financed SOW Receivables Tracking Certificate, the Future SOW Receivables Tracking Certificate and the LNP Receivables Tracking Certificate (each as defined in the Trust Agreement). As a condition to the effectiveness of the Loan Agreement, the Borrower will grant to Deutsche Bank AG, New York Branch (“DBNY”), as administrative agent acting on behalf of the Lenders (the “Administrative Agent”), a perfected, first priority security interest in and to the Financed SOW Receivables Tracking Certificate representing a beneficial intent in the Trust and the right to receive any amount available for distribution in connection with the Financed SOW Receivables.  In connection with the Customer’s agreements hereunder relating to the aforementioned transactions, the Contractor has delivered to the Customer the Operative Agreements (as defined in the Loan Agreement) in substantially the form to be executed by the parties thereto, except the Notes, the Fee Letter Agreement, each Receivables Assignment, each Lockbox Confirmation, the Master Agreement and the Amendment to Master Agreement, such documents delivered by Contractor referred to herein as the “Provided Agreements.”  Accordingly, the Customer acknowledges both the receipt of the Provided Agreements and that it has consulted with its counsel to the extent that it has deemed appropriate.

(b)Consent to Loan Facility and Assignment of SOW Receivables.  Without in any way implying whether a consent is or is not required under the Master Agreement and subject to the conditions set forth in this Section 5.1(b), the Customer consents to the following transactions (a) the transfer by the Contractor of all of its right, title and interest in and to the SOW Receivables and LNP Receivables (including all rights to payments with respect thereto) to the Borrower pursuant to the terms and conditions of the Transfer Agreement; (b) the conveyance by the Borrower of all of its right, title and interest in and to the SOW Receivables and LNP Receivables (including all rights to payments with respect thereto) to the Trust, in exchange for the Financed SOW Receivables Tracking Certificate, the Future SOW Receivables Tracking Certificate and the LNP Receivables Tracking Certificate; (c) the grant by the Borrower of a first priority security interest in and to the Financed SOW Receivables Tracking Certificate to the Administrative Agent, on behalf of the Lenders, to secure the Borrower’s obligations under the Loan Facility and the perfection of such security interest in accordance with the Provided Agreements, (d) the appointment of the Contractor to act as initial servicer of the SOW Receivables subject to the approval rights of the Administrative Agent provided for in the Provided Agreements, (e) the appointment of BNY Asset Management or another entity satisfactory to the Lenders in their sole discretion as back-up servicer for the Financed SOW Receivables; and (f) the appointment of such back-up servicer to become successor servicer for the Financed SOW Receivables, in accordance with the Servicing Agreement, and perform the duties thereunder upon the occurrence of and during the continuance of a Servicer Termination

3

SOW 30 NE

Event defined under the Servicing Agreement. Notwithstanding the foregoing, this consent shall be conditioned upon receipt by the Customer of a binding and effective agreement and acknowledgment, in a form satisfactory to Customer (the “Agreement and Acknowledgement”), that the Customer, Contractor, Administrative Agent, Borrower and Lenders agree and acknowledge that (1) notwithstanding any provisions of the Operative Agreements to the contrary and without in any way implying whether a consent is or is not required under the Master Agreement, the foregoing consent by the Customer is not intended to constitute and shall not be deemed or considered by the Lenders, the Administrative Agent, the Contractor or the Borrower to constitute a waiver of any rights or remedies whatsoever against or with respect to the Contractor or the Borrower (or any of their successors or assigns), that may now exist or which may in the future exist in the absence of the  Operative Agreements(other than as expressly waived solely with respect to the right of offset or deduction against Financed SOW Receivables as set forth in section 5.1( c ) below); (2) without in any way implying whether a consent is or is not required under the Master Agreement, the foregoing consent by the Customer is not intended to constitute and shall not be deemed or considered by any such parties to constitute a consent to the assignment of the SOW Receivables (other than the Financed SOW Receivables) or of the LNP Receivables or of any of their proceeds or products or of any of their corresponding Tracking Certificates (other than the Financed SOW Receivables Tracking Certificate), except for the assignments to the Borrower and to the Trust pursuant to the terms and conditions of the Provided Agreements, or to the grant of any security interest or pledge whatsoever in the SOW Receivables (other than the Financed SOW Receivables)or in the LNP Receivables or in any of their proceeds or products or any of their corresponding Tracking Certificates (other than the Financed SOW Receivables Tracking Certificate); (3) from and after the date hereof (and excepting for the transfer noted in section 5.1(d) below), without the prior written consent of the Customer which may be withheld by Customer in its sole discretion, the LNP Receivables, the LNP Receivables Tracking Certificate or the beneficial interests therein or any of their proceeds or products shall not be assigned, pledged, conveyed, hypothecated or in any way assigned to or for the benefit of the the Administrative Agent or the Lenders, or any one of them, or to or for the benefit of any one or more of their affiliates or related parties, in connection with the Loan Facility and the Operative Agreements or any amendments, modifications, revisions, enhancements, corrections, substitutions, replacements, cancellation or changes  thereto; (4) that the Administrative Agent, the Lenders, the Contractor and the Borrower and all of their successors and assigns will not assert or claim a position contrary to the foregoing and that the Lenders, the Contractor and the Borrower will cause their separate successors, assigns, agents, representatives or fiduciaries, including the Administrative Agent, Servicer and the Trustee not to assert or claim a position contrary to the foregoing ; and (5) that any consent of the Customer with respect to the Servicer shall be void to the extent contrary to the rulings or orders of the Federal Communications Commission, or any successor thereto.  Subject to the foregoing limitations, requirements and conditions, the consent set forth in this section 5.1(b) shall (i) be deemed to constitute a consent under Section 22.1 and (ii) apply notwithstanding the limitations set forth in Section 22.2 of the Master Agreement. Upon execution and delivery of the Agreement and Acknowledgement by all parties thereto, Customer shall provide written confirmation of the satisfaction of the requirements of delivery of the Agreement and Acknowledgment.

4

SOW 30 NE

(c)Waiver of Right of Set-Off.  The obligations of the Customer and the carriers and other entities which the Contractor is entitled to bill under the Master Agreement (“Users”) shall not be subject to, and the Customer hereby expressly waives, any right of setoff or deduction against amounts due and payable in respect of the Financed SOW Receivables that might arise by reason of any failure by the Contractor to perform any of its obligations relating to such Financed SOW Receivables or relating to any other Statement of Work entered into at any time, whether prior to or after the date hereof, under the Master Agreement or under any other agreement between the Customer and the Contractor and any of its affiliates (such other Statements of Work and other agreements are collectively referred to as the “Other Agreements”).  Notwithstanding the foregoing, by its execution hereof, neither the Customer nor any User releases, waives, discharges or otherwise agrees to forego any rights or remedies (other than set-off or deduction against amounts due and payable in respect of the Financed SOW Receivables) that may be asserted against the Contractor under any SOW or the Other Agreements, whether at law or in equity, including but not limited to termination, Performance Credits or damages, but subject to any applicable restrictions set forth in each SOW or the Other Agreements.

(d)Further Assurances.   Customer has given its consent as set forth in this SOW expressly conditioned upon the following additional assurances from the Contractor, the Borrower, the Lenders, the Administrative Agent, the Servicer and the Trustee:

(1)The LNP Receivables have been transferred and are held under the Trust Agreement for the benefit of Contractor and Borrower subject to the right of Users under User Agreements to assert setoff claims against the LNP Receivables. The Lenders, the Servicer, the Trustee and the Administrative Agent consent to the terms of this SOW.

(2)Any and all documents delivered under the Operative Documents which contain Customer information, files or data shall be afforded the confidentiality required by Contractor under the Master Agreement, and all disputes under the Master Agreement among Customer, Users, Contractor, Borrower, Lenders and/or Administrative Agent shall be governed by the dispute resolution procedures set forth in the Master Agreement.

(3)Customer and Users shall not be liable to the Lenders or the Administrative Agent for the failure of Borrower and/or Contractor to obtain approval of SOWs, or any modifications or amendments to SOWs or for any statements made by Borrower or Contractor with respect to the enforceability thereof or any purported claims or defenses thereunder (or the lack thereof) as it is understood that the Lenders and the Administrative Agent are relying solely upon Borrower and Contractor with respect to said covenants, warranties, representatives and disclosures.  In addition, Lenders, Administrative Agent, Servicer and Trustee each agree that Customer and Users may condition the execution of future Statements of Work upon the reinstatement of rights of offset and deduction with respect to receivables payable in connection with such future Statements of Work, to the extent that the Customer, any User or Users, Borrower or

5

SOW 30 NE

Contractor, in the context of the business negotiations, find such a reinstatement appropriate.

(4)The Contractor, the Borrower, the Lenders and the Administrative Agent agree that no previously executed document and no document executed in the future, except to the extent specifically provided therein and specifically consented to by Customer in writing shall contradict, diminish or otherwise impair the benefits, privileges and rights afforded the Customer under this SOW.  In particular, any documents requested to be executed under this section 5.1 (d) of this SOW shall expressly recite that they are made subject to and conditioned upon the assurances set forth in this Agreement and Acknowledgment.

(5)The Customer has made no representation or warranty whatsoever to the Contractor, the Borrower, the Lender, the Trustee or the Administrative Agent regarding the enforceability of the modification of the Master Agreement pursuant to this SOW on Users.

(6)The Lender and the Administrative Agent shall notify Customer of any material default by the Borrower or the Contractor under any of the Operative Agreements.

5.2Revision to Financing Costs.  The last three sentences of Article 13.1 of the Master Agreement are hereby deleted and replaced in their entirety with the following paragraph:

In the event the parties execute a Statement of Work after the Effective Date, whereunder Contractor agrees to provide Additional Services on behalf of Customer for a lump sum (the “SOW Purchase Price”), Customer shall have the option to select a method for payment of the SOW Purchase Price by Users of either (i) in one lump sum payment on the date the SOW Purchase Price is to be invoiced (the “SOW Invoice Date”), as determined in the applicable Statement of Work or (ii) through financing the SOW Purchase Price with Contractor for the lesser of (i)  thirty-six (36) months and (ii) the remainder of the term of this Agreement, commencing on the SOW Invoice Date.  In the event that Customer fails to provide Contractor with written notice of its intention to finance the SOW Purchase Price as set forth above within sixty (60) days after the applicable Statement of Work Effective Date, the entire SOW Purchase Price shall become immediately due and payable by the Users on the SOW Invoice Date.  The financing charge for any Statement of Work financed under this Article 13.1 shall be equal to 13 percent per year; provided, however, if Contractor has established the Loan Facility, the finance charge with respect to any Statement of Work (an “Applicable SOW”) for which the receivables associated with such Applicable SOW are considered Financed SOW Receivables under the Operative Agreements, shall from the specific Reallocation Date at which such Applicable SOW’s receivables are reallocated from the Future SOW Receivables Tracking Certificate to the Financed SOW Receivables Tracking Certificate pursuant to the terms of the Reallocation Agreement for such Applicable SOW and continuing for so long such Applicable SOW’s receivables are allocated to the Financed SOW Tracking Certificate, be equal to the lesser of: (i) the thirty-six (36) month LIBOR on the SOW Invoice Date plus 532 basis points and (ii)the “Reserve Adjusted LIBOR Rate” (as defined in the Loan Agreement) applicable to the Financed SOW Receivables under the Loan Facility plus loan fees actually attributable to and charged on

6

SOW 30 NE

the Financed SOW Receivables under Section 2.3(a), 2.3(b) and/or 2.3(c)(i) of the Loan Agreement.

6.0Miscellaneous.

6.1The following are the impacts on the Master Agreement:

Master Agreement

NoneExhibit B Functional Requirements Specification

NoneExhibit C Interoperable Interface Specification

NoneExhibit E Pricing Schedules

NoneExhibit F Project Plan and Test Schedule

NoneExhibit G ServiceLevel Requirements

NoneExhibit H Reporting and Monitoring Requirements

NoneExhibit J User Agreement Form

NoneExhibit K External Design

NoneExhibit L Infrastructure/Hardware

NoneExhibit N System Performance Plan for NPAC/SMS Services

NoneDisaster Recovery

NoneBack-up Plans

6.2Except as specifically modified and amended hereby, all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms.  From and after the SOW Effective Date hereof, any reference in the Master Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the SOW Effective Date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit, as modified and amended by this.  From and after the SOW Effective Date, this SOW shall be a part of the Master Agreement, including its Exhibits, and, as such, shall be subject to the terms and conditions therein.  Each of the respective Master Agreements with respect to separate Service Areas remains an independent agreement regarding the rights and obligations of each of the Parties thereto with respect to such Service Area, and neither this SOW nor any other instrument shall join or merge any Master Agreement with any other, except by the express written agreement of the Parties thereto.

6.3This SOW sets forth the entire understanding between the Parties with regard to the subject matter hereof and supersedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.

6.4If any provision of this SOW is held invalid or unenforceable the remaining provision of this SOW shall become null and void and be of no further force or effect.  If by rule, regulation, order, opinion or decision of the Federal Communications Commission or any

7

SOW 30 NE

other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this SOW or the Master Agreement, this SOW is required to be rescinded or is declared ineffective or void in whole or in part, whether temporarily, permanently or ab initio (an “Ineffectiveness Determination”), immediately upon such Ineffectiveness Determination and without any requirement on any party to appeal, protest or otherwise seek clarification of such Ineffectiveness Determination, this SOW shall be rescinded and of no further force or effect retroactively to the SOW Effective Date.  Consequently, the Master Agreement in effect immediately prior to the SOW Effective Date shall continue in full force and effect in accordance with its terms, unchanged or modified in any way by this SOW.  In the event of an Ineffectiveness Determination, any amounts that would have otherwise been due and payable under the terms and conditions of the Master Agreement, in effect immediately prior to the SOW Effective Date (including, but not limited to any amounts or credits, to any party hereunder), shall be invoiced by Contractor at the earliest practical billing cycle in accordance with the Master Agreement and shall be due and payable in accordance with the applicable invoice therewith or shall be credited or applied for the benefit of the Customer or any User in accordance with the Master Agreement.

6.5If at any time hereafter a Customer, other than a Customer that is a party hereto desires to become a party hereto, such Customer may become a party hereto by executing a joinder agreeing to be bound by the terms and conditions of this SOW, as modified from time to time.

6.6This SOW may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed thesame document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

6.7This SOW is the joint work product of representatives of Customer and Contractor; accordingly, in the event of ambiguities, no inferences will be drawn against either Party, including the Party that drafted the Agreement in its final form.

IN WITNESS WHEREOF, the undersigned have executed this Statement of Work 30NE

as of the date first written above.

Contractor:

NeuStar, Inc.

By:

Name:

Title:

8

SOW 30 NE

Customer:

North American Portability Management LLC
as successor to Northeast Carrier Acquisition Contractor, LLC

By:

Name:

Title:

9

NeuStar

STATEMENT OF WORK
AMENDING SOW 25NE

10

November 30, 2001 SOW 31NE

STATEMENT OF WORK
(Northeast Region Service Area)

1.Introduction; Parties.  This Statement of Work (referred to herein as “SOW 31NE”) is to amend the Agreement for Number Portability Administration Center / Service Management System, between NeuStar, Inc. (“Contractor”) and the North American Portability Management LLC, as successor to the Northeast Carrier Acquisition Company, LLC (“Customer”), as amended by all subsequent Statements of Work, including but not limited to SOW 25 - TIN Price Reduction and Contract Update and Extension (“SOW 25NE”), as provided in greater detail below (collectively referred to as amended as the “Master Agreement”).  Unless provided otherwise, capitalized terms shall have the meanings as defined in the Master Agreement and SOW 25NE.

2.Effective Date.  The Parties agree that upon execution of this SOW 31NE by the Parties, the amendments set forth herein immediately and automatically shall be considered to be effective as of November 1, 2001, as if this SOW 31NE had been executed on that date (the “SOW Effective Date”).

3.Amendment to Attachment 3 of SOW 25NE.  The Parties agree that effective on the SOW Effective Date, Attachment 3 of SOW 25NE shall be amended and restated in its entirety as set forth on Exhibit l, attached hereto and made a part hereof.

4.No Other Changes.  Except as specifically modified and amended hereby, all the provisions of the Master Agreement (including without limitation SOW 25NE) shall remain unaltered and in full force and effect in accordance with their terms.

5.Counterparts.  This SOW may be executed in two or more counterparts and by different Parties hereto in separate counterparts, with the same effect as if all Parties had signed the same document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

6.Joint Work Product.  This SOW is the joint work product of representatives of Customer and Contractor; accordingly, in the event of ambiguities, no inferences will be drawn against either Party, including the Party that drafted the Agreement in its final form.

7.Article 29.  The parties agree and acknowledge that Article 29 of the Master Agreement shall not apply with respect to the execution and delivery of this SOW 31 NE.

8.Integration.  This SOW 31NE sets forth the entire understanding between the Parties with regard to the subject matter hereof and supersedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.

9.Impacts On Master Agreement.  The following are the impacts on the Master Agreement:

11

November 30, 2001 SOW 31NE

                Master Agreement

NoneExhibit B Functional Requirements Specification

NoneExhibit C Interoperable Interface Specification

NoneExhibit E Pricing Schedules

NoneExhibit F Project Plan and Test Schedule

                Exhibit G Service Level Requirements

NoneExhibit H Reporting and Monitoring Requirements

NoneExhibit J User Agreement Form

NoneExhibit K External Design

NoneExhibit L Infrastructure/Hardware

NoneExhibit N System Performance Plan for NPAC/SMS Services

NoneDisaster Recovery

NoneBack-up Plans

12

November 30, 2001 SOW 31NE

Exhibit 1

ATTACHMENT 3 TO SOW 25NE

1)Amendment to Exhibit G:  The parties agree that SLR-2 is temporarily changed as follows:

SLR No.	Procedure	Service Commitment Level	Service Affecting/ Non-Service Affecting	Performance Credit	Report Frequency and Performance Credit Calculation Interval
2.	Scheduled Service Unavailability (Customer)	Scheduled Service Unavailability time shall not exceed any of the following: (1) 20 hours during the Three Month Period or any Subsequent Three Month Period (the “20 Hour Requirement”) (2) 0 hours for any day in any month other than the first Sunday of any month (the “Sunday Requirement”) (3) 10 hours for any single event of Scheduled Service Unavailability during any month (the “Single Event Requirement”) and (4) any task resulting in Scheduled Service Unavailability during any month must commence after 6 a.m. CST (the “6 a.m. Requirement”) Note:  For purposes of the foregoing, the Sunday Requirement, the Single Event Requirement and the 6 a.m. Requirement shall be referred to as the “Monthly Requirements.”	Service Affecting	$[* * *] for each hour portion thereof of Scheduled Service Unavailability time which exceeds or fails to satisfy any of the following: (1) 20 Hour Requirement Violation: If Scheduled Service Unavailability time exceeds the 20 Hour Requirement in any Three Month Period or any Subsequent Three Month Period; or (2) Monthly Requirements Violations: If Scheduled Service Unavailability time exceeds or fails to satisfy any one or more of the Monthly Requirements (that is, the Sunday Requirement, the Single Event Requirement or the 6 am Requirement) in any month; provided, however, that if the 20 Hour Requirement and one or more of the Monthly Requirements are violated in any single month, the Performance Credit for that month shall be computed based solely upon the violation of either the 20 Hour Requirement or that Monthly

13

November 30, 2001 SOW 31NE

SLR No.	Procedure	Service Commitment Level	Service Affecting/ Non-Service Affecting	Performance Credit	Report Frequency and Performance Credit Calculation Interval
				Requirement that results in the greatest Performance Credit for that month.  With respect to determining the Performance Credit in any month for a violation of the 20 Hour Requirement, (a) the Performance Credit for the first month in which the 20 Hour Requirement is violated will be computed based upon each hour or portion thereof in which the cumulative Scheduled Service Unavailability time commencing at the beginning of the applicable Three Month Period or Subsequent Three Month Period in which such month is contained and ending on the last day of such month exceeded the 20 Hour Requirement; and (b) the Performance Credit for any subsequent month contained within the applicable Three Month Period in which the 20 hour Requirement has already been violated, shall be computed based upon the difference between (1) each hour or portion thereof in which the cumulative Scheduled Service Unavailability time commencing at the beginning of the applicable Three Month Period or Subsequent Three Month Period in

14

November 30, 2001 SOW 31NE

SLR No.	Procedure	Service Commitment Level	Service Affecting/ Non-Service Affecting	Performance Credit	Report Frequency and Performance Credit Calculation Interval
				which such month is contained and ending on the last day of such month exceeded the 20 Hour Requirement; minus (2) each hour or portion thereof in which the cumulative Scheduled Service Unavailability time commencing at the beginning of the applicable Three Month Period or Subsequent Three Month Period in which such month is contained and ending on the last day of the month immediately preceding the current month exceeded the 20 Hour Requirement.

For purposes of this Attachment 3 to SOW 31 NE, the Three Month Period shall commence on November 1, 2001 and end on January 31, 2002. The first Subsequent Three Month Period as described in paragraph 2 of this Attachment 3, shall commence on February 1, 2002 and end on April 30, 2002. Any additional Subsequent Three Month Periods, if any, must be agreed to by the Parties in accordance with paragraph 2 of this Attachment 3.

2)Extension and Operation with Respect to GEP Element No. 3.  The Parties agree that they may extend the terms of the Temporary SLR-2 Modification upon the same terms of paragraph I of this Attachment 3 beyond April 30, 2002, only for one or more three month periods (a “Subsequent Three Month Period”) without otherwise changing the provisions of this Attachment 3 and without the requirement of a Statement of Work, and that they have, accordingly extended the terms of the Temporary SLR-2 Modification upon the same terms of paragraph 1 of this Attachment 3 for only the first Subsequent Three Month Period, which, as set forth above, shall commence on February 1, 2002 and end on April 30, 2002. The Parties also agree and acknowledge that prior to the SOW Effective Date, the provisions of Attachment 3 as it existed prior to the SOW Effective Date, including all extension letters with respect to Attachment 3 (the “Prior Attachment 3”) shall control, except for purposes of measuring satisfaction of GEP Element No. 3 pursuant to Section 32.6d of the Master Agreement, which is set forth in the following sentence. Accordingly, the Parties further agree that for purposes of measuring satisfaction of GEP Element No. 3 pursuant to Section 32.6d. of the Master Agreement, a “Failure” of GEP Element No. 3 shall be considered to occur when any one of the

15

November 30, 2001 SOW 31NE

following two events occurs, it being expressly understood that for this purpose, any Three Month Period or Subsequent Three Month Period as defined in the :Prior Attachment 3 shall be referred to as a “Prior Three Month Period”):

(a)20 Hour Requirement Violation: The Scheduled Service Unavailability time exceeds the 20 Hour Requirement in more than one of the following periods that fall in an Associated EP, even if the Subsequent Three Month Periods in which Scheduled Service Unavailability time exceed the 20 Hour Requirement are not consecutive: any Prior Three Month Period, the Three Month Period and any Subsequent Three Month Period.

(b)Monthly Requirements Violations: The Scheduled Service Unavailability time exceeds or fails to satisfy any one or more of the Monthly Requirements (that is, the Sunday Requirement, the Single Event Requirement or the 6 a.m. Requirement), whether the same Monthly Requirement or any combination of the Monthly Requirements either (1) in any 2 consecutive months in the Associated EP, or (2) in any 3 or more months (even if not consecutive) during the Associated EP. By way of illustrating the operation of the foregoing sentence, a “Failure” of GEP Element No. 3 shall be considered to occur during an Associated EP during which the Temporary SLR-2 Modification is in effect if (1) during the first month of the Associated EP Scheduled Service Unavailability time failed to satisfy the Sunday Requirement, (2) during the 4th month of the Associated EP Scheduled Service Unavailability time failed to satisfy the 6 am Requirement and (3) during the 10”‘ month of the Associated EP Scheduled Service Unavailability time failed to satisfy the Single Event Requirement. By way of additional illustration, a “Failure” of GEP Element No. 3 shall not be considered to have occurred during an Associated EP during which the Temporary SLR-2 Modification is in effect, if during a month within the Associated EP, Scheduled Service Unavailability time failed to satisfy in any single month any two or all of the Monthly Requirements, for example, both the Sunday Requirement and the 6 a.m. Requirement, because such failure to satisfy more than one Monthly Requirement in a single month is not by itself a condition sufficient to constitute a “Failure” of this GEP Element.

The Customer and the Contractor agree that there may be instances during an Associated EP and during such times as the Temporary SLR-2 Modification is in effect that they may agree to one or more express waivers of any one or more of the 20 Hour Requirement, the Sunday Requirement, the Single Event Requirement or the 6 am Requirement. Accordingly, the parties agree that for purposes of determining a “Failure” of GEP Element No. 3 during such times, the GEP Auditor shall consider the existence of such waiver to mean that a failure to satisfy any one or more of the 20 Hour Requirement, the Sunday Requirement, the Single Event Requirement or the 6 a.m. Requirement did not occur, if and only if the GEP Auditor determines upon examination that a waiver satisfying the following specific requirements was given: (1) the waiver is an original paper copy and not a photocopy or electronic version or copy; (2) the waiver is executed by both Co-Chairs of the Customer; (3) the waiver makes specific reference to which one or more of the 20 Hour Requirement, the Sunday Requirement, the Single Event Requirement or the 6 a.m.

16

November 30, 2001 SOW 31NE

Requirement is or are being waived; and (4) the waiver makes specific reference to which specific Subsequent Three Month Period or which specific month or months it is applicable. If the GEP Auditor is unable conclusively to determine satisfaction of any one or more of the preceding four requirements for any alleged waiver, then such waiver shall be considered by the GEP Auditor not to constitute a waiver sufficient to waive any GEP Element 3 Requirements.

3)Additional Obligations.  In addition to the foregoing and as a continuing obligation during the time of the Temporary SLR-2 Modification, and any extension thereof, Contractor shall be required to provide an Advance Notification and a Post Mortem Report of all activity/functions performed during each NPAC Scheduled Service Unavailability time.

a)The Advance Notification is to be provided to each respective of the Customer’s Project Executive at least 10 business days in advance of the date the Schedule Service Unavailability event is to be performed.

b)The Post Mortem report is to be provided to the Customer’s Project Executive on or before the close of four business days following the performance of each NPAC Scheduled Service Unavailable time.

c)Each Notification and/or Report shall report the required data under the following category descriptions: a Task by Task Description, Planned Down Time (Start and End Time), Actual Down Time (Start and End Time), and Duration.

4)Agreement to Consider Actual History.  Subject to the preceding provisions of this Attachment 3, from this SOW Effective Date through the end of the last Subsequent Three Month Period (currently April 30, 2002), Customer and Contractor shall jointly evaluate the prior results of NPAC Scheduled Service Unavailability time activity/functions actuals, i.e., actual Scheduled Service Unavailability required each month.

5)Express Continuing Reservation.  The agreement set forth herein is not intended by itself to in any way constitute an agreement or waiver of the Performance Credits referenced in Exhibit G (as modified by the SLR-2 Letter Agreement) for any period other than the period commencing with the SOW Effective Date and concluding with the expiration of the last Three Month Period, unless sooner ended pursuant to the previous provisions of this Attachment 3.

17

November 30, 2001 SOW 31NE

IN WITNESS WHEREOF, the undersigned have executed this SOW 31NE as of the SOW Effective Date.

Contractor:

NeuStar, Inc.

By:

Name:

Title:

Date:

Customer:

North American Portability Management LLC
as successor to Northeast Carrier Acquisition Company, LLC

By:

Name:

Title:

Date:

By:

Name:

Title:

Date:

18

July 8, 2002 SOW 34

STATEMENT OF WORK 34

NPAC/SMS TEST PLATFORM SERVICES

July 8, 2002 SOW 34

PROPOSED STATEMENT OF WORK
NPAC/SMS TEST PLATFORM SERVICES

(under Agreement for NPAC/SMS Services)

1.INTRODUCTION; PARTIES.  This Statement of Work (this “SOW”) is entered into pursuant to Article 13 of, and upon execution shall become a part of, the Agreement for Number Portability Administration Center / Service Management System (each, a “Master Agreement”) between NeuStar, Inc. (“Contractor”) and the North American Portability Management, LLC, on behalf of the respective limited liability companies indicated below (the “Customer”):

North American Portability Management, LLC, on behalf of:

LNP, LLC (Midwest)

Southwest Region Portability Company, LLC

Northeast Carrier Acquisition Company, LLC

Western Region Telephone Number Portability, LLC

Southeast Number Portability Administration Company, LLC

Mid-Atlantic Carrier Acquisition Company, LLC

West Coast Portability Services, LLC

The number in the upper right hand corner refers to this SOW.  Capitalized terms used herein without definition shall have the meanings as defined in the Master Agreements.  For the purposes of this SOW, the limited liability companies that executed the Master Agreement, including Customer, shall be referred to as the “Regional Companies”.

2.TERM OF SOW.  This SOW shall be effective with respect to the Contractor and the Customer only on execution by Contractor and Customer in accordance with Article 30 of the Master Agreement, and the date this SOW becomes effective shall be the “SOW Effective Date.”  This SOW shall remain in effect until May 31, 2006.

3.SCOPE OF ADDITIONAL SERVICES. The Additional Services contemplated under this SOW are a custom enhancement for a service that provides a test environment that is the functional equivalent to the production NPAC/SMS.  This test environment is specifically for services outside the scope of the Master Agreement and outside software release SOWs.  The Additional Services to be undertaken by Contractor are generally described as set forth below.  Furthermore, this SOW does not in any way entitle a User to access the production NPAC/SMS.  Testing associated with this SOW will not in any way satisfy the certification testing requirements of SOW 24 (Continuing Certification Process) and as such will not result in validation of the User’s systems as certified for LNP purposes.

The NPAC/SMS Test Platform (the “NPAC/SMS Test Platform”) shall provide a suitable environment for Service Providers to perform unsupported regression testing and testing for vendor software.

2

July 8, 2002 SOW 34

(a) NPAC/SMS Test Platform Configuration

On an ongoing basis, the NPAC/SMS Test Platform will support the current production release of software.  During new SOW software releases, the NPAC/SMS Test Platform will support the existing production release of software until all regions have successfully implemented the new software release.  The NPAC/SMS Test Platform will not support region custom releases.  The NPAC/SMS Test Platform front-end application will employ a HP server (HP N series, rp7410 server) while the back-end database will utilize a Sun series server (Sun Fire V880 server).  There will be no replication feature.

It is intended that any upgrades required to support future NPAC/SMS software releases will be recouped by the SOW associated with the software release.

(b) NPAC/SMS Test Platform Availability

NPAC/SMS Test Platform Normal Support Hours (“Normal Support Hours”) are defined to be 9:00am through 7:00pm EST during Business Days .  The NPAC/SMS Test Platform will be available on a 24/7 basis and maintain 90.0% minimum service availability per calendar month.   There will be a monthly maintenance allowance of ten (10) hours.  Contractor will give Users as much notice as reasonably possible prior to NPAC/SMS Test Platform maintenance periods.

Any condition other than the maintenance allowance mentioned above or any monthly maintenance over the 10 hour allowance where the NPAC/SMS Test Platform is inaccessible to all Users shall be considered NPAC/SMS Test Platform Unavailability (“NPAC/SMS Test Platform Unavailability”).  The maintenance hour allowance will not occur during NPAC/SMS Test Platform Normal Support Hours and will not count towards NPAC/SMS Test Platform Unavailability.

There shall be performance credits associated with NPAC/SMS Test Platform Unavailability.  These performance credits shall be in accordance with Table 1.

Table 1

Monthly Performance Credits

Test Platform Unavailability	Performance Credit	Maximum Credit
< 90%	One and One Half (1.5) hours for every full unavailable hour	[* * *]

Notes: (1) Performance Credit = [* * *] for every full unavailable hour

The Monthly Performance Credit listed above shall be the User’s sole and exclusive remedy and Contractor’s only liability for NPAC/SMS Test Platform Unavailability.  The duration of NPAC/SMS Test Platform Unavailability periods will be determined at the sole discretion of Contractor, based upon Contractor’s internal records.

3

July 8, 2002 SOW 34

(c) NPAC/SMS Test Platform Support Resources

NPAC/SMS Test Platformsupport shall be performed by Contractor Application Engineer (“Application Engineer”) resource.  The Application Engineer is a resource shared by all Users on a first-come, first-served basis whose responsibilities associated with the NPAC/SMS Test Platform shall include, but not be limited to, the following:

•System Administration

•Database Administration

•Application Support/Trouble Shooting

•Key Exchange

•Filter Management

•BDD File Requests

The Application Engineer resource shall be available during NPAC/SMS Test Platform Normal Support Hours.  Users may request Application Engineer support through a process to be defined by Contractor which will be posted on its web site.  The Application Engineer resource shall be available to assist Users on a “first-come-first-served” basis.

 A Dedicated Test Engineer (“Dedicated Test Engineer”) performs testing one-on-one solely for the requesting User.  Users may request Dedicated Test Engineer support resources through a process to be defined by Contractor which will be posted on its web site.  This type of resource is solely a User elective option based on User test requirements.  Dedicated Test Engineer support resources are charged directly to the requesting User in accordance with section 8.1 below.

If Dedicated Test Engineer support is scheduled by User and User does not advise Contractor of cancellation, changes, reductions or delays at least three (3) Business Days prior to scheduled commencement of Dedicated Test Engineer support activity, the Contractor shall charge the User the amount the Contractor in good faith determines the User would have paid if Dedicated Test Engineer support had occurred as scheduled.  Notwithstanding the foregoing, the maximum User payment liability shall be equal to eight (8) hours of Dedicated Test Engineer support cost.

If Dedicated Test Engineer support is scheduled by User but Dedicated Test Engineer support becomes unavailable due to Contractor’s actions or inactions, and provided Contractor does not advise User of unavailability of Dedicated Test Engineer support at least three (3) Business Days prior to scheduled commencement of Dedicated Test Engineer support activity, then Contractor will issue a credit to the User’s account, which credit shall be the User’s sole and exclusive remedy and Contractor’s only liability for such unavailability, the amount the Contractor in good faith determines the User would have paid if Dedicated Test Engineer support had occurred as scheduled.   Notwithstanding the foregoing, the maximum Contractor credit liability shall be equal to eight (8) hours of Dedicated Test Engineer support cost.

4

July 8, 2002 SOW 34

If Dedicated Test Engineer support resource was scheduled by User for testing activity on the NPAC/SMS Test Platform and theNPAC/SMS Test Platform is in a state of NPAC/SMS Test Platform Unavailability for any portion of the period for which Testing was scheduled, Contractor will waive User’s Dedicated Test Engineer support charge for the duration of the NPAC/SMS Test Platform Unavailability, even though the Dedicated Test Engineer support resource is available.

User may request a specific Dedicated Test Engineer support resource but if the specified Dedicated Test Engineer support resource becomes unavailable after originally scheduled, Contractor shall not be liable for credits if Contractor reasonably determines that a suitable replacement resource is available for the User’s scheduled Dedicated Test Engineer support activity.

4.OUT OF SCOPE SERVICES.  This SOW contains the agreed upon terms and conditions that shall govern Contractor’s performance of the services described herein.  The services provided for in this SOW and for which Contractor shall be compensated in accordance with Section 8 shall not be interpreted, implied, or assumed to include any other service(s), including, but not limited to, additional or changed services, not specifically described in this Section 2, Scope of Additional Services.  Any and all requested or required services or change orders (hereinafter “Out of Scope Services”) may be provided in accordance with the Master Agreement and, specifically, Section 13, Additional Services.

Any and all performance parameters, services or products associated with this Agreement will not be measured by nor directly impact the GEP metric requirements of SOW 25 – T/N Price Reduction And Contract Update And Extension or Exhibit G Service Level Requirements NPAC/SMS Services of the Master Agreement.

5.PROJECT PHASES.  The schedule set forth in the following table is a summary and estimate of tasks and time frames for implementation:

Phase	Summary Milestones	Interval
Phase 0.0	SOW Effective Date	Week 0
Phase 1.0	NPAC/SMS Test Platform Procurement	Weeks 1-6
Phase 2.0	NPAC/SMS Test Platform Set-up	Week 7-8
Phase 3.0	NPAC/SMS Test Platform General Availability	End of Week 8

Phase 0.0This phase marks agreement between the parties for the implementation of the Additional Services.

Phase 1.0This phase involves but is not limited to procuring NPAC/SMS Test Platform hardware and software required for the test environment and other resources for ongoing support.

5

July 8, 2002 SOW 34

Phase 2.0This phase involves but is not limited to configuration and integration of the NPAC/SMS Test Platform and database migration and the training of resources for ongoing support.

Phase 3.0This phase marks the implementation and availability of the Test Platform to the Users.  The completion of this phase constitutes the SOW Completion Date (“SOW Completion Date”) of the Additional Services.

6.   COMPLETION AND ACCEPTANCE CRITERIA.The following internal documents are applicable to the Additional Services contemplated under this SOW:

N/AFunctional Requirements Specifications

N/ARequirements Traceability Matrix

N/ASystem Design

N/ADetailed Design

N/AIntegration Test Plan

N/ASystem Test Plan

N/ASoftware Quality Assurance Program Report

User Documentation

N/ASoftware Configuration Management Plan

N/AStandards and Metrics

7.IMPACTS ON MASTER AGREEMENT (Includes Existing Specifications).

NoneMaster Agreement

NoneExhibit B Functional Requirements Specification

NoneExhibit C Interoperable Interface Specification

NoneExhibit E Pricing Schedules

NoneExhibit F Project Plan and Test Schedule

NoneExhibit G ServiceLevel Requirements

NoneExhibit H Reporting and Monitoring Requirements

NoneExhibit J User Agreement Form

NoneExhibit K External Design

NoneExhibit L Infrastructure/Hardware

NoneExhibit N System Performance Plan for NPAC/SMS Services

8.COMPENSATION AND PAYMENT

8.1Compensation

Customer represents that it is executing this SOW on behalf of their regional End-Users, as defined herein.  Customer understands that the Non-Recurring Charges and Monthly Recurring Fee are considered Allocable Charges as referenced in the FCC’s Third Report and Order, CC Docket 95-116, RM 8535, FCC 98-82 (“Cost Recovery Order”) and Statement of Work for Billing and Collection Operations and System (“SOW 11”).  Pursuant to the Cost Recovery

6

July 8, 2002 SOW 34

Order, all End-Users in each Subscribing Customer’s region are to be invoiced a portion of the Allocated Charges, as determined by an allocation percentage based on end-user revenue, provided that End-Users with no end-user revenue (i.e. Wholesalers) are to be invoiced [* * *]Dollars ($[* * *]) per region per year.  Customer understands that as a result of the Third Report and Order, all End-Users in each Subscribing Customer’s region are responsible to pay the total purchase price of the Enhancement, as defined herein.  As used under this SOW, “End-Users” shall mean all telecommunications carriers that are subject to local number portability contribution requirements and file Telecommunications Worksheets, FCC Form 499-A.

For the purposes of and in accordance with both Section 23.3 (“Users’ Liability for Payments”) of the Master Agreement and the Cost Recovery Order, this Enhancement shall be considered by all End-Users to be services performed prior to any effective date of termination. Accordingly and notwithstanding any other provisions to the contrary in the Master Agreement or any exhibit attached thereto, in the event any amounts owed pursuant to this SOW remain outstanding upon any termination or expiration of the Master Agreement or this SOW, such amounts shall be immediately due and payable by the charged End-Users as provided for herein.

Customer’s payment obligations hereunder shall not be subject to, and Customer hereby expressly waives, any right of setoff or deduction with respect to any such amounts.

A.Non-Recurring Charges

Non-Recurring Charges (“Non-Recurring Charges”) are defined as initial costs and set-up fees associated with the establishment of the NPAC/SMS Test Platform.

Pricing Methodology.  The price for Non-Recurring Charges under this SOW shall be calculated based upon the following pricing methodology:

Pricing. The pricing for Non-Recurring Charges shall be an amount equal to the Costs plus the Fee, not to exceed the cap or maximum amount of Non-Recurring Charges as more particularly described herein below (the “Cap”).

(i)Costs.As used in this SOW,“Costs” or “Cost” mean those costs that have been incurred or will be incurred by Contractor as a result of implementing or postponing the implementation of the NPAC/SMS Test Platform, which Costs shall include but not be limited to the following:

Direct costs.Those direct costs incurred by Contractor attributable to the implementation of the NPAC/SMS Test Platform, including, but not limited to hardware, software, licenses, maintenance, dedicated resources, quality assurance, configuration control, any delay caused by a User, labor, employee benefits, incentive payments, bonuses, consultants, and associated operating expenses thereof and other allocable direct charges (collectively, “Direct Costs”);

7

July 8, 2002 SOW 34

Corporate Overhead costs.  Those shared expenses that are allocable as indirect costs, applied in accordance with Contractor’s overhead indirect allocation methodology, and which is consistent with U.S. general accepted accounting principles (collectively, “Corporate Overhead Costs”);

(ii)Fee. As used in this SOW, “Fee” shall be equal to [* * *]

[* * *]Dollars ($[* * *]).  Contractor shall be solely responsible for any and all Costs which cause the Cost plus the Fee to exceed the Cap.

There are two payment options for Non-Recurring Charges: (i) in one lump sum payment on the SOW Completion Date (“SOW Invoice Date”) to be billed no earlier than January, 2003  (ii) through financing the Non-Recurring Charges with Contractor over thirty-six (36) months, billing to commence no earlier than January, 2003.  These payments options are illustrated in Table 2, using the CAP as the amount financed.

Table 2

Example of Non-Recurring Charges Payment Options

	Total Price		Total Price Per Region
Lump Sum Payment	$	[* * *]	$	[* * *]

Finance Option	Total		Per Region
Total Financed	$	[* * *]	$	[* * *]
Number of Months**	[* * *]		[* * *]
APR**	[* * *]		[* * *]
Monthly Payment	$	[* * *]	$	[* * *]
Total of Payments	$	[* * *]	$	[* * *]

** Assumes an SOW Completion Date of December, 2002 with payments beginning in Jan-03 and continuing through Dec-05 (36 months) at a 10.5% APR.  Interest will accrue on amount financed beginning on the SOW Completion Date.

The financing charge shall be equal to the lesser of: (i) 10.5%; (ii) the thirty-six (36) month London Interbank Offered Rate (“LIBOR”) on the SOW Invoice Date plus 532 basis points(1)  or (iii) Contractor’s actual financing rate, inclusive of any structuring, administrative, or other related financing costs.

In the event that Customer fails to provide Contractor with written notice of its intention to finance the Non-Recurring Charges as set forth above within sixty (60) days after the SOW Effective Date, Customer shall be obligated to pay the entire Non-Recurring Charge on the SOW Invoice Date.

(1) The 532 basis spread was calculated by substracting the thrity-six(36) month LIBOR as of 5/31/2004 from 10.5%.

8

July 8, 2002 SOW 34

The prices set forth herein are valid only if all seven (7) Regional Companies execute the SOW.  It is hereby understood that if the Canadian LNP Consortium, Inc. (the “Consortium”) implements the Enhancement contemplated by this SOW, or portions thereof, then the Consortium will share on a proportional basis the relevant costs (e.g., Non-Recurring Charges and Monthly Recurring Fee) in the same manner as the costs of Enhancements set forth in other SOWs.

B.  Monthly Recurring Fee

The Monthly Recurring Fee (“Monthly Recurring Fee”) is defined as the allocable charge to the customer billed at the end of each month.  Monthly Recurring Fees will begin accruing immediately after the SOW Completion Date.  Any Monthly Recurring Fees incurred in 2002 will be billed as a lump sum in January, 2003.  Subsequent Monthly Recurring Fees will be invoiced with the next billing cycle after the month in which they were incurred.  The first and final invoices may be prorated as necessary.

a)Pricing.  The pricing for the Monthly Recurring Fee shall be equal to the amounts shown in Table 3 below.The Monthly Recurring Fee reflects all maintenance and resource charges associated with operating the NPAC/SMS Test Platform.  These charges include but are not limited to hardware and software maintenance and NPAC/SMS Test Platform support resources.

Table 3

Monthly Recurring Fee

Year 1

Year 2

Year 3

Year 4

Per Region

Total

Per Region

Total

Per Region

Total

Per Region

Total

Monthly Recurring Fee

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

* Year 1 will be the first 12 calendar months after the SOW Completion Date.  Subsequent years will begin on months 13, 25, and 37.

The prices are valid only if all seven (7) Regional Companies execute the SOW It is hereby understood that if the Canadian LNP Consortium, Inc. (the “Consortium”) implements the Enhancement contemplated by this SOW, or portions thereof, then the Consortium will share on a proportional basis the relevant costs (e.g., Non-Recurring Charges and Monthly Recurring Fee) in the same manner as the costs of Enhancements set forth in other SOWs.

b)Usage Fees.   Users will be charged directly for any Dedicated Test Engineer support resources requested and scheduled.  Dedicated Test Engineer

9

July 8, 2002 SOW 34

support resources shall be scheduled for periods of a minimum of four (4) hours.  The price for a 4-hour period is [* * *]Dollars ($[* * *]).

8.2Payment Terms

Invoicing:

Contractor shall prepare invoices (separate from Master Contract invoicing, but which may include invoicing for other SOW charges) on the last day of a calendar month and send to each User for the amount of its User Charges.  Contractor shall also prepare and deliver to Customer a report (the “Monthly Summary of Charges”) setting forth the billing calculation above for each User in the Service Area, and for all Users within the Service Area.  All invoices shall be due and payable within thirty (30) days of the date of the invoice.   Late payments will be subject to a One and Twenty Five One Hundredths percent (1.25%) interest charge per month, or, if lower, the maximum rate permitted by law.

With respect to End-Users that are not Users (individually a “Non-User” and collectively, “Non-Users”), Contractor shall prepare invoices (separate from Master Contract invoicing, but which may include invoicing for other SOW charges) on the last day of a calendar quarter and send to each Non-User for the amount of its charges.  Contractor shall also prepare and deliver to Customer a report (the “Monthly Summary of Charges”) setting forth the billing calculation above for each Non-User in the Service Area, and for all Non-Users within the Service Area.  All invoices shall be due and payable within thirty (30) days of the date of the invoice.   Late payments will be subject to a One and Twenty Five One Hundredths percent (1.25%) interest charge per month, or, if lower, the maximum rate permitted by law.

Collections and remedies for those carriers and other entities that are Users (including without limitation that disputes be resolved by arbitration as specified in Article 13 of the User Agreement) will be as defined in their User Agreement.  With respect Non-Users, collections and remedies terms with respect to payment of all amounts billable to such carriers, whether for charges for this SOW or for any other Allocated Charges billed in accordance with the Cost Recovery Order, shall be as defined in Exhibit A of this SOW.

Any billing disputes shall be promptly presented to Contractor in writing and in reasonable detail.  Requests for adjustment shall not be cause for delay in payment of the undisputed balance due. User may withhold payment of any amounts which are subject to a bona fide dispute; provided it shall pay all undisputed amounts owing to Contractor that have been separately invoiced to User.  If re-invoice occurs following the thirty (30) day payment schedule, such invoice for the undisputed amount shall be paid within ten (10) business days of receipt by User.  User and Contractor shall seek to resolve any such disputes expeditiously, but in any event within less than thirty (30) days after receipt of notice thereof.  All disputed amounts ultimately paid or awarded to Contractor shall bear interest from the thirtieth (30^th) day following the original invoice.

Notwithstanding the foregoing, User may not withhold payment of any amounts invoiced by Contractor based solely upon a dispute between Customer and User concerning how User is allocated charges under the Allocation Model.

10

July 8, 2002 SOW 34

The payments provided for in this Section shall not be applied against the Annual Target Amounts referred to in the Master Agreement.

Taxes:

Each End-User is to remit to or reimburse Contractor for any taxes that an EndUser is obligated to pay by law, rule or regulation or under this Agreement or its respective NPAC/SMS User Agreement.

Assignment of Monies Due:

As provided in Section 22.2 of the Master Agreement, Contractor may, upon written notice to Customer, assign monies due or that are to become due under a Statement of Work, provided that no such assignment may impose upon Customer or Users any obligations in addition to or different than those set forth in the Master Agreement or the subject Statement of Work, or preclude Customer or Users from dealing solely and directly with Contractor, except for billing and payments, in all matters pertaining to this Agreement or the subject Statement of Work, including the negotiation of amendments and the settlement of disputed invoices.

8.3Secured Financing.

Consent to Assignment:

Customer acknowledges that Contractor intends to reallocate receivables due under this SOW (the “SOW 34 Receivables”) from Future SOW Receivables to Financed SOW Receivables, as those terms are defined in SOW 30 to the Master Agreement (“SOW 30”).  Without in any way implying whether consent is or is not required under the Master Agreement, Customer consents to the transfer and assignment by Contractor of all of its right, title and interest in and to SOW 34 Receivables, and all rights to payments with respect thereto, to the Borrower pursuant to the Transfer Agreement for making loans through the Loan Facility under the Loan Agreement, as those terms are defined in SOW 30, as well as all other related transactions contemplated thereunder.  Upon the request and at the expense of Contractor, Customer shall do all such things (including the signing and execution of documents and other instruments) as may be reasonably required to effectuate the intent and purposes of the forgoing.

Waiver of Right of Set-Off:

The obligations of the Customer and the carriers and other entities which the Contractor is entitled to bill under the Master Agreement shall not be subject to, and the Customer hereby expressly waives, any right of setoff or deduction against amounts due and payable in respect of the SOW 34NE Receivables that might arise by reason of any failure by the Contractor to perform any of its obligations hereunder.  Notwithstanding the foregoing, by its execution hereof, neither the Customer nor any such entities releases, waives, discharges or otherwise agrees to forego any rights or remedies (other than set-off or deduction against amounts due and payable in respect of the SOW Receivables) that may be asserted against the Contractor under this SOW,

11

July 8, 2002 SOW 34

whether at law or in equity, including but not limited to termination, Performance Credits or damages, but subject to any applicable restrictions set forth herein.

8.4Price Review.

Contractor will cause its regular independent auditor (“Contractor’s Auditor”) to commence a review of the accuracy and validity of the Costs associated with the Non-Recurring Charges incurred under this SOW during the first Contractor quarterly financial audit that occurs after the SOW Completion Date.  This audit will validate the Costs incurred and Fees applied plus any changes to the fees to be charged to Users, and the schedule of effective date(s) for said changes in the fee structure.

If it is determined by Contractor’s Auditor that the Non-Recurring Charges are greater than the Costs incurred from Phase 0.0 continuing up to the SOW Completion Date plus the Fee applied, Contractor shall refund the overcharge to Customer.

9.PROJECT MANAGEMENT.  When deemed appropriate by User and Contractor, Project Managers will be assigned to produce and verify a delivery schedule, to coordinate logistics and delivery of all deliverables, and to conduct project quality review meetings.  The Assigned Project Managers are:

Contractor Project Manager	Darius Irani(or designee)
	45980 Center Oak Plaza, Bldg 10
	Sterling, VA 20166
User Project Manager

10.CONTINUATION OF MASTER AGREEMENT AND USER AGREEMENT.  Except as specifically modified and amended hereby (including by the SOW Specifications where applicable), all the provisions of the Master Agreement and the User Agreements entered into with respect thereto shall remain unaltered and in full force and effect in accordance with their terms.  From and after the date hereof, any reference in either the Master Agreement to itself or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the date hereof, shall be deemed to be a reference to such agreement as modified and amended by this SOW.  Notwithstanding the foregoing, with respect to User Enhancements, (i) the Master Agreement shall be modified and amended only to the extent necessary to give effect to the terms of this SOW and without affecting those Users or their User Agreements that are not Subscribing Users, and (ii) only those User Agreements that have been entered into with the Subscribing Users shall be modified and amended hereby.  From and after the effectiveness of this SOW, this SOW shall be a part of the Master Agreement and, as such, shall be subject to the terms and conditions therein.

12

July 8, 2002 SOW 34

11.JOINDER.  If at any time hereafter a Customer, other than a Subscribing Customer desires to become a Subscribing Customer or, with respect to User Enhancements, a User, other than a Subscribing User, desires to become a Subscribing User, Such Customer or User may become a Subscribing Customer or Subscribing User, respectively, by executing a joinder agreement in which they agree to be bound by the terms and conditions of this SOW, as modified from time to time.  A Customer or User executing such a joinder shall share in the payment of the price of the Additional Services provided for herein in a fair and equitable manner, and in no event in excess of the payments which would have been incurred had such Customer or User been a Subscribing Customer or Subscribing User at the time of effectiveness of this SOW, excluding any incremental work, such as Industry Regression Testing, borne by the Contractor in order to properly implement the Additional Services provided herein.

12.INTEGRATION.This SOW sets forth the entire understanding between the Parties with regard to the subject matter hereof and supercedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.

13.COUNTERPARTS.  This SOW may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed thesame document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

13

July 8, 2002 SOW 34

IN WITNESS WHEREOF, the undersigned have executed this SOW 34 as of the SOW Effective Date.

Contractor:
NeuStar, Inc.
By:
	Name:
	Title:
	Date:
Customer:

North American Portability Management LLC

By:
	Name:
	Title:
	Date:

By:
	Name:
	Title:
	Date:

14

July 8, 2002 SOW 34

EXHIBIT A

COLLECTION POLICY

Schedule for PAST DUE Bills

Days Past Due	Amount of Invoice(s)	Action
3	>$50K	Follow-up call to carrier
10	>$5K	Follow-up call to carrier
20	ALL	Send letter to carrier
40	ALL	Escalate: Send certified letter to carrier, List of Delinquent carriers to NANC and FCC for 208 process(2)
60	ALL	Write-off overdue amount and send to Collection Agency (1)

ALL LATE PAYMENTS
ARE SUBJECT TO A 1.25% INTEREST CHARGE PER MONTH.

(1)Any overdue accounts referred to a collection agency will be written off, including bankruptcies.  Any amount collected net of collection agency charges will be credited to the carrier per the allocation in effect.  NeuStar will seek Customer approval for write-offs greater than Ten Thousand Dollars ($10,000), but in no case will approval be unreasonably withheld for accounts One Hundred Eighty (180) days past due.

(2)Contractor, as part of its normal business practice, will maintain a collection history file for all accounts.  The collection history file will contain invoice dates, dates of letter and phone contacts and responses (or non-responses) to those contacts from the carriers.  This information will be provided to Subscribing Customer(s) or any regulatory agency in support of the 208 process, if required.

15

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

SETTLEMENT OF BILLING FOR MODIFIES DISPUTE

UNDER

AGREEMENT FOR NUMBERING ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM

16

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

SETTLEMENT OF BILLING FOR MODIFIES DISPUTE

UNDER

AGREEMENT FOR NUMBERING ADMINISTRATION CENTER/SERVICE
MANAGEMENT SYSTEM

1.  PARTIES

This amendment (this “Amendment”) is entered into pursuant to Article 30 of, and upon execution shall be a part of, the Agreement for Number Portability Administration Center/Service Management System (referred to as the “Master Agreement”) by and between NeuStar, Inc., a Delaware corporation (“Contractor”) and the North American Portability Management LLC, a Delaware limited liability company (the “Customer” or “NAPM”), as the successor in interest to and on behalf of Northeast Carrier Acquisition Company, L.L.C. (the “Subscribing Customer”).

2.  EFFECTIVENESS

This Amendment shall be effective as of April 2, 2003 (the “Amendment Effective Date”) only upon execution of separate amendments by Contractor and Customer as the successor in interest to and on behalf of all of the following entities that were signatories under separate agreements with Contractor and which were merged into NAPM and no longer exist (each a “Subscribing Customer”):

•LNP, L.L.C. (Midwest)

•Mid-Atlantic Carrier Acquisition Company, L.L.C.

•Northeast Carrier Acquisition Company, L.L.C.

•Southeast Number Portability Administration Company, L.L.C.

•Southwest Region Portability Company, L.L.C.

•West Coast Portability Services, L.L.C.

•Western Region Telephone Number Portability, LLC

The number in the upper left-hand corner refers to this Amendment.  Capitalized terms used herein without definition shall have the meanings as defined in the Master Agreement.

3.  DISPUTE & SETTLEMENT

3.1Modifies as TN Porting Event.  Customer and Contractor have disagreed on whether certain operations (referred to in this Amendment as “Modifications”) involving a modification action on any data in an active subscription version associated with a particular Telephone Number (“TN”) and the subsequent broadcast of the information related thereto constitutes a

17

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

“TN Porting Event,” properly chargeable to Users in accordance with Schedule 1 of Exhibit E to the Master Agreement (the “Dispute”).

3.2Settlement.  In consideration of the compromise and settlement of the Dispute under the terms and conditions set forth in this Amendment, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, the parties agree as set forth in this Amendment.

3.3Reservations.  The modifications, amendments and price concessions made herein were negotiated together and collectively, and each is made in consideration of all of the other terms herein.  All such modifications, amendments and price concessions are interrelated and are dependent on each other.  No separate, additional or different consideration is contemplated with respect to the modifications, amendments and price concessions herein. Notwithstanding anything to the contrary contained in this Amendment, the parties expressly and explicitly agree and acknowledge that the only consideration for the compromise and settlement of the Dispute is the agreement of the parties to the resolution of the Dispute hereunder and the modifications, amendments and price concessions made herein and that no other consideration, express or implied, was involved in such compromise and settlement of the Dispute. Both parties expressly and explicitly state that nothing contained in this Amendment is intended to constitute nor shall it be implied to constitute an acceptance or acknowledgment of, or an acquiescence to, the contentions or positions of the other party regarding the Dispute.  Further, nothing contained in this Amendment is intended nor shall it be implied to constitute any change or any acknowledgment, with respect to the inclusion, treatment or charges for operations or processes other than the Modifications, and the parties expressly and explicitly do not waive, release or otherwise alter their rights or remedies with respect to such other operations or processes.

4.  SETTLEMENT PAYMENT

4.1Computation.  Contractor will pay to all End-Users in all Service Areas for all Subscribing Customers the amounts set forth below as Unamortized Payments and Amortized Payments.  These payments shall be divided equally between Service Areas as set forth in Section 4.2.

(a)Unamortized Payments. For purposes of this Amendment, the “Unamortized Payment” shall mean (i) for all Service Areas cumulatively, the monthly payment of a principal amount of [* * *]Dollars (US$[* * *]) in seventeen (17) equal installments and (ii) for any single Service Area, the monthly payment of a principal amount of [* * *] Dollars ($[* * *]) in seventeen (17) equal monthly installments as set forth in Section 4.2.

(b)Amortized Payments.  For purposes of this Amendment, the “Amortized Payment” shall mean (i) for all Service Areas cumulatively, the monthly payment that amortizes a principal amount of [* * *]Dollars (US$[* * *]) over seventeen (17) months with an interest rate equal to the Seventeen Month LIBOR, as defined in Section 4.4, plus 532 basis points,

18

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

payable in seventeen (17) equal monthly installments, and (ii) for any single Service Area, the monthly payment that amortizes a principal amount of [* * *] Dollars ($[* * *] over seventeen (17) months with an interest rate equal to the Seventeen Month LIBOR, as defined in Section 4.4, plus 532 basis points, payable in seventeen (17) equal monthly installments as set forth in Section 4.2.

4.2Payment Via User Crediting.  The Unamortized Payment and Amortized Payment will be paid by Contractor in equal monthly payments (each a “Monthly Settlement Payment”).  Each Monthly Settlement Payment for all Service Areas cumulatively shall be apportioned between the separate Service Areas by dividing the Monthly Settlement Payment for all Service Areas cumulatively equally among the Subscribing Customers.  Each respective Subscribing Customer’s apportionment of the Monthly Settlement Payment for all Services Areas cumulatively shall be paid to End Users within that respective Subscribing Customer’s Service Area by crediting this apportioned amount of the Monthly Settlement Payment against Allocated Charges within that Service Areas for each calendar month, commencing with the January 2005 invoice and concluding with the May 2006 invoice.  Allocated Charges shall have the meaning set forth in SOW11 and shall be computed within each Service Area in accordance with the FCC’s Matter of Telephone Number Portability, Third Report and Order, CC Docket 95-116, RM 8535, FCC 98-82, as it may subsequently be revised or amended (the “Cost Recovery Order”).  Subject to the forgoing, the division, apportioning and invoicing of the Monthly Settlement Payments among the Users, End-Users and other entities within a Service Area that Contractor is entitled to bill under the Master Agreement shall be determined in the same manner as the division, apportioning and invoicing of Allocated Charges is determined under SOW11 and in accordance with the Cost Recovery Order.

4.3Customer Remedies.  Except as set forth in clause (c) of this Section 4.3 below, the payment of Additional Payments (as set forth in clause (a) of this Section 4.3 below) and the reductions in the TN Porting Price (as set forth below in clause (b) of this Section 4.3 below) shall constitute the exclusive damages for Subscribing Customers, Users, End-Users and other entities that Contractor is entitled to bill under the Master Agreement with respect only to Contractor’s failure properly to credit any amounts of all due and payable Monthly Settlement Payment, Additional Payment (as defined in clause (a) below) and reductions in the TN Porting Prices in accordance with this Amendment.  The forgoing shall not be interpreted to waive any Subscribing Customer’s, User’s, End-User ‘s or other entity’s rights or remedies, including setoff.

(a)Additional Payment.  If (i) Contractor fails to credit a Monthly Settlement Payment or an Additional Payment (as defined herein) in any Service Area either directly or in accordance with the method of crediting set forth in Section 4.2 on the date such installment is due and payable,  (ii) any Users, End-Users or other entities that Contractor is entitled to bill under the Master Agreement fail to setoff, and (iii) such failure continues for more than ten (10) business days, then Contractor shall credit to Users, End Users and such other entities in each

19

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

respective Service Area a late payment charge (the “Additional Payment”)in the amount equal to the sum of the following:

(A)  the product of (I.) the original principal amount of the Unamortized Payments for that respective Service Area hereunder minus the sum of all Unamortized Payments actually credited or setoff hereunder for that Service Area and (II.) the Seventeen Month LIBOR, as defined in Section 4.4, plus 1,032 basis points, compounded monthly; and

(B)  the product of (I.) the sum of the original amortized amount of all Amortized Payments for that respective Service Area computed hereunder minus the sum of all Amortized Payments actually credited or setoff hereunder for that respective Service Area and (II.) five (5%) percent per anum, compounded monthly.

Contractor’s obligation under this clause (a) of Section 4.3 to credit the Additional Payment shall continue until all amounts of due and payable Monthly Settlement Payment and Additional Payment are properly credited in accordance with this Amendment.

(b) Reductions in TN Porting Prices.  The proper credit of both the Monthly Settlement Payment in each Service Area and the amounts of the Additional Payment specified in the immediately preceding clause (a) of this Section 4.3 for any respective Service Area shall be auditable charges for purposes of Element No. 7b of the Gateway Evaluation Process (“GEP”) in that respective Service Area and could result in reductions in TN Porting Prices in accordance with the GEP.  Contractor shall cause the auditor to include these credits and payments as an auditable item under Element No. 7b within the auditor’s audit plan.

(c) Default.  Any failure for a period of six (6) months to pay or to credit any Monthly Settlement Payment or Additional Payment as set forth herein or any failure for a period of six (6) months properly to credit any reductions in the TN Porting Price in any Service Area resulting from any Failures of Element No. 7b of the GEP occasioned by the occurrence of the failure timely to credit as set forth in clause (b) above, shall each constitute a failure by the Contractor to perform a material obligation under the Master Agreement, and if any such failure continues for a period of two hundred seventy (270) days after receipt of notice from Customer in any Service Area of such failure, then Contractor shall be considered to be in Default under Section 16.5 of the Master Agreement, with no further requirements of notice by Customer or any Users, End-Users or other entities and no further right to cure such failure.

4.4Seventeen Month LIBOR.  For the purposes of this Amendment, the “Seventeen Month LIBOR” shall mean the annual London Interbank Offered Rate (“LIBOR”) for seventeen (17) months as of January 2, 2005.

20

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

5.  WAIVER AND RELEASE

5.1Dispute.  On the Amendment Effective Date, Customer hereby expressly waives any rights or remedies that now exist or ever existed and otherwise releases, acquits, and forever discharges Contractor and its respective present and former officers, directors, employees, affiliates, subsidiaries, agents, attorneys, servants, and representatives, as well as the respective heirs, successors and assigns of any and all of them (hereinafter collectively included in the definition of “Contractor”), in perpetuity, from any and all claims, demands, actions, causes of action, suits, obligations, accounts, damages, costs, expenses, debts, defenses, offsets or liabilities of any kind or character whatsoever, whether known, suspected or unknown, whether asserted or unasserted, which Customer and any Users, End-Users or other entities that Contractor is entitled to bill under the Master Agreement now has or ever had, related to, or arising from, either directly or indirectly, the Master Agreement with respect to the Dispute from the date of the commencement of Services through the Amendment Effective Date.

5.2Representation.  Customer hereby represents that as of the Amendment Effective Date, no dispute over whether a specific action constitutes a TN Porting Event under Exhibit E (Pricing Schedules) to the Master Agreement has been brought to the attention of the Co-Chairpersons of Customer, except for the Dispute and those disputes set forth in Schedule 1 (Disclosure List) hereunder. Notwithstanding anything to the contrary contained herein, Contractor acknowledges and agrees that the Customer has made no representation or warranty whatsoever to the Contractor or to any third parties regarding the enforceability of the foregoing waiver and release by Customer against Users, End-Users or other entities that Contractor is entitled to bill under the Master Agreement, by this Amendment or otherwise.

6.  IMPACTS ON MASTER AGREEMENT

6.1Pricing Schedule.  Effective on the Amendment Effective Date, Footnote 4 (TN Porting Event) in Exhibit E of the Master Agreement shall be amended and replaced in its entirety as set forth in Attachment 1, attached hereto and made a part hereof.

6.2Inapplicability of Article 29.  Article 29 of the Master Agreement shall not apply with respect to the execution and delivery of this Amendment.

6.3Impacts on Master Agreement.  The following portions of the Master Agreement are impacted by this Amendment:

	Master Agreement
None	Exhibit B Functional Requirements Specification
None	Exhibit C Interoperable Interface Specification

21

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

	Exhibit E Pricing Schedules
None	Exhibit F Project Plan and Test Schedule
None	Exhibit G Service Level Requirements
None	Exhibit H Reporting and Monitoring Requirements
None	Exhibit J User Agreement Form
None	Exhibit K External Design
None	Exhibit L Infrastructure/Hardware
None	Exhibit N System Performance Plan for NPAC/SMS Services
None	Disaster Recovery
None	Back-up Plans

6.4SOW25.  Except as expressly provided for, nothing herein shall affect the settlement of the “Dispute” under Section 5.1 of SOW25 (“STATEMENT OF WORK FOR T/N PRICE REDUCTION AND CONTRACT UPDATE AND EXTENSION) to the Master Agreement.

6.5Numbering Scheme.  Beginning with this Amendment, each future modification to the Master Agreement shall be referenced as an “Amendment” followed by a number signifying the sequence of such amendment, e.g., “Amendment No. 40”.  If such amendment embodies a Statement of Work under the Master Agreement, then the amendment shall also be identified as a Statement of Work. All amendments shall also bear a reference by abbreviation or otherwise to clearly identify the Service Area to which it applies.

7.  MISCELLANEOUS

7.1CounterpartsThis Amendment may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed the same document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

7.2Severability.  If any provision of this Amendment is held invalid or unenforceable, the remaining provisions of this Amendment shall become null and void and be of no further force or effect.  If by rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this Amendment or the Master Agreement, this Amendment is required to be rescinded or is declared ineffective or void in whole or in part, whether temporarily, permanently or ab initio (an “Ineffectiveness Determination”), immediately upon such Ineffectiveness Determination and without any requirement on any party to appeal, protest or

22

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

otherwise seek clarification of such Ineffectiveness Determination, this Amendment shall be rescinded and of no further force or effect retroactively to the Amendment Effective Date.  Consequently, the Master Agreement in effect immediately prior to the Amendment Effective Date shall continue in full force and effect in accordance with its terms, unchanged or modified in any way by this Amendment.  In the event of an Ineffectiveness Determination, any amounts that would have otherwise been due and payable under the terms and conditions of the Master Agreement, in effect immediately prior to the Amendment Effective Date (including, but not limited to any adjustments necessary to retroactively reprice TN Porting Events under Schedule E from the Amendment Effective Date through the date of the Ineffectiveness Determination, or other amounts or credits, to any party hereunder), shall be invoiced by Contractor at the earliest practical billing cycle in accordance with the Master Agreement and shall be due and payable in accordance with the applicable invoice therewith or shall be credited or applied for the benefit of the Customer or any User in accordance with the Master Agreement.

7.3Joinder. If at any time hereafter a Customer, other than a Customer that is a party hereto desires to become a party hereto, such Customer may become a party hereto by executing a joinder agreeing to be bound by the terms and conditions of this Amendment, as modified from time to time.

7.4No Inferences.  This Amendment is the joint work product of representatives of Customer and Contractor; accordingly, in the event of ambiguities, no inferences will be drawn against either party, including the party that drafted the Agreement in its final form.

7.5Entire Agreement.  This Amendment sets forth the entire understanding between the Parties with regard to the subject matter hereof and supercedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.

[THIS SPACE INTENTIONALLY LEFT BLANK]

23

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

IN WITNESS WHEREOF, the undersigned have executed this Amendment:

CONTRACTOR:	NeuStar, Inc.
By:
Its:
Date:

CUSTOMER: North American Portability Management, LLC
as the successor in interest to and on behalf of Northeast Carrier Acquisition Company, L.L.C.

By:

Its:

Date:

CUSTOMER: North American Portability Management, LLC
as the successor in interest to and on behalf of Northeast Carrier Acquisition Company, L.L.C.

By:

Its:

Date:

24

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

SCHEDULE 1

TO

AMENDMENT NO. 36-NAPM(NE)

Disclosure List

1.Billing dispute with BellSouth concerning charges for SPID transfers on NeuStar invoice dated August 31, 2002.

25

Amendment No.36-NAPAM(NE)

APRIL 2, 2003 - FINAL

SOW: No

_ Yes

ATTACHMENT 1

TO

AMENDMENT NO. 36-NAPM(NE)

Amended Footnote 4 of Exhibit E (Pricing Schedules)

(a)  (4)   [* * *]

26

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

EXTENSION AGREEMENT

FOR

AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION
CENTER / SERVICE MANAGEMENT SYSTEM

27

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

EXTENSION AGREEMENT

FOR

AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION
CENTER/SERVICE MANAGEMENT SYSTEM

1.             PARTIES

This amendment (this “Amendment”) is entered into pursuant to Article 30 of, and upon execution shall be a part of, the Agreement for Number Portability Administration Center/Service Management System, as amended and in effect immediately prior to the Amendment Effective Date (the “Master Agreement”), by and between NeuStar, Inc., a Delaware corporation (“Contractor”), and the North American Portability Management LLC, a Delaware limited liability company (the “Customer”), as the successor in interest to and on behalf of Northeast Carrier Acquisition Company, LLC ( the “Subscribing Customer”). 

2.             EFFECTIVENESS AND DEFINED TERMS

This Amendment shall be effective as of the 22^nd day of October, 2003 (the “Amendment Effective Date”), conditioned upon execution by Contractor and Customer of this Amendment and six other separate amendments, in substantially the form of this Amendment, applicable to the other six (6) Service Areas for the United States (collectively, the “United States Service Areas”), whereby the Customer is the successor in interest to and acting on behalf of each of the respective other six subscribing customers named in each such amendment.

The number in the upper left-hand corner refers to this Amendment.  Capitalized terms used herein without definition or which do not specifically reference another agreement shall have the meanings as defined in the Master Agreement.  As set forth in Section 9.3 below, “Allocated Payor” means those entities that the Contractor is entitled to invoice for Allocated Charges under the Cost Recovery Order, as that term is defined in Section 7.2

3.             CONSIDERATION RECITAL

In consideration of the terms and conditions set forth in this Amendment, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, Contractor and Customer agree as set forth in this Amendment. The modifications and amendments made herein were negotiated together, and each is made in consideration of all of the other terms and conditions herein. All such modifications and amendments are interrelated and are dependent on each other. No separate, additional or different consideration is contemplated with respect to the modifications and amendments herein.  Contractor and Customer acknowledge that Contractor’s agreements hereunder, including by way of example and not limitation, certain TN Porting Event pricing reductions reflected in Rate Card No. 2 (defined below in this Amendment) and the Fixed Credit Payments for 2003, the Fixed Credit Payments for 2004 and the Variable Credit Payments (all as reflected and defined in this Amendment) have been offered in part because of past and

28

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

expected TN Porting Event volumes for the United States Service Areas and the cost savings asserted by Contractor that are or may be associated with the current and coordinated implementation in the United States Service Areas of Release 3.2 of the NPAC/SMS Software.  Notwithstanding the foregoing, Customer makes no representations with respect to expected TN Porting Event volumes in the United States Service Areas and does not guarantee or otherwise ensure any TN Porting Event volumes, and Contractor makes no representations with respect to Contractor’s realization of current or anticipated cost savings associated with the implementation in the United States Service Areas of Release 3.2 of the NPAC/SMS Software.  Nonetheless, Contractor expressly agrees and acknowledges that regardless of Contractor’s realization of any such current or anticipated costs savings, immediately upon the Amendment Effective Date, Exhibit E (Pricing Schedules) of the Master Agreement as amended and restated pursuant to Article 5 of this Amendment shall govern as provided therein.

4.             EXTENSION OF MASTER AGREEMENT

Article 3 of the Master Agreement is deleted and replaced in its entirety with the following:

This Agreement shall commence as of the Effective Date of this Agreement and continue for an initial term ending on May 31, 2011 (the “Initial Term”), unless terminated earlier under the terms of this Agreement.  After expiration of the Initial Term, this Agreement shall automatically renew for consecutive one-year terms (one year at a time) unless an election not to renew is made either (i) by Customer, by providing at least ninety (90) days written notice to Contractor prior to the end of the Initial Term or any subsequent term in which the Agreement is in effect, or (ii) by Contractor, by providing at least one hundred and eighty (180) days written notice to Customer prior to the end of the Initial Term or any subsequent term in which the Agreement is in effect.

5.             PRICING SCHEDULES

Effective on the Amendment Effective Date, Exhibit E (Pricing Schedules) of the Master Agreement is hereby amended and restated in its entirety as set forth in Attachment 1 hereunder.  Such amendment and restatement shall include, among other changes reflected therein, the identification of two separate schedules of prices per TN Porting Event in the Customer’s Service Area.  “Rate Card No. 2” (as defined in Exhibit E, as amended hereby), shall apply, commencing January 1, 2004, to determine the price per TN Porting Event in the Subscribing Customer’s Service Area, in accordance with a schedule of charges based upon the cumulative number of TN Porting Events that occur in the Subscribing Customer’s Service Area after December 31, 2003, so long as the cumulative number of TN Porting Events that have occurred in the Subscribing Customer’s Service Area since the Effective Date of the Master Agreement equal or exceed 10,000,000 on or before December 31, 2003.  If Rate Card No. 2 is not applicable, then “Rate Card No. 1” (as defined in Exhibit E, as amended hereby), shall apply to determine the price per TN Porting Event in the Subscribing Customer’s Service Area, in accordance with a schedule of charges based upon the cumulative number of TN Porting Events that occur in the Subscribing Customer’s Service Area since the Effective Date of the Master Agreement.

29

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

6.             FIXED CREDIT PAYMENTS

6.1   Fixed Credit Payment for 2003 

(a)   For Entire Service Area.  In accordance with Section 6.1(b) below, Contractor shall make an aggregate payment in the amount of [* * *] Dollars ($[* * *]) to all Allocated Payors in the Subscribing Customer’s Service Area (the “Fixed Credit Payment for 2003”). 

(b)   Division Among Allocated Payors Within the Service Area.  Each Allocated Payor’s share of the Fixed Credit Payment for 2003 shall be applied in the same manner as the division, apportioning and invoicing of Allocated Charges is determined under SOW11 and in accordance with the FCC’s Matter of Telephone Number Portability, Third Report and Order, CC Docket 95-116, RM 8535, FCC 98-82, as it may subsequently be revised or amended (the “Cost Recovery Order”), commencing with the invoices issued to Allocated Payers in January, 2004 pursuant to Section 6.6(c) of the Master Agreement.  If for any Allocated Payor such credit applied on that invoice does not pay in full such Allocated Payor’s share of the Fixed Credit Payment for 2003, then the remaining share of the Fixed Credit Payment for 2003 allocable to that Allocated Payor shall be applied to and utilized on subsequent invoices in the amount of the lesser of (i) the full amount of the remaining share of the Fixed Credit Payment for 2003 allocable to that Allocated Payor or (ii) the full amount of all charges for Services shown on such invoice and allocable or chargeable to such Allocated Payor under the Master Agreement, but not including charges allocable or chargeable pursuant to a Statement of Work for Additional Services, until the share of the Fixed Credit Payment for 2003 allocable to that Allocated Payor is fully credited and utilized.  The invoice in which the Allocated Payor’s share of the Fixed Credit Payment for 2003 is first applied shall clearly identify the amount of the share of the Fixed Credit Payment for 2003 allocable to the Allocated Payor which is applied on the invoice, and any amount of the Allocated Payor’s share of the Fixed Credit Payment for 2003 which is remaining after utilization on that invoice shall be aggregated with and added to amounts of the Allocated Payor’s share of the Fixed Credit Payment for 2004 and the Variable Credit Payments (as those terms are defined below) remaining for utilization on future invoices, and such sum shall be clearly identified on such invoice and any subsequent invoice(s) if the Allocated Payor’s share of the Fixed Credit for 2003 has not been fully utilized.  Each Allocated Payor shall be provided by Contractor with access, at no additional charge, to a secure, password-protected Web site which will provide a report identifying the application and utilization of the Allocated Payor’s share of the Fixed Credit Payment for 2003.  Such report will be provided for a period of twelve (12) months after the date of the invoice in which such credits were last utilized.  Further, Contractor shall consult with Customer prior to issuance of a form cover letter to accompany those invoices to Allocated Payors for the application of the Fixed Credit Payment for 2003.  After consultation with Customer, Contractor shall issue in November, 2003 a letter to all Allocated Payors in the Service Area describing the nature, calculation and expected payment of the Fixed Credit Payment for 2003, the Fixed Credit Payment for 2004 and the Variable Credit Payments (as those terms are defined herein), the new charges for TN Porting Events (“Rate Card 2”), as set forth in

30

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

Article 5, and identifying the contact personnel in the Contractor’s billing department to whom inquiries may be directed concerning the foregoing.

6.2   Fixed Credit Payment for 2004

(a)   For Entire Service Area.  Contractor shall make an aggregate payment in the amount of [* * *] Dollars ($[* * *]) to all Allocated Payors in the Subscribing Customer’s Service Area (the “Fixed Credit Payment for 2004”) in accordance with Section 6.2(b) below. 

(b)   Division Among Allocated Payors Within the Service Area.  Each Allocated Payor’s share of the Fixed Credit Payment for 2004 shall be applied in the same manner as the division, apportioning and invoicing of Allocated Charges is determined under SOW11 and in accordance with the Cost Recovery Order, by crediting the first invoice issued to the Allocated Payor in such each calendar quarter of 2004 pursuant to Section 6.6(c) of the Master Agreement by an amount equal to such Allocated Payor’s share of the Fixed Credit Payment for 2004, divided by four.  If for any Allocated Payor the quarterly application and utilization of the Allocated Payor’s share of the Fixed Credit Payment for 2004 do not pay in full such Allocated Payor’s share of the Fixed Credit Payment for 2004, then the remaining share of the Fixed Credit Payment for 2004 allocable to that Allocated Payor shall be applied to and utilized on subsequent invoices in the amount of the lesser of (i) the full amount of the remaining share of the Fixed Credit Payment for 2004 allocable to that Allocated Payor or (ii) the full amount of all Charges for Services shown on such invoice and allocable or chargeable to such Allocated Payor under the Master Agreement, but not including charges allocable or chargeable pursuant to a Statement of Work for Additional Services, until the share of the Fixed Credit Payment for 2004 allocable to that Allocated Payor is fully credited and utilized.  Each invoice in which any portion of the Allocated Payor’s share of the Fixed Credit Payment for 2004 is first applied shall clearly identify the amount of the share of the Fixed Credit Payment for 2004 allocable to the Allocated Payor which is applied on the invoice, and any amount of the Allocated Payor’s share of the Fixed Credit Payment for 2004 which is remaining after utilization on that invoice shall be aggregated with and added to amounts of the Allocated Payor’s share of the Fixed Credit Payment for 2003 and the Variable Credit Payments (as that term is defined below) remaining for utilization on future invoices, and such sum shall be clearly identified on such invoice and any subsequent invoice(s) if the Allocated Payor’s share of the Fixed Credit for 2004 has not been fully utilized.  Each Allocated Payor shall be provided by Contractor with access, at no additional charge, to a secure, password-protected Web site which will provide a report identifying the application and utilization of the Allocated Payor’s share of the Fixed Credit Payment for 2004.  Such report will be provided for a period of twelve (12) months after the date of the invoice in which such credits were last utilized.  Further, Contractor shall consult with Customer prior to issuance of a form cover letter to accompany those invoices to Allocated Payors commencing the first instance in which a credit is applied for the Fixed Credit Payment for 2004.

6.3   Fixed Credit Payments:  Miscellaneous

(a)   The division, apportioning, application, utilization and invoicing of the Fixed Credit Payment Credit for 2003 and the Fixed Credit Payment for 2004 among Allocated Payors

31

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

as set forth in this Article 6 are separate from the computation of any Reduced TN Porting Price under Article 32 of the Master Agreement.  Further, the division, apportioning, application, utilization and invoicing of the Fixed Credit Payment for 2003 and the Fixed Credit Payment for 2004 do not and shall not be construed as altering or amending the charges for TN Porting Events set forth in Rate Card No. 1 or Rate Card No. 2.

(b)   The division, apportioning, application, utilization and invoicing of the Fixed Credit Payment Credit for 2003 and the Fixed Credit Payment for 2004 among Allocated Payors as set forth in this Article 6, including the computation of the share of the Fixed Credit Payment for 2003 and the Fixed Credit Payment for 2004 allocable to each Allocated Payor and the application, utilization and crediting on invoices of Allocated Payors, shall be auditable and included in determining “accuracy” of invoices for purposes of Element No. 7b of the Gateway Evaluation Process, as set forth in Article 32 of the Master Agreement.  The Fixed Credit Payments for 2003 and the Fixed Credit Payments for 2004 provided in this Article 6 relate to and are applicable against all charges for Services allocable to Allocated Payors, including, but not limited to TN Porting Event charges, but do not relate to and are not applicable against charges for Additional Services under Statements of Work under Article 13 of the Master Agreement. 

(c)   Allocated Payors retain their right of set-off against all charges for Services allocable to Allocated Payors under the Master Agreement, including, but not limited to TN Porting Event charges, for Contractor’s failure to properly and accurately compute and credit the Fixed Credit Payments for 2003 and the Fixed Credit Payments for 2004 as contemplated under this Article 6.

7.             VARIABLE CREDIT PAYMENTS

7.1   Computation.

(a)   For Entire Service Area.  In accordance with Section 7.1(b) below, for each calendar year during the Initial Term, and after the Amendment Effective Date, Contractor shall make an aggregate payment (the “Variable Credit Payment”) to all Allocated Payors in the Service Area of the Subscribing Customer, equal to the product of the amounts calculated in subparagraphs (i) and (ii) below.

(i)Calculate the following (i.e., the earned portion of the Annual Available Credit dollars for all United States Services Areas):

[(A – C) / (B – C)] * D

Where:

A = Actual number of aggregate TN Porting Events in all of the United States Service Areas, up to a maximum not to exceed the amount for Maximum TN Porting Events below in “B”.

B = Maximum TN Porting Events in the aggregate for all United States Service Areas

C= Threshold TN Porting Events in the aggregate for all United States Service Areas

32

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

D = Annual Available Credit dollars for all United States Service Areas

AGGREGATE FOR ALL UNITED STATES SERVICE AREAS	2003		2004		2005		2006		2007
Maximum TN Porting Events	64,032,000		122,887,000		126,591,000		130,098,000		129,994,000
Threshold TN Porting Events	60,000,000		100,000,000		100,000,000		100,000,000		100,000,000
Annual Available Credit	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]

AGGREGATE ALL UNITED STATES SERVICE AREAS	2008		2009		2010		2011
Maximum TN Porting Events	127,394,000		126,120,000		124,859,000		123,610,000
Threshold TN Porting Events	100,000,000		100,000,000		100,000,000		100,000,000
Annual Available Credit	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]

(ii)Calculate a fraction (i.e., the Service Area’s pro-rated share of invoiced charges), the numerator of which is the aggregate amount of invoiced charges for all Allocated Payors in the Subscribing Customer’s Service Area for TN Porting Events during a calendar year and the denominator of which is the aggregate amount of invoiced charges for all Allocated Payors in all United States Service Areas for TN Porting Events during the same calendar year.

(b)   Division Among Allocated Payors Within the Service Area.  Each Allocated Payor’s share of the Variable Credit Payment for each applicable calendar year shall be applied in the same manner as the division, apportioning and invoicing of Allocated Charges is determined under SOW11 and in accordance with the Cost Recovery Order, by crediting the first invoice issued to such Allocated Payor following the end of the applicable calendar year pursuant to Section 6.6(c) under the Master Agreement by an amount equal to the Allocated Payor’s share of the Variable Credit.  If for any Allocated Payor the credit does not pay in full the Allocated Payor’s share of Variable Credit Payment, then the remaining share of the Variable Credit allocable to that Allocated Payor shall be applied to and utilized on subsequent invoices in the amount of the lesser of (i) the full amount of the remaining share of the Variable Credit Payment allocable to that Allocated Payor or (ii) the full amount of all Charges for Services shown on such invoice and allocable or chargeable to such Allocated Payor under the Master Agreement, but not including charges allocable or chargeable pursuant to a Statement of Work for Additional Services, until the share of the Variable Credit Payment allocable to that Allocated Payor is fully credited and utilized.   Each invoice in which any portion of the Allocated Payor’s share of a Variable Credit Payment for a particular calendar year is first applied shall clearly identify the amount of the share of the Variable Credit Payment allocable to the Allocated Payor which is applied on the invoice, and any amount of the Allocated Payor’s share of the Variable Credit Payment which is remaining after utilization on that invoice shall be aggregated with and added to amounts of the Allocated Payor’s share of the Fixed Credit Payment for 2003, the Fixed Credit

33

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

Payment for 2004, and previous calendar year Variable Credit Payments remaining for utilization on future invoices, and such sum shall be clearly identified on such invoice and any subsequent invoice(s) if the Allocated Payor’s share of a Variable Credit Payment has not been fully utilized.  Each Allocated Payor shall be provided by Contractor with access, at no additional charge, to a secure, password-protected Web site which will provide a report identifying the application and utilization of the Allocated Payor’s share of each calendar year’s Variable Credit Payment.  Such report will be provided for a period of twelve (12) months after the date of the invoice in which such credits were last utilized.  Further, Contractor shall consult with Customer prior to issuance of a form cover letter to accompany those invoices to Allocated Payors commencing the first instance in which a credit is applied for the applicable Variable Credit Payment.

(c)   Limitation on Annual Available Credit.  Notwithstanding anything herein to the contrary, in no event shall any amount of the Annual Available Credit for any year set forth above be used in the computation under Subparagraphs 7.1(a)(i) and (ii) above for any amount in a subsequent calendar year.

7.2   Allocated Charges

Allocated Charges shall have the meaning set forth in SOW11 and shall be computed within each United States Service Area in accordance with the Cost Recovery Order.  Subject to the forgoing, the division, apportioning and invoicing of payments among Allocated Payors shall be determined in the same manner as the division, apportioning and invoicing of Allocated Charges is determined under SOW11 and in accordance with the Cost Recovery Order.

7.3   Variable Credit Payments:  Miscellaneous

(a)   The division, apportioning, application, utilization and invoicing of the Variable Credit Payments set forth in this Article 7 are separate from the computation of any Reduced TN Porting Price under Article 32 of the Master Agreement.  Further, the division, apportioning, application, utilization and invoicing of the Variable Credit Payments do not and shall not be construed as altering or amending the charges for TN Porting Events set forth in Rate Card No. 1 or Rate Card No. 2. 

(b)   The computation of the Variable Credit Payments, and the division, apportioning, application, utilization and invoicing of the Variable Credit Payments shall be auditable and included in determining “accuracy” of invoices for purposes of Element No. 7b of the Gateway Evaluation Process, as set forth in Article 32 of the Master Agreement.  The Variable Credit Payments provided in this Article 7 relate to and are applicable against all charges for Services allocable to Allocated Payors, including, but not limited to TN Porting Event charges, but do not relate to and are not applicable against charges for Additional Services under Statements of Work under Article 13 of the Master Agreement.  

(c)   Allocated Payors retain their right of set-off against all charges for Services allocable to Allocated Payors under the Master Agreement, including, but not limited to TN

34

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

Porting Event charges, for Contractor’s failure to properly and accurately compute and credit the Variable Credit Payments as contemplated under this Article 7.

8.             GATEWAY EVALUATION PROCESS

Contractor and Customer acknowledge and agree that the Gateway Evaluation Process (GEP), as contemplated by Article 32 of the Master Agreement, shall continue through the Initial Term (as defined in Article 4 of this Amendment) and any extensions thereafter. 

9.             MISCELLANEOUS IMPACTS ON MASTER AGREEMENT

9.1   Invoices

The first sentence of Section 6.6(c) (Invoicing of Monthly Charges for Users; Monthly Summary of Charges) of the Master Agreement is hereby deleted and replaced in its entirety by the following:

(c)           Invoicing of Monthly Charges for Users; Monthly Summary of Charges.  Promptly after the end of each Billing Cycle, Contractor shall prepare and send to each User an invoice for the amount of its User Charges, plus such User’s share of the Allocable Target Shortfall, if any, and less the sum of (i) such User’s share of the Allocable Target Credit, if any, (ii) such User’s share of any liquidated damages, if any, assessed against Contractor pursuant to Article 16 hereof and (iii) any credits pursuant to an amendment under Article 30 or SOW under Article 13. 

9.2   Allocated Payor Definition

Article 1 of the Master Agreement is hereby amended by adding the following definition for “Allocated Payors” as follows:

The term “Allocated Payors” means those entities that the Contractor is entitled to invoice for Allocated Charges under the Cost Recovery Order.

9.3   Business Hours

Article 1 of the Master Agreement is hereby amended by deleting and replacing in its entirety the definition of “Normal Business Hours” as follows:

The term “Normal Business Hours” means 7:00 a.m. to 11 p.m. Central Time during Business Days and 8:00 a.m. to 11 p.m. Central Time on Saturdays and Sundays, excluding the same days excluded in the definition of “Business Days”.

35

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

9.4   Deletion of One-year Renewal Term

(a)   Section 32.1 (Gateway Evaluation Process Overview) under the Master Agreement, as amended by SOW25, is hereby amended as follows.

(i)The parenthetical “(a)” in the second paragraph is hereby deleted.

(ii)The phrase “and (b) determining whether Contractor qualifies for an Automatic One-year Renewal Term pursuant to Article 3 of this Agreement” in the second paragraph is hereby deleted. 

(iii)The phrase “and the qualification for the Automatic One-Year Renewal Term under Article 3” in the fourth paragraph is hereby deleted.

(b)   Subparagraph (2)(B) (“Failure”) of Section 32.6(f) (GEP Element No. 5: Root Cause Analysis and Reporting Satisfaction) under the Master Agreement, as amended by SOW25, is hereby amended as follows.

(i)The phrase “and for purposes of determining qualification for the Automatic One-Year Renewal Term” is hereby deleted.

(c)   Subparagraph (2)(B) (“Failure”) of Section 32.6(g) (GEP Element No. 6: Problem Escalation Satisfaction) under the Master Agreement, as amended by SOW25, is hereby amended as follows.

(i)The phrase “and for purposes of determining qualification for the Automatic One-Year Renewal Term” is hereby deleted.

9.5   Inapplicability of Article 29

Article 29 of the Master Agreement shall not apply with respect to the execution and delivery of this Amendment.

9.6   Impacts on Master Agreement

The following portions of the Master Agreement are impacted by this Amendment:

	Master Agreement
None	Exhibit B Functional Requirements Specification
None	Exhibit C Interoperable Interface Specification
	Exhibit E Pricing Schedules
None	Exhibit F Project Plan and Test Schedule
None	Exhibit G Service Level Requirements
None	Exhibit H Reporting and Monitoring Requirements

36

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

None	Exhibit J User Agreement Form
None	Exhibit K External Design
None	Exhibit L Infrastructure/Hardware
None	Exhibit N System Performance Plan for NPAC/SMS Services
None	Disaster Recovery
None	Back-up Plans
	Article 32 of Master Agreement (Gateway Evaluation Process)

10.          MISCELLANEOUS

(a)   Except as specifically modified and amended hereby, all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms.  From and after the Amendment Effective Date hereof, any reference in the Master Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the Amendment Effective Date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit, as modified and amended by this.  From and after the Amendment Effective Date, Amendment shall be a part of the Master Agreement, including its Exhibits, and, as such, shall be subject to the terms and conditions therein.  Each of the respective Master Agreements with respect to separate Service Areas remains an independent agreement regarding the rights and obligations of each of the Parties thereto with respect to such Service Area, and neither this Amendment nor any other instrument shall join or merge any Master Agreement with any other, except by the express written agreement of the Parties thereto.

(b)   If any provision of this Amendment is held invalid or unenforceable the remaining provision of this Amendment shall become null and void and be of no further force or effect.  If by rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this Amendment or the Master Agreement, this Amendment is required to be rescinded or is declared ineffective or void in whole or in part, whether temporarily, permanently or ab initio (an “Ineffectiveness Determination”), immediately upon such Ineffectiveness Determination and without any requirement on any party to appeal, protest or otherwise seek clarification of such Ineffectiveness Determination, this Amendment shall be rescinded and of no further force or effect retroactively to the Amendment Effective Date.  Consequently, the Master Agreement in effect immediately prior to the Amendment Effective Date shall continue in full force and effect in accordance with its terms, unchanged or modified in any way by this Amendment.  In the event of an Ineffectiveness Determination, any amounts that would have otherwise been due and payable under the terms and conditions of the Master Agreement, in effect immediately prior to the Amendment Effective Date (including, but not limited to any

37

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

adjustments necessary to retroactively re-price TN Porting Events under Schedule E from the Amendment Effective Date through the date of the Ineffectiveness Determination, or other amounts or credits, to any party hereunder), shall be invoiced by Contractor at the earliest practical billing cycle in accordance with the Master Agreement and shall be due and payable in accordance with the applicable invoice therewith or shall be credited or applied for the benefit of the Customer or any Allocated Payor in accordance with the Master Agreement.

(c)   This Amendment may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed the same document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

(d)   If at any time hereafter a Customer, other than a Customer that is a party hereto desires to become a party hereto, such Customer may become a party hereto by executing a joinder agreeing to be bound by the terms and conditions of this Amendment, as modified from time to time. 

(e)   This Amendment is the joint work product of representatives of Customer and Contractor; accordingly, in the event of ambiguities, no inferences will be drawn against either party, including the party that drafted the Agreement in its final form.

(f)    This Amendment sets forth the entire understanding between the Parties with regard to the subject matter hereof and supercedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.  The modifications, amendments and price concessions made herein were negotiated together and collectively, and each is made in consideration of all of the other terms herein.  All such modifications, amendments and price concessions are interrelated and are dependent on each other.  No separate, additional or different consideration is contemplated with respect to the modifications, amendments and price concessions herein.

[THIS SPACE INTENTIONALLY LEFT BLANK]

38

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

IN WITNESS WHEREOF, the undersigned have executed this Amendment:

CONTRACTOR:   NeuStar, Inc.

By:

Its:

Date:

CUSTOMER:  North American Portability Management, LLC as successor in interest to and on behalf of Northeast Carrier Acquisition Company, LLC

By:

Its:

Date:

39

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

ATTACHMENT 1

TO

AMENDMENT NO. 42-NAPM (NE)

Amended and Restated Exhibit E (Pricing Schedules)

40

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

EXHIBIT E - PRICING SCHEDULES

The following schedules set forth the prices at which Contractor will be compensated for rendering the Services under the Agreement.  A general description of these charges and the methods of billing therefor are set forth in Section 6 of the Agreement.  See Agreement for other applicable charges.

Schedule 1

Service Element Fees/Unit Pricing

Category	Service Element	Unit	Price
[* * *]
	[* * *]	[* * *]	$[* * *]
	[* * *](1)	[* * *]	$[* * *]
	[* * *](2)	[* * *]	$[* * *]
	[* * *]	[* * *]	$[* * *]
	[* * *]	[* * *]	$[* * *]
[* * *]
	[* * *](3)	[* * *]	$[* * *]
	[* * *](3)	[* * *]	- $[* * *]
			- $[* * *]

(1) Monthly port charges [* * *] The specific cost elements include

(2) See Note 1 above. 

(3) [* * *]

41

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

[* * *](4)	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
		$	[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *](5)	[* * *]	$	[* * *]
[* * *]	[* * *]	[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]	[* * *]	$	[* * *]

(4) [* * *]

(5) [* * *]

42

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

[* * *]
	[* * *](6)	[* * *]	$	[* * *]
	[* * *](7)	[* * *]	$	[* * *]

Billable NPAC User Support Manual Request Table

Category	Description of Request
Create SV	New SP asks Help Desk to issue new SP Create, for single TN or range of TNs
Create SV	Old SP asks Help Desk to issue old SP Create, for single TN or range of TNs
Prevent SV Activation	Old SP asks Help Desk to change concur flag to “false” on pending SV (or SVs, for range of TNs)
Activate SV	New SP asks Help Desk to activate a pending SV for a single TN (or SVs, for a range of TNs)
Remove Prevention of SV Activation	Old SP (or New SP, after due date or t2 timer’s expiration) asks Help Desk to change concur flag to “true” on pending SV (or SVs, for range of TNs)
Modify Pending SV	New SP asks Help Desk to modify single SV (or SVs, for a range of TNs)
Disconnect TN	Current SP asks Help Desk to issue disconnect for TN (or range of TNs)
Cancel Pending SV	Old SP or New SP asks Help Desk to issue its cancel for pending SV (or SVs, for range of TNs)
Look Up SV	SP asks Help Desk to look up active SV for a TN (or SVs for range of TNs)
Modify Active SV	Current SP asks Help Desk to modify single active SV
Audit SV	SP asks Help Desk to issue audit request for a TN, or range of TNs, with SV(s) in active state
Look Up Network Data	SP asks Help Desk to look up NPA-NXX, NPA-NXX ID, LRN, or LRN ID to determine associated SPID and/or ID
Change Network Data	SP asks Help Desk to add to or to delete from the NPAC’s network data an NPA-NXX(s) or LRN(s). Requests to delete these data can be accommodated only if the SP making the request is the SP that originally entered the data. This limitation does not apply in the case where the SP asks Help Desk to delete an NPA-NXX (but not an LRN) where the NPA is not associated with the NPAC Service Area in which the NPA-NXX is open.
Change GUI Password	SP asks Help Desk to change its GUI Password
Re-enter GUI Logon	SP asks Help Desk to re-enter its GUI Logon which SP has allowed to expire

(6) The one-time Log-on [* * *]

(7) The Mechanized Interface [* * *]

43

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

Schedule 2

Training Charges

Service Element	Unit	Cost Per Participant
[* * *](8)	[* * *]	$	[* * *]
		$	[* * *]
		$	[* * *]
[* * *](9)	[* * *]	$	[* * *]
		$	[* * *]
		$	[* * *]

Schedule 3

Interoperability Testing

Category & Service Element	Unit	Price
[* * *]
	[* * *]	$	[* * *]
[* * *]
	[* * *]	$	[* * *]
[* * *]
[* * *]
	[* * *]	$	[* * *]
[* * *]
	[* * *]	$	[* * *]
[* * *]

(8) [ * *  *]

(9) [* * * ]

44

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

Schedule 4

Schedule of Representative Hourly Labor Charges
Applicable to Statements of Work
For Contract Years 1 Through End

Labor Category

Year 1

Year 2

Year 3

Year 4

Year 5*

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

*Amounts after Year 5 for each Labor Category shall be increased by 5% annually from the prior year.

Schedule 5

Schedule of Target Amounts

Target Options

Monthly Targets for Nov/Dec 1997(2)

Monthly Targets for 1Q 1998 (2)

Monthly Targets for 2Q 1998 through 4Q 2001 (2)

Monthly Targets for 1Q 2002 through 2Q 2002 (2)

Monthly Target for July 2002

Total Contract Targets

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

Notes:

(2)The target schedule depends on the service term selected by the Customer.  If the service term begins on 10/1/97, then Option A applies.  Likewise, if the service term begins on 1/1/98, then Option B applies.

(2)The targets are listed in monthly amounts for each of the respective calendar periods outlined above.  The targets are calculated and applied on a monthly basis as described in Section 6.6 of the Agreement.

45

Amendment No.42-NPAM(NE) October 22,2003

Sow:       No

                _ Yes

Schedule 6

Sample Annual Target and Allocable Target Shortfall/Credit Calculation

The following is an example of how Allocable Target Shortfalls and Allocable Targets are determined in connection

with the Quarterly Targets.  A description of the methodology (including defined terms used below) is set forth in

Section 6.6 of the Agreement.

	Jan-98		Feb-98		Mar-98
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	[* * *]		$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *] *	$	[* * *]	$	[* * *]	$	[* * *]
[* * *] *	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
* [* * *]

46

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

AMENDMENT
OF
AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION CENTER /
SERVICE MANAGEMENT SYSTEM

47

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

AMENDMENT
OF
AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION
CENTER/SERVICE MANAGEMENT SYSTEM

1.PARTIES

This amendment (this “Amendment”) is entered into pursuant to Article 30 of, and upon execution shall be a part of, the Agreement for Number Portability Administration Center/Service Management System, as amended and in effect immediately prior to the Amendment Effective Date (the “Master Agreement”), by and between NeuStar, Inc., a Delaware corporation (“Contractor”), and the North American Portability Management LLC, a Delaware limited liability company (the “Customer”), as the successor in interest to and on behalf of Northeast Carrier Acquisition Company, LLC ( the “Subscribing Customer”). 

2.EFFECTIVENESS AND DEFINED TERMS

This Amendment shall be effective as of the 3^rd day of December, 2003 (the “Amendment Effective Date”), conditioned upon execution by Contractor and Customer of this Amendment and six other separate amendments, in substantially the form of this Amendment, applicable to the other six (6) Service Areas for the United States (collectively, the “United States Service Areas”), whereby the Customer is the successor in interest to and acting on behalf of each of the respective other six subscribing customers named in each such amendment. 

The number in the upper left-hand corner refers to this Amendment.  Capitalized terms used herein without definition or which do not specifically reference another agreement shall have the meanings as defined in the Master Agreement, including Amendment No. 42, effective October 22, 2003 (“Amendment No. 42”).  The term “Allocated Payor” shall have the same meaning set forth in Article 1 of the Master Agreement, as amended by Section 9.2 of Amendment No. 42 i.e., any of the entities that the Contractor is entitled to invoice for Allocated Charges under the FCC’s Matter of Telephone Number Portability, Third Report and Order, CC Docket 95-116, RM 8535, FCC 98-82, as it may subsequently be revised or amended (the “Cost Recovery Order”).

3.CONSIDERATION RECITAL

In consideration of the terms and conditions set forth in this Amendment, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, Contractor and Customer agree as set forth in this Amendment. The modifications and amendments made herein were negotiated together, and each is made in consideration of all of the other terms and conditions herein. All such modifications and amendments are interrelated and are dependent on each other. No separate, additional or different consideration is contemplated with respect to the modifications and amendments herein.  Notwithstanding the foregoing or anything else in this Amendment, neither Contractor nor Customer makes any representations with respect to

48

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

expected TN Porting Event volumes in the United States Services Areas, cumulatively or, individually, in any United States Service Areas, and does not guarantee or otherwise ensure any TN Porting Event volumes.

4.             RATIFICATION OF REMAINING PROVISIONS OF AMENDMENT NO. 42

As set forth in Article 5 of this Amendment, Article 6 and Article 7 of Amendment No. 42 are deleted in their entirety, and therefore, Customer and Contractor agree that the remaining provisions of Amendment No. 42 remain in full force and effect, and Customer and Contractor hereby ratify and reaffirm Amendment No. 42, as amended herein.

5.             DELETION OF ARTICLE 6 AND ARTICLE 7 OF AMENDMENT NO. 42

5.1Deletion of Article 6: Fixed Credit Payments. 

Article 6 (Fixed Credit Payments) of Amendment No. 42 is hereby deleted in its entirety.

5.2Deletion of Article 7: Variable Credit Payments.

Article 7 (Variable Credit Payments) of Amendment No. 42 is hereby deleted in its entirety.

6.CREDIT PAYMENTS FOR 2003 AND 2004

The Master Agreement is hereby amended as of the Amendment Effective Date by the addition of Article 33, which will read in it entirety as follows:

ARTICLE 33 – CREDIT PAYMENTS FOR 2003 AND 2004

33.1         Overview. 

(a)           Credit Payments for 2003.  Commencing with the invoices issued to Allocated Payors in the Service Area pursuant to Section 6.6(c) of this Agreement in January, 2004, Contractor agrees in accordance with the provisions of this Article 33 to issue and apply as a credit a portion of the following to each Allocated Payor in the Service Area: (1) the Fixed Credit Payment for 2003; (2) Fixed Credit Payment Interest for 2003; (3) the Variable Credit Payment for 2003; and (4) the Variable Credit Payment Interest for 2003.

(b)           Credit Payments for 2004.  Commencing with the invoices issued to Allocated Payors in the Service Area pursuant to Section 6.6(c) of this Agreement in January, 2005, Contractor agrees in accordance with the provisions of this Article 33 to issue and apply as a credit a portion of the following to each Allocated Payor in the Service Area: (1) the Fixed Credit

49

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

Payment for 2004; (2) Fixed Credit Payment Interest for 2004; (3) the Credit Payment for 2004; and (4) the Credit Payment Interest for 2004.

(c)           Nomenclature.  For the purposes of making installment payments to Allocated Payors under this Article 33, the term “issue” and its derivatives shall refer to the availability of a particular share or portion of an installment of a credit or interest payment hereunder on an invoice for application against charges set forth in an invoice, and the term “apply” and its derivatives shall refer to the reduction of charges set forth in an invoice, except for charges allocable or chargeable pursuant to a Statement of Work for Additional Services, by the share or portion of such issued credits or interest installment payments set forth in such invoice.

33.2Fixed Credit Payment, Fixed Credit Installment and Fixed Credit Installment Interest

(a)           Fixed Credit Payment for 2003. For calendar year 2003, Contractor shall make an aggregate payment in the amount of [* * *] Dollars $[* * *] to all Allocated Payors in the Subscribing Customer’s Service Area (the “Fixed Credit Payment for 2003”).  The Fixed Credit Payment for 2003 reflects a price reduction for TN Porting Event volumes already achieved in calendar year 2003, and Allocated Payors shall not be entitled to any further reductions to TN Porting Event charges as a result of this Section 33.2(a).  Contractor shall make the Fixed Credit Payment for 2003 by issuing and applying 12 equal credit installments in accordance with Section 33.2(e) of this Agreement to Allocated Payors in calendar year 2004, commencing with the invoices issued to Allocated Payors in the Service Area pursuant to Section 6.6(c) of this Agreement in January, 2004 (i.e., for the Billing Cycle ending December 31, 2003).  The aggregate amount of each of the 12 equal credit installments of the Fixed Credit Payment for 2003 to be issued and applied for the benefit of all Allocated Payors in the Service Area shall equal [* * *] Dollars $[* * *] (each such equal credit installment referred to as a “Fixed Credit Installment for 2003”). 

(b)           Fixed Credit Installment Interest for 2003. Commencing with the invoices issued to Allocated Payors in the Service Area pursuant to Section 6.6(c) of this Agreement in February, 2004 (i.e., for the Billing Cycle ending January 31, 2004) and concluding in January 2005 (i.e., for the Billing Cycle ending December 31, 2004), upon the issuance of the last Fixed Credit Installment for 2003, in accordance with Section 33.2(e) of this Agreement below, Contractor shall pay an additional credit in each monthly invoice to each Allocated Payor in the Service Area by issuing a credit calculated each month equal to the product of an interest rate (set forth below) and the balance of the Fixed Credit Installments for 2003 not yet issued in the invoices of such Allocated Payors issued in calendar year 2004 (such interest amount referred to as the “Fixed Credit Installment Interest for 2003”).  The amount of the Fixed Credit Installment Interest for 2003 shall be computed from January 1, 2004, based upon the actual number of days in

50

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

each month, shall be compounded daily and shall utilize the average after-tax interest rate on deposits that was actually obtained by Contractor from its principal bank (that is, the bank having the greatest outstanding balance of cash deposits) on cash deposits during the month preceding the invoice on which the Fixed Credit Installment Interest for 2003 appears.  For the avoidance of doubt, the forgoing interest calculation shall not apply to any portion of the Fixed Credit Installment for 2003 that is issued in invoices but not yet applied against payments due.

(c)           Fixed Credit Payment for 2004. For calendar year 2004, Contractor shall make an aggregate payment in the amount of [* * *] Dollars $[* * *] to all Allocated Payors in the Subscribing Customer’s Service Area (the “Fixed Credit Payment for 2004”).  The Fixed Credit Payment for 2004 reflects a price reduction for TN Porting Event volumes expected in calendar year 2004, and Allocated Payors shall not be entitled to any further reductions to TN Porting Event charges as a result of this Section 33.2(c). Contractor shall make the Fixed Credit Payment for 2004 by issuing and applying 12 equal credit installments in accordance with Section 33.2(e) of this Agreement to Allocated Payors in calendar year 2005, commencing with the invoices issued to Allocated Payors in the Service Area pursuant to Section 6.6(c) of this Agreement in January, 2005 (i.e., for the Billing Cycle ending December 31, 2004).  The aggregate amount of each of the 12 equal credit installments of the Fixed Credit Payment for 2004 to be issued and applied for the benefit of all Allocated Payors in the Service Area shall equal [* * *]$[* * *] (each such equal credit installment, referred to as a “Fixed Credit Installment for 2004”). 

(d)           Fixed Credit Installment Interest for 2004. Commencing with the invoices issued to Allocated Payors in the Service Area pursuant to Section 6.6(c) of this Agreement in February, 2005 (i.e., for the Billing Cycle ending January 31, 2005) and concluding in January, 2006 (i.e., for the Billing Cycle ending December 31, 2005), upon the issuance of the last Fixed Credit Installment for 2004, in accordance with Section 33.2(e) of this Agreement below, Contractor shall pay an additional credit in each monthly invoice to each Allocated Payor in the Service Area by issuing a credit calculated each month equal to the product of an interest rate (set forth below) and the balance of the Fixed Credit Installments for 2004 not yet issued in the invoices of such Allocated Payors issued in calendar year 2005 (such interest amount referred to as the “Fixed Credit Installment Interest for 2004”).  The amount of the Fixed Credit Installment Interest for 2004 shall be computed from January 1, 2005 based upon the actual number of days in each month, shall be compounded daily and shall utilize the average after-tax interest rate on deposits that was actually obtained by Contractor from its principal bank (that is, the bank having the greatest outstanding balance of cash deposits) on cash deposits during the month preceding the invoice on which the Fixed Credit Payment Interest for 2004 appears. For the avoidance of doubt, the forgoing interest calculation shall not apply to any portion of the Fixed Credit Installment for 2004 that is issued in invoices but not yet applied against payments due.

51

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

(e)Division, Application and Invoicing Among Allocated Payors in Service Area

(1)Division Among Allocated Payors Within the Service Area.  Each Allocated Payor’s share of each Fixed Credit Installment for 2003, Fixed Credit Installment Interest for 2003, Fixed Credit Installment for 2004, and Fixed Credit Installment Interest for 2004 shall be issued in the same manner as the division, apportioning and invoicing of Allocated Charges is determined under SOW11 and in accordance with the Cost Recovery Order, pursuant to Section 6.6(c) of this Agreement, and shall be applied as a reduction against all charges for Services shown on such invoice and allocable or chargeable to such Allocated Payor under the Master Agreement, but not including charges allocable or chargeable pursuant to a Statement of Work for Additional Services.  If for any Allocated Payor such credit actually applied on that invoice does not apply in full such Allocated Payor’s share of the Fixed Credit Installment for 2003, Fixed Credit Installment Interest for 2003, Fixed Credit Installment for 2004, or Fixed Credit Installment Interest for 2004, as the case may be, then the remaining share of such unapplied credit allocable to that Allocated Payor shall be applied again on the next monthly invoice, and any subsequent invoices as necessary, of such Allocated Payor in the amount of the lesser of (i) the full amount of the remaining unapplied amount of the Fixed Credit Installment for 2003, Fixed Credit Installment Interest for 2003, Fixed Credit Installment for 2004, or Fixed Credit Installment Interest for 2004, as the case may be, allocable to that Allocated Payor or (ii) the full amount of all charges for Services shown on such invoice and allocable or chargeable to such Allocated Payor under the Master Agreement, but not including charges allocable or chargeable pursuant to a Statement of Work for Additional Services, until the share of the Fixed Credit Installment for 2003, Fixed Credit Installment Interest for 2003, Fixed Credit Installment for 2004, or Fixed Credit Installment Interest for 2004, as the case may be, allocable to that Allocated Payor is fully applied.

(2)Invoices.  The invoices in which each Allocated Payor’s share of the Fixed Credit Installment for 2003 and of the Fixed Credit Installment for 2004, respectively, as the case may be, are first issued shall clearly identify the amount of both the share of the Fixed Credit Payment for 2003 and of the Fixed Credit Installment for 2003, and the Fixed Credit Payment for 2004 and the Fixed Credit Installment for 2004, respectively, as the case may be, allocable to the Allocated Payor which is issued and applied on the invoice.  Likewise, the invoices in which each Allocated Payor’s share of the Fixed Credit Installment Interest for 2003 and of the Fixed Credit Installment Interest for 2004, respectively, as the case may be, are first issued shall clearly identify the amount of both the share of the Fixed Credit Installment Interest for 2003 and of the Fixed Credit Installment Interest for 2004, respectively, as the case may be, allocable to the Allocated Payor which is issued and applied on the invoice.  Any amount of

52

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

such Allocated Payor’s share of any of the credits referenced in this Section 33.2(e)(2) that remains after application on that invoice shall be aggregated with and added to amounts of the Allocated Payor’s share of such credits remaining for application on future invoices.  Any such amounts of such credits actually applied on subsequent invoices shall be clearly identified on such invoice and any subsequent invoices.

(3)Invoice Explanation and Records.  Each Allocated Payor shall be provided by Contractor with access, at no additional charge, to a secure, password-protected Web site that will provide a report identifying the issuance and application of the Allocated Payor’s share of each Fixed Credit Installment for 2003, Fixed Credit Installment Interest for 2003, Fixed Credit Installment for 2004, and Fixed Credit Installment Interest for 2004.  Such report will be provided for a period of twelve (12) months after the date of the invoice in which such credits were last applied.  Further, Contractor shall consult with Customer prior to issuance of a form cover letter to accompany those invoices to Allocated Payors for the issuance and application of each Fixed Credit Installment for 2003, Fixed Credit Installment Interest for 2003, Fixed Credit Installment for 2004, and Fixed Credit Installment Interest for 2004.  After consultation with Customer, Contractor shall issue in December, 2003 a letter to all Allocated Payors in the Service Area describing the nature, calculation and expected payment of the Fixed Credit Payment for 2003 (pursuant to the Fixed Credit Payment Installments for 2003), the Fixed Credit Payment for 2004 (pursuant to the Fixed Credit Payment Installments for 2004), the Fixed Credit Installment Interest for 2003, the Fixed Credit Installment Interest for 2004, the Variable Credit Payments for 2003 and 2004 (pursuant to the Variable Credit Installments), the Variable Credit Installment Interest for 2003 and 2004, the Annual Volume Dependent TN Porting Event Price Reductions (as those terms are defined herein), the new charges for TN Porting Events (“Rate Card 2”), as set forth in Article 5 of Amendment No. 42, and identifying the contact personnel in the Contractor’s billing department to whom inquiries may be directed concerning the foregoing.

(f)Miscellaneous.

(1)Separate from Reduced TN Porting Event Charge or Rate Cards.  The computation, division, apportioning, issuance, application, and invoicing of the Fixed Credit Payment Credit for 2003 (pursuant to the Fixed Payment Credit Installments for 2003), the Fixed Credit Installment Interest for 2003, the Fixed Credit Payment for 2004 (pursuant to the Fixed Payment Credit Installment for 2004) and the Fixed Credit Installment Interest for 2004 among Allocated Payors as set forth in this Section 33.2 are separate from the computation of any Reduced TN Porting Price under Article 32 of this Agreement.  Further, the computation, division, apportioning, issuance, application, and invoicing of the Fixed Credit Payment Credit for 2003 (pursuant

53

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

to the Fixed Payment Credit Installments for 2003), the Fixed Credit Installment Interest for 2003, the Fixed Credit Payment for 2004 (pursuant to the Fixed Payment Credit Installment for 2004) and the Fixed Credit Installment Interest for 2004 do not and shall not be construed as altering or amending the charges for TN Porting Events set forth in Rate Card No. 1 or Rate Card No. 2.

(2)Application of Gateway Evaluation Process.  The computation, division, apportioning, issuance, application, and invoicing of the Fixed Credit Payment Credit for 2003 (pursuant to the Fixed Payment Credit Installments for 2003), the Fixed Credit Installment Interest for 2003, the Fixed Credit Payment for 2004 (pursuant to the Fixed Payment Credit Installment for 2004) and the Fixed Credit Installment Interest for 2004 among Allocated Payors as set forth in this Section 33.2, shall be auditable and included in determining “accuracy” of invoices for purposes of Element No. 7b of the Gateway Evaluation Process, as set forth in Article 32 of this Agreement. The Fixed Credit Payment Credit for 2003 (pursuant to the Fixed Payment Credit Installments for 2003), the Fixed Credit Installment Interest for 2003, the Fixed Credit Payment for 2004 (pursuant to the Fixed Payment Credit Installment for 2004) and the Fixed Credit Installment Interest for 2004 provided in this Section 33.2 relate to and are applicable against all charges for Services allocable to Allocated Payors, including, but not limited to TN Porting Event charges, but do not relate to and are not applicable against charges for Additional Services under Statements of Work under Article 13 of the Master Agreement.

(3) Preservation of Rights of Setoff.  Allocated Payors retain their right of set-off against all charges for Services allocable to Allocated Payors under the Master Agreement, including, but not limited to TN Porting Event charges, for Contractor’s failure to properly and accurately compute and credit the Fixed Credit Payment Credit for 2003 (pursuant to the Fixed Payment Credit Installments for 2003), the Fixed Credit Installment Interest for 2003, the Fixed Credit Payment for 2004 (pursuant to the Fixed Payment Credit Installment for 2004) and the Fixed Credit Installment Interest for 2004, all as contemplated under this Section 33.2.

33.3Variable Credit Payment, Variable Credit Installment and Variable Credit Installment Interest.

(a)Computation of Variable Credit Payment and Variable Credit Installment.

(1)Variable Credit Payment and Variable Credit Installment for Entire Service Area.  For each of calendar years 2003 and 2004, Contractor shall make an aggregate payment (the “Variable Credit Payment”) to all Allocated Payors in the Service Area of the Subscribing Customer, equal to the product of the amounts calculated in subparagraphs (i) and

54

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

(ii) below. The Variable Credit Payment for 2003 reflects a price reduction for TN Porting Events volumes already achieved in calendar year 2003, the Variable Credit Payment for 2004 reflects a price reduction for TN Porting Events volumes expected in calendar year 2004, and Allocated Payors shall not be entitled to any further reductions to TN Porting Event charges as a result of this Section 33.3(a)(1).   Contractor shall make the Variable Credit Payment by issuing and applying 12 equal credit installments in accordance with Section 33.2(e) of this Agreement to Allocated Payors in the immediately following calendar year, commencing with the invoices issued to Allocated Payors in the Service Area pursuant to Section 6.6(c) of this Agreement in February of such immediately following calendar year (i.e., the invoice for the Billing Cycle ending January 31 of the applicable calendar year).  Each such equal credit installment of the applicable calendar year’s Variable Credit Payment shall be referred to as a “Variable Credit Installment” for such applicable calendar year.  .

(i) Calculate the following (i.e., the earned portion of the Annual Available Credit dollars for all United States Services Areas):

[(A – C) / (B – C)] * D

Where, as identified in the table below:

A = Actual number of aggregate TN Porting Events in all of the United States Service Areas, up to a maximum not to exceed the amount for Maximum TN Porting Events below in “B”.

B = Maximum TN Porting Events in the aggregate for all United States Service Areas

C= Threshold TN Porting Events in the aggregate for all United States Service Areas

D = Annual Maximum Available Credit dollars for all United States Service Areas

For the avoidance of doubt, the “Annual Maximum Available Credit” is the maximum possible amount of the Variable Credit Payment available in the aggregate for computation hereunder for all United States Service Areas for each applicable calendar year.

AGGREGATE FOR ALL UNITED STATES SERVICE AREAS	2003		2004
Maximum TN Porting Events (“B”)	64,032,000		122,887,000
Threshold TN Porting Events (“C”)	60,000,000		100,000,000
Annual Maximum Available Credit (“D”)	$	[* * *]	$	[* * *]

55

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

(ii) Calculate a fraction (i.e., the Service Area’s pro-rated share of invoiced charges), the numerator of which is the aggregate amount of invoiced charges for all Allocated Payors in the Subscribing Customer’s Service Area for TN Porting Events during a calendar year and the denominator of which is the aggregate amount of invoiced charges for all Allocated Payors in all United States Service Areas for TN Porting Events during the same calendar year.

(2)Variable Credit Installment Interest for 2003.  Commencing with the invoices issued to Allocated Payors in the Service Area pursuant to Section 6.6(c) of this Agreement in February, 2004 (i.e., the Billing Cycle ending January 31, 2004) and concluding in January 2005 (i.e., the Billing Cycle ending December 31, 2004), upon the issuance of the last Variable Payment Credit Installment for 2003, in accordance with Section 33.3(e) of this Agreement below, Contractor shall pay an additional credit in each monthly invoice to each Allocated Payor in the Service Area by issuing a credit calculated each month equal to the product of an interest rate (set forth below) and the balance of the Variable Credit Installments for 2003 not yet issued in the invoices of such Allocated Payors issued in calendar year 2004 (such interest amount referred to as the “Variable Credit Installment Interest” for 2003).  The amount of the Variable Credit Installment Interest for 2003 shall be computed from January 1, 2004, based upon the actual number of days in each month, shall be compounded daily and shall utilize the average after-tax interest rate on deposits that was actually obtained by Contractor from its principal bank (that is, the bank having the greatest outstanding balance of cash deposits) on cash deposits during the month preceding the invoice on which the Variable Credit Installment Interest for 2003 appears.  For the avoidance of doubt, the forgoing interest calculation shall not apply to any portion of the Variable Credit Payment for 2003 that is issued in invoices but not yet applied against payments due.

(3)Variable Credit Installment Interest for 2004. Commencing with the invoices issued to Allocated Payors in the Service Area pursuant to Section 6.6(c) of this Agreement in February, 2005 (i.e., the Billing Cycle ending January 31, 2005) and concluding in January, 2006 (i.e., Billing Cycle ending December 31, 2005), upon the issuance of the last Variable Payment Credit for 2004, in accordance with Section 33.3(e) of this Agreement below, Contractor shall pay an additional credit in each monthly invoice to each Allocated Payor in the Service Area by issuing a credit calculated each month equal to the product of an interest rate (set forth below) and the balance of the Variable Credit Installments for 2004 not yet issued in the invoices of such Allocated Payors issued in calendar year 2005 (such interest amount referred to as the “Variable Credit Installment Interest” for 2004).  The amount of the Variable Credit Installment Interest for 2004 shall be computed from January 1, 2005, based upon the actual number of days in each month, shall be compounded daily and shall utilize the average after-tax interest rate on deposits that was actually

56

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

obtained by Contractor from its principal bank (that is, the bank having the greatest outstanding balance of cash deposits) on cash deposits during the month preceding the invoice on which the Variable Credit Installment Interest for 2004 appears.  For the avoidance of doubt, the forgoing interest calculation shall not apply to any portion of the Variable Credit Payment for 2004 that is issued in invoices but not yet applied against payments due.

(b)Division, Application and Invoicing Among Allocated Payors in Service Area

(1)Division Among Allocated Payors Within the Service Area. Each Allocated Payor’s share of each Variable Credit Installment for 2003 and 2004, Variable Credit Installment Interest for 2003, and Variable Credit Installment Interest for 2004 shall be issued in the same manner as the division, apportioning and invoicing of Allocated Charges is determined under SOW11 and in accordance with the Cost Recovery Order, pursuant to Section 6.6(c) of this Agreement, and shall be applied as a reduction against all charges for Services shown on such invoice and allocable or chargeable to such Allocated Payor under this Agreement, but not including charges allocable or chargeable pursuant to a Statement of Work for Additional Services.  If for any Allocated Payor such credit actually applied on that invoice does not apply in full such Allocated Payor’s share of the Variable Credit Installment for 2003 or 2004, Variable Credit Installment Interest for 2003, or Variable Credit Installment Interest for 2004, as the case may be, then the remaining share of such unapplied credit allocable to that Allocated Payor shall be applied again on the next monthly invoice, and any subsequent invoices as necessary, of such Allocated Payor in the amount of the lesser of (i) the full amount of the remaining unapplied amount of the Variable Credit Installment for 2003 or 2004, Variable Credit Installment Interest for 2003, or Variable Credit Installment Interest for 2004, as the case may be, allocable to that Allocated Payor or (ii) the full amount of all charges for Services shown on such invoice and allocable or chargeable to such Allocated Payor under this Agreement, but not including charges allocable or chargeable pursuant to a Statement of Work for Additional Services, until the share of the Variable Credit Installment for 2003 or 2004, Variable Credit Installment Interest for 2003, or Variable Credit Installment Interest for 2004, as the case may be, allocable to that Allocated Payor is fully applied.

(2)Invoices.  The invoices in which each Allocated Payor’s share of the Variable Credit Installment for 2003 and for 2004, respectively, as the case may be, are first issued shall clearly identify the amount of both the share of the Variable Credit Payment for 2003 and of the Variable Credit Installment for 2003, and the Variable Credit Payment for 2004 and the Variable Credit Installment for 2004, respectively, as the case may be, allocable to the Allocated Payor which is issued and applied on the invoice.  Likewise, the

57

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

invoices in which each Allocated Payor’s share of the Variable Credit Installment Interest for 2003 and for 2004, respectively, as the case may be, are first issued and applied shall clearly identify the amount of both the share of the Variable Credit Installment Interest for 2003 and for 2004, respectively, as the case may be, allocable to the Allocated Payor which is applied on the invoice.  Any amount of such Allocated Payor’s share of any of the credits referenced in this Section 33.3(b)(2) that remains after application on that invoice shall be aggregated with and added to amounts of the Allocated Payor’s share of such credits remaining for application on future invoices.  Any such amounts of such credits actually applied on subsequent invoices shall be clearly identified on such invoice and any subsequent invoices.

(3)Invoice Explanation and Records.  Each Allocated Payor shall be provided by Contractor with access, at no additional charge, to a secure, password-protected Web site that will provide a report identifying the issuance and application of the Allocated Payor’s share of the Variable Credit Payment for 2003 and 2004, the Variable Credit Installment for 2003 and 2004 and the Variable Credit Installment Interest for 2003 and 2004.  Such report will be provided for a period of twelve (12) months after the date of the invoice in which such credits were last applied.  Further, Contractor shall consult with Customer prior to issuance of a form cover letter to accompany those invoices to Allocated Payors for which amounts of the Variable Credit Payment for 2003 and 2004, the Variable Credit Installment for 2003 and 2004 and the Variable Credit Installment Interest for 2003 and 2004, respectively, are each first applied and utilized.

(4)Limitation on Annual Maximum Available Credit.  Notwithstanding anything herein to the contrary, in no event shall any unused amount of an Annual Maximum Available Credit for any year set forth above be available or otherwise be used (i.e., carry over) in the computation under Section 33.3(a)(1)(i) and (ii) above in a subsequent calendar year.

(c)Miscellaneous

(1)Separate from Reduced TN Porting Event Charge or Rate Cards.  The computation, division, apportioning, issuance, application, and invoicing of the Variable Payment Credit for 2003 and for 2004 (pursuant to the Variable Payment Credit Installments for 2003 and for 2004, and the Variable Credit Installment Interest for 2003 and for 2004 among Allocated Payors as set forth in this Section 33.3 are separate from the computation of any Reduced TN Porting Price under Article 32 of this Agreement.  Further, the computation, division, apportioning, issuance, application, and invoicing of the Variable Payment Credit for 2003 and for 2004 (pursuant to the Variable Payment Credit Installments for 2003 and for 2004, and the Variable Credit Installment Interest

58

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

for 2003 and for 2004 do not and shall not be construed as altering or amending the charges for TN Porting Events set forth in Rate Card No. 1 or Rate Card No. 2.

(2)Application of Gateway Evaluation Process.  The computation, division, apportioning, issuance, application, and invoicing of the Variable Payment Credit for 2003 and for 2004 (pursuant to the Variable Payment Credit Installments for 2003 and for 2004, and the Variable Credit Installment Interest for 2003 and for 2004 among Allocated Payors as set forth in this Section 33.3, shall be auditable and included in determining “accuracy” of invoices for purposes of Element No. 7b of the Gateway Evaluation Process, as set forth in Article 32 of this Agreement. The Variable Payment Credit for 2003 and for 2004 (pursuant to the Variable Payment Credit Installments for 2003 and for 2004, and the Variable Credit Installment Interest for 2003 and for 2004 provided in this Section 33.3 relate to and are applicable against all charges for Services allocable to Allocated Payors, including, but not limited to TN Porting Event charges, but do not relate to and are not applicable against charges for Additional Services under Statements of Work under Article 13 of the Master Agreement.

(3)Preservation of Rights of Setoff.  Allocated Payors retain their right of set-off against all charges for Services allocable to Allocated Payors under this Agreement including, but not limited to TN Porting Event charges, for Contractor’s failure to properly and accurately compute and credit the Variable Payment Credit for 2003 and for 2004 (pursuant to the Variable Payment Credit Installments for 2003 and for 2004, and the Variable Credit Installment Interest for 2003 and for 2004, all as contemplated under this Section 33.3.

7.ANNUAL VOLUME DEPENDENT TN PORTING PRICE REDUCTIONS

The Master Agreement is hereby amended as of the Amendment Effective Date by the addition of Article 34, which will read in its entirely as follows:

ARTICLE 34 – ANNUAL VOLUME DEPENDENT TN PORTING PRICE REDUCTIONS FOR 2005 TO END OF INITIAL TERM

34.1Overview.  Customer and Contractor agree that annually for calendar years commencing in 2005 until the expiration of the Initial Term of this Agreement, and in addition to any TN Porting Price Reductions under Section 32.5 of this Agreement, if any, Contractor shall within any given calendar year, and if certain volumes are attained, on a temporary basis, and in accordance with this Article 34, further reduce the TN Porting Event charge to Allocated Payors in the Subscribing Customer’s Service Area based upon the attainment of various ranges of volumes of TN Porting Events in all United States Service Areas for each calendar year (each such range referred to, respectively, in this Article 34 as the “Tier 1 Volume Range” and the “Tier 2 Volume Range”).  Each reduction in the TN Porting Event

59

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

charge under this Article 34 and referred to in the preceding sentence shall be referred to as the “Annual Volume Dependent TN Porting Price Reduction.”  For the purposes of this Article 34, the “Prevailing TN Porting Charge” shall mean the then effective TN Porting Event charge, as set forth in Schedule 1 (Service Element Fees/Unit Pricing) of Exhibit E (Pricing Schedules) of this Agreement, as adjusted by any TN Porting Price Reductions under Section 32.5 of this Agreement.

34.2Computation.  For each calendar year commencing in 2005 and concluding in 2011, Contractor shall temporarily reduce, in accordance with Section 34.3, the Prevailing TN Porting Event Charge for Allocated Payors in the Subscribing Customer’s Service Area by the respective amount of Annual Volume Dependent TN Porting Price Reductions set forth in the following tables below (each an “Annual Volume Dependent TN Porting Price Reduction”).  The Annual Volume Dependent TN Porting Price Reduction is based upon the aggregate volume of TN Porting Events for all United States Service Areas in each applicable calendar year reaching certain tiered volume ranges (i.e., Tier 1 Volume Range and Tier 2 Volume Range shown for each such year as set forth in the following tables). 

	2005					2006
	Annual
ANNUAL TN PORTING	Volume		Maximum		ANNUAL TN PORTING	Annual Volume		Maximum
EVENT VOLUMES FOR	Dependent TN		Equivalent		EVENT VOLUMES FOR	Dependent TN		Equivalent
ALL UNITED STATES	Porting Price		National		ALL UNITED STATES	Porting Price		National
SERVICE AREAS	Reduction		Reduction		SERVICE AREAS	Reduction		Reduction
< 100,000,000	$	[* * *]	$	[* * *]	< 100,000,000	$	[* * *]	$	[* * *]
Tier 1 Volume Range: 100,000,000 – 126,591,000	$	[* * *]	$	[* * *]	Tier 1 Volume Range: 100,000,000-130,098,000	$	[* * *]	$	[* * *]
Tier 2 Volume Range: 126,591,001 – 153,182,000	$	[* * *]	$	[* * *]	Tier 2 Volume Range: 130,098,001 – 160,195,000	$	[* * *]	$	[* * *]
>153,182,000	$	[* * *]	$	[* * *]	>160,195,000	$	[* * *]	$	[* * *]

	2007					2008
	Annual
ANNUAL TN PORTING	Volume		Maximum		ANNUAL TN PORTING	Annual Volume		Maximum
EVENT VOLUMES FOR	Dependent TN		Equivalent		EVENT VOLUMES FOR	Dependent TN		Equivalent
ALL UNITED STATES	Porting Price		National		ALL UNITED STATES	Porting Price		National
SERVICE AREAS	Reduction		Reduction		SERVICE AREAS	Reduction		Reduction
< 100,000,000	$	[* * *]	$	[* * *]	< 100,000,000	$	[* * *]	$	[* * *]
Tier 1 Volume Range: 100,000,000 – 129,994,000	$	[* * *]	$	[* * *]	Tier 1 Volume Range: 100,000,000-127,394,000	$	[* * *]	$	[* * *]
Tier 2 Volume Range: 129,994,001 – 159,987,000	$	[* * *]	$	[* * *]	Tier 2 Volume Range: 127,394,001 – 154,787,000	$	[* * *]	$	[* * *]
>159,987,000	$	[* * *]	$	[* * *]	>154,787,000	$	[* * *]	$	[* * *]

60

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

	2009					2010
	Annual
ANNUAL TN PORTING	Volume		Maximum		ANNUAL TN PORTING	Annual Volume		Maximum
EVENT VOLUMES FOR	Dependent TN		Equivalent		EVENT VOLUMES FOR	Dependent TN		Equivalent
ALL UNITED STATES	Porting Price		National		ALL UNITED STATES	Porting Price		National
SERVICE AREAS	Reduction		Reduction		SERVICE AREAS	Reduction		Reduction
< 100,000,000	$	[* * *]	$	[* * *]	< 100,000,000	$	[* * *]	$	[* * *]
Tier 1 Volume Range: 100,000,000 – 126,120,000	$	[* * *]	$	[* * *]	Tier 1 Volume Range: 100,000,000-124,859,000	$	[* * *]	$	[* * *]
Tier 2 Volume Range: 126,120,001 – 152,240,000	$	[* * *]	$	[* * *]	Tier 2 Volume Range: 124,859,001 – 149,717,000	$	[* * *]	$	[* * *]
>152,240,000	$	[* * *]	$	[* * *]	>149,717,000	$	[* * *]	$	[* * *]

61

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

	2011
	Annual
ANNUAL TN PORTING	Volume		Maximum
EVENT VOLUMES FOR	Dependent TN		Equivalent
ALL UNITED STATES	Porting Price		National
SERVICE AREAS	Reduction		Reduction
< 100,000,000	$	[* * *]	$	[* * *]
Tier 1 Volume Range: 100,000,000 –123,610,000	$	[* * *]	$	[* * *]
Tier 2 Volume Range: 123,610,001 –147,220,000	$	[* * *]	$	[* * *]
>147,220,000	$	[* * *]	$	[* * *]

34.3Timing and Application.  For each calendar year, each Annual Volume Dependent TN Porting Price Reduction, if any, shall be applied in accordance with the following:

(a) No Annual Volume Dependent TN Porting Price Reduction shall apply to reduce the Prevailing TN Porting Charge for any Allocated Payor in the Subscribing Customer’s Service Area when the aggregate number of TN Porting Events for all United States Service Areas for the applicable calendar year is less than the lowest number in the Tier 1 Volume Range.

(b) Upon the aggregate number of TN Porting Events in all United States Service Areas for the applicable calendar year equaling the lowest number in the Tier 1 Volume Range and until the aggregate number of TN Porting Events in all United States Service Areas in such calendar year exceeds the highest number in the Tier 1 Volume Range, the Annual Volume Dependent TN Porting Price Reduction set forth immediately opposite the Tier 1 Volume Range for that year shall apply to reduce the Prevailing TN Porting Charge for all the TN Porting Events in the Subscribing Customer’s Service Area which are included in the Tier 1 Volume Range.

(c) Upon the aggregate number of TN Porting Events in all United States Service Areas for the applicable calendar year equaling the lowest number in the Tier 2 Volume Range and until the aggregate number of TN Porting Events in all United States Service Areas for the applicable calendar year exceeds the highest number in the Tier 2 Volume Range, the Annual Volume Dependent TN Porting Price Reduction referenced in Paragraph (b) above shall expire and be replaced by the Annual Volume Dependent TN Porting Price Reduction set forth immediately opposite the Tier 2 Volume Range for that calendar year shall apply to reduce the Prevailing TN Porting Charge for all the TN Porting Events in the Subscribing Customer’s Service Area in such calendar year which are included in the Tier 2 Volume Range.

62

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

(d) Upon the aggregate number of TN Porting Events in all United States Service Areas for the applicable calendar year exceeding the highest number in the Tier 2 Volume Range for that calendar year, the Annual Volume Dependent TN Porting Price Reduction referenced in Paragraph (c) above shall expire and no Annual Volume Dependent TN Porting Price Reduction shall apply to reduce the Prevailing TN Porting Charge for any subsequent TN Porting Events in the Subscribing Customer’s Service Area for the remainder of that applicable calendar year.  After such expiration, only the Prevailing TN Porting Charge, as defined in Section 34.1, shall apply for that calendar year.

(e) Any Annual Volume Dependent TN Porting Price Reductions determined by Sections 34.3(a) through (d) above shall be immediately effective to reduce the Prevailing TN Porting Event Charge, and shall be issued and reflected on Allocated Payors’ invoices issued for the Billing Cycle in which such Annual Volume Dependent TN Porting Price Reductions became effective.

(f) The dollar amounts set forth under the “Maximum Equivalent National Reduction” for each of Tier 1 Volume Range and Tier 2 Volume Range in the tables above represent the maximum amount of aggregate price reductions under this Article 34 available to all United States Service Areas for the applicable calendar year; i.e., the product of the Annual Volume Dependent TN Porting Price Reduction and the maximum value of the corresponding tiered volume range.  In no event shall such maximum amounts carry over to any subsequent calendar year.

(g) Solely for the purpose of calculating the Annual Volume Dependent TN Porting Price Reduction under this Article 34 for each applicable calendar year, the actual volume of TN Porting Events for all United States Service Areas shall be reset to zero each calendar year on January 1^st, and in no event shall the volume of TN Porting Events used in determining whether an Annual Volume Dependent TN Porting Price Reduction in any given year carry over to any subsequent calendar year.

34.4Invoice Explanation.  Contractor shall consult with Customer prior to issuance of a form cover letter to accompany those invoices to Allocated Payors on which, for each calendar year, the first Annual Volume Dependent TN Porting Price Reduction appears or becomes applicable.

34.5Application of Gateway Evaluation Process. The computation, division, apportioning, issuance, application, and invoicing of any Annual Volume Dependent TN Porting Price Reduction shall be auditable and included in determining “accuracy” for purposes of Element No. 7b of the Gateway Evaluation Process, as set forth in Article 32 of this Agreement, only on the third invoice after the Billing Cycle in which each such Annual Volume Dependent TN Porting Price Reduction was effective, and the previous two invoices shall be

63

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

considered accurate with respect to that particular issuance of an Annual Volume Dependent TN Porting Price Reduction for purposes of Element No. 7b of the Gateway Evaluation Process, regardless of whether the relevant Annual Volume Dependent TN Porting Price Reduction was accurately reflected on those two invoices.  Nothing herein shall preclude Contractor, in the event that Contractor does not reflect such Annual Volume Dependent TN Porting Event Charge Reduction when and as required under Section 34.3(e), from issuing an adjustment credit to reflect the proper computation, division, apportioning, issuance, application, and invoicing of the Annual Volume Dependent TN Porting Price Reduction on any one or more invoices issued after such Annual Volume Dependent TN Porting Event Charge Reduction became effective.

8.IMPACTS ON MASTER AGREEMENT

The following portions of the Master Agreement are impacted by this Amendment:

	Master Agreement
None	Exhibit B Functional Requirements Specification
None	Exhibit C Interoperable Interface Specification
	Exhibit E Pricing Schedules
None	Exhibit F Project Plan and Test Schedule
None	Exhibit G Service Level Requirements
None	Exhibit H Reporting and Monitoring Requirements
None	Exhibit J User Agreement Form
None	Exhibit K External Design
None	Exhibit L Infrastructure/Hardware
None	Exhibit N System Performance Plan for NPAC/SMS Services
None	Disaster Recovery
None	Back-up Plans
	Gateway Evaluation Process (Article 32 of Master Agreement)

9.MISCELLANEOUS

(a)Except as specifically modified and amended hereby, all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms.  From and after the Amendment Effective Date hereof, any reference in the Master

64

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the Amendment Effective Date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit, as modified and amended by this.  From and after the Amendment Effective Date, Amendment shall be a part of the Master Agreement, including its Exhibits, and, as such, shall be subject to the terms and conditions therein.  Each of the respective Master Agreements with respect to separate Service Areas remains an independent agreement regarding the rights and obligations of each of the Parties thereto with respect to such Service Area, and neither this Amendment nor any other instrument shall join or merge any Master Agreement with any other, except by the express written agreement of the Parties thereto.

(b)If any provision of this Amendment is held invalid or unenforceable the remaining provision of this Amendment shall become null and void and be of no further force or effect.  If by rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this Amendment or the Master Agreement, this Amendment is required to be rescinded or is declared ineffective or void in whole or in part, whether temporarily, permanently or ab initio (an “Ineffectiveness Determination”), immediately upon such Ineffectiveness Determination and without any requirement on any party to appeal, protest or otherwise seek clarification of such Ineffectiveness Determination, this Amendment shall be rescinded and of no further force or effect retroactively to the Amendment Effective Date.  Consequently, the Master Agreement in effect immediately prior to the Amendment Effective Date shall continue in full force and effect in accordance with its terms, unchanged or modified in any way by this Amendment.  In the event of an Ineffectiveness Determination, any amounts that would have otherwise been due and payable under the terms and conditions of the Master Agreement, in effect immediately prior to the Amendment Effective Date (including, but not limited to any adjustments necessary to retroactively re-price TN Porting Events under Schedule E from the Amendment Effective Date through the date of the Ineffectiveness Determination, or other amounts or credits, to any party hereunder), shall be invoiced by Contractor at the earliest practical billing cycle in accordance with the Master Agreement and shall be due and payable in accordance with the applicable invoice therewith or shall be credited or applied for the benefit of the Customer or any Allocated Payor in accordance with the Master Agreement.

(c)This Amendment may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed the same document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

(d)If at any time hereafter a Customer, other than a Customer that is a party hereto desires to become a party hereto, such Customer may become a party hereto by executing a joinder agreeing to be bound by the terms and conditions of this Amendment, as modified from time to time.

65

Amendment No.43-NPAM(NE) December 3,2003

Sow:       No

                _ Yes

(e)This Amendment is the joint work product of representatives of Customer and Contractor; accordingly, in the event of ambiguities, no inferences will be drawn against either party, including the party that drafted the Agreement in its final form.

(f)This Amendment sets forth the entire understanding between the Parties with regard to the subject matter hereof and supercedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.  The modifications, amendments and price concessions made herein were negotiated together and collectively, and each is made in consideration of all of the other terms herein.  All such modifications, amendments and price concessions are interrelated and are dependent on each other.  No separate, additional or different consideration is contemplated with respect to the modifications, amendments and price concessions herein.

[THIS SPACE INTENTIONALLY LEFT BLANK]

66

Amendment No.43-NAPM(NE) December 3,2003

Sow:       No

                _ Yes

IN WITNESS WHEREOF, the undersigned have executed this Amendment:

CONTRACTOR:   NeuStar, Inc.

By:

Its:

Date:

CUSTOMER:  North American Portability Management, LLC as successor in interest to and on behalf of Northeast Carrier Acquisition Company, LLC

By:

Its:

Date:

CUSTOMER:  North American Portability Management, LLC as successor in interest to and on behalf of Northeast Carrier Acquisition Company, LLC

By:

Its:

Date:

67

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

STATEMENT OF WORK

AMENDING PRICING SCHEDULES

UNDER

AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM

68

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

STATEMENT OF WORK

AMENDING PRICING SCHEDULES

UNDER

AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION
CENTER/SERVICE MANAGEMENT SYSTEM

4.PARTIES

This statement of work amendment (this “Statement of Work” or “SOW”) is entered into pursuant to Article 13 of, and upon execution shall be a part of, the Agreement for Number Portability Administration Center/Service Management System, as amended and in effect immediately prior to the SOW Effective Date (the “Master Agreement”), by and between NeuStar, Inc., a Delaware corporation (“Contractor”), and the North American Portability Management LLC, a Delaware limited liability company (the “Customer”), as the successor in interest to and on behalf of the respective limited liability companies listed below for the separate Service Areas (referred to individually as a “Subscribing Customer” and collectively as the “Subscribing Customers”):

•LNP, LLC (Midwest)

•Mid-Atlantic Carrier Acquisition Company, LLC

•Northeast Carrier Acquisition Company, LLC

•Southeast Number Portability Administration Company, LLC

•Southwest Region Portability Company, LLC

•West Coast Portability Services, LLC

•Western Region Telephone Number Portability, LLC

5.EFFECTIVENESS AND DEFINED TERMS

This Statement of Work shall be effective as of the 20^th day of February 2004 (the “SOW Effective Date”).  The number in the upper left-hand corner refers to this Statement of Work.  Capitalized terms used herein without definition or which do not specifically reference another agreement shall have the meanings as defined in the Master Agreement.

6.CONSIDERATION RECITAL

In consideration of the terms and conditions set forth in this Statement of Work, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, Contractor and Customer agree as set forth in this Statement of Work.

7.AMENDMENTS TO PRICING SCHEDULES

Effective on the SOW Effective Date, Exhibit E (Pricing Schedules) of the Master Agreement is hereby amended and restated in its entirety as set forth in Attachment 1 hereunder.  Such amendment and restatement shall include, among other changes reflected therein, the addition of

69

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

a charge for an Initial Ad Hoc Report, a Subsequent Ad Hoc Report, and Dedicated Technical Support.

8.IMPACTS ON MASTER AGREEMENT

This Statement of Work impacts the following portions of the Master Agreement:

None	Master Agreement
None	Exhibit B Functional Requirements Specification
None	Exhibit C Interoperable Interface Specification
	Exhibit E Pricing Schedules
None	Exhibit F Project Plan and Test Schedule
None	Exhibit G Service Level Requirements
None	Exhibit H Reporting and Monitoring Requirements
None	Exhibit J User Agreement Form
None	Exhibit K External Design
None	Exhibit L Infrastructure/Hardware
None	Exhibit N System Performance Plan for NPAC/SMS Services
None	Disaster Recovery
None	Back-up Plans
None	Gateway Evaluation Process (Article 32 of Master Agreement)

9.MISCELLANEOUS

(g)Except as specifically modified and amended hereby, all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms.  From and after the SOW Effective Date hereof, any reference in the Master Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the SOW Effective Date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit, as modified and amended by this.  From and after the SOW Effective Date, Amendment shall be a part of the Master Agreement, including its Exhibits, and, as such, shall be subject to the terms and conditions therein.  Each of the respective Master Agreements with respect to separate Service Areas remains an independent agreement regarding the rights and obligations of each of the Parties thereto with respect to such Service Area, and

70

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

neither this Statement of Work nor any other instrument shall join or merge any Master Agreement with any other, except by the express written agreement of the Parties thereto.

(h)If any provision of this Statement of Work is held invalid or unenforceable the remaining provision of this Statement of Work shall become null and void and be of no further force or effect.  If by rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this Statement of Work or the Master Agreement, this Statement of Work is required to be rescinded or is declared ineffective or void in whole or in part, whether temporarily, permanently or ab initio (an “Ineffectiveness Determination”), immediately upon such Ineffectiveness Determination and without any requirement on any party to appeal, protest or otherwise seek clarification of such Ineffectiveness Determination, this Statement of Work shall be rescinded and of no further force or effect retroactively to the SOW Effective Date.  Consequently, the Master Agreement in effect immediately prior to the SOW Effective Date shall continue in full force and effect in accordance with its terms, unchanged or modified in any way by this Statement of Work.  In the event of an Ineffectiveness Determination, any amounts that would have otherwise been due and payable under the terms and conditions of the Master Agreement, in effect immediately prior to the SOW Effective Date (including, but not limited to any adjustments necessary to retroactively re-price TN Porting Events under Schedule E from the SOW Effective Date through the date of the Ineffectiveness Determination, or other amounts or credits, to any party hereunder), shall be invoiced by Contractor at the earliest practical billing cycle in accordance with the Master Agreement and shall be due and payable in accordance with the applicable invoice therewith or shall be credited or applied for the benefit of the Customer or any Allocated Payor in accordance with the Master Agreement.

(i)This Statement of Work may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed the same document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

(j)If at any time hereafter a Customer, other than a Customer that is a party hereto desires to become a party hereto, such Customer may become a party hereto by executing a joinder agreeing to be bound by the terms and conditions of this Statement of Work, as modified from time to time.

(k)This Statement of Work is the joint work product of representatives of Customer and Contractor; accordingly, in the event of ambiguities, no inferences will be drawn against either party, including the party that drafted the Agreement in its final form.

(l)This Statement of Work sets forth the entire understanding between the Parties with regard to the subject matter hereof and supercedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.  The modifications, amendments and price concessions made herein were negotiated together and collectively, and each is made in consideration of all of the other terms herein.  All such modifications, amendments and price concessions are interrelated and are

71

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

dependent on each other.  No separate, additional or different consideration is contemplated with respect to the modifications, amendments and price concessions herein.

[THIS SPACE INTENTIONALLY LEFT BLANK]

72

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

IN WITNESS WHEREOF, the undersigned have executed this Statement of Work:

CONTRACTOR:   NeuStar, Inc.

By:

Its:

Date:

CUSTOMER:  North American Portability Management, LLC as successor in interest to and on behalf of Mid-Atlantic Carrier Acquisition Company, LLC

By:

Its:

Date:

CUSTOMER:  North American Portability Management, LLC as successor in interest to and on behalf of Mid-Atlantic Carrier Acquisition Company, LLC

By:

Its:

Date:

73

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

EXHIBIT E - PRICING SCHEDULES

The following schedules set forth the prices at which Contractor will be compensated for rendering the Services under the Agreement.  A general description of these charges and the methods of billing therefor are set forth in Section 6 of the Agreement.  See Agreement for other applicable charges.

Schedule 1

Service Element Fees/Unit Pricing

Category	Service Element	Unit	Price
[* * *]
	[* * *]	[* * *]	$	[* * *]
	[* * *](1)	[* * *]	$	[* * *]
	[* * *](2)	[* * *]	$	[* * *]
	[* * *]	[* * *]	$	[* * *]
	[* * *]	[* * *]	$	[* * *]
[* * *]
	[* * *](3)	[* * *]	$	[* * *]
	[* * *](3)	[* * *]	$		- [* * *]
			$		- [* * *]

(1)  Monthly port charges [* * *] The specific cost elements include

(2)  See Note 1 above. 

(3)  [* * *]

74

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

Category	Service Element	Unit	Price
	[* * *](4)	[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
			$[* * *]
	[* * *](5)	[* * *]	$[* * *]
	[* * *](6)	[* * *]	$[* * *]
	[* * *]	[* * *]	$[* * *]
	[* * *](7)	[* * *]	$[* * *]
	[* * *]	[* * *]	[* * *]
	[* * *]	[* * *]	[* * *]

(4) [* * *]

(5) [* * *]

(6) [* * *]

(7) [* * *]

75

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

	[* * *]	[* * *]	$[* * *]
	[* * *](8)	[* * *]	$[* * *]
[* * *]
	[* * *](9)	[* * *]	$[* * *]
	[* * *](10)	[* * *]	$[* * *]

Billable NPAC User Support Manual Request Table

Category	Description of Request
Create SV	New SP asks Help Desk to issue new SP Create, for single TN or range of TNs
Create SV	Old SP asks Help Desk to issue old SP Create, for single TN or range of TNs
Prevent SV Activation	Old SP asks Help Desk to change concur flag to “false” on pending SV (or SVs, for range of TNs)
Activate SV	New SP asks Help Desk to activate a pending SV for a single TN (or SVs, for a range of TNs)
Remove Prevention of SV Activation	Old SP (or New SP, after due date or t2 timer’s expiration) asks Help Desk to change concur flag to “true” on pending SV (or SVs, for range of TNs)
Modify Pending SV	New SP asks Help Desk to modify single SV (or SVs, for a range of TNs)
Disconnect TN	Current SP asks Help Desk to issue disconnect for TN (or range of TNs)
Cancel Pending SV	Old SP or New SP asks Help Desk to issue its cancel for pending SV (or SVs, for range of TNs)
Look Up SV	SP asks Help Desk to look up active SV for a TN (or SVs for range of TNs)
Modify Active SV	Current SP asks Help Desk to modify single active SV
Audit SV	SP asks Help Desk to issue audit request for a TN, or range of TNs, with SV(s) in active state
Look Up Network Data	SP asks Help Desk to look up NPA-NXX, NPA-NXX ID, LRN, or LRN ID to determine associated SPID and/or ID
Change Network Data	SP asks Help Desk to add to or to delete from the NPAC’s network data an NPA-NXX(s) or LRN(s). Requests to delete these data can be accommodated only if the SP making the request is the SP that originally entered the data. This limitation does not apply in the case where the SP asks Help Desk to delete an NPA-NXX (but not an LRN) where the NPA is not associated with the NPAC Service Area in which the NPA-NXX is open.
Change GUI Password	SP asks Help Desk to change its GUI Password
Re-enter GUI Logon	SP asks Help Desk to re-enter its GUI Logon which SP has allowed to expire

(8) [* * *]

(9) The one-time Log-on ID [ * * *]

(10) The Mechanized interface [* * *]

76

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

Schedule 2

Training Charges

Service Element		Unit	Cost Per Participant
[* * *]	(11)	[* * *]	$	[* * *]
			$	[* * *]
			$	[* * *]
[* * *]	(12) (13)	[* * *]	$	[* * *]
			$	[* * *]
			$	[* * *]

Schedule 3

Interoperability Testing

Category & Service Element	Unit	Price
[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]
[* * *]	[* * *]	$	[* * *]
[* * *]	[* * *]	$	[* * *]

(11) [* * *]

(12) [* * *]

(13) [* * *]

77

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

Schedule 4

Schedule of Representative Hourly Labor Charges

Applicable to Statements of Work

For Contract Years 1 Through End

Labor Category	Year 1		Year 2		Year 3		Year 4		Year 5*
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]	$	[* * *]

* Amounts after Year 5 for each Labor Category shall be increased by 5% annually from the prior year.

Schedule 5

Schedule of Target Amounts

Target Options

Monthly Targets for Nov/Dec 1997 (2)

Monthly Targets for 1Q 1998 (2)

Monthly Targets for 2Q 1998 through 4Q 2001 (2)

Monthly Targets for 1Q 2002 through 2Q 2002 (2)

Monthly Target for July 2002

Total Contract Targets

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

$

[* * *]

Notes:

(1)The target schedule depends on the service term selected by the Customer.  If the service term begins on 10/1/97, then Option A applies.  Likewise, if the service term begins on 1/1/98, then Option B applies.

(2)The targets are listed in monthly amounts for each of the respective calendar periods outlined above.  The targets are calculated and applied on a monthly basis as described in Section 6.6 of the Agreement.

Schedule 6

Sample Annual Target and Allocable Target Shortfall/Credit Calculation

The following is an example of how Allocable Target Shortfalls and Allocable Targets are determined in connection with the Quarterly Targets.  A description of the methodology (including defined terms used below) is set forth in Section 6.6 of the Agreement.

78

Amendment No.47-NAPM(NE) February 20, 2004

Sow:       No

                _ Yes

	Jan-98		Feb-98		Mar-98
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	[* * *]		$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]*	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]*	$	[* * *]	$	[* * *]	$	[* * *]
[* * *]	$	[* * *]	$	[* * *]	$	[* * *]

* [* * *]

79

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

AMENDMENT

OF

AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM

FOR

INTERMODAL PORTED TELEPHONE NUMBER IDENTIFICATION SERVICE

80

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

AMENDMENT

OF

AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION
CENTER/SERVICE MANAGEMENT SYSTEM

FOR

INTERMODAL PORTED TELEPHONE NUMBER IDENTIFICATION SERVICE

1.PARTIES

This amendment (this “Amendment”) is entered into pursuant to Article 30 of, and upon execution shall be a part of, the Agreement for Number Portability Administration Center/Service Management System, as amended and in effect immediately prior to the Amendment Effective Date (the “Master Agreement”), by and between NeuStar, Inc., a Delaware corporation (“Contractor”), and the North American Portability Management LLC, a Delaware limited liability company (the “Customer”), as the successor in interest to and on behalf of Northeast Carrier Acquisition Company, LLC ( the “Subscribing Customer”).

2.EFFECTIVENESS AND DEFINED TERMS

This Amendment shall be effective as of the 2^nd day of April, 2004 (the “Amendment Effective Date”), conditioned upon execution by Contractor and Customer of this Amendment and six other separate amendments, in substantially the form of this Amendment, applicable to the other six (6) Service Areas for the United States (collectively, the “United States Service Areas”), whereby the Customer is the successor in interest to and acting on behalf of each of the respective other six Subscribing Customers named in each such amendment.

The number in the upper left-hand corner refers to this Amendment.  Capitalized terms used herein without definition or which do not specifically reference another agreement shall have the meanings as defined in the Master Agreement.

3.CONSIDERATION RECITAL

In consideration of the terms and conditions set forth in this Amendment, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, Contractor and Customer agree as set forth in this Amendment.

4.REASON FOR THIS AMENDMENT

4.1Requests for User Data. The United States Federal Communications Commission (the “FCC”) has by order implementing the Telephone Consumer Protection Act of 1991 (the “TCPA”) adopted rules, including those set forth in 47 C.F.R. Sec. 64.1200, (together with the TCPA, the “TCPA Rules”), prohibiting the initiation of telephone calls (other than a call made for emergency purposes or made with the prior express consent of the called party) using automatic telephone dialing systems or an artificial or prerecorded voice to telephone numbers assigned to a paging service, cellular telephone service, specialized mobile radio service, or other radio common carrier service, or any service for which the called party is charged for the call (referred to herein as “TCPA Prohibited Conduct”).  As a result, for the purpose of avoiding

81

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

engaging in TCPA Prohibited Conduct, various parties have requested that Contractor provide portions of User Data to them.

4.2Limitations on Disclosure and Use of Confidential Information and User Data.  Both the Master Contract and the User Agreement restrict the disclosure and use of User Data.  User Data is provided to Contractor by respective Users pursuant to the terms and conditions of the User Agreement.  Pursuant to Section 6.1(k) of the User Agreement, Contractor expressly accepts the obligation to maintain the confidentiality of User Data as provided in Article 15 of the Master Agreement. Further, Section 7.6 of the User Agreement expressly prohibits Users from engaging in specific enumerated conduct with respect to the User Data of other Users.  Accordingly, questions have arisen with respect to the allowability under the Master Agreement and the User Agreement of providing any portions of User Data to parties requesting it for the purpose of avoiding engaging in TCPA Prohibited Conduct.

5.CLARIFICATION OF OPERATION OF MASTER AGREEMENT AND USER AGREEMENT

After careful consideration, Customer and Contractor desire to amend the Master Agreement by this Amendment to clarify the operation of the Master Agreement and the User Agreement with respect solely to requests for specified portions of User Data to be used by such requesting parties to avoid engaging in TCPA Prohibited Conduct.  Accordingly, the Master Agreement is hereby amended as of the Amendment Effective Date by the addition of new Section 15.7 to follow immediately after existing Section 15.6, such new Section 15.7 to read in its entirety as follows:

15.7Intermodal Ported TN ID Services

(a)Scope.  Notwithstanding the foregoing provisions of this Article 15, Contractor is authorized in accordance with this Section 15.7 to provide certain User Data elements to any entity making a request to Contractor in writing and who satisfies the requirements and conditions set forth in this Section 15.7 (referred to herein as a “Qualified Limited User Data Recipient”).  The provision of such User Data elements to Qualified Limited User Data Recipients pursuant to the requirements and conditions of this Section 15.7 shall be referred to as the “Intermodal Ported Telephone Number Identification Service,” or “Intermodal Ported TN ID Service,” for short.  The Intermodal Ported TN ID Service contemplated hereunder is neither Services, Additional Services nor an Enhancement, as those terms are defined in this Agreement.  Accordingly, and for all purposes of this Agreement, the Intermodal Ported TN ID Service shall not (1) be considered in the definition of or to constitute Services, NPAC/SMS services, or Additional Services under this Agreement or to constitute access or use of Services, NPAC/SMS services or Additional Services under this Agreement, (2) be subject to the requirements and provisions of

82

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

Article 13 of this Agreement, (3) be considered in the definition of or to constitute a User Enhancement or a Custom Enhancement under this Agreement.  It is the intention of the Customer and the Contractor that the Intermodal Ported TN ID Service is allowable under this Agreement and the User Agreement in furtherance of law, rule, regulation or order of the Federal Communications Commission or other regulatory agencies having jurisdiction over the NPAC/SMS Service.

(b)Intermodal Ported TN ID Service Agreement.  The Intermodal Ported TN ID Service shall only be provided to Qualified Limited User Data Recipients, as determined in accordance with this Section 15.7, after execution and delivery of an agreement satisfying the requirements set forth in Section 15.7(f), in substantially the form of Exhibit O attached hereto and made a part hereof, and as it may be amended from time to time in accordance with or permitted by this Section 15.7 (the “Intermodal Ported TN ID Service Agreement”).  Contractor shall have the right to amend or to change any provision of the Intermodal Ported TN ID Service Agreement which is not required under Section 15.7(f) and which is not otherwise in violation or breach of this Agreement, including this Section 15.7; provided, however that Contractor shall provide Customer with at least thirty (30) days advance written notice of any such allowable change or revision to the Intermodal Ported TN ID Service Agreement; and provided, further, that changes or amendments to those provisions in the Intermodal Ported TN ID Service Agreement which are required under Section 15.7(f)  may be made and shall only be effective upon the advance written agreement of Customer and the Contractor. In consideration for providing the Intermodal Ported TN ID Service in accordance with the Intermodal Ported TN ID Service Agreement and this Section 15.7, Contractor shall be compensated directly and exclusively from each respective Qualified Limited User Data Recipient in accordance with Section 15.7(i).  Customer shall not unreasonably withhold consent to Customer requests for the use of alternative versions of the Intermodal Ported TN ID Service Agreement for differently situated Qualified Limited User Data Recipients, so long as those agreements otherwise comply with the requirements of this Section 15.7.

(c)Relationship to User Agreements.  Nothing in this Section 15.7 shall supersede the rights of any User under a User Agreement with respect to that User’s User Data and other User’s User Data, and nothing in this Section 15.7 shall alter or otherwise change the acknowledgment and agreement under Section 7.8 of the User Agreement and Section 15.1 of this Agreement that all User Data shall remain the property of the User furnishing it to Contractor.  Accordingly, Customer and Contractor hereby agree and acknowledge that a User (and User’s properly authorized agents,

83

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

attorneys, and legal representatives) may obtain and use User Data pursuant to the terms of the User Agreement for the purpose of ensuring that such User does not itself engage in TCPA Prohibited Conduct (as defined below in Section 15.7(f)(2)) without being subject to this Section 15.7 or being required to enter into an the Intermodal Ported TN ID Service Agreement and at no additional charge other than as provided in the User Agreement.  In addition, Customer and Contractor further hereby agree and acknowledge that a User may obtain and disclose or otherwise make available to a Third Party that is an “Affiliate” of the User (referred to as an “Affiliated Third Party”) User Data for the purpose of ensuring that such Affiliated Third Party does not itself engage in TCPA Prohibited Conduct (as defined below in Section 15.7(f)(2)), without being subject to this Section 15.7 or being required to enter into an Intermodal Ported TN ID Service Agreement and at no additional charge; provided, however, that the obtaining, disclosure and otherwise making available of such User Data by a User to an Affiliate Third Party shall not be considered in violation of Section 7.6 of the User Agreement and shall be considered in satisfaction of Article 9 of the User Agreement, only so long as such User certifies to Contractor that such Affiliated Third Party is an Affiliate of the User and such Affiliated Third Party executes a confidentiality agreement directly with Contractor, as set forth in Section 15.6 of this Agreement, which confidentiality agreement shall include the substantive restrictions set forth in this Article 15 and shall otherwise be in a form reasonably satisfactory to Contractor and Customer.  For purposes of the foregoing sentence, an “Affiliate” of a User is any entity, directly or indirectly, through one or more intermediaries, controlling, controlled by or under common control with the respective User, and the term “control” for purposes of determining an “Affiliate” shall mean either the right to exercise, directly or indirectly, more than ten percent (10%) of the voting rights attributable to the controlled entity or the ownership, directly or indirectly, of more than ten percent (10%) of the total interest in the profits or losses of the controlled entity.

(d)Relationship to NPAC/SMS Services.  The Contractor and the Customer expressly agree and acknowledge that the Intermodal Ported TN ID Service shall only be offered so long as it does not adversely affect the operation and performance of the NPAC/SMS and the delivery of Services pursuant to this Agreement, and accordingly, the provision of Services under the terms and conditions of this Agreement other than this Section 15.7 shall take priority to the provision of the Intermodal Ported TN ID Service.  Further, in addition to causes for termination of this Agreement and the User Agreement set forth in this Agreement and the User Agreement, the provision of the Intermodal Ported TN ID Service and all Intermodal Ported TN ID Service Agreements may be terminated upon the

84

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

occurrence of those events set forth in Section 15.7(l). If Contractor establishes an Intermodal Ported TN ID Service help desk, the telephone number for such help desk shall be different than any current telephone number for a NPAC/SMS help desk and such costs not be included in any charges with respect to the Services.

(e)Inapplicability of Service Levels, GEP Elements and Benchmarking Process.  Contractor and Customer expressly agree and acknowledge that Contractor’s provision of the Intermodal Ported TN ID Service hereunder shall not be subject to any separate Service Level Requirements under Article 8 of this Agreement and Exhibit G, to any Benchmarking Process under Article 7 of this Agreement, or to the Gateway Evaluation Process under Article 32 of this Agreement, and thus no separate Service Levels, GEP Elements or Benchmarking Process are hereby established with respect to the provision of the Intermodal Ported TN ID Services .  Notwithstanding the foregoing, the effect and consequences on the Services from the provision of the Intermodal Ported TN ID Service shall be included in evaluating the obligations of Contractor with respect to the Service Levels under Article 8 and the GEP Elements under Article 32, including but not limited to all the remedies and recourses resulting from Contractor’s failure or noncompliance under this Agreement and the User Agreement.

(f)Required Provisions of Intermodal Ported TN ID Service Agreement.  Each Intermodal Ported TN ID Service Agreement shall be only between the Contractor and the Qualified Limited User Data Recipient and, in addition to containing provisions customary in commercial contracts of this nature, must contain provisions specifying the following:

(i)User Data Elements Provided. Contractor shall make available, by whatever manner and format Contractor considers commercially feasible, and not more frequently than daily, two (2) files consisting of lists of intermodal ports of TNs since November 24, 2003, segregated between wireline to wireless ports and wireless to wireline ports (“Intermodal Ports”) for each of the of the 7 Service Areas, on a password secure Web/FTP site for downloading by the Qualified Limited User Data Recipient.  The data elements of such Intermodal Ports shall consist exclusively of TNs, and no other User Data elements.  Contractor shall not provide the Qualified Limited User Data Recipient direct access to the NPAC or any other User Data elements.

(ii)Specified Exclusive Use. The United States Federal Communications Commission (the “FCC”) has by order

85

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

implementing the Telephone Consumer Protection Act of 1991 (the “TCPA”) adopted rules, including those set forth in 47 C.F.R. Sec. 64.1200, (together with the TCPA, the “TCPA Rules”), prohibiting the initiation of telephone calls (other than a call made for emergency purposes or made with the prior express consent of the called party) using automatic telephone dialing systems or an artificial or prerecorded voice to telephone numbers assigned to a paging service, cellular telephone service, specialized mobile radio service, or other radio common carrier service, or any service for which the called party is charged for the call (referred to herein as “TCPA Prohibited Conduct”).  Accordingly, the Intermodal Ports shall be considered Confidential Information and shall only be provided to a Qualified Limited User Data Recipient for the sole purposes of either (A) permitting that Qualified Limited User Data Recipient to avoid engaging in TCPA Prohibited Conduct by verifying whether TNs are assigned to a paging service, cellular telephone service, specialized mobile radio service, or other radio common carrier service, or any service for which the called party is charged for the call or (B) allowing that Qualified Limited User Data Recipient to disclose, sell, assign, lease or otherwise provide to any other party (referred to as a “Second Tier Limited User Data Recipient”) to permit such a Second Tier Limited User Data Recipient to avoid engaging in TCPA Prohibited Conduct by verifying whether TNs are assigned to a paging service, cellular telephone service, specialized mobile radio service, or other radio common carrier service, or any service for which the called party is charged for the call.  Other than the foregoing, the Qualified Limited User Data Recipient and the Second Tier Limited User Data Recipient shall be absolutely prohibited, subject to damages and injunctive relief, from (a) disclosing, selling, assigning, leasing or otherwise providing to any other party the Intermodal Ports, including to a local service management system or other party or public database, or (b) commercially exploiting the Intermodal Ports in any way, including by way of example and not limitation, for resale or marketing purposes.

(iii)Compliance with Laws.  The Qualified Limited User Data Recipient shall be required to comply with all applicable laws, orders and regulations applicable, including those applicable to the NPAC/SMS, including User Data.

(iv)Acknowledgment of Non-liability of Customer and Users.  Both Contractor and the Qualified Limited User Data Recipient shall agree and expressly acknowledge the rights of termination under

86

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

this Agreement, including by reason of Section 15.7(l), the absolute exclusions from liability with respect to Customer and the exclusion from liability with respect to Users and End-Users for any amounts that would have otherwise been due and payable by such Qualified Limited User Data Recipient under the terms and conditions of the Intermodal Ported TN ID Service Agreements or as a result of the provision the Intermodal Ported TN ID Service upon the termination of the provision the Intermodal Ported TN ID Service (the “Unpaid Intermodal Charges”) without an explicit rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this Agreement directing the responsibility and liability for payment of those Unpaid Intermodal Charges by Users or End Users.

(v)Other Termination. Both Contractor and the Qualified Limited User Data Recipient shall agree and expressly acknowledge that, in addition to the rights of termination under this Agreement, including by reason of Section 15.7(l), the Intermodal Ported TN ID Service Agreement may be terminated by either Contractor or the Qualified Limited User Data Recipient with sixty (60) days advance written notice for any reason or for no reason at all, but that the restrictions with respect to User Data and Intermodal Ports shall survive such termination.

(vi)Liability, Indemnification and Dispute Resolution.  The Intermodal Ported TN ID Service Agreement shall contain liability, indemnification and dispute resolution terms and conditions customary in the industry for like services.

(vii)Compensation. Subject to Section 15.7(i) of this Agreement, Contractor may charge compensation and the Qualified Limited User Data Recipient shall agree to pay such compensation for the provision of the Intermodal Ported TN ID Service.

(viii)Continuing Qualification.  The Qualified Limited User Data Recipient agrees to the continuing qualification process set forth in Section 15.7(h)(iii).

(g)Remain User Data.  The Intermodal Ports, being provided as part of the Intermodal Ported TN ID Service, being User Data, shall remain User Data and Confidential Information.

87

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

(h)Qualification and Continuing Qualification Process.  Contractor shall not provide Intermodal Ported TN ID Service to any party, whether a User or otherwise, unless pursuant to this Section 15.7(h) such party qualifies, and continues to qualify during the time such Intermodal Ported TN ID Service is provided to such party, as a Qualified Limited User Data Recipient, and such party enters into and executes the Intermodal Ported TN ID Service Agreement.

(i)Application.  Any party requesting the Intermodal Ported TN ID Service shall be required to complete an application.  Such an application will require the applying party to identify the User Data which it is requesting, the intended use of the Intermodal Ports to be received through the Intermodal Ported TN ID Service and any all Second Tier Limited User Data Recipients to whom such party intends to disclose, sell, assign, lease or otherwise provide the requested User Data.

(ii)Evaluation of Qualification. Based upon this application, Contractor shall determine, based upon a good-faith, reasonable interpretation of the information provided by such applicant, (A) whether the User Data requested constitutes solely Intermodal Ports, AND (B) whether the intended use of the requested User Data is for the sole purposes of either (I) permitting that applicant as a Qualified Limited User Data Recipient to avoid engaging in TCPA Prohibited Conduct by verifying whether TNs are assigned to a paging service, cellular telephone service, specialized mobile radio service, or other radio common carrier service, or any service for which the called party is charged for the call or (II) allowing that applicant as a Qualified Limited User Data Recipient to disclose, sell, assign, lease or otherwise provide to another third party who qualify as Second Tier Limited User Data Recipients who shall use the User Data only to avoid engaging in TCPA Prohibited Conduct by verifying whether TNs are assigned to a paging service, cellular telephone service, specialized mobile radio service, or other radio common carrier service, or any service for which the called party is charged for the call.  If Contractor is able to make both determinations set forth in clauses (A) and (B) of the preceding sentence AND PROVIDED FURTHER THAT the applicant is otherwise not already a Second Tier Limited User Data Recipient AND no Second Tier Limited User Data Recipient identified in such applicant application is already itself a Qualified Limited User Data Recipient, then upon execution by both Contractor and the applicant of the Intermodal Ported TN ID Service Agreement, such applicant shall be considered a Qualified

88

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

Limited User Data Recipient.  Contractor shall have no duty to investigate the accuracy of any information provided by an applicant on such application.  If Contractor is unsure whether a party qualifies as a Qualified Limited User Data Recipient, Contractor shall refer such application to Customer for its decision before entering into an the Intermodal Ported TN ID Service Agreement with such party, which shall be binding.

(iii)Continued Qualification Process. Contractor shall require each Qualified Limited User Data Recipient on the anniversary date of its execution of the Intermodal Ported TN ID Service Agreement to certify to Contractor the following:  (A) that it is in full compliance with the terms and conditions of the Intermodal Ported TN ID Service Agreement, (B) that it intends in the upcoming year to continue to comply with the terms and conditions of the Intermodal Ported TN ID Service Agreement and (C) if it is providing Intermodal Ports to Second Tier Limited User Data Recipients, that (I) all such Second Tier Limited User Data Recipients have agreed to use the User Data only to avoid engaging in TCPA Prohibited Conduct by verifying whether TNs are assigned to a paging service, cellular telephone service, specialized mobile radio service, or other radio common carrier service, or any service for which the called party is charged for the call and (II) either the identity of those Second Tier Limited User Data Recipients has not changed since the later of the original execution of the Intermodal Ported TN ID Service Agreement or the last preceding certification or listing the additions and deletions to that list of Second Tier Limited User Data Recipients. If a Qualified Limited User Data Recipient fails to deliver such certification on such date to Contractor, or if Contractor determines, by reason of the certification or otherwise, that such party no longer qualifies as a Qualified Limited User Data Recipient, or if such party breaches any of the obligations of the Intermodal Ported TN ID Service Agreement, then Contractor shall notify Customer and shall take appropriate action, including, without limitation, immediately discontinuing the delivery of Intermodal Ports to such parity, terminating the Intermodal Ported TN ID Service Agreement and seeking appropriate damages and remedies thereunder.

(iv)Quarterly Reports.  At no additional charge, Contractor shall provide to Customer a quarterly report listing all applicants for the Intermodal Ported TN ID Service during the preceding quarter, and all current Qualified Limited User Data Recipients and Second Tier Limited User Data Recipients, which report shall set

89

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

forth in a separate section all new Qualified Limited User Data Recipients and Second Tier Limited User Data Recipients since the last report.

(i)Compensation.

(i)Basis for Compensation.  Contractor shall not be entitled to compensation of any kind under this Section 15.7 from Customer, Subscribing Customer, Users or End-Users, and shall look solely to the respective Qualified Limited User Data Recipients for any and all compensation for the provision of the Intermodal Ported TN ID Service (referred to as the “Intermodal Charges”).  Customer and Contractor agree and acknowledge that the Intermodal Ported TN ID Service is not necessary for the provision of number portability.  Contractor agrees to compute and to allocate the compensation for the provision of Intermodal Ported TN ID Service in a fair and non-discriminatory manner consistent with the rules, regulations, orders, opinions and decisions of the Federal Communications Commission and other regulatory body having jurisdiction or delegated authority with respect to the NPAC/SMS or this Agreement.

(ii)Cost Plus the Fee.  Subject to Section 15.7(i)(i) above and Section 15.7(i)(iv) below, the aggregate amount of Intermodal Charges received by Customer under this Section 15.7(i) since the inception of the Intermodal Ported TN Identification Service and during the Initial Term shall equal not more than the Cost plus the Fee, as more particularly described herein below.

(A)Costs. “Costs” means those costs that have been incurred or will be incurred by Contractor as a result of providing the Intermodal Ported TN ID Service and which have not been recovered by Contractor by way of payment of compensation under this Section 15.7 or otherwise, which Costs shall include the Direct Costs, Engineering Overhead Costs, and Administrative Overhead Costs, which are defined as follows.

“Direct Costs” costs are those direct costs incurred commencing January 1, 2004 or which will be incurred by Contractor, or by a subcontractor or vendor at the direction

90

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

of the Contractor, attributable to the Intermodal Ported TN ID Service, including activities related to, but not limited to, start-up costs, design, coding and unit testing, system integration testing, regression testing, program management, quality assurance, configuration control and documentation management.  Direct Costs shall also include, without limitation, to labor, employee benefits, incentive payments, bonus, travel, meals, the costs of any audit under Section 15.7(j) below, and associated incremental maintenance and operating expenses thereof, and other direct or allocable direct charges, but excluding any Performance Credits and GEP Price Reductions.  Support for Direct Costs will include Contractor’s timesheets and/or specific invoices from subcontracts or vendors in support of the associated work.

“Engineering Overhead Costs” are those costs associated with support activities provided by engineering, software development and information technology/systems personnel that are not captured as Direct Costs.  Engineering Overhead Costs shall be derived by first calculating an overhead rate (the “Engineering Overhead Rate”) based on Contractor’s overall ratio of direct and indirect activities within engineering, software development and information technology/systems departments. The Engineering Overhead Rate will be then be applied to Direct Costs as a markup to establish Engineering Overhead Costs.

“Administrative Overhead Costs” are those general administrative costs associated with any applicable work that are not captured as Direct Costs or as part of the Engineering Overhead Costs.  Administrative Overhead Costs shall be derived by first calculating an overhead rate (the “Administrative Overhead Rate”) based on Contractor’s overall ratio of direct engineering, software development and information technology/systems costs and the indirect costs of support functions provided by, but not limited to, the procurement, finance, human resources, facilities, and legal departments.  The Administrative Overhead Rate will then be applied to Direct Costs as a markup to establish the Administrative Overhead Costs.

91

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

(B)Fee. “Fee” is the amount that equals [* * *]percent ([* * *]%) of the sum of Direct Costs, Engineering Overhead Costs and Administrative Overhead Costs.

(iii)Allocation.  In establishing the Intermodal Charges payable by Qualified Limited User Data Recipients, Contractor shall allocate the Cost plus Fee among Qualified Limited User Data Recipients in any manner that is fair and reasonable, which for the purposes of this Section 15.7(i) shall mean usage based, equitably, customary for similar services, commercially reasonable, and which does not discriminate against similarly situated Qualified Limited User Data Recipients.  Notwithstanding the foregoing, Contractor and Customer expressly agree and acknowledge that the manner of allocating the Cost plus Fee shall be solely the responsibility of the Contractor, and that Customer assume no responsibility or control with respect to such manner nor does Customer in any way endorse the manner selected by Contractor; subject, however, to the right of the Customer to seek guidance or direction from the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this Agreement.  Further, no amounts of any Intermodal Charges which, for whatever reason are not recovered by Contractor or allocated and paid for by Qualified Limited User Data Recipients, including by way of inclusion in any cost or overhead computations related to Services under the Master Agreements, any Statements of Work or otherwise, shall be charged or allocated to or assessed and paid by Customer, any Subscribing Customer, any User or any End-User.

(iv)Cost Review.  Within ninety (90) days after the end of each calendar year, Contractor will cause its regular independent auditor (“Contractor’s Auditor”) to commence a review of the accuracy and validity of the Costs and related calculations under Section 15.7(ii) (the “Intermodal Cost Review”).  Within sixty (60) days after commencing the Intermodal Cost Review, Contractor’s Auditor shall issue a sufficiently detailed report (“Intermodal Cost Report”) to the Contractor validating the Costs incurred and the Fee applied.  Contractor shall make available to Contractor’s Auditor such documentation necessary to conduct the Intermodal Cost Review and issue the Intermodal Cost Report, including the following: general ledger reports of Intermodal Ported TN Identification Service activity, accounts payable vouchers, invoices, and documents supporting purchases in support of the Intermodal Ported TN Identification Service activity, and other

92

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

financial records used to support general ledger activity related to the Intermodal Ported TN Identification Service and any other records reasonably requested by Contractor’s Auditor (collectively, the “Intermodal Review Documents”).

Contractor shall present Customer with the Intermodal Price Report within thirty (30) days after Contractor’s receipt of the Intermodal Price Report.  Upon Customer’s receipt of the Intermodal Price Report, Customer shall have forty-five (45) days to review the Intermodal Price Report and, at Subscribing Customer’s sole cost and expense, do either of the following (i) meet with Contractor’s Auditor to review and explain the Intermodal Price Report, or (ii) inform Contractor in writing that Customer shall employ a separate auditor (“Customer’s Auditor”) to conduct a separate review of the accuracy and validity of the Costs incurred under this Section 15.7.  Customer’s Auditor will be given reasonable access to the Intermodal Review Documents.  Customer’s Auditor shall complete such separate review within ninety (90) days of receipt of the Intermodal Price Report.  Before access is given to Customer’s Auditor, Customer’s Auditor will have to execute a non-disclosure agreement with Contractor to prevent the disclosure of Contractor proprietary or confidential information or other information not relevant to verifying the accuracy and validity of the Costs incurred by the Contractor under this Section 15.7.

If it is determined by Contractor’s Auditor or Customer’s Auditor that the compensation Contractor has received since the inception of the Intermodal Ported TN Identification Service under this Section 15.7 exceeds Cost plus the Fee, Contractor shall propose to Contractor’s Auditor and Customer’s Auditor, if any, its plan, which may include, but is not limited to, at Contractor’s discretion, changes to the Intermodal Charges under Section 15.7(i)(i) and and/or the allocations under Section 15.7(i)(iii), such that its continuing aggregate compensation does not exceed Cost plus the Fee in accordance with Section 15.7(i)(ii).  Contractor’s Auditor and Customer’s Auditor, if any, shall review for reasonableness and adequacy Contractor’s proposal and supplement, as necessary, the Intermodal Cost Report.  In no event shall Contractor be deemed in violation of Section 15.7(i)(ii) merely because the amount of Intermodal Charges received by Customer under this Section 15.7(i) since the inception of the Intermodal Ported TN Identification Service and during the Initial Term exceeds Cost plus the Fee; provided, however, that Contractor’s Auditor and

93

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

 Customer’s Auditor, if any, concludes that Contractor’s proposal under this paragraph for limiting its aggregate compensation such that it does not exceed the limit set forth in Section 15.7(i)(ii) is reasonable and adequate.

If Customer’s Auditor determines that the amount of Intermodal Charges received by Customer under this Section 15.7(i) since the inception of the Intermodal Ported TN Identification Service and during the Initial Term exceeds Cost plus the Fee by more than seven and one half percent (7.5%), Contractor shall reimburse Customer for the reasonable costs of such review by the Customer’s Auditor; provided however that such reimbursement for Customer collectively shall not exceed One Hundred Thousand US Dollars (US $100,000).

(j)Audit of Section 15.7 Performance. Subject to Section 15.7(e), Contractor shall annually engage the GEP Auditor separately to audit Contractor’s compliance with this Section 15.7 (referred to as the “Intermodal Services Audit”), including the maintenance of the certifications and issuance of the reports set forth in Section 15.7(h) and the computation of the Intermodal Services Charge under Section 15.7(i).  The costs and expenses of the Intermodal Services Audit shall be charged and accounted for separately from the costs and expenses of the GEP Audit and shall be properly included in “Direct Costs” under Section 15.7(i).  A report from the GEP Auditor regarding the results of the Intermodal Services Audit (“Intermodal Services Audit Report”) shall be provided to the Customer and the Contractor for informational purposes only in the same manner that the GEP Audit Report is provided under Section 34.4(e), and such Intermodal Services Audit Report shall be so provided within thirty (30) days after its completion, subject to any review and consideration of a draft of the Intermodal Services Audit Report Draft.  If the GEP Auditor is unable alone to determine the methodology and procedures for the Intermodal Services Audit, such Auditor shall determine the methodology and procedures in consultation with the Customer and the Contractor, and the GEP Auditor shall included in such Intermodal Services Audit Report both findings and recommendations to correct and identified deficiencies or failures to comply with the provisions of this Section 15.7.  Notwithstanding the foregoing, the Customer and the Contractor agree and acknowledge that neither the Intermodal Services Audit nor this Section 15.7 is intended to result in the imposition of any damages, Performance Credits, TN Porting Price Reductions, subject to Section 15.7(d) above regarding the effect and consequences on the Services from the provision of the Intermodal Ported TN ID Service and the causes for termination of the provision of the

94

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

Intermodal Ported TN ID Service and all Intermodal Ported TN ID Service Agreements set forth in Section 15.7(l) below.

(k)Neutrality Reviews.  In addition to the Intermodal Services Audit, and further subject to Section 15.7(e), the Intermodal Ported TN ID Service shall be included in the Neutrality Review provided for in the Assignment Agreement (Contractor Services Agreement),dated November 30, 1999, by and among Contractor, Lockheed Martin IMS and the Customer (the “Assignment Agreement).  If it is determined under and as part of a Neutrality Review that Contractor’s provision of the Intermodal Ported TN ID Service in any way resulted in the violation of a neutrality requirement set forth in the Master Agreement, the User Agreement, the Assignment Agreement, or any applicable rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this Amendment or the Master Agreement.  Contractor shall attempt to correct such violation within thirty (30) days following the date of the issuance of the Neutrality Review; provided, however, that where such failure cannot reasonably be cured within such thirty (30) day period, so long as Contractor is diligently pursuing such cure, and regulatory authorities having jurisdiction over such matters (after having reviewed the details of the event(s) causing Contractor’s failure) have not specifically required Customer to terminate the Intermodal Ported TN ID Service and terminate all Intermodal Ported TN ID Service Agreements, the time for curing such failure shall be extended for such period as may be necessary for Contractor to complete such cure.  Notwithstanding the foregoing, the Customer may, at its election but without duty or obligation, and without risk of costs or damages recoverable from Contractor for Customer’s election, seek the guidance and direction of such regulatory authorities if such failure has not been cured with ninety (90) days following the date of the issuance of the Neutrality Review and the Intermodal Ported TN ID Service and all Intermodal Ported TN ID Service Agreements have not been terminated.  The costs and expenses of including the Intermodal Ported TN ID Service in the Neutrality Review shall be charged and accounted for separately from the costs and expenses of the Neutrality Review and shall be properly included in “Direct Costs” under Section 15.7(i).

(l)Additional Causes for Termination.  In addition to the causes for termination of this Agreement and the User Agreement set forth in this Agreement and the User Agreement, the provision of the Intermodal Ported TN ID Service and all Intermodal Ported TN ID Service Agreements shall immediately be terminated upon the direction of the Federal Communications Commission or any other regulatory body having

95

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

jurisdiction or delegated authority with respect to the subject matter of this Agreement or upon an finding or determination of the Federal Communications Commission or any other regulatory body that the continued provision of the Intermodal Ported TN ID Service is contrary to or inconsistent with the duties or roles of the Contractor or the Customer in any way.  Contractor shall be responsible for any fines and penalties arising from any noncompliance by Contractor, its subcontractors or agents with any such determinations, findings or rulings or with Contractor’s refusal to terminate the provision of the Intermodal Ported TN ID Service and all Intermodal Ported TN ID Service Agreements.

6.IMPACTS ON MASTER AGREEMENT

The following portions of the Master Agreement are impacted by this Amendment:

	Master Agreement
None	Exhibit B Functional Requirements Specification
None	Exhibit C Interoperable Interface Specification
None	Exhibit E Pricing Schedules
None	Exhibit F Project Plan and Test Schedule
None	Exhibit G Service Level Requirements
None	Exhibit H Reporting and Monitoring Requirements
None	Exhibit J User Agreement Form
None	Exhibit K External Design
None	Exhibit L Infrastructure/Hardware
None	Exhibit N System Performance Plan for NPAC/SMS Services
None	Disaster Recovery
None	Back-up Plans
None	Gateway Evaluation Process (Article 32 of Master Agreement)

96

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

7.MISCELLANEOUS

(a)Neither Customer nor Subscribing Customer shall in any way be liable to any Qualified Limited User Data Recipient or Second Tier Limited User Data Recipient or to Contractor or any User under the Intermodal Ported TN ID Service Agreements or as a result of the provision the Intermodal Ported TN ID Service.

(b)Except as specifically modified and amended hereby, all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms.  From and after the Amendment Effective Date hereof, any reference in the Master Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the Amendment Effective Date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit, as modified and amended by this.  From and after the Amendment Effective Date, Amendment shall be a part of the Master Agreement, including its Exhibits, and, as such, shall be subject to the terms and conditions therein.  Each of the respective Master Agreements with respect to separate Service Areas remains an independent agreement regarding the rights and obligations of each of the Parties thereto with respect to such Service Area, and neither this Amendment nor any other instrument shall join or merge any Master Agreement with any other, except by the express written agreement of the Parties thereto.

(c)If any provision of this Amendment is held invalid or unenforceable the remaining provision of this Amendment shall become null and void and be of no further force or effect.  If by rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this Amendment or the Master Agreement, this Amendment is required to be rescinded or is declared ineffective or void in whole or in part, whether temporarily, permanently or ab initio (an “Ineffectiveness Determination”), immediately upon such Ineffectiveness Determination and without any requirement on any party to appeal, protest or otherwise seek clarification of such Ineffectiveness Determination, this Amendment shall be rescinded and of no further force or effect retroactively to the Amendment Effective Date.  Consequently, the Master Agreement in effect immediately prior to the Amendment Effective Date shall continue in full force and effect in accordance with its terms, unchanged or modified in any way by this Amendment.  In the event of an Ineffectiveness Determination, any amounts that would have otherwise been due and payable under the terms and conditions of the Intermodal Ported TN ID Service Agreements or as a result of the provision the Intermodal Ported TN ID Service (the “Unpaid Intermodal Charges”) will in no event be charged to allocated to Users or End Users, including by way of inclusion in any cost or overhead computations related to Services under the Master Agreements, any Statements of Work or otherwise, without an explicit rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this Amendment or the Master Agreement directing the responsibility and liability for payment of those Unpaid Intermodal Charges by Users or End Users.

(d)This Amendment may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed the same document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

97

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

(e)If at any time hereafter a Customer, other than a Customer that is a party hereto desires to become a party hereto, such Customer may become a party hereto by executing a joinder agreeing to be bound by the terms and conditions of this Amendment, as modified from time to time.

(f)This Amendment is the joint work product of representatives of Customer and Contractor; accordingly, in the event of ambiguities, no inferences will be drawn against either party, including the party that drafted the Agreement in its final form.

(g)This Amendment sets forth the entire understanding between the Parties with regard to the subject matter hereof and supercedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.  The modifications, amendments and price concessions made herein were negotiated together and collectively, and each is made in consideration of all of the other terms herein.  All such modifications, amendments and price concessions are interrelated and are dependent on each other.  No separate, additional or different consideration is contemplated with respect to the modifications, amendments and price concessions herein.

(h)This Amendment, the use of the Cost Plus Fee method for determining compensation payable by Qualified Limited User Data Recipients and the composition and details of the Cost Plus Fee method set forth in this Amendment are intended by Contractor and Customer to be separate and distinct from and unrelated to any agreement with respect to Statements of Work under the Master Agreement and the method of determining the cost of such Statements of Work, and shall not be considered to alter, modify, change or amend any such agreements with respect to Statements of Work or to supersede any such agreements with respect to such Statements of Work.

[THIS SPACE INTENTIONALLY LEFT BLANK]

98

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

IN WITNESS WHEREOF, the undersigned have executed this Amendment:

CONTRACTOR:   NeuStar, Inc.

By:

Its:

Date:

CUSTOMER:  North American Portability Management, LLC as successor in interest to and on behalf of Northeast Carrier Acquisition Company, LLC

By:

Its:

Date:

By:

Its:

Date:

99

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

EXHIBIT O

INTERMODAL PORTED TN IDENTIFICATION SERVICE AGREEMENT

100

Amendment No.48-NAPM(NE) April 2, 2004

Sow:       No

                _ Yes

101

NEUSTAR

August 14, 2002

Ms. Pamela Connell

Co-Chair, NAPM, LLC

1200 Peachtree Street

Room 5101

Atlanta, GA  30309

Mr. Richard Theiss

Co-Chair, NAPM, LLC

545 E. John Carpenter Freeway

Irving, TX  75062-7971

Re: Bank of America Revolving Credit Loan Agreement

Ms. Connell:

Mr. Theiss:

1.Background:

1.1As you know, NeuStar, Inc. (“Contractor”) proposes to enter into a revolving credit loan agreement (the  “Credit Agreement”) with Bank of America, N.A. (“BofA”) as Administrative Agent, Lender and Letter of Credit (“L/C”) Issuer, dated August 14, 2002, and to secure loans of up to Twenty-Five Million Dollars ($25,000,000) under the Credit Agreement and Contractor’s other obligations under the Credit Agreement and the other loan documents, all dated August 14, 2002, entered into in connection with the Credit Agreement (the “Loan Documents”) with a pledge of substantially all of its properties and assets pursuant to a general Security Agreement and a Securities Pledge Agreement, including the “LNP Receivables Tracking Certificate” and the “LNP Receivables” (as those terms are defined in the Credit Agreement), but not including the “SOW Receivables” (as defined in the Credit Agreement).

1.2Unless otherwise explicitly defined herein, capitalized terms used herein shall have the meanings as defined in the Loan Documents or in the Agreements for Number Portability Administration Center/Service Management System between NeuStar, Inc., as Contractor, and North American Portability Management LLC (“NAPM”), acting on behalf of the Subscribing Customers named therein for each of the seven United States Service Areas, even if documented as separate legal instruments for each of the seven United States Service Areas (individually, a Master Agreement and collectively, the “Master Agreements”), as the case may be.  If terms used herein have different meanings between the Loan Documents and the Master Agreements, then the meaning assigned to any such term in the Loan Documents shall govern.

2.Representations of Contractor.  Contractor hereby represents and warrants to NAPM that:

2.1Without in any way implying whether a consent is or is not required under the Master Agreements with respect to indebtedness incurred by NeuStar which involves an assignment or transfer of any rights or obligations under the Master Agreements, under the Credit Agreement, neither Contractor nor any of its affiliates (other than Warburg, Pincus & Co. and DB Capital Investors, L.P., and ABS Capital Partners and their respective affiliates) has incurred indebtedness to BofA, or any of its successors, assigns or affiliates, in excess of Twenty-Five Million Dollars ($25,000,000) in principal amount, and Contractor further agrees that, neither Contractor nor any of its affiliates will incur indebtedness (including principal, interest, penalties or any other fees) to BofA, or any of its successors, assigns or affiliates, in excess of Twenty Five Million Dollars ($25,000,000) in principal amount.

2.2Contractor represents that it will provide 14 days advance written notice to NAPM of any indebtedness (other than the indebtedness referred to in Section 2.1 above) incurred by Contractor after the date hereof that is secured by amounts due or payable under the Master Agreements.

2.3In connection with entering into the Credit Agreement, Contractor will not make any representations or warranties or covenant to provide any releases or waivers to BofA regarding rights of set-off or deduction, or any waiver thereof, by NAPM or any “Users” under any of the Master Agreements.

2.4If Contractor violates any of the provisions of Sections 2.1, 2.2, or 2.3 hereof; the assignment or transfer of any rights or obligations under the Master Agreements with respect to any indebtedness incurred in violation of this Section 2 shall be void.

3.Modification of and Amendment to the Master Agreements.

3.1LNP Receivables Secured Financing.

Acknowledgement.  NAPM acknowledges that (i) the Contractor will enter into the Credit Agreement pursuant to which the Lenders will establish for the Contractor a secured revolving credit loan facility for the purposes of making the Loans described in the Credit Agreement (the “Credit Facility”), and (ii) all of the Contractor’s right, title and interest in and to the LNP Receivables, including any LNP Receivables arising in the future, and in and to the LNP Receivables Tracking Certificate will be transferred and assigned as collateral security to secure Contractor’s obligations to the Lenders under the Credit Facility pursuant to a Security Agreement and a Securities Pledge Agreement attached as Exhibits to the Credit Agreement.  As a condition to the effectiveness of the credit Agreement, the Contractor will grant BofA, as administrative agent acting on behalf of the Lenders (the “Administrative Agent”), a perfected, first priority security interest in and to the LNP Receivables Tracking Certificate and the LNP Receivables and the right to collect and receive any amount available for distribution in connection with the LNP Receivables.  In connection with the NAPM’s agreements and consents hereunder relating to the aforementioned transactions, the Contractor has delivered to NAPM the Credit Agreement, the Guaranty Agreement, the Security Agreement, the Securities Pledge Agreement, the Lockbox Account Agreement and the Intercreditor Agreement in substantially the form to be executed by the parties thereto, such documents delivered by Contractor referred to herein as the “Provided Agreements.”  Accordingly, NAPM acknowledges both the receipt of

2

the Provided Agreements and that it has consulted with its counsel to the extent that it has deemed appropriate.

3.2Consent to Credit Facility and Assignment of LNP Receivables.  Without in any way implying whether a consent is or is not required under the Master Agreements or otherwise, and subject to the conditions set forth in this Section 3.2, NAPM consents to the grant by the Contractor of a first priority security interest in and to the LNP Receivables Tracking Certificate and the LNP Receivables to the Administrative Agent, on behalf of the Lenders, to secure the Contractor’s obligations under the Credit Facility and to the perfection of such security interest in accordance with the Provided Agreements.  Notwithstanding the foregoing, this consent shall be conditioned, and shall only be effective, upon receipt by NAPM of an acknowledgment by BofA that it has received a copy and acknowledged the terms of this letter agreement, and Contractor agrees and acknowledges (1) that notwithstanding any provisions of the Loan Documents to the contrary and without in any way implying whether a consent is or is not required under the Master Agreements or otherwise, the foregoing consent by NAPM is not intended to constitute and shall not be deemed or considered by the Contractor to constitute a waiver of any rights or remedies whoever, including, without limitation, any right of offset or deduction, against or with respect to the Contractor (or any of its successors or assigns) that may now exist or which may in the future exist in the absence of the Loan Documents; (2) that without in any way implying whether a consent is or is not required under the Master Agreements, the foregoing consent by NAPM is not intended to constitute and shall not be deemed or considered by Contractor to constitute a consent to the assignment of the LNP Receivables or of any of their proceeds or products or of the LNP Receivables Tracking Certificate, except for the grant of a security interest in the LNP Receivables and their proceeds or products and corresponding LNP Receivables Tracking Certificate pursuant to the Loan Documents; and (3) that the Contractor and its successors and assigns will not assert or claim a position contrary to the foregoing and that the Contractor will cause its successors, assigns, agents, representatives or fiduciaries not to assert or claim a position contrary to the foregoing.  Subject to the foregoing, the consent set forth in this Section 3.2 shall (i) be deemed to constitute a consent under Section 22.1 and (ii) apply notwithstanding the limitations set forth in Section 22.2 of the Master Agreements.

3.3Further Assurances.  NAPM has given its consent as set forth herein expressly conditioned upon the following additional assurances from the Contractor:

(a)The LNP Receivables have been assigned by Contractor under the Loan Documents to the Administrative Agent as collateral security for the benefit of the Lenders subject to the right of the carriers and other entities Contractor is entitled to bill under the Master Agreements (“Users”) to assert setoff or deduct claims against the LNP Receivables.

(b)Any and all documents delivered under the Loan Documents which contain NAPM or User information, files or data shall be afforded the confidentiality required by Contractor under the Master Agreements, and all disputes under the Master Agreements among NAPM, Users and Contractor shall be governed by the dispute resolution procedures set forth in the Master Agreements.

3

(c)The Contractor, agrees that no previously executed document and no document executed in the future, except to the extent specifically provided therein and specifically consented to by NAPM in writing, shall contradict, diminish or otherwise impair the benefits, privileges and rights afforded NAPM and the Users under this letter agreement.  To the extent Contractor does not comply with the foregoing sentence, any such document shall be void.  In particular, any documents requested to be executed under this Section 3.3(c) shall expressly recite that they are made subject to and conditioned upon the assurances set forth in this letter agreement as of the time of execution of such documents.

(d)NAPM has made no representation or warranty whatsoever to the Contractor regarding the enforceability of the modification of the Master Agreements pursuant hereto on Users.

(e)The Contractor shall notify NAPM as soon as reasonably practicable, but no later than five (5) business days after the occurrence of any of the following events:  (i) any violation, or any waiver by the Lenders of any violation, of any provision of Section 8.11 of the Credit Agreement, (ii) any increase in the “Available Amount” (as defined in the Credit Agreement), and (iii) any termination or reduction of “Commitments” (as defined in the Credit Agreement) pursuant to Section 2.05 of the Credit Agreement.  The requirement to provide the notices under this Section 3.3(e) shall be incorporated in the GEP process under SOW 25 as it relates to reporting requirements.

(f)Subject to the rights of Users under User Agreements to assert setoff or deduction claims on amounts owed under the Master Agreements, as amended under any Statement of Work thereunder, Users rights to assert setoff or deduction claims may be exercised against the LNP Receivables, or, to the extent that the LNP Receivables Tracking Certificates represents a right with respect to the LNP Receivables, the LNP Receivables Tracking Certificates; provided however, that any such right of setoff or deduction against the LNP Receivables and LNP Receivables Tracking Certificates shall terminate upon payment of such amounts to the Trust

(g)Contractor agrees that without the prior written consent of NAPM Contractor shall not amend Section 9.01(m) of the Credit Agreement, which consent will not be unreasonably withheld, delayed or conditioned.

4.Miscellaneous.

4.1NAPM hereby waives any requirement under that certain letter dated November 2, 2001 relating to the Wachovia loan facility that Contractor provide it with 14 days advance written notice of any indebtedness incurred pursuant to the Credit Agreement, without either NAPM or Contractor agreeing or acknowledging that such notice or Contractor’s agreement to provide such notice constitutes either an acknowledgment of the need to seek or to obtain the consent of NAPM to such indebtedness or the grant of consent by NAPM to such indebtedness.

4.2Except as specifically modified hereby, all the provisions of the Master Agreements and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their

4

terms, and, in accordance therewith, Contractor’s grant of the security interest and the perfection thereof as contemplated by the Loan Documents does not alter or modify any of the provisions of the Master Agreements and the User Agreements, and all exhibits and schedules thereto, and any agreements contemplated thereby.  From and after the effective date hereof, this letter agreement shall be a part of the Master Agreements, including its exhibits, and, as such, shall be subject to the terms and conditions therein.  Each of the respective Master Agreements with respect to separate Service Areas remains an independent agreement regarding the rights and obligations of each of the Parties thereto with respect to such Service Area, and neither this letter agreement nor any other instrument shall join or merge any Master Agreement with any other, except by the express written agreement of the Parties thereto.

4.3This letter agreement sets forth the entire understanding between the Contractor and NAPM with regard to the subject matter hereof and supersedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.

4.4If any provision of this letter agreement is held invalid or unenforceable the remaining provisions of this letter agreement shall become null and void and be of no further force or effect.  If by rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this letter agreement or the Master Agreements, this letter agreement is required to be rescinded or is declared ineffective or void in whole or in part, whether temporarily, permanently or ab initio (an “Ineffectiveness Determination”), immediately upon such Ineffectiveness Determination and without any requirement on any party to appeal, protest or otherwise seek clarification of such Ineffectiveness Determination, this letter agreement shall be rescinded and of no further force or effect retroactively to the date hereof.  Consequently, the Master Agreements in effect immediately prior to the date hereof shall continue in full force and effect in accordance with their respective terms, unchanged or modified in any way by this letter ageement.

4.5This letter agreement may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed the same document.  All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

4.6This letter agreement is the joint work product of representatives of NAPM and Contractor, accordingly, in the event of ambiguities, no inferences will be drawn against either Party, including the Party that drafted the Agreement in its final form.

4.7All notices or other communications required or permitted to be given to NAPM under this letter agreement, including, without limitation, specifically the notices required under Sections 2.2 and 3.3(e) of this letter agreement, must be in writing, as the requirement of writing is defined in Section 27.6(a) of the Master Agreements and shall be given to the then current chair (or if more than one chair, all co-chairs) of NAPM, with notice given to NAPM’s then-current legal counsel, and each such notice or communication shall for purposes of this letter agreement be deemed to be given and delivered in accordance with the requirements of Section 27.6(b) of the Master Agreements.

5

Please indicate your consent to the transactions described in Sections 1 and 3 of this letter by executing in the space provided below and returning to the undersigned a copy of this letter. NeuStar appreciates your cooperation and prompt attention to this matter.

Very truly yours,

NeuStar, Inc.

By:

The undersigned on behalf of NAPM acknowledge, accept, consent to and rely upon the terms of this letter agreement as set forth herein.

NORTH AMERICAN PORTABILITY MANAGEMENT LLC

By:
	Pamela H. Connell
	Co-Chair

By:
	Richard Theiss
	Co-Chair

By:	/s/ Pamela H. Connell
	Pamela H. Connell
	Co-Chair

Receipt and acknowledgment of the terms of an executed copy of the foregoing letter agreement are hereby acknowledged

BANK OF AMERICA, N.A.

By:

Authorized Signatory

6