Document:

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.4 SOFTWARE
  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 OR REGULATORY
  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.1                                 The
term “Acceptance Date” shall have the meaning set forth in Section 8.2.

 

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

 

1.3                                 The
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.4                                 The
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.5                                 The
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.6                                 The
term “Billing Cycle” means any calendar month, or portion thereof, during which
Services are rendered hereunder.

 

1.7                                 The
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.8                                 The
term “Centralized NPAC LLCs” shall have the meaning given to such term in Article 29
hereof.

 

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

 

1.10                           The
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.11                           The
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.12                           The
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.13                           The
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.14                           The
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.15                           The
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.16                           The
term “Delay Extensions” shall have the meaning given to such term in Section 8.1(c).

 

1.17                           The
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.18                           The
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.19                           The
term “Effective Date” means the date set forth in the preamble to this
Agreement.

 

1.20                           The
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.21                           The
term “Final Delivery Date” shall mean November 3, 1997, as such date may
be extended by Delay Extensions.

 

1.22                           The
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.23                           The
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.25                           The
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.26                           The
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.27                           The
term “Member” shall mean a company which has joined the LLC pursuant to the
Operating Agreement.

 

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

 

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

 

1.30                           The
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.31                           The
term “Normal Business Hours” means 7:00 a.m. to 7:00 p.m. Central
Time during Business Days.

 

1.32                           The
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.33                           The
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.34                           The
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.35                           The
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.36                           The
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.37                           The
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.38                           The
term “Object Code” means the machine-readable form of any computer programming
code.

 

1.39                           The
terms “Party” or “Parties” mean Contractor
and/or Customer

 

1.40                           The
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.41                           The
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.42                           The
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.43                           The
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.44                           The
term “Services” means the delivery of NPAC/SMS services in the manner provided
under this Agreement and shall include Additional Services.

 

1.45                           The
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.46                           The
term “Service Element” means any of the individual service items identified and
priced in Exhibit E - Pricing Schedules.

 

1.47                           The
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.48                           The
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.49                           The
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.50                           The
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.51                           The
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.52                           The
term “Specifications” means the functional, technical and design specifications 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.53                           The
term “Standard Report” means a report designated in Section 9 of Exhibit B
- NANC NPAC/SMS Functional Requirements Specifications.

 

11

 

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

 

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

 

1.56                           The
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.57                           The
term “Third Party” means any individual, corporation, partnership, association
or other entity, other than the Parties hereto.

 

1.58                           The
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.59                           The
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.60                           The
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.61                           The
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.62                           The
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.63                           The
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.64                           The
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.65                           The
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.1                               Compensation

 

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.2                               NPAC/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.1                               General

 

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
CPI for 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.2                               Service
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.3                               User
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.4                               Interoperability
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.5                               Expenses

 

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.6                               Target
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.7                               Most
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.8                               Adoption
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.1                               Benchmark
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.2                               Benchmarker

 

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.3                               Benchmark

 

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.4                               Benchmark
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.5                               Benchmarking
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.1                               Testing
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.2                               Acceptance;
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.3                               Provision
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.4                               Compliance
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.5                               Security;
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.6                               Procurement;
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.7                               Training

 

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.8                               Taxes

 

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.9                               Licenses
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.10                        Laws
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.11                        Immigration
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.12                        Quality

 

Contractor shall provide
high-quality service and support to Users consistent
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.13                        Notification
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.1                               Ownership
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.2                               Grant
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.3                               Grant
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.4                               Software
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.1                        Hotline
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.2                        Problem
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.1                        Project
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.2                        Project
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 project quality
review meetings as necessary.

 

11.3                        Conduct
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.1                        Contractor’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.2                        Disaster
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.3                        Disaster
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.4                        Implementing
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.5                        Data
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.6                        Occurrence
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.7                        Allocation
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.8                        Permanent
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.1                        Requested
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.2                        Proposed
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.3                        Changes
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.4                        Statement
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.5                        Staffing

 

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.6                        Enhancements
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.1                        Contractor’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.2                        Access
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.3                        Provision
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.4                        Audit
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.5                        Record
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.6                        Compliance
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.1                        Confidential
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.2                        Exclusions

 

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.3                        Return
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.4                        Injunctive
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.5                        Loss
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.6                        Third
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.1                        Notice
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.2                        Delays
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.3                        Performance
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.4                        Allocation
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.5                        Contractor
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.6                        Force
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.1                        Mutual
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, those based 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.2                        Contractor
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 those based 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.3                        Procedures

 

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.1                        Contractor’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.2                        Contractor’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), if none
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 subject Custom 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.1                        DIRECT
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.2                        CONSEQUENTIAL
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.3                        EXCLUSIONS

 

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.1                        Contractor’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.2                        Contractor’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.3                        Self
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.4                        Customer’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.5                        Customer’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.6                        Additional
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.1                        Harmful
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.2                        No 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.3                        Conformance
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.4                        Authority

 

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.5                        EXCLUSIVE
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.1                        Consent
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.2                        Assignment
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.1                        Termination
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.2                        Nonwaiver

 

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.3                        Users’
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.4                        Return 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.1                        Contractor’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.2                        Optional
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.3                        Optional
Extension Upon Termination or Non-Renewal With License, Loss of Neutrality or Regulatory 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.4                        Transition
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.1                        Users 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.2                        Changes 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.1                        Internal
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.2                        Arbitration

 

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.3                        Continuation
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.4                        Disputes
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.1                        Successors
and Assigns

 

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

 

27.2                        Attorneys’
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.3                        Service
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.4                        Advertising
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.5                        Non-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.6                        Notices

 

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.7                        Governing
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.8                        Severability

 

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.9                        Remedies

 

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

 

27.10                 Survival

 

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.11                 Joint
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.12                 Headings

 

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.13                 Counterparts

 

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.6          Evaluation of Proposals

 

The
criteria to be used for the proposal evaluation include:

(a) technical merit

(b) schedule

(c) price and cost

(d) quality considerations

(e) responsiveness to contract provisions

(f) Prime Vendor’s financial stability, history, including program
management

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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.1          Provision Service Process

 

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

 

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

 

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

 

From
the time the new service provider sends a notification to the time it sends the
activation notice, the new service provider may send a message to the NPAC SMS
to cancel the notification.  If this
occurs,

 

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.2          Disconnect Process

 

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

 

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

 

(refer
to the Attachmented process flows)

 

2.3          Conflict Resolution Process

 

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

 

2.4          Disaster Recovery and Backup Process

 

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

 

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

 

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

 

3.1.1        Service Data

 

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

 

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

 

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

 

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

 

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

 

3.1.2        Service Provider Data

 

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

 

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

 

A. NPAC/SMS User Name

 

B. Facility-based NPAC/SMS User Identification

 

C. NPAC/SMS User Address

 

D. NPAC/SMS User Phone

 

E. NPAC/SMS User Contact

 

F. NPAC/SMS User Repair Center Information

 

G. NPAC/SMS User System Data Link Information

 

3.1.3        Subscription Data

 

Subscription
Data consists of information about the ported TNs.

 

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.4        Data Used for Validation

 

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

 

A.           Participating facilities-based service
providers and their IDs

 

B.             NPA-NXXs that are portable

 

C.             LRNs associated with each facilities-based
service provider

 

D.            Service Provider valid Location Values

 

E.              Valid Billing IDs

 

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

 

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

 

3.2          NPAC Personnel Functionality

 

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

 

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

 

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

 

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

 

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

 

27

 

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

 

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

 

3.3          System Functionality

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

28

 

Section 4:  NPAC/SMS
User Data Administration

 

4.1          NPAC/SMS User Data
Administration and Management

 

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

 

NPAC/SMS User Administration Requirements

 

4.1.1        User Functionality

 

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

 

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

 

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

 

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

 

R4-4                        View NPAC/SMS User data.

 

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

 

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

 

4.1.2        System Functionality

 

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

 

4.1.2.1     NPAC/SMS User Data Creation

 

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

 

29

 

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

 

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

 

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

 

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

 

NPAC/SMS User name, address,
phone number, and contact  

organization  <—  required data.

 

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

 

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

 

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

 

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

 

Network Address of NPAC to
Local SMS interface

 

Network Address of NPAC to
SOA interface

 

Security data

 

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

 

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

 

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

 

4.1.2.2               NPAC/SMS User Data Modification

 

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

 

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

 

30

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

4.1.2.3               Delete NPAC/SMS User Data

 

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

 

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

 

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

 

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

 

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

 

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

 

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.3        NPAC/SMS User Queries

 

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

 

Assumptions

 

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

 

User Functionality

 

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

 

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

 

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

 

all subscriptions associated
with a NPAC/SMS User, or

 

all subscriptions associated
with a LRN.

 

System Functionality

 

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

 

NPAC/SMS
User Query

 

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

 

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

 

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

 

32

 

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

 

Subscription
List Query

 

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

 

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

 

33

 

Section 5: 
Subscription Administration

 

5.1          Subscription Administration
and Management

 

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

 

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

 

5.1.1        Record Management

 

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

 

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

 

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

 

34

 

Requirements

 

Record Status

 

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

 

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

 

Invalid -  failed validations.

 

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

 

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

 

Sending - being sent to the
network.

 

Active - currently active in
the network.

 

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

 

Old - previously active in
the network.

 

Canceled - previously
pending, invalid, or in conflict.

 

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

 

35

 

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

 

	
  Last status before cancellation

  	
   

  	
  Parameter value

  
	
   

  	
   

  	
   

  
	
  pending

  	
   

  	
  90 Days

  
	
   

  	
   

  	
   

  
	
  invalid

  	
   

  	
  90 Days

  
	
   

  	
   

  	
   

  
	
  conflict

  	
   

  	
  30 Days

  

 

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

 

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

 

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

 

Activity Type: create,
modify, active, activate,  conflict “on,”
conflict “off,” disconnect, cancel, or query

 

Initial Record Status

 

New Record Status

 

User ID and/or Login

 

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

 

Date and Time Stamp

 

Ported Telephone Number

 

Status Flag - successful or
failed

 

36

 

5.1.2        Subscription Administration Requirements

 

5.1.2.1     User Functionality

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

5.1.2.2               System Functionality

 

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

 

Additionally, SMS
functionality is required to perform operations which are not invoked by a
direct user request.  This functionality
shall monitor a subscription record to determine whether the old and the new
facilities-based NPAC/SMS Users have

 

(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-14                  When the user is the old (ported-from)
NPAC/SMS User SMS shall receive the following to identify the subscription
record to be created:

 

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

 

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

 

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

 

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

 

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

 

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

 

38

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Billing Service Provider ID

 

End-User Location - Value

 

End-User Location - Type

 

SMS shall invoke the
following Record Creation functionality:

 

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

 

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

 

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

 

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

 

SMS shall perform the
following validations for the record:

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

5.1.2.2.2 Subscription
Record Modification

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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-28                  The following fields are for future use.  The new facilities-based SOA User may not be
required to treat these fields as mandatory.

 

Billing Service Provider ID

 

End-User Location - Value

 

End User Location - Type

 

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

 

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

 

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

 

R5-32                  Deleted requirement.  Do not respond.

 

5.1.2.2.2.2                                             Modification of an Active Subscription Record

 

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

 

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

 

42

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Billing Service Provider ID

 

End-User Location - Value

 

End-User Location - Type

 

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

 

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

 

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

 

43

 

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

 

5.1.2.2.3                                                      Conflict Subscription Record

 

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

 

44

 

5.1.2.2.3.1  Placing a Subscription Record in Conflict

 

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

 

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

 

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

 

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

 

5.1.2.2.3.2  Removing a Subscription Record from Conflict

 

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

 

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

 

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

 

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

 

45

 

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

 

5.1.2.2.4 Subscription
Record Activation

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

R5-59                  If a positive acknowledgment is received from
all involved Local SMSs, then the subscription record shall be marked with a
status of active in the

 

46

 

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

 

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

 

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

 

5.1.2.2.5 Disconnect
Subscription Record

 

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

 

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

 

47

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

send the disconnect message
to the Local SMSs, and

 

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

 

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

 

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

 

R5-68                  If the disconnect request fails in some of
the Local SMSs to which it was sent (e.g., the link between SMS and a specific
network node is down), the disconnect request shall remain in queue and shall
be resent to the Local

 

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

 

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

 

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

 

49

 

5.1.3        Subscription Queries

 

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

 

Assumptions

 

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

 

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

 

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

 

User Functionality

 

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

 

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

 

System Functionality

 

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

 

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

 

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

 

Ported Telephone Number(s)

 

Due Date

 

New facilities-based service
provider ID

 

Old facilities-based service
provider ID

 

Authorization from old
facilities-based SOA User

 

Location Routing Number
(LRN)

 

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

 

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.1          SOA to NPAC SMS Interface

 

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

 

[Graphic
Omitted:  SOA to NPAC Interface]

 

6.1.1        Request Administration

 

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

 

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

 

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

 

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

 

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

 

52

 

6.1.2                        Subscription Administration

 

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

 

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

 

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

 

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

 

6.1.3                        Notifications

 

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

 

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

 

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

 

53

 

6.2          NPAC SMS to Local SMS
Interface

 

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

 

[Graphic
Omitted:  Interface diagram]

 

6.2.1        Transaction Administration

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

54

 

6.2.2                        Network Subscription Administration

 

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

 

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

 

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

 

6.3          Interface Transactions

 

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

 

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

 

6.4.         Interface and Protocol
Requirements

 

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

 

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

 

55

 

6.4.1        Protocol Requirements

 

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

 

R6-20:

 

	
  Application:

  	
  ASCE,
  CMISE/ROSE (ANSI T1.224)

  
	
   

  	
   

  
	
  Presentation:

  	
  as
  described in ANSI T1.224

  
	
   

  	
   

  
	
  Session:

  	
  as
  described in ANSI T1.224

  
	
   

  	
   

  
	
  Transport:

  	
  OSI
  Transport Class 0, RFC 1006, and TCP

  
	
   

  	
   

  
	
  Network:

  	
  Internet
  (IETF) IP

  
	
   

  	
   

  
	
  Link:

  	
  ethernet
  routing, or frame relay, or ATM

  
	
   

  	
  (or
  more than one of these)

  
	
   

  	
   

  
	
  Physical:

  	
  as
  appropriate

  

 

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

 

6.4.2                        Interface Performance Requirements

 

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

 

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

 

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

 

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

 

6.4.3 Interface Specification

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

57

 

7.2          Authentication

 

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

 

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

 

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

 

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

 

7.2.1                        Password Requirements

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

58

 

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

 

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

 

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

 

(2)          Passwords
must not contain the associated userid.

 

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

 

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

 

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

 

7.3          Access Control

 

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

 

7.3.1                        System Access

 

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

 

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

 

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

 

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

 

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

 

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

 

59

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

60

 

NOTICE: This is a private computer system.

 

Unauthorized access or use may lead to prosecution.

 

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

 

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

 

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

 

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

 

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

 

7.3.2        Resource Access

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

61

 

7.4                               Data and System Integrity

 

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

 

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

 

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

 

(1)               Monitoring of system resources

 

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

 

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

 

(4)               Detection of Link Outages.

 

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

 

(1)               Proper rule checking on data update

 

(2)               Proper handling of duplicate/multiple inputs

 

(3)               Checking of return status

 

(4)               Checking of inputs for reasonable values

 

(5)               Proper serialization of update transactions.

 

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

 

7.5          Transaction Audit Log Generation

 

7.5.1                        Audit Log Generation

 

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

 

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

 

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

 

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

 

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

 

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

 

62

 

(1)  Invalid
user authentication attempts

 

(2)  Logins
and activities of NPAC users

 

(3)  Unauthorized
data or transaction access attempts.

 

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

 

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

 

(1)  Date and
time of the event

 

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

 

(3)  Type of
event

 

(4)  Name of
resources accessed

 

(5)  Success
or failure of the event.

 

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

 

7.5.2                        Reporting and Intrusion Detection

 

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

 

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

 

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

 

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

 

7.6          Continuity of Service

 

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

 

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

 

63

 

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

 

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

 

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

 

7.7                               Software Vendor

 

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

 

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

 

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

 

7.8                               OSI Security Environment

 

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

 

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

 

64

 

7.8.1                        Threats

 

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

 

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

 

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

 

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

 

Switching
customers to various carriers without their consent

 

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

 

7.8.2                        Security Services

 

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

 

R7-89                  Authentication
(at association setup)

 

R7-90                  Data
origin authentication for each incoming message

 

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

 

R7-92                  Non-repudiation
of origin

 

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

 

7.8.3                        Security Mechanisms

 

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

 

7.8.3.1               Encryption

 

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

 

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

 

65

 

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

 

7.8.3.2               Authentication

 

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

 

•                  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-98                  The
authenticator shall be conveyed in the CMIP access control field. (An
appropriate syntax for this EXTERNAL field shall be provided.)

 

7.8.3.3               Data
Origin Authentication

 

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

 

7.8.3.4               Integrity
and Non-repudiation

 

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

 

R7-101            The
values of the components of the authenticator shall also be as specified for
the authenticator above, except that the digital signature shall apply to all
the fields in the notification, except the security field, in the order in
which they

 

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

 

7.8.3.5               Access
Control

 

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

 

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

 

7.8.3.6               Audit
Trail

 

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

 

7.8.3.7               Key
Exchange

 

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

 

R7-108            Upon
remote reception of a list of keys the recipient shall send an acknowledgment
to the sender of the list.  The
acknowledgment shall consist of the MD5 hash of each one of the keys in the
list.  The acknowledgment shall be
provided in electronic form via at least two different channels.  In addition, the

 

67

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

8.2                               Periodic Audits

 

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

 

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

 

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

 

8.3                               NPAC SMS Verify of Data in Local SMS

 

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

 

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

 

69

 

Section 9:  Report Management

 

9.1          Overview

 

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

 

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

 

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

 

Examples
of the items available from active database are:

 

•                  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.2          User Functionality

 

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

 

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

 

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

 

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

 

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

 

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

 

R9-7                        Vendors must provide examples of report outputs.

 

9.3                               System Functionality

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

R10-9                  The
design will provide:

 

•                  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-10            If
the system becomes unavailable for normal operations due to any reason,
including both scheduled and unscheduled maintenance, service providers must be
notified of the system unavailability.

 

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

 

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

 

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

 

•                  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-14            Reports
documenting the performance of the NPAC SMS in regards to the above requirements
will be provided periodically to the service providers.

 

10.2 Capacity and Performance

 

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

 

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

 

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

 

73

 

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

 

Assumptions
used for estimating the quantity of transactions are:

 

•                  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-18            Data
storage of the History file must keep track of all transactions made for one
year (churn and new records.)  It is
assumed that there will be thirty percent churn of accumulated records.

 

74

 

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

 

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

 

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

 

75

 

Section 11:  Billing / Resource Accounting

 

11.1        Overview

 

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

 

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

 

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

 

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

 

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

 

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

 

D.            Number of errors encountered in transactions

 

E.              Number of errors encountered during
transmission

 

F.              Number of current records maintained

 

G.             Number of pending records maintained

 

H.            Number of history records maintained

 

I.                 Number of records downloaded as normal action

 

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

 

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

 

L.              Number of records in conflict

 

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

 

N.            Number of records audited on request

 

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

 

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

 

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

 

11.3        User Functionality

 

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

 

11.4                        System Functionality

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

77

 

Section 12:  Number Portability
Administration Center

 

12.1        Number Portability Administration Center (NPAC)

 

NPAC Role

 

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

 

Operational Functions

 

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

 

Administrative Functions

 

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

 

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

 

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

 

System Administration

 

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

 

78

 

12.2        Logon Administration

 

Key Responsibilities

 

R12-1      Assist with new logon requests

 

R12-2      Verify logon signature approval

 

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

 

R12-4      Update data base and add new users

 

R12-5      Notify user of logon activation

 

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

 

Procedure Description

 

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

 

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

 

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

 

12.3        Customer Record Security

 

Key Responsibilities

 

R12-7      Establish user boundaries through user access
permission classes

 

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

 

R12-9      Exercise absolute control of access to
customer information

 

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

 

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

 

Key Responsibilities

 

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

 

Procedure Description

 

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

 

12.5                        Software Release Acceptance Testing

 

Key Responsibilities

 

R12-12            Update
software test plans

 

R12-13            Allocate
staff for performing tests

 

R12-14            Execute
test plans

 

R12-15            Generate
and resolve testing trouble reports

 

R12-16            Document
test results

 

R12-17            Certify
NPAC SMS software and release for operation

 

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

 

Key Responsibilities

 

R12-18            Create
and maintain NPAC SMS data table

 

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

 

R12-20            Create
and maintain descriptive data table labels

 

Procedure Description

 

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

 

•                  Location
Routing Number (LRN) tables

•                  Service
Provider GTT information tables

 

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

 

81

 

12.7        Mass Change Administration

 

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

 

Key Responsibilities

 

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

 

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

 

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

 

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

 

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

 

Procedure Description

 

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

 

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

 

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

 

12.8                        User Support Group

 

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

 

This
group provides the NPAC SMS user a central point of contact for resolution of
NPAC SMS problems and trouble reporting. 
Resolution of user problems will be handled primarily through the
efforts of the User Support Group itself. 
Those issues requiring the efforts of another NPAC group will be
promptly referred to the appropriate group. 
Issues requiring Vendor or NPAC SMS Data Center

 

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

 

Key Responsibilities

 

R12-26            Resolve
customer record access problems

 

R12-27            Clarify
feature capabilities for users

 

R12-28            Resolve
customer record input and modification problems

 

R12-29            Perform
acceptance testing for new software releases

 

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

 

Procedure Description

 

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

 

12.8.2              Software Release Acceptance
Testing

 

Key Responsibilities

 

R12-30            Update
software test plans

 

R12-31            Allocate
staff for performing tests

 

R12-32            Execute
test plans

 

83

 

R12-33            Generate
and resolve testing trouble reports

 

R12-34            Document
test results

 

R12-35            Certify
NPAC SMS software and release for operation

 

Procedure Description

 

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

 

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

 

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

 

Key Responsibilities

 

R12-36            Notify
users of upcoming NPAC SMS software releases

 

Procedure Description

 

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

 

84

 

12.8.4              Training Administration

 

Key Responsibilities

 

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

 

R12-38            Ensure
availability of all NPAC SMS training

 

Procedure Description

 

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

 

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

 

12.8.5              Document Order
Administration

 

Key Responsibilities

 

R12-39            Process
documentation requests

 

R12-40            Provide
billing documentation

 

R12-41            Initiate
documentation update distribution

 

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

 

Procedure Description

 

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

 

12.8.6              Training and Documentation
User Feedback

 

Key Responsibilities

 

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

 

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

 

Key Responsibilities

 

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

 

Procedure Description

 

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

 

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

 

12.9                        System Support Group

 

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

 

86

 

12.9.1–NPAC SMS Report Administration

 

Key Responsibilities

 

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

 

R12-46            Validate
the accuracy of report contents

 

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

 

R12-48            Resolve
report interpretation problems

 

Procedure Description

 

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

 

12.9.2              Failure Recovery
Administration and User Notification

 

Key Responsibilities

 

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

 

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

 

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

 

Key Responsibilities

 

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

 

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

 

R12-53            Generate
automatic audit reports

 

Procedure Description

 

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

 

12.9.4              Software Release Acceptance
Training

 

Key Responsibilities

 

R12-54            Update
software test plans

 

R12-55            Allocate
staff for performing tests

 

88

 

R12-56            Execute
test plans

 

R12-57            Generate
and resolve testing trouble reports

 

R12-58            Document
test results

 

R12-59            Certify
NPAC SMS software and release for operation

 

Procedure Description

 

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

 

•                  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.10                 NPAC Organizational Interface Requirements

 

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

 

12.11                 NPAC SMS Data Center

 

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

 

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

 

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

 

Key Responsibilities

 

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

 

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

 

R12-62            Analyze
documentation and training impact

 

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

 

R12-64            Coordinate
critical software release cutover

 

R12-65            Provide
billing for service providers’ usage

 

R12-66            Manage
NPAC accounts receivable collection

 

R12-67            Manage
NPAC accounts payable responsibilities

 

R12-68            Resolve
any NPAC billing disputes

 

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

 

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

 

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

 

R12-72            Manage
NPAC facilities

 

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

 

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

 

R12-75            List
of cleared trouble reports

 

12.13                 Facilities Requirements

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

12.14                 Telecommunications Requirements

 

Key Requirements

 

R12-82            Individual
phone lines for staff members

 

R12-83            24
hour hotline

 

R12-84            Voice
messaging system

 

R12-85            Data
communication facilities

 

R12-86            FAX
Machine

 

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

 

91

 

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

 

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

 

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

 

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

 

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

 

12.15                 Staffing

 

Key Requirements

 

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

 

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

 

92

 

12.16                 Service Objectives

 

NPAC Availability

 

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

 

Quality of Service

 

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

 

Performance Standards

 

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

 

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

 

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

 

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

 

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

 

R12-97            Service
consistency

 

R12-98            Service
reliability

 

R12-99            Service
response time

 

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

 

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.1   Document
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.2   Abbreviations
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.3   Document 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.4   Document
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.1   NPAC
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.2   NPAC
SMS Functional Overview

 

1.2.1   Provisioning 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.2   Disconnect 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.3   Repair 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.4   Conflict 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.5   Disaster 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.6   Order 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.7   Audit 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.8   Report 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.9   Data Management
Functionality

 

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

 

1.2.9.1   NPAC
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.2   Service 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.3   Subscription Version
Data

 

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

 

1.3   Background

 

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.4   Objective

 

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

 

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.6   Constraints

 

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

 

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.7   Related 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.1   Provision
Service Process

 

This process flow defines the
provisioning flow in which a customer ports a telephone number to a new Service
Provider.  The service provisioning flow
activities are shown in Flow 2.1, Appendix A page 3.

 

2.1.1   Service
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.2   Subscription 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.3   Service 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.4   NPAC 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.1   New
Service Provider sends activation to NPAC SMS.

 

The new Service Provider sends
an activate notification to the NPAC SMS.

 

2.1.4.2   NPAC
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.3   Failure
- 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.4   Initiate
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.5   Service 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.2   Disconnect
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.1   Customer 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.2   NPAC 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.3   NPAC 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.3   Repair
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-A   Service
provider receives problem notification from customer.

 

2.3.1-B   Service
provider receives problem notification from another Service Provider.

 

2.3.1-C   Service
provider receives problem notification from NPAC SMS.

 

2.3.2   Service
provider analyzes the problem.

 

2.3.3   Service
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.4   Request
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.5   Broadcast
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.4   Conflict 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.1   Subscription
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.2   New 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.3   New 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.4   Missing 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.5   Subscription 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.6   Conflict
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.5   Disaster 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.1   NPAC 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.2   NPAC 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.3   Service 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.4   Backup 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.5   Service 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.6   Backup 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.7   Service providers
reconnect to primary NPAC

 

The Service Providers
re-establish associations with the primary NPAC application using their normal
connections.

 

2.5.8   Primary 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.6   Service 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.1   Service 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.2   NPAC 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.3   NPAC 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.7   Audit
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.1   Service provider
requests audit

 

Any Service Provider can
request audits of the entire network or of individual Service Provider’s
networks.

 

2.7.2   NPAC 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.3   NPAC 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.4   NPAC SMS updates
appropriate Local SMS databases

 

The NPAC SMS updates Subscription
Version information in the appropriate Local SMS databases.

 

10

 

2.8   Report
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.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

 

This section defines the
activities performed by the NPAC when Service Providers make a manual request
for data administration.

 

2.9.1   Service provider
requests administration of data by NPAC personnel

 

Service provider personnel are
able to contact NPAC personnel to request data administration activities.

 

2.9.2   NPAC 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.3   NPAC SMS personnel
inputs user’s request

 

Upon validation of the request,
NPAC personnel will input the request.

 

2.9.4   NPAC SMS performs
user’s request

 

The NPAC SMS processes the
request.

 

11

 

2.9.5   NPAC 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.1   Overview

 

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.1   Data 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.2   NPAC
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.3   Subscription
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 Retention tunable
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 the Old
Subscription Retention tunable.

 

8

 

R5-2.3
Old Subscription Retention - Tunable Parameter Default

 

NPAC SMS shall default the Old
Subscription Retention tunable
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 conflict resolution pending 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 Window tunable
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 Window date
tunable parameter.

 

R5-21.3
Initial Concurrence Window - Tunable Parameter Default

 

NPAC SMS shall default the
Initial Concurrence Window date 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 Window tunable
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 Window tunable
parameter.

 

R5-23.3
Final Concurrence Window Tunable - Tunable Parameter Default

 

NPAC SMS shall default the
Final Concurrence Window tunable
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
Concurrence Window tunable parameter expires and a 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
and an 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 Window tunable
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 Window tunable
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 Window tunable
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 Window tunable
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 Window tunable
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 Window tunable parameter.

 

RR5-17.3 Conflict Resolution-Initial Concurrence
Window - Tunable Parameter Default

 

NPAC SMS shall default the Conflict Resolution-Initial Concurrence Window tunable 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 Window tunable
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 Window tunable parameter.

 

RR5-18.3 Conflict Resolution-Final Concurrence
Window - Tunable Parameter Default

 

NPAC SMS shall default the
Conflict Resolution-Final Concurrence Window tunable
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 Window tunable 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
Window tunable parameter expires.

 

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 the Local 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 Attempts tunable
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 Interval tunable
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 Attempts tunable 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 Interval tunable parameter.

 

R5-60.5
Subscription Activation Retry Attempts - Tunable Parameter Default

 

NPAC SMS shall default the
Subscription Activation Retry Attempts tunable
parameter to 3 times.

 

R5-60.6
Subscription Activation Retry Interval - Tunable Parameter Default

 

NPAC SMS shall default the
Subscription Activation Retry Interval tunable
parameter to 2 minutes.

 

R5-60.7
Subscription Version Activation Failure Retry

 

NPAC SMS shall resend the
activated Subscription Version a Subscription Activation Retry Attempts tunable parameter number of times to a Local SMS that has
not acknowledged the receipt of the activation request once the Subscription
Activation Retry Interval tunable
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 all the Local SMSs to which it was 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 all the Local SMSs to which it was
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 Attempts tunable 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 Attempts tunable
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 Interval tunable 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 Interval tunable
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 Attempts tunable parameter number of times to a Local SMS that has
not acknowledged the receipt of a disconnect once the Subscription Disconnect
Retry Interval tunable 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 Attempts tunable
parameter period 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 Window tunable
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 Window tunable parameter.

 

RR5-32.3 Cancellation-Initial Concurrence Window -
Tunable Parameter Default

 

NPAC SMS shall default the
Cancellation-Initial Concurrence Window tunable
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.3       Subscription
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.1    User
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.2    System
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.1          SOA to
NPAC SMS Interface

 

The SOA to NPAC SMS Interface
could be used by a variety of local Service Provider systems for retrieving and
updating subscription data in an NPAC SMS. The types of systems that are
expected to use this interface are Service Provisioning OSs and/or Gateway
Systems. 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.1       Request
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.2       Subscription
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.3       Audit
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.4       Notifications

 

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.2          NPAC
SMS to Local SMS Interface

 

The NPAC SMS to Local SMS
Interface could be used to send subscription data and audit requests to a
variety of 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.1       Transaction
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.2       Network
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.3          Interface
Transactions.

 

The CMIP protocol provides for
six types of transactions over the interface (Reference: ISO 9595 and 9596).
They are Create, Delete, Set, Get, 

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.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-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.1       Protocol
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.2                       Interface 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.3       Interface
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.5          Requirements
Defined in the Proposal

 

6.5.1       NPAC
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.6          Network
Requirements

 

6.6.1       NPAC
SMS WAN Topology Requirements

 

6.6.1.1    The 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.2       NPAC
SMS WAN Hardware Requirements

 

6.6.2.1    Enterprise
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.2    Local 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.1          Identification

 

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

 

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.1       Password
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.3          Access
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.1       System 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.2              Resource 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.4  Data 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.5  Audit

 

7.5.1              Audit 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.2              Reporting 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.6  Continuity 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.7  Software
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.8  OSI Security Environment

 

7.8.1              Threats

 

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

 

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

 

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

 

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

 

Switching customers to
various carriers without their consent

 

19

 

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

 

7.8.2              Security 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.3              Security Mechanisms

 

This section outlines the
requirements to specify security mechanisms.

 

7.8.3.1    Encryption

 

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

 

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.3    Data
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.4    Integrity
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.5    Access
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.6    Audit
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.7    Key
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.1  Service 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.2  NPAC 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.3  System 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.4  Audit 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.5  Requirements in the Proposal

 

RP8-1
Valid Audit Statuses

 

NPAC SMS shall support the
following valid audit statuses:

 

•                  In-progress

 

•                  Canceled

 

•                  Complete

 

7

 

8.6  Database 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.1  Overview

 

The NPAC SMS must support
scheduled and ad hoc report generation for selectable reports. The report
generation service shall create output report files according to specified
format definitions, and distribute reports to output devices as requested. A
report distribution service is used to distribute report files to selected
output devices. Authorized NPAC personnel can request reports from active
database, history logs, error logs, traffic measurements, usage measurements,
and performance reports.

 

9.2  User 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.3  System 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.1        Availability
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.2        Capacity 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.3  Requirements 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.1  User 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.2  System 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.3  Requirements
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
SMS Interoperable 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]
IMPLICIT               GraphicString(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]
IMPLICIT               GraphicString(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 chapter of 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.0                               PROPOSAL
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:

 

216

 

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.

 

217

 

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

 

218

 

•                  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

  

 

219

 

	
  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

  

 

220

 

	
  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

 

221

 

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

 

222

 

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.

 

223

 

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.

 

224

 

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.

 

225

 

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.

 

226

 

This Page Intentionally
Blank

 

227

 

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

 

 

228

 

software.  The Team also includes
three consultants—Mark Foster of
MDF Associates, John Shea, and Lisa Marie Maxson of Telecom Software Enterprises—all of whom 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 in Exhibit 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.

 

229

 

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.

 

230

 

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

 

231

 

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.

 

232

 

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

 

233

 

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

 

234

 

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

 

235

 

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

 

236

 

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

 

237

 

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

  

 

238

 

	
  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

  

 

239

 

	
  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.

  

 

240

 

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

 

241

 

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.

 

242

 

1.3.2                     Evolving
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.

 

243

 

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

 

244

 

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.3                     DSET
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).

 

245

 

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

 

246

 

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

 

247

 

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.

 

248

 

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

 

249

 

(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.4                     Stratus
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

 

250

 

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.

 

251

 

This Page Intentionally Blank

 

252

 

 

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

 

253

 

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

 

254

 

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.

 

255

 

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

 

256

 

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.

  

 

257

 

	
  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

  

 

258

 

	
  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.

  

 

259

 

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

 

260

 

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.

 

261

 

1.3.2                     Evolving
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.

 

262

 

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

 

263

 

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.3                     DSET
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).

 

264

 

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.4                     Stratus
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.4                               NEUTRALITY
(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.3                     NPAC 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.4                     NPAC
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.1                     Expansion 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.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.  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.9                               COMPLIANCE
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.0             FUNCTIONAL 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.1                     PROJECT
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-2 depicts
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.2                     IMPLEMENTATION
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.1           Preliminary 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-3 illustrates 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® ContinuumTM 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/RTM 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.3                        NPAC
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-16 shows 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.2                               BUSINESS
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-1 illustrates
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.3                               NPAC
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 in Exhibit 2.3-12 or 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.1                     NPAC/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-3 or
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.5                                           SUBSCRIPTION
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.3 contains 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.1           Record 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-4 and
2.5-5 illustrate 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-6 and 2.5-7 illustrate 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.1                             Modification
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-9 is 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.6                               NPAC 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.7                               SECURITY
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-4 shows 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.8                               AUDIT 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.1           On-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.2           On-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-6 to 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.1              Availability
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® ContinuumTM 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.11                        BILLING/RESOURCE
ACCOUNTING

(RFP Sect. 11)

 

2.11.1              Overview (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.12                        NUMBER
PORTABILITY ADMINISTRATION CENTER (RFP Sect. 12)

 

2.12.1 Number Portability Administration            Center (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-1 illustrates
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.2              System
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.

 

A single, 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-1 is
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-4 is 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.4                          System
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-1 illustrates 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.5                                NPAC 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 IDSTM 228 digital
telephone system from EXECUTONE Information
Systems to support our NPAC operations. 
This system is configured with advanced automatic call distribution and
system add-on INFOSTARTM/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 IDSTM  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 INFOSTARTM/VX2, the ISOTEC IDSTM  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 IDSTM 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.  Those assigned
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 President for 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, Senior Vice 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.13                              FUTURE
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

 

 

(2)              See Note 1 above.

 

(3)              [* * *]

 

(4)              The
TN Porting Event [* * *]

 

The TN Porting Event [* * *]

 

(5)              The one-time Log-on
ID [* * *]

 

(6)              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 than 2 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 15th
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.1                                 The 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.2                                 The 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.3                                 The term “Certified
System” shall have the meaning set forth in Section 7.3(b) hereof.

 

1.4                                The term “Confidential
Information” shall have the meaning set forth in Section 15.1 and 15.2 of
the Master Contract.

 

1.5                                The 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.6                                 The term “Customer”
shall mean the Northeast Carrier Acquisition Company, L.L.C.

 

1.7                                 The term “Effective
Date” shall mean the date of  this
Agreement, as set forth in the preamble to this Agreement.

 

1.8                                 The 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.9                                 The term “Party” or
“Parties” shall mean Contractor and/or Users.

 

1.10                          The term “Service
Establishment Date” shall have the meaning set forth in Article 8 hereof.

 

1.11                          The 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.12                           The term “Statements of
Work” shall have the meaning set forth in Section 7.12 hereof.

 

1.13                           The term “Test Schedule”
shall have the meaning set forth in Section 6.3 hereof.

 

1.14                          The term “Third Party” shall
mean any individual, corporation, partnership, association or other entity,
other than the Parties to this Agreement or the Customer.

 

1.15                          The term “User Data” shall
have the meaning set forth in Section 1.64 of the Master Contract.

 

 

ARTICLE 2 - MASTER CONTRACT TO GOVERN

 

2.1                                 Incorporation
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.2                                 Amendments
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.1                                 Representations 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.2                                 Representations
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.1                                 Provision
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.2                                 Connectivity
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.3                                 Testing
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.1                                 Payment
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.2                                 Disputed
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.3                                 Schedule 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.4                                 Update
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.5                                 Training
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.6                                 Use
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.7                                 Security,
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.8                                 User
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.9                                 Facilities
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.10                           Compliance
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.11                           Appointment
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.12                           Statements
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.13                           Interface
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.1                           Termination

 

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.2                           Force
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.1                           Damages

 

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 User and (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.2                           Insurance

 

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.3                        Self
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.4                        Failure 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.1                           Mutual
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, those based
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.2                           Contractor
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 those based 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.3                           Procedures

 

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.1                           Arbitration
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.2                           Exclusions
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.3                           Joinder
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.1                           Any
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.2                           All 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.1                           Relationship
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.2                           Headings

 

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.3                           Third-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.4                           Compliance
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.5                           Severability

 

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.6                           Survival

 

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.7                           No
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.8                           Advertising
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.9                           Governing
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.10                     Attorney’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

 

	
  NPAC SMS Error Messages

  	
   

  
	
   

  	
   

  
	
  Terms
  and Acronyms

  	
   

  
	
   

  	
   

  
	
  NPAC SMS
  Reports

  	
   

  
	
   

  	
   

  
	
  Download File Examples

  	
   

  
	
   

  	
   

  
	
  Subscription Download File

  	
   

  
	
   

  	
   

  
	
  Network
  Download File

  	
   

  
	
   

  	
   

  
	
  Encryption Key Exchange

  	
   

  
	
   

  	
   

  
	
  Key
  Exchange File

  	
   

  

 

 

	
  Key Acknowledgment File

  	
   

  
	
   

  	
   

  
	
  Key Exchange using PGP

  	
   

  
	
   

  	
   

  
	
  Service Element Usage
  Export File

  	
   

  
	
   

  	
   

  
	
  NPAC SMS Web Site

  	
   

  
	
   

  	
   

  
	
  Open
  NPA-NXX Data

  	
   

  
	
   

  	
   

  
	
  Open LRN Window

  	
   

  
	
   

  	
   

  
	
  NPAC Customer
  Information Window

  	
   

  

 

[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.1                                   Obligation
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.2                                   Identification 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.3                                   Deposit 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.4                                   Acceptance
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.5                                   Contractor’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.6                                   Verification.  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.7                                   Deposit
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.8                                   Removal 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.1                                   Confidentiality.  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.2                                   Status
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.3                                   Audit 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.1                                   Title
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.2                                   Right 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.3                                   Right
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.1                                   Filing
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.2                                   Release
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.3                                   Escrow 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.4                                   Resolution 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.5                                   Effect
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.1                                   Term 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.2                                   Termination
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.3                                   Termination
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.4                                   Disposition 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.5                                   Survival 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.1                                   Right
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.2                                   Indemnification. 
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.3                                   Dispute
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.4                                   Controlling 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.5                                   Notice 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.1                                   Entire
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.2                                   Notices.  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.3                                   Severability.  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.4                                   Successors.  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.5                                   Bankruptcy.  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.6                                   Regulations.  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.7                                   Waiver.  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.8                                   Assignment.
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-4

 

(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.3         Verification
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-5

 

4.1         Initial
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
+ 1⁄2 INTNcurr 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 by cumulative 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 by the 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
by the 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.3         Revision
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.4         Efforts
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.0                                           This
phase marks agreement between the parties for the implementation of the
Additional Services as described in the Schedule Notes.

 

Phase 1.0                                           This
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.0                                           This
phase involves detailed analysis of the requirements,

 

Phase 3.0                                           This
phase involves developing the Enhancement as well as any testing or
implementation tools and procedures.

 

Phase 4.0                                           This
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.0                                           This
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.0                                 COMPENSATION
AND PAYMENT

 

6.1                                 Compensation

 

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.1                     Interim
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.2                     Penalty

 

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.2                               Testing
Prices

 

6.2.1                     Industry
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.2                     LTI 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.3                               Payment
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

 

10

 

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 part of,
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 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

  

 

9.                                      PRICING

 

9.1                               Obligation.  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.2                               Price
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.3                               Price
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.4                               Payment
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 (30th) 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 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 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 NANC and 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 Service Level
  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 (30th)
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 the same 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.1                     Amendment
to Section 6.2.

 

4.3.1.1               Hotline 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.2               Charges
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.3               Customer
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 7th
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 46th 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 7th 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.3                                                Frequency

 

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.4                                                GEP
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.5                                                TN
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 30th 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 30th 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.6                        Specific
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.6                        Notices

 

(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.1                                 The 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.2                                 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 25NE.

 

5.3                                 The
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 Service Level
  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.4                                 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

 

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.7                                 If
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 the same document.  All
such counterparts shall be deemed an original, shall be construed together and
shall constitute one and the same instrument.

 

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

 

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 15th 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.1       SOW 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.2                               Revision 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.0                                 Miscellaneous.

 

6.1                                 The
following are the impacts on the Master Agreement:

 

                                   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

 

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

 

6.4                                 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

 

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.5                                 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 SOW, as
modified from time to time.

 

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

 

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

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

                                  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

 

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 Platform support 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 the NPAC/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.0                                           This
phase marks agreement between the parties for the implementation of the
Additional Services.

 

Phase 1.0                                           This
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.0                                           This
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.0                                           This
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/A                         Functional
Requirements Specifications

N/A                         Requirements
Traceability Matrix

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

                                      User
Documentation

N/A                         Software
Configuration Management Plan

N/A                         Standards
and Metrics

 

7.                                      IMPACTS ON
MASTER AGREEMENT (Includes Existing Specifications).

 

None                   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

 

8.                                      COMPENSATION
AND PAYMENT

 

8.1                               Compensation

 

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.2                               Payment
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 (30th) 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.3                               Secured
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.4                               Price
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 the same 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.1                                 Modifies
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.2                                 Settlement.  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.3                                 Reservations.  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.1                                 Computation.  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.2                                 Payment
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.3                                 Customer
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.4                                 Seventeen
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.1                                 Dispute.  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.2                                 Representation.  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.1                                 Pricing
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.2                                 Inapplicability
of Article 29.  Article 29
of the Master Agreement shall not apply with respect to the execution and
delivery of this Amendment.

 

6.3                                 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

  

 

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.4                                 SOW25.  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.5                                 Numbering
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.1                                 Counterparts  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.

 

7.2                                 Severability.  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.3                                 Joinder.
 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.4                                 No
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.5                                 Entire
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 22nd 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

 

	
   

  	
   

  	
  TN Porting
  Event (4)

  	
   

  	
  The price
  per TN Porting Event in the Service Area will be determined by application of
  [***] Rate Card No. 2, as set forth and defined below.

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  [***]

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  Rate Card
  No. 2. Commencing January 1, 2004, if the cumulative
  TN Porting Events since the Effective Date of the Master Agreement that have
  occurred in the Service Area on or before December 31, 2003 equal or exceed
  10,000,000, the following schedule of charges per TN Porting Event in the
  Service Area shall apply thereafter, based upon the cumulative number of TN
  Porting Events that have occurred in the Service Area after December 31, 2003
  (such schedule hereinafter referred to as “Rate Card No. 2”)

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  < 35,714,285

  	
   

  	
  $

  	
  1.08

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  35,714,286 – 71,428,571

  	
   

  	
  $

  	
  1.05

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  71,428,572 – 107,142,857

  	
   

  	
  $

  	
  1.03

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  107,142,858 – 142,857,142

  	
   

  	
  $

  	
  1.00

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  142,857,143 – 178,571,428

  	
   

  	
  $

  	
  0.97

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  178,571,429 – 214,285,714

  	
   

  	
  $

  	
  0.95

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  >214,285,714

  	
   

  	
  $

  	
  0.93

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](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 3rd 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.1                                 Deletion
of Article 6: Fixed Credit Payments.  

 

Article 6 (Fixed Credit
Payments) of Amendment No. 42 is hereby deleted in its entirety.

 

5.2                                 Deletion
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.2                           Fixed
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.3                           Variable
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.1                           Overview.  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.2                           Computation.  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

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  	
  < 100,000,000

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  
	
  Tier 1 Volume Range:

  100,000,000 – 126,591,000

  	
   

  	
  $

  	
  0.188

  	
   

  	
  $

  	
  5,000,000

  	
   

  	
  Tier 1 Volume Range:
  100,000,000-130,098,000

  	
   

  	
  $

  	
  0.166

  	
   

  	
  $

  	
  5,00,000

  	
   

  
	
  Tier 2 Volume Range:

  126,591,001 – 153,182,000

  	
   

  	
  $

  	
  0.094

  	
   

  	
  $

  	
  2,500,000

  	
   

  	
  Tier 2 Volume Range:
  130,098,001 – 160,195,000

  	
   

  	
  $

  	
  0.083

  	
   

  	
  $

  	
  2,500,000

  	
   

  
	
  >153,182,000

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  	
  >160,195,000

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  

 

	
   

  	
   

  	
  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

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  	
  < 100,000,000

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  
	
  Tier 1 Volume Range:

  100,000,000 – 129,994,000

  	
   

  	
  $

  	
  0.100

  	
   

  	
  $

  	
  3,000,000

  	
   

  	
  Tier 1 Volume Range:
  100,000,000-127,394,000

  	
   

  	
  $

  	
  0.110

  	
   

  	
  $

  	
  3,000,000

  	
   

  
	
  Tier 2 Volume Range:

  129,994,001 – 159,987,000

  	
   

  	
  $

  	
  0.050

  	
   

  	
  $

  	
  1,500,000

  	
   

  	
  Tier 2 Volume Range: 127,394,001
  – 154,787,000

  	
   

  	
  $

  	
  0.055

  	
   

  	
  $

  	
  1,500,000

  	
   

  
	
  >159,987,000

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  	
  >154,787,000

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  

 

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

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  	
  < 100,000,000

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  
	
  Tier 1 Volume Range:

  100,000,000 – 126,120,000

  	
   

  	
  $

  	
  0.115

  	
   

  	
  $

  	
  3,000,000

  	
   

  	
  Tier 1 Volume Range:
  100,000,000-124,859,000

  	
   

  	
  $

  	
  0.121

  	
   

  	
  $

  	
  3,000,000

  	
   

  
	
  Tier 2 Volume Range:

  126,120,001 – 152,240,000

  	
   

  	
  $

  	
  0.057

  	
   

  	
  $

  	
  1,500,000

  	
   

  	
  Tier 2 Volume Range: 124,859,001
  – 149,717,000

  	
   

  	
  $

  	
  0.060

  	
   

  	
  $

  	
  1,500,000

  	
   

  
	
  >152,240,000

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  	
  >149,717,000

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  

 

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

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  
	
  Tier 1
  Volume Range:

  100,000,000 –123,610,000

  	
   

  	
  $

  	
  0.127

  	
   

  	
  $

  	
  3,000,000

  	
   

  
	
  Tier 2
  Volume Range:

  123,610,001 –147,220,000

  	
   

  	
  $

  	
  0.064

  	
   

  	
  $

  	
  1,500,000

  	
   

  
	
  >147,220,000

  	
   

  	
  $

  	
  0

  	
   

  	
  $

  	
  0

  	
   

  

 

34.3                           Timing
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 1st, 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.4                           Invoice
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.5                           Application
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 20th 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

  	
   

  
	
   

  	
   

  	
  TN Porting
  Event (4)

  	
   

  	
  The price
  per TN Porting Event in the Service Area will be determined by application of
  [***] Rate Card No. 2, as set forth and defined below.

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  [***]

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  Rate Card
  No. 2. Commencing January 1, 2004, if the cumulative
  TN Porting Events since the Effective Date of the Master Agreement that have
  occurred in the Service Area on or before December 31, 2003 equal or exceed
  10,000,000, the following schedule of charges per TN Porting Event in the
  Service Area shall apply thereafter, based upon the cumulative number of TN
  Porting Events that have occurred in the Service Area after December 31, 2003
  (such schedule hereinafter referred to as “Rate Card No. 2”)

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  < 35,714,285

  	
   

  	
  $

  	
  1.08

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  35,714,286 – 71,428,571

  	
   

  	
  $

  	
  1.05

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  71,428,572 – 107,142,857

  	
   

  	
  $

  	
  1.03

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  107,142,858 – 142,857,142

  	
   

  	
  $

  	
  1.00

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  142,857,143 – 178,571,428

  	
   

  	
  $

  	
  0.97

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  178,571,429 – 214,285,714

  	
   

  	
  $

  	
  0.95

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  >214,285,714

  	
   

  	
  $

  	
  0.93

  	
   

  
	
   

  	
   

  	
  [* * *](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 2nd 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.1                              Requests 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.2                              Limitations 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.7                        Intermodal
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.1           As 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.2           Unless 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.1           Without 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.2           Contractor 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.3           In 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.4           If 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.1          LNP 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.2           Consent 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.3           Further 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.1           NAPM 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.2           Except 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.3           This 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.4           If 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.5           This 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.6           This 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.7           All 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

 

	
  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 

 

1

 

	
  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]

 

2

 

	
  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:

  	
   

  	
   

  
					

 

3

 

	
  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)  [* * *]

 

4

 

	
  Amendment
  No.47-NAPM(NE)

  	
   

  	
  February 20, 2004

  

Sow:       No

                _ Yes

 

	
  Category

  	
   

  	
  Service Element

  	
   

  	
  Unit

  	
   

  	
  Price

  	
   

  
	
   

  	
   

  	
  [* * *](4)

  	
   

  	
  [* * *]

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](5)

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](6)

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](7)

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  

 

(4) [* * *]

(5) [* * *]

(6) [* * *]

(7) [* * *]

 

5

 

	
  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
[* * *]

 

6

 

	
  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) [* * *]

 

7

 

	
  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.

 

8

 

	
  Amendment
  No.47-NAPM(NE)

  	
   

  	
  February 20, 2004

  

Sow:       No

                _ Yes

 

	
   

  	
   

  	
  Jan-98

  	
   

  	
  Feb-98

  	
   

  	
  Mar-98

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
    [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
    [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
    [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]*

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]*

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

	
  * [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  

 

 

9

 

	
  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

 

10

 

	
  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 2nd 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.1                              Requests 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 

 

11

 

	
  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.2                              Limitations 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.7                        Intermodal
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 

 

12

 

	
  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, 

 

13

 

	
  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 

 

14

 

	
  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 

 

15

 

	
  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 

 

16

 

	
  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.

 

17

 

	
  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

 

18

 

	
  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 

 

19

 

	
  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 

 

20

 

	
  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.

 

21

 

	
  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 

 

22

 

	
  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

 

23

 

	
  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 

 

24

 

	
  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 

 

25

 

	
  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)

  

 

26

 

	
  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.

 

27

 

	
  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]

 

28

 

	
  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:

  	
   

  	
   

  
					

 

29

 

	
  Amendment
  No.48-NAPM(NE)

  	
   

  	
  April 2, 2004

  

Sow:       No

                _ Yes

 

EXHIBIT O

 

INTERMODAL PORTED TN IDENTIFICATION SERVICE
AGREEMENT

 

30

 

	
  Amendment
  No.48-NAPM(NE)

  	
   

  	
  April 2, 2004

  

Sow:       No

                _ Yes

 

 

31

 

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.1           As 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.2           Unless
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.1           Without
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.2           Contractor
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.3           In
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.4           If
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.1          LNP 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.2           Consent 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.3           Further 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.1           NAPM
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.2           Except
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.3           This
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.4           If 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.5           This
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.6           This
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.7           All
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

  

 

6Exhibit 10.2.1

 

Pursuant to 17 CFR
240.24b-2, 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.

 

	
  Amendment No. 46(CA) Rev. 1

  	
   

  	
  Date: June 1, 2005

  
	
  SOW:

  	
  ý No

  	
   

  	
   

  
	
   

  	
  o Yes

  	
   

  	
   

  

 

 

AMENDMENT

TO

CONTRACTOR SERVICES AGREEMENT

FOR

NUMBERING ADMINISTRATION CENTER / SERVICE 

MANAGEMENT SYSTEM 

ANNUAL UPDATE TO CONVERSION FACTOR

FOR THE PERIOD JUNE 1, 2005 TO MAY 31, 2006

 

1

 

AMENDMENT

TO

CONTRACTOR SERVICES AGREEMENT FOR NUMBERING 

ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM

 

Annual Update to
Conversion Factor

 

For the Period June 1,
2005 to May 31, 2006

 

1.                                      PARTIES

 

This Revision 1 (“Revision”) of Amendment
Number 46 ( “Amendment 46”) is entered into pursuant to Article 30 of, and
upon execution shall be a part of, the Contractor Services Agreement for Number
Portability Administration Center/Service Management System (the “Master
Agreement”) by and between NeuStar, Inc., a Delaware corporation (“Contractor”)
and the Canadian LNP Consortium, Inc., a corporation incorporated under
the laws of Canada (the “Customer”).

 

2.                                      EFFECTIVENESS

 

This Revision shall be effective as of the 1st
day of June 2005 (the “Revision Effective Date”) only upon execution of
this Revision by Contractor and Customer. 
The number in the upper left-hand corner refers to this Revision.  Undefined capitalized terms used herein shall
have the meanings ascribed by the Master Agreement.

 

3.                                      ANNUAL UPDATE

 

Pursuant to that certain Amending Agreement,
effective March 31, 2003 (the “Amending Agreement”), of the Master
Agreement, Contractor and Customer agreed to specify all amounts chargeable,
payable, or to be credited under the Master Agreement, including, for greater
certainty and without limitation, amounts listed in Exhibit E, Exhibit G
and amounts under or pursuant to any Statement of Work and any Performance
Credits, in Canadian dollars, but except as otherwise provided in the Amending
Agreement.  For the period June 1,
2003 to May 31, 2004, each such dollar amount, was initially converted
from its U.S. dollar amount into Canadian dollars by multiplying each such
amount by a conversion factor equal to 1.5723.

 

In accordance with the terms of the Amending
Agreement, effective on each anniversary of the Amending Agreement, the
conversion factor set forth above is recomputed based on the average of the
exchange rates for each of the last five (5) Business Days in the month of
April immediately preceding the applicable anniversary of the Amending
Agreement’s effective date, as published in the Key Currency Cross Rates column
of the Wall Street Journal.  In
accordance with the terms and conditions of the Amending Agreement, the
conversion factor for the period of June 1, 2004 to May 31, 2005 was
calculated to equal 1.3612, as reflected in Amendment 46.

 

2

 

In accordance with the terms and conditions
of the Amending Agreement, the conversion factor for the period of June 1,
2005 to May 31, 2006 was calculated to equal 1.2484.

 

Finally, as a result of the requirements in
Statement of Work 40 (VPN Access to NPAC/SMS for LTI Users), the entry under
Item No. 1 (Monthly Charges) in Schedule 1 (Service Element Fees Unit
Pricing) of Exhibit E to the Master Agreement, whose Service Element is
styled “Dial-Up Port to NPAC network”, is hereby deleted in its entirety.

 

4.                                      AMENDMENT AND RESTATEMENT

 

Effective on the Revision Effective Date, and
throughout the Initial Term, the parties hereby amend and restate Exhibit E
and Exhibit G to the Master Agreement and Article 16 of the Master
Agreement in their entirety to reflect all amounts chargeable, payable, or to
be credited under the Master Agreement in Canadian dollars based on the
conversion factor set forth in Article 3 above (attached hereto as
Attachments 1, 2 and 3, respectively). 
Notwithstanding the foregoing, except when and as otherwise expressly
provided by a written agreement between Contractor and Customer, and subject to
the reservation in Article 5 below, any amended and restated document
attached hereto is intended for information purposes only.

 

5.                                      RESERVATION

 

The rights and obligations of the parties
with respect to the calculation and application of a conversion factor are
defined in the Master Agreement, as amended by the Amending Agreement.  It is the intent of the parties that neither
party will be prejudiced by any errors or mistakes in calculating any
conversion factor or by the application of any conversion factor.  Upon the discovery of any such error or
mistake, the parties will promptly and in good faith issue a correction; e.g.,
by issuing a revised Statement of Work.

 

6.                                      COMPLETION AND ACCEPTANCE CRITERIA

 

The following internal documents are
applicable to the Additional Services contemplated under this Revision:

 

	
  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

  

 

3

 

7.                                      IMPACTS ON MASTER AGREEMENT.

 

The following portions of the Master
Agreement are impacted by this Revision:

 

	
  ý

  	
   

  	
  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 Service Level Requirements

  
	
  None

  	
   

  	
  Exhibit H Reporting and Monitoring Requirements

  
	
  None

  	
   

  	
  Exhibit I Key Personnel

  
	
  None

  	
   

  	
  Exhibit J User Agreement Form

  
	
  None

  	
   

  	
  Exhibit K External Design

  
	
  None

  	
   

  	
  Exhibit L Infrastructure/Hardware

  
	
  None

  	
   

  	
  Exhibit M Software Escrow Agreement

  
	
  None

  	
   

  	
  Exhibit N System Performance Plan for NPAC/SMS Services

  
	
  None

  	
   

  	
  Exhibit O Statement of Work Cost Principles

  

 

8.                                      MISCELLANEOUS.

 

8.1                                 Continuation of Master Agreement and User
Agreement.

 

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 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
Revision.  From and after the Revision
Effective Date, this Revision shall be a part of the Master Agreement and, as
such, shall be subject to the terms and conditions therein.

 

8.2                                 Counterparts.

 

This Revision 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.

 

8.3                                 Entire Agreement.

 

This Revision 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.

 

4

 

[THIS SPACE
INTENTIONALLY LEFT BLANK]

 

5

 

IN WITNESS WHEREOF, the undersigned have
executed and delivered this Revision 1 to Amendment No. 46:

 

	
  CONTRACTOR:

  	
  NeuStar, Inc.

  	
   

  	
   

  
	
   

  	
   

  
	
  By:

  	
   

  	
   

  
	
   

  	
   

  
	
  Its:

  	
   

  	
   

  
	
   

  	
   

  
	
  Date:

  	
   

  	
   

  
	
   

  	
   

  
	
  CUSTOMER:

  	
  Canadian LNP
  Consortium, Inc.

  	
   

  
	
   

  	
   

  
	
  By:

  	
   

  	
   

  
	
   

  	
   

  
	
  Its:

  	
   

  	
   

  
	
   

  	
   

  
	
  Date:

  	
   

  	
   

  
								

 

6

 

ATTACHMENT
1

TO

REVISION 1 TO AMENDMENT NO. 46(CA)

 

Amended and Restated Exhibit E
to Master Agreement

 

7

 

EXHIBIT E

 

PRICING
SCHEDULES

 

NPAC/SMS
SERVICES

 

This amended
and restated document is intended for information purposes only.  The rights and obligations of the parties are
defined in the Contractor Services Agreement dated May 19, 1998, as
amended by the Canadian NPAC/SMS Contractor Services Agreement Amending
Agreement, dated March 31, 2003.  Exhibit E
updated effective June 1, 2005.

 

 

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.

 

Notwithstanding anything in the Agreement to
the contrary: (a) all amounts chargeable, payable, or to be credited under
the Agreement, including, for greater certainty and without limitation, amounts
listed in Exhibit E, Exhibit G and amounts under or pursuant to any
Statement of Work and any Performance Credits, shall be in Canadian dollars;
and (b) all amounts described in subparagraph (a)immediately above,
excluding the amount set forth in Sections 20.1(iv) (which amount shall
continue to be denominated in US dollars) and 20.4(iv) (which amount shall
continue to be denominated in Canadian dollars as set forth below), will be
adjusted as follows:

 

(I)                                    effective on the
Effective Date, for the period June 1, 2003 to May 31, 2004, each
such dollar amount, shall be converted from its U.S. dollar amount, as such
amounts appear in the Agreement immediately prior to the Effective Date (other
than such of those amounts expressly amended by an Amending Agreement between
Contractor and Customer, dated March 31, 2003, which amended amounts shall
be utilized for the purposes of the conversion described herein) into Canadian
dollars by multiplying each such amount by the number 1.5723; and

 

(II)                                effective on each
anniversary of the Effective Date, each such dollar amount shall be converted
from its U.S. dollar amount, as such U.S. dollar amounts appear in the
Agreement immediately prior to the Effective Date (other than such of those
amounts expressly amended by an Amending Agreement between Contractor and
Customer, dated March 31, 2003, which amended amounts shall be utilized
for the purposes of the conversion described herein), into Canadian dollars by
multiplying each such amount by the average of the exchange rates for each of
the last five (5) Business Days in the month of April immediately
preceding the applicable anniversary of the Effective Date, as published in the
Key Currency Cross Rates column of the Wall Street Journal.

 

Effective on the Effective Date, and throughout
the Initial Term, the dollar amount set forth in Section 20.4  will be adjusted by multiplying such dollar
amount by the number 1.0000.

 

Within fifteen (15) days following the last
Business Day in April of each year, the parties shall amend and restate Exhibit E,
Exhibit G, and Article 16 in their entirety, to reflect all dollar
amounts in Canadian dollars based on the applicable exchange rate.

 

The exchange rate determined at the June 1,
2005 anniversary is 1.2484.

 

E-1

 

Schedule 1

 

Service
Element Fees/Unit Pricing

 

	
  Category

  	
   

  	
  Service Element

  	
   

  	
  Unit

  	
   

  	
  Price

  U.S.

  Dollars

  	
   

  	
  Price

  Canadian

  Dollars

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
  (1)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
  (1)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
  (3)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
  (4)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  [* * *]

  [* * *]

  	
   

  	
  $

  	
  [* * *]

  [* * *]

  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  [* * *] 

  	
   

  	
  [* * *]

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
  (5)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
  (6)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
  (7)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
  (8)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
   

  	
   

  	
  [* * *]

  	
  (9)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
												

 

Schedule 2

 

Training
Charges

 

	
  Service Element

  	
   

  	
  Unit

  	
   

  	
  Price

  U.S.

  Dollars

  	
   

  	
  Price

  Canadian

  Dollars

  
	
  [* * *]* [*
  * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
  [* * *]* [*
  * *] (10) (11)

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  

 

*  Training consists of LTI User Training
lasting 8 to 12 hours.

 

E-2

 

Schedule 3

 

Interoperability
Testing *

 

	
  Category & Service

  Element

  	
   

  	
  Unit

  	
   

  	
  Price

  	
   

  	
  Price Canadian

  Dollars

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  
	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  

 

*                                         [* * *]

(1)                                  Monthly
port charges [* * *]

(2)                                  Reserved

(3)                                  [*
* *]

(4)                                  The
TN Porting Event [* * *]

The TN Porting Event [* *
*]

(5)                                  An
Ad Hoc Report [* * *]

(6)                                  [*
* *]

(7)                                  [*
* *]

(8)                                  The
one-time Log-on ID [* * *]

(9)                                  The
Mechanized Interface [* * *]

(10)                            [* *
*]

(11)                            [* *
*]

 

E-3

 

ATTACHMENT
2

TO

REVISION 1 TO AMENDMENT NO. 46(CA)

 

Amended and Restated Exhibit G
to Master Agreement

 

8

 

EXHIBIT G

 

SERVICE LEVEL REQUIREMENTS

 

NPAC/SMS

 

	
  No.

  	
   

  	
  Procedure

  	
   

  	
  Service Commitment Level

  	
   

  	
  Service Affecting/

  Non-Service Affecting

  	
   

  	
  Performance Credit US

  Dollars

  	
   

  	
  Performance Credit

  Canadian Dollars

  	
   

  	
  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%: $[* * *]

  	
   

  	
  >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 than 20 hours per calendar quarter, or such longer period otherwise
  agreed to by the Parties, provided that such twenty (20) hour period (each, a
  “20 Hour Period”) shall not include time reasonably required for release
  implementations, data rebuilds, and other non-routine tasks (the time for
  which shall be agreed to on a case by case basis). Contractor shall, not less
  than ten (10) business days prior to, and not less than four (4) business
  days after, each Scheduled Service Unavailability event, provide to Customer
  a request for maintenance and report, respectively, both in the form of Annex
  A attached to this Exhibit G. Contractor shall not proceed with the
  proposed Scheduled Service Unavailability unless it has received prior
  written approval (e-mail is acceptable) from Customer for its request for
  maintenance, which approval shall not be unreasonably withheld. For greater
  certainty, for any Scheduled Service Unavailability in excess of 20 hours in
  each 20 Hour Period, Customer shall be entitled to enforce all remedies
  available to it, including without limitation Performance Credits as set
  forth in this SLR 2. No Scheduled Service Unavailability event shall exceed
  ten (10) hours. Each such event shall be scheduled in advance and shall
  be coordinated with each User’s maintenance schedule.

  	
   

  	
  Service Affecting

  	
   

  	
  $[* * *] for each hour or portion thereof in excess
  of approved Scheduled Service Unavailability or such longer period otherwise
  agreed to by the Parties

  	
   

  	
  $[* * *] for each hour or portion thereof in excess
  of approved Scheduled Service Unavailability or such longer period otherwise
  agreed to by the Parties

  	
   

  	
  Monthly

  

 

 

	
  No.

  	
   

  	
  Procedure

  	
   

  	
  Service Commitment Level

  	
   

  	
  Service Affecting/

  Non-Service Affecting

  	
   

  	
  Performance Credit US

  Dollars

  	
   

  	
  Performance Credit

  Canadian Dollars

  	
   

  	
  Report

  Frequency and

  Performance Credit

  Calculation Interval

  
	
  3.

  	
   

  	
  SOA/LSMS Acknowledge- ment 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 10 transactions per second per
  User LSMS for 95% of the transactions (excluding the impact of delays caused
  by Users)

  	
   

  	
  Service Affecting

  	
   

  	
  $[* * *]

  	
   

  	
  $[* * *]

  	
   

  	
  Monthly

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  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%: $[* * *]

  	
   

  	
  >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

  	
   

  	
  $[* * *] 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

  	
   

  	
  $[* * *] 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 US

  Dollars

  	
   

  	
  Performance Credit

  Canadian Dollars

  	
   

  	
  Report

  Frequency and

  Performance Credit

  Calculation Interval

  
	
  11.

  	
   

  	
  RESERVED

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  12.

  	
   

  	
  User Problem Resolution

  	
   

  	
  Minimum 80% calls during Normal Business Hours
  answered by live operators within 10 seconds

  	
   

  	
  Non-Service Affecting

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  Monthly

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  13.

  	
   

  	
  RESERVED

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  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.

  	
   

  	
  RESERVED

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  17.

  	
   

  	
  RESERVED

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  18.

  	
   

  	
  System Security

  	
   

  	
  Monitor and record unauthorized system access

  	
   

  	
  Non-Service Affecting

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  Per Event

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  19.

  	
   

  	
  System Security

  	
   

  	
  Remedy logon security permission errors immediately
  after User notification

  	
   

  	
  Non-Service Affecting

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  Per Event

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  20.

  	
   

  	
  RESERVED

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  21.

  	
   

  	
  Scheduled Service Unavailability Notification

  	
   

  	
  Notice of Scheduled Service Unavailability for
  routine maintenance of NPAC/SMS to be given a minimum of 2 weeks in advance. 

  

  Notice of Scheduled Service Unavailability for non-routine maintenance of 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

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  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

  

 

 

	
  No.

  	
   

  	
  Procedure

  	
   

  	
  Service Commitment Level

  	
   

  	
  Service Affecting/

  Non-Service Affecting

  	
   

  	
  Performance Credit US

  Dollars

  	
   

  	
  Performance Credit

  Canadian Dollars

  	
   

  	
  Report

  Frequency and

  Performance Credit

  Calculation Interval

  
	
  24.

  	
   

  	
  RESERVED

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  25.

  	
   

  	
  RESERVED

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  26

  	
   

  	
  RESERVED

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  27.

  	
   

  	
  RESERVED

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  

 

 

ATTACHMENT
3

TO

REVISION 1 TO AMENDMENT NO. 46(CA)

 

Amended and Restated Article 16
of the Master Agreement

 

9

 

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

 

16.1                           Notice
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 delay in Contractor’s performance of an
obligation by the date specified therefor, if any, in this Agreement, 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 a 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.2                           [Deleted]

 

16.3                           Performance
Credits

 

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
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 CA$ [* *
*].  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.  [Amended]

 

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.4                           Allocation
of Damages Among Users

 

The aggregate amount of accrued liquidated
damages under Section 16.3 above shall be allocated among Users as
directed by Customer and credited against the next succeeding monthly billing
to such Users for Services 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 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). [Amended]

 

16.5                           Contractor
Defaults

 

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

 

(a)                                  chronically fail to
provide the Canadian NPAC/SMS at one or more of the “Service Affecting” Service
Levels, which failure is evidenced by recurring events of the same or similar
nature that are indicative of a systemic problem and which either have been
unaffected by Contractor’s repeated cure efforts, if any, 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 30 days; or  [Amended]

 

(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 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 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.6                           Force
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 is directly or
indirectly caused 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 or Canada, court order, or the occurrence of a Force
Majeure Event (as otherwise defined herein) affecting the non-performing Party’s
first-tier suppliers, subcontractors or agents (i.e.,not subcontractors of
subcontractors), or any other similar cause beyond the reasonable control of
such Party and without the fault or negligence of such Party and which cannot
be reasonably circumvented by the non-performing Party through the use of
alternate sources, workaround plans or other means (each, 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 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.

 

ws51D.tmp

Source: [{"source": "alea-institute/alea-institute/kl3m-data-edgar-agreements/train-00089-of-00352.parquet"}, [{"source": "alea-institute/alea-institute/kl3m-data-edgar-agreements/train-00089-of-00352.parquet"}]]