Document:

Exhibit
4.2

 

 

 

 

[FACE
OF CERTIFICATE]

NUMBER

NB

[LOGO]

NEUSTAR,
INC.

INCORPORATED
UNDER THE LAWS OF THE STATE OF DELAWARE

CLASS B
COMMON STOCK

SHARES

SEE
REVERSE FOR CERTAIN DEFINITIONS

THIS
CERTIFIES that

is
the owner of

FULLY
PAID AND NON-ASSESSABLE SHARES OF THE CLASS B COMMON STOCK, PAR VALUE OF
$0.001 PER SHARE, OF

NEUSTAR,
INC.

transferable
on the books of the Corporation by the holder hereof in person or by duly
authorized attorney upon surrender of this Certificate properly endorsed. This
Certificate is not valid unless countersigned and registered by the Transfer
Agent and Registrar.

IN
WITNESS WHEREOF, said Corporation has caused this Certificate to be signed in
facsimile by its duly authorized officers, and its Corporate Seal to be affixed
in facsimile.

Dated:

/s/

SECRETARY

[SEAL]

/s/

CHAIRMAN

COUNTERSIGNED
AND REGISTERED:

WACHOVIA
BANK, N.A.

(CHARLOTTE,
N.C.)

TRANSFER
AGENT AND REGISTRAR

BY

AUTHORIZED
SIGNATURE

 

[REVERSE
OF CERTIFICATE]

The
Corporation is authorized to issue more than one class or series of stock. The
Corporation will furnish without charge to each stockholder who so requests the
powers, designations, preferences and relative, participating, optional or
other special rights of each class of stock or series thereof and the qualifications,
limitations or restrictions of such preferences and/or rights.

The
shares represented by this certificate are subject to restrictions on ownership
and transfer set forth in Article IV of the Corporation’s Restated
Certificate of Incorporation. In addition to certain further restrictions and
except as expressly provided in the Corporation’s Restated Certificate of
Incorporation, no TSP or TSP Affiliate may Beneficially Own shares of the
Corporation’s Capital Stock equal to, or in excess of, five percent (5.0%) of
the voting power of the Corporation, unless such Person is an Excepted Holder
(in which case the Excepted Holder Limit shall be applicable). Any Person who
Beneficially Owns or attempts to Beneficially Own shares of Capital Stock which
causes or will cause a Person to Beneficially Own shares of Capital Stock in
excess or in violation of the above limitations must immediately notify the
Corporation. If any of the restrictions on transfer or ownership are violated,
the holder of the shares of Capital Stock represented hereby will be required
to sell excess shares immediately either to the Corporation or its designee (at
the Corporation’s election) or to another Person whose Beneficial Ownership of
such shares will not violate such restrictions on transfer or ownership. All
capitalized terms in this legend have the meanings defined in the Corporation’s

 

 

Restated
Certificate of Incorporation, as the same may be amended from time to time, a
copy of which, including the restrictions on transfer and ownership, will be
furnished to each holder of Capital Stock of the Corporation on request and
without charge. Requests for such a copy may be directed to the Secretary of
the Corporation at its principal office.

The
following abbreviations, when used in the inscription on the face of this
certificate, shall be construed as though they were written out in full
according to applicable laws or regulations:

TEN
COM - as tenants in common

TEN
ENT - as tenants by the entireties

JT
TEN - as joint tenants with right of survivorship and not as tenants in common

UNIF
GIFT MIN ACT–

        (Cust)                 Custodian       (Minor)                 
under Uniform Gifts to Minors Act          (State)              

Additional
abbreviations may also be used though not in the above list.

For
value received, hereby sell, assign and transfer unto

PLEASE
INSERT SOCIAL SECURITY OR OTHER IDENTIFYING NUMBER OF ASSIGNEE

(PLEASE
PRINT OR TYPEWRITE NAME AND ADDRESS, INCLUDING ZIP CODE, OF ASSIGNEE)

shares
of the capital stock represented by the within Certificate, and do hereby
irrevocably constitute and appoint

Attorney
to transfer the said stock on the books of the within named Corporation with
full power of substitution in the premises.

Dated

NOTICE:
THE SIGNATURE TO THIS ASSIGNMENT MUST CORRESPOND WITH THE NAME AS WRITTEN UPON
THE FACE OF THE CERTIFICATE IN EVERY PARTICULAR, WITHOUT ALTERATION OR
ENLARGEMENT OR ANY CHANGE WHATSOEVER.

Signature(s)
Guaranteed:

THE
SIGNATURE(S) MUST BE GUARANTEED BY AN ELIGIBLE GUARANTOR INSTITUTION (BANKS,
STOCKBROKERS, SAVINGS AND LOAN ASSOCIATIONS AND CREDIT UNIONS WITH MEMBERSHIP
IN AN APPROVED SIGNATURE GUARANTEE MEDALLION PROGRAM), PURSUANT TO S.E.C. RULE
17Ad-15.

KEEP
THIS CERTIFICATE IN A SAFE PLACE. IF IT IS LOST, STOLEN, MUTILATED OR
DESTROYED, THE CORPORATION WILL REQUIRE A BOND OF INDEMNITY AS A CONDITION TO
THE ISSUANCE OF A REPLACEMENT CERTIFICATE.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:

 

1

 

Proposal Benefits and Features

 

•                  Completely
neutral, experienced Lockheed Martin Team, with full backing and resources of
$30 billion Lockheed Martin Corporation, has been working aggressively toward
NPAC/SMS deployment, initially for Illinois.

 

•                  Demonstrated
commitment of the Lockheed Martin Team to work cooperatively and innovatively
with the industry as a team player for LNP to satisfy FCC and industry
deployment timetables.

 

•                  Assured
on-time delivery of NPAC/SMS on May 15, 1997, and start of “live”
operations by October 1, 1997.

 

•                  Demonstrated
leadership and competence, having developed open, non-proprietary NPAC/SMS
technical standards: NPAC SMS Interoperable Interface Specification (IIS) and
NPAC SMS Generic Functional Requirements Specification (G-FRS).

 

•                  Fully
regionalized NPAC/SMS incorporating the latest industry business process flows
and numerous enhancements, including support for location portability.

 

•                  NPAC
SMS service scalability through distributed SMS service and software architecture
engineered for full regional loads.

 

•                  Highest
operational integrity, with service assurance capabilities including
mutual-database integrity sampling, to ensure consistency of LNP routing data
throughout New York and, when desired, the surrounding region.

 

2

 

•                  Highest
possible NPAC/SMS service availability through network element-level
availability and engineering standards using a diverse, fault-tolerant,
real-time synchronized, mated-pair architecture.  Cut-over to the backup system is virtually
instantaneous, without causing NPAC service disruption or outage.

 

•                  Hands-on
experience of providing support for service-provider system (LSMS, SOA)
vendors/implementers, including interoperability testing (lab-to-lab developer
testing) as demonstrated in interface forums conducted to train
vendors/developers in the implementation of the NPAC SMS interfaces.

 

•                  Harmonized
NPAC/SMS service offerings across the industry providing technical operating
efficiencies and cost-sharing across regions, including standard national
NPAC/SMS service pricing for all regions the Lockheed Martin Team may be
selected to serve.

 

Corporate Commitment

 

Lockheed Martin IMS (IMS), with the full
backing and support of the Lockheed Martin Corporation, is fully committed to
supporting the needs of the telecommunications industry.  Our Communications Industry Services (CIS)
line of business is dedicated solely to providing neutral services, like LNP,
required by communications services providers. 
CIS is managed and staffed by experienced, dedicated individuals from
within the telecommunications industry who are keenly aware of the
sensitivities and needs of the industry at this significant time in the
industry’s history.  Those needs include:

 

•                  Experienced
neutral and evenhanded third parties;

 

•                  Guaranteed
on-time, low-risk service delivery;

 

•                  Extremely
highly-reliable and consistent service and systems;

 

3

 

•                  A
partner sensitive to the demands, timetables, and ever-changing landscape of
the current regulatory environment;

 

•                  Subject
matter expertise in key technologies, such as LNP, SMS, and CMISE; and

 

•                  Commitment
to develop and deploy cooperatively a first-of-its-kind capability in the industry
in a fully open, non-proprietary environment.

 

Lockheed Martin understands the nature of
number portability administration, as well as the challenges the industry faces
relative to LNP deployment and deregulation in general.  In recognizing the spirit of the industry’s
needs for its selected LNP administrator, we offer services and support that go
beyond the letter of the requirements and that speak to our willingness and
commitment to provide not just the services procured and contracted for but address
the broader needs that really exist, as depicted in the chart that follows:

 

	
  Industry Need

  	
   

  	
  Lockheed Martin Response

  
	
   

  	
   

  	
   

  
	
  
Leadership in development of open,
  non-proprietary, NPAC/ SMS technical standards

  	
   

  	
  •                  NPAC
  SMS interfaces (NPAC SMS Interoperable Interface Specification [IIS])

  •                  NPAC
  SMS functional requirements (NPAC SMS Generic Functional Requirements
  Specification) 

  •                  Design
  of functional enhancements in anticipation of regionalization of NPAC/SMS
  services

  
	
  Flexibility, given the technical and operational
  uncertainties

  	
   

  	
  •                  Have
  refined and adapted NPAC/SMS implementation to evolving industry needs

  •                  Incorporated
  numerous changes and process enhancements (109 new requirements) at service
  provider request in Illinois during five months of requirements definition,
  documentation, and review cycles

  •                  Latest
  industry business process flows incorporated

  •                  Scalability
  of NPAC/SMS solution, recognizing unpredictability of LNP penetration rates 

  •                  A
  system and service capable of supporting:

  •     Wireless
  participation

  •     Number
  pooling (pooled number administration)

  •     Inter-NPAC
  and national LNP activities

  
	
   

  	
   

  	
  •                  Developed
  implementation enhancement (bulk download capability) to meet performance
  requirements to suit

  

 

4

 

	
  Industry Need

  	
   

  	
  Lockheed Martin Response

  
	
   

  	
   

  	
   

  
	
  Creativity in engineering and recommending
  solutions that reflect an understanding of and address underlying bus-iness
  needs

  	
   

  	
  LSMS constraints and scalability while
  still meeting the business requirements (to be able to download 25
  numbers/second)

  •                  Moved
  real-time audit processing into NPAC/SMS to simplify LSMS implementation

  •                  Unsolicited
  enhancements:

  •     Surrogate
  SOA capability through direct user interface to NPAC SMS (OpGUI) 

  •     Location
  portability

  •     Direct
  customer-manageable network and profile data on NPAC/SMS

  
	
  Support for service-provider system
  (LSMS,SOA) vendors/ implementers

  	
   

  	
  •                  Support
  of interoperability testing (lab-to-lab developer testing)

  •                  Leadership
  role in providing Interface Forums to train vendors/developers in
  implementation of the NPAC SMS interfaces

  •                  Provide
  NPAC SMS support for system vendors/developers

  •                  End-user
  graphical interface to NPAC SMS to provide surrogate SOA functions in NPAC in
  lieu of SOA system upgrades

  
	
  Harmonize NPAC/SMS service offerings across
  the industry

  	
   

  	
  •                  Development
  of standardized NPAC SMS generic software for consistency of NPAC/SMS
  services

  •                  Establishment
  of standard national NPAC/SMS service pricing for all regions Lockheed Martin
  IMS may be fortunate to serve 

  •                  Common
  service element-based pricing provides for NPAC/SMS service cost parity
  across the country

  •                  No
  inter-regional pricing disparities or inequities for service providers (and
  their end-users)

  •                  Cost-sharing
  of economies of scale across regions

  •                  Usage
  sensitive pricing that links discount thresholds to higher transaction rates

  
	
  Support aggressive LNP de-ployment
  schedules

  	
   

  	
  •     Lockheed
  Martin has the scale, technical strength, and operating capability to
  implement and deliver NPAC/SMS services. Lockheed Martin is a $30 billion
  world class systems integration and services provider, operating very large,
  complex systems, with 200,000 employees 

  •     Strict
  project schedule and risk management of ongoing development to ensure
  on-time delivery of NPAC/SMS to industry 

  •     Willingness
  to initiate early start in New York with good-faith Letter of Intent to
  lock-in schedule 

  •     Initiated
  early start in Illinois, well ahead of formation of

  

 

5

 

	
  Industry Need

  	
   

  	
  Lockheed Martin Response

  
	
   

  	
   

  	
   

  
	
   

  	
   

  	
  Illinois LNP LLC and start of contract
  negotiations 

  •     Incurred
  financial exposure in Illinois well above that covered by Letter of Intent,
  in order to safeguard the schedule

  
	
   

  	
   

  	
   

  
	
  Economic and responsive provision of
  NPAC/SMS services

  	
   

  	
  •     Lockheed
  Martin’s NPAC/SMS proposal and implementation program demonstrate our
  commitment to quality, responsiveness, and economic value 

  •     Lockheed
  Martin will cooperate with NYCAC to establish processes and provisions
  ensuring NPAC/SMS services are highly responsive and economically priced 

  •     Depth
  of Lockheed Martin Corporate resources ($30B, 200K employees, world-class
  systems integrator) and long experience in being entrusted with national
  strategic assets (e.g., 800 NASC, defense, aerospace) 

  •     Have
  agreed to contractual protections in Illinois to ensure continued performance
  and responsiveness, and independent NPAC/SMS maintenance in case of default 

  •     Active
  support of open, permanently non-proprietary, technical standards 

  •     Long
  tradition of Lockheed Martin conducting business with highest of ethics,
  fairness, and evenhandedness

  
	
  Flexibility given regulatory uncertainties

  	
   

  	
  •     Willingness
  to incur substantial financial exposure (early start in Illinois) given these
  uncertainties 

  •     Firm
  belief in eventuality of LNP deployment, need for NPAC/SMS services, and
  Lockheed Martin’s suitability as lead NPAC/SMS services provider 

  •     Have
  recognized constraints on LLC authority and uncertainty regarding contract
  term and future events. Have requested reasonable commercial terms under
  circumstances of early termination without cause 

  •     Willingness
  to actively support and cooperate, to the extent appropriate, with NANC LNPA
  standards and selection process 

  •     Willingness
  to undertake advocacy role with regulators as subject matter experts in
  NPAC/SMS for the benefit of whole industry to the extent appropriate without
  jeopardizing strict neutrality (e.g., ex parte 95-116 presentation to FCC).

  

 

The Team

 

Lockheed Martin IMS, as the prime contractor
for the NYCAC NPAC/SMS, has carefully selected a team of companies who possess
the financial stability, proven performance, and complementary strengths

 

6

 

that will result in the provision of an
NPAC/SMS that is on time, reliable, scalable, feature rich, competitively
priced, and managed in an independent, evenhanded fashion.

 

The Lockheed Martin Team comprises the
following companies:

 

Evolving Systems, Inc.
(ESI):  An
Englewood, Colorado company with a proven record of developing and delivering
high quality software systems for the telecommunications industry.  As the lead NPAC SMS software developer for
the Lockheed Martin Team, ESI is currently deeply into the design and development
of the Lockheed Martin NPAC SMS generic software that forms the basis of
NPAC/SMS services Lockheed Martin IMS will offer throughout the industry.  ESI has extensive experience in client server
solutions, CMISE, GUI applications, network design, and on-time delivery.  With nine of every 10 employees involved in
the development of software and their knowledge of requirements gleaned from
their participation in the state portability workshops, ESI has the breadth and
depth of talent to deliver a quality NPAC SMS application.

 

DSET:  A New Jersey company that is very prominent
in the design and implementation of software tools that facilitate TMN system
interfaces.  DSET’s tools, which are
utilized by ESI, and their extensive experience in implementing and testing
production-quality CMISE-based systems will ensure that the NPAC/SMS’
mechanized interface with the LSMS and SOA are impeccably implemented and
validated.  DSET will build on its
experience in conformance testing of CMISE interfaces to continue providing
NPAC SMS interface interoperability testing, in support of service provider
systems (LSMS and SOA) deployment serving both the Illinois LNP LLC and NYCAC
jurisdictions, to the industry to ensure end-to-end interoperability of

 

7

 

service provider LSMS and SOA
systems built to the IIS.  These services
are essential to ensure timely and error-free turn-up testing in support of LNP
deployment for NYCAC.

 

Stratus Computers, Inc.:  A Massachusetts company, Stratus’ fault
tolerance and virtually continuous availability make it particularly well
suited to the NPAC/SMS requirements. 
Stratus platforms have been the linchpins of high transaction, mission
critical applications in the telecommunications industry for years and were the
logical choice for Lockheed Martin’s NPAC/SMS since the local service providers
and their customers would be intolerant of any service outages resulting for
NPAC SMS unavailability.

 

Lockheed Martin:  A corporation with a strong balance sheet and
a proud record of growth and profitability. 
We have the depth of resources ($30 billion revenues, and 200,000
people) and long experience in being entrusted with national strategic assets
(e.g., 800 NASC, defense, aerospace) to support wide-scale deployment of
NPAC/SMS services throughout the industry.

 

Lockheed Martin has designated its
Information Management Services (IMS) company to lead the NYCAC NPAC/SMS
initiative.  Lockheed Martin IMS will be
fully responsible for system implementation, operations, and service delivery —
repeating our demonstrated successes as a system integrator and service
provider managing multi-disciplinary teams including major software systems
developers.  In addition to Lockheed
Martin IMS’ acknowledged leadership in the 800/888 toll free portability environment,
we have augmented these substantial capabilities with the addition of
experienced telecommunications consultants — Mark Foster (Principal of MDF
Associates), Lisa Marie Maxson (Telecom Software Enterprises), and John Shea.  Sections 1.1 through 1.4 of our proposal
fully describe the exact roles and responsibilities of each team member, and
our team-wide qualifications and relevant experience.

 

8

 

The Solution

 

Lockheed Martin is convinced that our Team
has designed a technical and operational solution that satisfies and exceeds
all the requirements stipulated within the NYCAC RFP.  Furthermore, Lockheed Martin proposes
NPAC/SMS performance metrics that reflect our willingness to accept
accountability for the provisioning of high quality service to our
customers.  Some significant aspects of
the Lockheed Martin Team’s solution are as follows:

 

Neutrality

 

Lockheed Martin and all our team members are
completely neutral in the light of the RFP requirements.  Furthermore, to foreclose any concerns
regarding the NPAC/SMS application and its title, Lockheed Martin has acquired
ownership of all intellectual property rights for this software and any
modifications or enhancements that may be made while going forward.  Much like we demonstrate every day in the
operation of the 800 NASC, Lockheed Martin takes our responsibilities to fairly
represent the industry very seriously, and we have structured our business
arrangements accordingly.

 

Implementation

 

Lockheed Martin has assembled a team that has
the credentials, experience, and resources necessary to deliver the NPAC/SMS in
accordance with the stated RFP requirements. 
Our implementation schedule is realistic and attainable, especially
in light of our early start on the design and development of the NPAC SMS
applications software even prior to our selection as the NPAC/SMS provider in
Illinois.  Furthermore, we believe that
the level of detail and technical competency portrayed in this proposal is
indicative of the Lockheed Martin Team’s commitment and capability to deliver
the proposed solution on time.

 

9

 

NYCAC has aggressively driven the deployment schedule for
local portability.  Lockheed Martin will
facilitate that vision by delivering the NPAC/SMS on May 15, 1997, and
ensuring that full operations are supported by October 1, 1997.

 

The Future

 

The Lockheed Martin NPAC/SMS is designed to
grow as the needs of the competitive local service marketplace dictate.  The Lockheed Martin solution accommodates the
addition of local service providers, geographic jurisdictions, or feature
enrichments, such as:

 

•            Broader
location and service portability

 

•            Wireless
portability

 

•            Direct
support of resellers

 

•            Pooled
number administration.

 

In choosing Lockheed Martin, the NYCAC can be
secure in the knowledge that the NPAC/SMS has been designed with the future in
mind and that Lockheed Martin is committed to supporting ongoing New York LNP
activities geared to initial LNP deployment in New York and future deployment
throughout the surrounding region.

 

The Price

 

Lockheed Martin has made every effort to
understand the evolving competitive local service marketplace.  We recognize the vagaries of cost recovery
and the two year ramp-up of local service provider revenue.  With that in mind, we have designed an
NPAC/SMS that is fairly and flexibly priced and sensitive to the service
providers’ needs.

 

10

 

Conclusion

 

Given the national attention and visibility
afforded the implementation of local number portability throughout the United
States and the aggressive timetable mandated by the FCC, we believe that NYCAC
must choose a qualified team that:

 

•                  Demonstrates
a thorough understanding of the requirements, the marketplace, and the business
issues

 

•                  Is
knowledgeable and can begin immediately after contract award with a full
understanding of the requirements

 

•                  Is
credible and can unquestionably deliver the NPAC/SMS by May 15, 1997 for
testing

 

•                  Is
backed by the full faith and commitment of a neutral prime contractor with
substantial financial and technical resources.

 

As our NPAC/SMS experience demonstrates and
as this proposal validates, the Lockheed Martin Team is the best team for
NYCAC, providing an honest and experienced partner, a fully compliant solution,
and a competitive price.

 

11

 

This Page Intentionally Blank

 

12

 

	
  NYCAC NPAC/SMS Proposal

  	
   

  	
  1.1 Team Composition, Roles, & Responsibilities

  

 

HIGHLIGHTS

 

•                  Neutral
position as a telecom-munications system administrator guarantees neutral,
impartial service delivery

 

•                  As
providers of continuously available computing platforms, NPAC SMS software, and
TMN tools, the Team has all the requisite experience for a successful, on-time
delivery

 

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

 

 

13

 

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.

 

14

 

Evolving Systems, Inc. (ESI)

 

As a team member responsible for systems and
support that meet RFP requirements, ESI will:

 

•                  Develop,
test, and install NPAC SMS application software and support systems

 

•                  Support
system integration and operational turn-up testing among the NPAC and the local
SMSs and SOAs of NYCAC member carriers, and between the primary NPAC SMS and
the back-up disaster recovery NPAC SMS

 

•                  Provide
software documentation and application training.

 

DSET Corporation (DSET)

 

As a supporting NPAC SMS team member, DSET
will:

 

•                  Review
and support NPAC SMS system development and testing

 

•                  Support
design, testing, and installation of TMN-type system interfaces

 

•                  Support
interoperability testing between the NPAC SMS and the local SMSs and SOAs of
NYCAC member carriers.

 

Stratus Computer, Inc. (Stratus)

 

Stratus Computer, Inc. will provide,
install, and maintain system hardware and related software, and will work with
others on the team to ensure system operability by the deadlines proposed in
the RFP.

 

15

 

	
  NYCAC NPAC/SMS Proposal

  	
   

  	
  1.2 Financial Responsibility

  

 

HIGHLIGHTS

 

•                  Lockheed
Martin, a financially stable and strong $30 billion corporation, as Prime
Vendor ensures project success

 

•                  Financial
strength to support NYCAC NPAC/SMS services for many years, including regional
expansion outside the State of New York

 

•                  All
team members are in good financial standing, enabling them to perform and complete
con-tractual requirements

 

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

 

16

 

The success and sustained growth of Lockheed
Martin IMS reflects the successful provision of information management and
processing services.  Our company’s
growth and innovation over the past 10 years has been facilitated by the
Corporation’s sound financial backing.

 

Evolving Systems, Inc. (ESI)
is a software developer engaged in the design, development, and implementation
of distributed software systems and products—with emphasis on the UNIX
operating system—for the telecommunications, cable, and entertainment
industries. The Company is headquartered in Englewood, Colorado, a southern
suburb of Denver, and employs more than 300 people.

 

Founded in 1985, ESI has grown to become one
of the foremost UNIX development companies in the United States.  Revenues have increased from $4.8 million in 1991
to $45.3 million in 1995.  ESI is in the
business of providing software solutions, not merely programming assistance, to
its customers. As a result, ESI’s customers have typically been large
corporations that require substantial systems design work, including Fortune
500 companies, most of the Regional Bell Operating Companies (RBOCs), large
independent telephone companies, telephone research and development companies,
major investment companies, and major software providers to the personal
computer industry.

 

DSET is the premier
vendor of TMN tools and solutions and an industry leader in distributed
systems.  The company has a six-year
history and has been engaged for hundreds of projects ranging in duration from
two to 18 months.  Clients have included
long distance carriers including AT&T; RBOCs; wireless vendors including
Motorola and Hughes Network Systems; systems companies, including IBM and HP;
switch manufacturers, including Ericsson; and international corporations,
including Samsung, Hitachi, and Dae Woo. 
DSET is a $10 million, internationally recognized telecommunications
company headquartered in Bridgewater, New Jersey.

 

17

 

Stratus Computer, Inc.
lends further financial strength and stability to the Lockheed Martin
Team.  The firm is headquartered in
Marlborough, Massachusetts, and has a 16-year history as a multi-system
hardware vendor.  The company is publicly
held and grossed nearly $600 million in sales in l995.  Its financial strength is highly rated by Dun &
Bradstreet.  Stratus is a leading edge
systems producer of international reputation and has sales offices throughout
the world.  The company continues to grow
and currently employs 2,400 people.

 

The last three year-end financial reports/statements
of each team member are located in the Appendix G of our proposal.

 

 

This Page Intentionally Blank

 

18

 

HIGHLIGHTS

 

•                  Leading
neutral third party administrator of databases and systems for the telecommuni-cations
industry

 

•                  Third
party administrator/agent for more than 140 jurisdictions

 

•                  Deep
experience with NPAC type operations via our 800 NASC contract and recent
Chicago NPAC/SMS work

 

•                  Strong
telecommunications system development and system provision expertise

 

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

 

19

 

service experience focused on specialized
client needs in regulated and complex business environments that demand
management expertise and sophisticated technical solutions.  As a service-oriented company, Lockheed
Martin IMS draws on the product development assets and deep technical strengths
of other Lockheed Martin companies to bring valuable expertise and experience
to IMS’ customers.

 

Systems management, integration, and
specialized technology services—provided by the Corporation’s Information and
Technology Services Sector, shown in Exhibit 1.3-1—are Lockheed Martin’s
fastest-growing lines of business.  The
Corporation has made a strong commitment to these areas of business while
placing an increased emphasis on product and business development.

 

1.3.1  
Lockheed Martin IMS Background and Qualifications

 

Lockheed Martin IMS was founded in 1963 and
has evolved into a highly diverse data processing firm.  Headquartered in Teaneck, New Jersey, we have
more than 40 regional offices worldwide as shown in Exhibit 1.3-2, and
currently employ more than 1,400 individuals. 
We provide third party services and systems for more than 140 separate
customers in a variety of applications. 
We have developed extensive and deep systems integration, data
processing, and customer service experience focused on specialized client
needs.  Our role within Lockheed Martin
is to provide full facility management services related to high volume
automated transaction processing.  Our
mission is to be the preeminent provider of high quality operational systems
and third party services to government programs and public and private sector
organizations.

 

Much of our business involves designing and
delivering management and data processing services for complex, multifaceted
customer entities with performance and service needs similar to the
NPAC/SMS.  We have a state-of-the-art
services facility at our data center in Tarrytown, New York, staffed by more
than 150 experienced systems analysts, management personnel, and user support
teams.  These

 

20

 

individuals and others offer expertise in
operations and functions mirroring those proposed for the NPAC/SMS.

 

Lockheed Martin IMS and its key management
staff are organized into the “lines of business” depicted in Exhibit 1.3-3.

 

•                  Communications Industry Services—This organization provides
neutral third party services and supporting systems to the telecommunications
industry, including two of particular relevance to the NYCAC NPAC/SMS.  Our operation of the 800 NASC and
implementation of the NPAC/SMS for Chicago are performed by the organization.

 

•                  Children and Family Services—This organization focuses on
privatization of systems development, operations, and associated services in
support of programs concerned with the health and welfare of children and their
families, including child support enforcement and electronic benefits transfer.  Children and Family Services has active
contracts in New York, Maryland, California, Illinois, Minnesota, Virginia,
Pennsylvania, and Colorado.  Service
parallels with the NPAC/SMS include customer service, training, hardware and
software maintenance, and facilities management.

 

•                  Municipal Services—This organization provides systems,
large-scale database operations, and back-office services to more than 100
cities in support of high-volume parking management, traffic violations
processing, and emergency medical services billing programs.  There are parallels between service offerings
in this business line and NPAC/SMS requirements, including customer service,
hardware and software maintenance, customer account maintenance, performance
reporting, and training.  Operating in high
demand, high scrutiny public environments, we manage enforcement

 

21

 

programs that dramatically improve client
revenues and meet the customer’s need for responsive and sensitive service.

 

•                  Transportation Systems and Services—Established in 1986,
this organization now serves toll authorities and more than 30 states,
providing electronic toll collection systems and services; supporting the
registration, taxation, and regulation of commercial motor vehicles with
systems integration, software development and program management functions; and
serving the motor carrier industry with “Intelligent Transportation” solutions.

 

•                  Criminal Justice Services—Our newest organization leverages
core competencies of the company into the criminal justice field through the
provision of court fine and fee collection services.

 

In each of these enterprises, we are called
upon to provide solutions that require superior service and strict information
security.  All of our lines of business
are founded upon the right blend of people, facilities, systems, and process
knowledge.  Our ability to support large,
complex systems derives from our capacity to collect and place the appropriate
resources: hardware, software, and personnel.  In addition, all of our services have the
characteristics required of the NPAC/SMS and local number portability
services:  high
visibility, revenue sensitive, time sensitive, enhanced service to
all clients within a customer-sensitive, complex environment.

 

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

 

22

 

local number portability.  This perseverance paid off in 1993, when
Lockheed Martin IMS was selected to transition from Bellcore and operate the
800 NASC on a neutral, third party basis.

 

In November 1993, Lockheed Martin IMS
completed successful transition from the Bellcore NASC, and has operated the
800 NASC to the satisfaction of our users and to Database Services Management,
Incorporated (a subsidiary company of Bellcore) ever since.  Much of our experience over the past three
years relates directly to the NPAC/SMS. 
For example, in our operation of the 800 NASC, we provide the following
categories of NPAC services, all of which are required by Section 12 of
the NYCAC NPAC/SMS RFP:

 

System Administration

 

Exhibit 1.3-4 depicts the direct
correlation between the NPAC/SMS requirements and our experience in performing
the same functions.  Clearly, we have had
significant exposure to all aspects of the RFP’s System Administration
requirements, enabling us to provide carriers with solid, high quality NPAC
service.

 

SYSTEM
ADMINISTRATION

A Direct
Correlation Between Our Experience and NPAC Needs

 

	
  NPAC Functions

  	
   

  	
  Lockheed Martin 800 NASC
  Experience (Through 1995)

  
	
  Logon Administration

  	
   

  	
  •     Processed
  over 2,100 logon requests

  •     Uses
  identical process as specified in RFP

  
	
  Customer Record Security

  	
   

  	
  •     Prepared
  Security Permissions Document

  •     Audit
  user ID usage •Stringent
  facility and LAN security 

  •     Periodic
  reports

  
	
  Scheduled System Unavailability
  Notification

  	
   

  	
  •     Provide
  six months advance notice 

  •     Provide
  a minimum of two weeks final notice via Bulletin Board and fax

  
	
  Software Release Acceptance Testing

  	
   

  	
  •     Created
  approximately 2000 new feature and regression test cases in support of three
  major releases

  

 

23

 

	
  Service Administration

  	
   

  	
  •     Performed
  thousands of transactions to update 800 portability tables.

  
	
  Mass Change Administration

  	
   

  	
  •     Have
  coordinated efforts between data center and site support on scores of NPA
  splits and changes.

  •     Good
  working relationships with NANPA and traffic routing administrators

  

 

	
  Exhibit 1.3-4. We
  currently perform all NPAC System Administration tasks for the SMS/800
  system.

  

 

User Support

 

Our 800 NASC User Support team knowledge is
fully transferable to the NYCAC NPAC/SMS effort, providing the NYCAC with all
the experiential benefits gained from the 800 NASC program.  Exhibit 1.3-5 shows, in a similar
fashion, the strong foundation upon which we base our confidence in being able
to perform the required user support functions within specified performance
standards.

 

USER
SUPPORT

A Direct
Correlation Between Our Experience and NPAC Needs.

 

	
  NPAC Functions

  	
   

  	
  Lockheed Martin 800 NASC
  Experience (Through 1995)

  
	
  User Problem Resolution

  	
   

  	
  •     Processed
  over 30,000 user calls

  •     Developed
  trouble tracking system to accom-modate user queries

  •     Exceeded
  response performance objective 

  •     93%
  of calls closed on initial contact

  
	
  Software Release Acceptance Testing

  	
   

  	
  •     Created
  approximately 2000 new features and regression test cases in support of three
  major releases

  
	
  Software Modification Update

  	
   

  	
  •     Provide
  a minimum of six months advanced notice

  •     Provide
  a minimum of two weeks confirming notification

  
	
  Training Administration

  	
   

  	
  •     Developed
  training updates in support of major releases

  •     Created
  training curricula brochure

  •     Scheduled
  training, billing, and collections for over 120 students

  

 

24

 

	
  NPAC Functions

  	
   

  	
  Lockheed Martin 800 NASC
  Experience (Through 1995)

  
	
  Document Order Administration

  	
   

  	
  •     Distribute
  application training student and instructor guides which we develop and
  maintain

  •     Work
  closely with Bellcore document distribution center

  •     Distribute
  industry guidelines

  
	
  Training and Documentation User Feedback

  	
   

  	
  •     All
  students are given post-training surveys

  •     Information
  shared with documentation preparers

  
	
  Local SMS Download Problem Resolution

  	
   

  	
  •     SCP
  Download exception reports reviewed daily

  •     SCP
  Download problem resolution coordinated with application support

  

 

	
  Exhibit 1.3-5.                    The benefits
  to be derived from the transfer of comparable knowledge is readily apparent
  from the listing of our user support responsibilities in the 800 NASC.

  

 

25

 

System Support

 

We will provide technical support of the NPAC/SMS system operation,
resolving communications and interface problems, administering scheduled report
production, and notifying users of unscheduled unavailability of the system. In
addition, we will administer, operate, and maintain the NPAC/SMS’ extensive,
state-of-the-art infrastructure of redundant voice and data communications,
WAN, Stratus NPAC SMS servers, LAN, PBX/ACD, etc.  Exhibit 1.3-6 demonstrates the relevancy
of our 800 NASC role to the NPAC System Support requirements.

 

SYSTEM
SUPPORT

 

A Direct
Correlation Between Our Experience and NPAC Needs

 

	
  NPAC Functions

  	
   

  	
  Lockheed Martin 800 NASC
  Experience (Through 1995)

  
	
  NPAC SMS Report Administration

  	
   

  	
  •     Prepare
  and distribute regularly scheduled periodic reports to users 

  •     Coordinate
  and negotiate ordering, scheduling and distribution of special request
  reports 

  •     Explain
  report content to users

  
	
  Failure recovery administration and user
  notification

  	
   

  	
  •     Notify
  users via NASC recorded messages and fax

  •     Maintain
  close coordination with data center and site support

  •     Keep
  users updated every 30 minutes

  
	
  NPAC SMS Interface Monitoring

  	
   

  	
  •     Involved
  in the reporting and resolution of data link problems 

  •     Assist
  users in accessing the system

  
	
  Software Release Acceptance Testing

  	
   

  	
  •     Created
  approximately 2000 new feature and regression test cases in support of three
  major releases

  

 

	
  Exhibit 1.3-6.Lockheed
  Martin’s administrator responsibilities over the last 3 years have prepared
  us well for assuming the SMS system support functions.

  

 

In addition to our 800 NASC experience,
Lockheed Martin IMS was selected by the Illinois Commerce Commission SMS/RFP
Subcommittee to develop an NPAC SMS and provide supporting NPAC services

 

26

 

for Chicago LATA 358.  In Chicago, the six member carriers of the
SMS/RFP Subcommittee—Ameritech, AT&T, MCI, Sprint, MFS Communications, and
Teleport Communications Group—released the ICC NPAC/SMS RFP and unanimously
selected Lockheed Martin IMS to develop and administer the NPAC/SMS.

 

The Lockheed Martin Team is currently
implementing the NPAC/SMS and supporting operations for Chicago.  Just weeks ago, the Interoperable Interface
Specification and the Functional Requirements Specification of the NPAC SMS
developed by Lockheed Martin were approved by the Illinois LNP, L.L.C.
members.  We have also begun an
extraordinary amount of work on the external and internal NPAC SMS design.  The Chicago NPAC SMS (Release 1) and
supporting NPAC operations are scheduled to be up and operational, ready for
turn-up testing, in March 1997.

 

For the NYCAC NPAC/SMS, the Lockheed Martin
Team will draw on our Chicago NPAC/SMS experience, as appropriate.  We will commit a group of experience
professionals with directly relevant experience and provide them with the
latest tools for accomplishing their mission, thus satisfying not only our
performance metrics but carrier expectations. With our acknowledged NASC and
Illinois NPAC/SMS background, we envision a smooth, timely, and problem-free
implementation of the NPAC/SMS for the NYCAC.

 

Write-ups of additional Lockheed Martin
projects that are similar in complexity and scope to the NYCAC NPAC/SMS are
provided in Appendix A of our response.

 

27

 

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

 

28

 

•                  Development of the Interactive Voice Response (IVR)
systems, including screen synchronization of caller data with voice call
arrival, and preview, progressive, and predictive dialing.

 

•                  Development of the Evolving Systems, Inc. Environment
(ESIEâ). ESI developed an application layer
that rides on top of UNIX to provide system operators and developers with a
robust set of tools for remote reporting, analysis, and control. ESIEâ is
used in virtually all ESI projects. ESI also developed an SNMP Management
Information Base (MIB) that allows systems based on the ESIEâ to
be remotely monitored and controlled.

 

•                  Development of the ESI Voice/Data Integration System
(VDIS), an API based on ESIEâ. 
VDIS combines the power of an Automatic Call Distributor (ACD), IVR,
data communications with mainframes or other external systems, sophisticated
agent interfaces, and a predictive dialing mechanism to produce significant
efficiencies in both inbound and outbound call processing.

 

In addition, four projects particularly
demonstrate ESI’s capabilities to support the NPAC/SMS effort.  In its Advanced Intelligent Network (AIN)
Project for GTE, ESI is designing, implementing, and servicing a Local Service
Management System (SMS) for a variety of Intelligent Network Services.  Both the system and software architecture for
this Local SMS are parallel to that of a Regional SMS for LNP.  The GTE Local SMS consists of three major subcomponents:
sales order entry, order processing, and system management.  System functions include customer number
allocation, order validation, updating of customer information, and
provisioning data on SCPs.

 

29

 

For another customer, ESI developed a CDPD
MD-IS (Mobile Data Intermediate System) network infrastructure.  The firm designed, developed, implemented,
and is servicing an application for transmission of advanced cellular digital
data packets over existing phone channels. 
Network management tasks performed here are directly applicable to
regional SMS requirements.

 

GTE commissioned ESI to design a Provisioning
Analysis and Control System (PACS). 
These software modules were used to automate complex phone service
provisioning. Phone service orders are programmed in the switch using an
ESI-Developed Interface.

 

ESI designed a Benefits Eligibility
Verification System utilizing a web server host and interface for US WEST.  The current pilot system will eventually
provide the infrastructure necessary to support many health care transactions.  The user interface proposed for NYCAC
NPAC/SMS is based on the design and development completed for this project.

 

Write-ups of other ESI projects that are
similar in complexity and scope to the NYCAC NPAC/SMS are provided in Appendix
A of our response.

 

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

 

30

 

In 1989 and 1990, DSET developed its own
development platform, called DSG, the Distributed Systems Generator.  DSG provides: 1) a powerful object oriented
development methodology, ideally suited to develop object oriented CMIP applications,
and 2) a communications infrastructure critical to real-time embedded and
distributed applications.

 

With its native support for ASN.1 and OSI,
the DSG platform quickly became the backbone of the DSET TMN
(Telecommunications Management Network) tools. 
All of the DSET TMN tools are built on top of this platform.  Included are CMIP, TMN Agent Toolkit, TMN
Manager Tools, CMIP Agent Tester, CMIP Agent Emulator, etc.  The platform architecture provides the DSET
TMN tools with a number of industry competitive distinctions.  For example, cross platform development is
facilitated.  Applications developed on a
UNIX platform can be easily migrated to a real-time operating system
platform.  An element manager comprising
both TMN agent and manager roles is simplified in the DSET architecture because
the DSG platform underlies both agent and manager components.  Communications between the agent and the
manager are easily handled by the DSG platform.

 

With five years of development enhancements,
the DSG platform is a heavy-duty, well-tested, industrial- strength platform
effective for UNIX and real-time embedded systems applications.  DSET invests significantly in new
development.  The DSET tools are
regularly updated and enhanced to meet customers’ needs.

 

Currently, DSET and its tools play an
important part in the development of the NPAC SMS for Chicago.  DSET has been used to review the NPAC SMS
Interoperable Interface Specification. 
DSET’s tools have been used to ensure that the GDMO object code and
ASN.1 source compile.  As implementation
proceeds in Chicago, DSET will assist in the interoperability testing of the
NPAC SMS interfaces with the carriers’ local SMSs and SOAs.  Lockheed Martin will use the DSET suite of
tools for the NPAC

 

31

 

SMS deployed in New York and in the
surrounding region, and it is anticipated that DSET will also support
interoperability testing.

 

DSET plays an active role in industry core
standards committees to be aware of and influence new standards that impact the
DSET software tools.  Some of the key
standards committees are:

 

•                  The
Network Management Forum

 

•                  OSE
(Open Systems Environment) Implementors Workshop (OIW)

 

•                  The
ANSI T1M1.5 Committees.

 

As shown in Exhibit 1.3-7, DSET’s experience spans many
industry-related fields and applications, including:

 

•                  Electronic
bonding

 

•                  AIN
Service Management Systems

 

•                  TR-303

 

•                  Wireless
CDPD

 

•                  Network
traffic (GR-495).

 

32

 

Electronic Bonding

 

DSET’s CMIP tools are used extensively for electronic bonding.  Both local telephone companies (LECs) and
interexchange carriers (IXCs), maintain trouble administration systems.  When telephone company customers call their
local telephone company to report a problem on the telephone line, the LEC
enters this as a trouble ticket into one of their database systems to manage
resolution.  If, for example, the LEC
dispatches a repair person to a customer’s location to work on the problem,
this is recorded in the trouble administration system.  The status of the outstanding trouble ticket
is updated regularly.  When the trouble
is cleared, this is entered into the system as well.

 

Many troubles will also impact the IXC serving the customer.  To manage this, the IXC maintains its own
trouble administration systems and manually enters information it obtains from
the customer or from the LEC into their system. 
In 1993, a better way to manage the resolution of problems across
carrier domains was developed by an industry committee, which agreed to
electronically bond the trouble administration system of the LECs to those of
the IXCs utilizing a CMIP gateway architecture. 
The IXC would build a CMIP manager functionality to send messages from
its trouble administration systems to the LECs over a full 7-layer OSI
stack.  The LECs would build a CMIP Agent
functionality to connect messages from the IXC Manager to its trouble
administration systems.  The carriers
worked together in the TIM1.5 Committee of ANSI to build a managed object
model, ultimately under the specifications T1.227 and T1.228, to handle the
management functionality.

 

To date, four of the carriers have selected the DSET CMIP Agent and
Manager tools to build their own CMIP Gateway. 
This application provided DSET with a number of new challenges.  For example, the CMIP stack had to undergo
full compliance testing under the CTS-3 Conformance Testing Suite provided
under the auspices of the Corporation for Open Systems and the International
Consortium for Conformance Testing.  In
1994, DSET completed this multi-month process on several UNIX platforms.

 

33

 

With stack conformance testing accomplished, the carriers integrated
the CMIP Gateways into their trouble administration systems.  Once completed, their systems underwent
comprehensive interoperability testing between carriers.  DSET assisted its customers through this
rigorous effort, which was followed by managed object conformance testing for
each of the carriers.  AT&T,
BellSouth, Southwestern Bell, and Pacific Bell have utilized the DSET CMIP
Agent and Manager tools to build their CMIP Gateways.  With DSET’s software and consulting support,
all four have successfully implemented their systems and have had them in
commercial service since late 1994.

 

A second electronic bonding application, for Preferred Interexchange
Carrier (PIC), is under standardization and in early development at this point
by some of the carriers.  All four of the
carriers mentioned in the previous paragraph have selected the DSET tools for
PIC.  Other telephone companies,
including Ameritech, Bell Atlantic, NYNEX, Cincinnati Bell Telephone, and
Southern New England Telephone, are exploring the use of the DSET CMIP tools
for PIC.

 

SMS for AIN Services Interfacing to SCPs

 

Bellcore selected the DSET software for several aspects of its
Integrated Service Control Point (ISCP). 
The DSG software was used as the communications infrastructure
internally to the ISCP, and DSET ASN.1 tools were used as the basis for two of
the ISCP interfaces.  These are the
provisioning interface called the Service Provisioning and Creation Environment
(SPACE) Server, and the Billing interface. 
Both of these interfaces use an RFC 1006 OSI stack from OSET and a
message set and context definitions built with the DSET tools.  Bellcore delivered DSET software in its ISCP
3.0 and is now developing its third generation of ISCP (ISCP 5.0) based on the
DSET software.  This has been successful
both for Bellcore and DSET.  The
interface work with Bellcore led DSET to many vendors and companies building
service management systems (SMS) to communicate with service control point

 

34

 

(SCP) systems and service order systems.  Other companies using the DSET AIN Service
Order software tools include:  DSC
Communications for their SMS; Bell Atlantic for their SMS and billing systems;
Southwestern Bell for their AIN interfaces; Pacific Bell for an intelligent
peripheral processor to their Service Order systems; US West for their AIN
billing systems interface; and Stentor in Canada for their SMS interface and
the IBM SCP interface.

 

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

 

35

 

UNIX-based software.  Stratus
systems installed in OS environments help improve the efficiency of the
operational infrastructure of the network, reducing operating costs.  Applications available on Stratus include
real-time billing, voice response directory assistance, payphone management,
and automated dispatch.  Network
management applications and network monitoring operations are consolidated on
Stratus systems to provide centralized surveillance and analysis of network
elements, alarms, and trouble ticket operations for any size network.

 

36

 

This Page Intentionally
Blank

 

37

 

 

	
  NYCAC NPAC/SMS Proposal

  	
   

  	
  1.3 Background, Quals., & Relevant Experience

  

 

HIGHLIGHTS

 

•                  Leading
neutral third party administrator of databases and systems for the
telecommuni-cations industry

 

•                  Third
party administrator/agent for more than 140 jurisdictions

 

•                  Deep
experience with NPAC type operations via our 800 NASC contract and recent
Chicago NPAC/SMS work

 

•                  Strong
telecommunications system development and system provision expertise

 

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

 

38

 

service experience focused on specialized
client needs in regulated and complex business environments that demand
management expertise and sophisticated technical solutions.  As a service-oriented company, Lockheed
Martin IMS draws on the product development assets and deep technical strengths
of other Lockheed Martin companies to bring valuable expertise and experience
to IMS’ customers.

 

Systems management, integration, and
specialized technology services—provided by the Corporation’s Information and
Technology Services Sector, shown in Exhibit 1.3-1—are Lockheed Martin’s
fastest-growing lines of business.  The
Corporation has made a strong commitment to these areas of business while
placing an increased emphasis on product and business development.

 

1.3.1  
Lockheed Martin IMS Background and Qualifications

 

Lockheed Martin IMS was founded in 1963 and
has evolved into a highly diverse data processing firm.  Headquartered in Teaneck, New Jersey, we have
more than 40 regional offices worldwide as shown in Exhibit 1.3-2, and
currently employ more than 1,400 individuals. 
We provide third party services and systems for more than 140 separate
customers in a variety of applications. 
We have developed extensive and deep systems integration, data
processing, and customer service experience focused on specialized client
needs.  Our role within Lockheed Martin
is to provide full facility management services related to high volume
automated transaction processing.  Our
mission is to be the preeminent provider of high quality operational systems
and third party services to government programs and public and private sector
organizations.

 

Much of our business involves designing and
delivering management and data processing services for complex, multifaceted
customer entities with performance and service needs similar to the
NPAC/SMS.  We have a state-of-the-art services
facility at our data center in Tarrytown, New York, staffed by more than 150
experienced systems analysts, management personnel, and user support
teams.  These

 

39

 

individuals and others offer expertise in
operations and functions mirroring those proposed for the NPAC/SMS.

 

Lockheed Martin IMS and its key management
staff are organized into the “lines of business” depicted in Exhibit 1.3-3.

 

•                  Communications Industry Services—This organization provides
neutral third party services and supporting systems to the telecommunications
industry, including two of particular relevance to the NYCAC NPAC/SMS.  Our operation of the 800 NASC and
implementation of the NPAC/SMS for Chicago are performed by the organization.

 

•                  Children and Family Services—This organization focuses on
privatization of systems development, operations, and associated services in
support of programs concerned with the health and welfare of children and their
families, including child support enforcement and electronic benefits
transfer.  Children and Family Services
has active contracts in New York, Maryland, California, Illinois, Minnesota,
Virginia, Pennsylvania, and Colorado. 
Service parallels with the NPAC/SMS include customer service, training,
hardware and software maintenance, and facilities management.

 

•                  Municipal Services—This organization provides systems,
large-scale database operations, and back-office services to more than 100
cities in support of high-volume parking management, traffic violations
processing, and emergency medical services billing programs.  There are parallels between service offerings
in this business line and NPAC/SMS requirements, including customer service,
hardware and software maintenance, customer account maintenance, performance
reporting, and training.  Operating in
high demand, high scrutiny public environments, we manage enforcement programs
that dramatically improve client revenues and meet the customer’s need for
responsive and sensitive service.

 

40

 

•                  Transportation Systems and Services—Established in 1986,
this organization now serves toll authorities and more than 30 states,
providing electronic toll collection systems and services; supporting the
registration, taxation, and regulation of commercial motor vehicles with
systems integration, software development and program management functions; and
serving the motor carrier industry with “Intelligent Transportation” solutions.

 

•                  Criminal Justice Services—Our newest organization leverages
core competencies of the company into the criminal justice field through the
provision of court fine and fee collection services.

 

In each of these enterprises, we are called
upon to provide solutions that require superior service and strict information security.  All of our lines of business are founded upon
the right blend of people, facilities, systems, and process knowledge.  Our ability to support large, complex systems
derives from our capacity to collect and place the appropriate resources:
hardware, software, and personnel.  In
addition, all of our services have the characteristics required of the NPAC/SMS
and local number portability services:  high visibility, revenue sensitive, time sensitive, enhanced service
to all clients within a customer-sensitive, complex environment.

 

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

 

41

 

In November 1993, Lockheed Martin IMS
completed successful transition from the Bellcore NASC, and has operated the
800 NASC to the satisfaction of our users and to Database Services Management,
Incorporated (a subsidiary company of Bellcore) ever since.  Much of our experience over the past three
years relates directly to the NPAC/SMS. 
For example, in our operation of the 800 NASC, we provide the following
categories of NPAC services, all of which are required by Section 12 of
the NYCAC NPAC/SMS RFP:

 

System Administration

 

Exhibit 1.3-4 depicts the direct
correlation between the NPAC/SMS requirements and our experience in performing
the same functions.  Clearly, we have had
significant exposure to all aspects of the RFP’s System Administration
requirements, enabling us to provide carriers with solid, high quality NPAC
service.

 

SYSTEM
ADMINISTRATION

A Direct
Correlation Between Our Experience and NPAC Needs

 

	
  NPAC Functions

  	
   

  	
  Lockheed Martin 800 NASC
  Experience (Through 1995)

  
	
  Logon Administration

  	
   

  	
  •     Processed
  over 2,100 logon requests

  •     Uses
  identical process as specified in RFP

  
	
  Customer Record Security

  	
   

  	
  •     Prepared
  Security Permissions Document

  •     Audit
  user ID usage

  •     Stringent
  facility and LAN security

  •     Periodic
  reports

  
	
  Scheduled System Unavailability
  Notification

  	
   

  	
  •     Provide
  six months advance notice

  •     Provide
  a minimum of two weeks final notice via Bulletin Board and fax

  
	
  Software Release Acceptance Testing

  	
   

  	
  •     Created
  approximately 2000 new feature and regression test cases in support of three
  major releases

  
	
  Service Administration

  	
   

  	
  •     Performed
  thousands of transactions to update 800 portability tables.

  

 

42

 

	
  NPAC Functions

  	
   

  	
  Lockheed Martin 800 NASC
  Experience (Through 1995)

  
	
  Mass Change Administration

  	
   

  	
  •     Have
  coordinated efforts between data center and site support on scores of NPA
  splits and changes.

  •     Good
  working relationships with NANPA and traffic routing administrators

  
	
  Exhibit 1.3-4. We
  currently perform all NPAC System Administration tasks for the SMS/800
  system.

  

 

User Support

 

Our 800 NASC User Support team knowledge is
fully transferable to the NYCAC NPAC/SMS effort, providing the NYCAC with all
the experiential benefits gained from the 800 NASC program.  Exhibit 1.3-5 shows, in a similar
fashion, the strong foundation upon which we base our confidence in being able
to perform the required user support functions within specified performance
standards.

 

USER
SUPPORT

A Direct
Correlation Between Our Experience and NPAC Needs.

 

	
  NPAC Functions

  	
   

  	
  Lockheed Martin 800 NASC
  Experience (Through 1995)

  
	
  User Problem Resolution

  	
   

  	
  •     Processed
  over 30,000 user calls

  •     Developed
  trouble tracking system to accom-modate user queries

  •     Exceeded
  response performance objective

  •     93%
  of calls closed on initial contact

  
	
  Software Release Acceptance Testing

  	
   

  	
  •     Created
  approximately 2000 new features and regression test cases in support of three
  major releases

  
	
  Software Modification Update

  	
   

  	
  •     Provide
  a minimum of six months advanced notice

  •     Provide
  a minimum of two weeks confirming notification

  
	
  Training Administration

  	
   

  	
  •     Developed
  training updates in support of major releases

  •     Created
  training curricula brochure

  •     Scheduled
  training, billing, and collections for over 120 students

  
	
  Document Order Administration

  	
   

  	
  •     Distribute
  application training student and instructor guides which we develop and
  maintain

  •     Work
  closely with Bellcore document distribution center

  •     Distribute
  industry guidelines

  

 

43

 

	
  NPAC Functions

  	
   

  	
  Lockheed Martin 800 NASC
  Experience (Through 1995)

  
	
  Training and Documentation User Feedback

  	
   

  	
  •     All
  students are given post-training surveys

  •     Information
  shared with documentation preparers

  
	
  Local SMS Download Problem Resolution

  	
   

  	
  •     SCP
  Download exception reports reviewed daily 

  •     SCP
  Download problem resolution coordinated with application support

  

 

	
  Exhibit 1.3-5.The
  benefits to be derived from the transfer of comparable knowledge is readily
  apparent from the listing of our user support responsibilities in the 800
  NASC.

  

 

44

 

System Support

 

We will provide technical support of the
NPAC/SMS system operation, resolving communications and interface problems, administering
scheduled report production, and notifying users of unscheduled unavailability
of the system. In addition, we will administer, operate, and maintain the
NPAC/SMS’ extensive, state-of-the-art infrastructure of redundant voice and
data communications, WAN, Stratus NPAC SMS servers, LAN, PBX/ACD, etc.  Exhibit 1.3-6 demonstrates the relevancy
of our 800 NASC role to the NPAC System Support requirements.

 

SYSTEM
SUPPORT

A Direct
Correlation Between Our Experience and NPAC Needs

 

	
  NPAC Functions

  	
   

  	
  Lockheed Martin 800 NASC
  Experience (Through 1995)

  
	
  NPAC SMS Report Administration

  	
   

  	
  •     Prepare
  and distribute regularly scheduled periodic reports to users

  •     Coordinate
  and negotiate ordering, scheduling and distribution of special request
  reports

  •     Explain
  report content to users

  
	
  Failure recovery administration and user
  notification

  	
   

  	
  •     Notify
  users via NASC recorded messages and fax

  •     Maintain
  close coordination with data center and site support

  •     Keep
  users updated every 30 minutes

  
	
  NPAC SMS Interface Monitoring

  	
   

  	
  •     Involved
  in the reporting and resolution of data link problems

  •     Assist
  users in accessing the system

  
	
  Software Release Acceptance Testing

  	
   

  	
  •     Created
  approximately 2000 new feature and regression test cases in support of three
  major releases

  

 

Exhibit 1.3-6.                    Lockheed
Martin’s administrator responsibilities over the last 3 years have prepared us
well for assuming the SMS system support functions.

 

In addition to our 800 NASC experience,
Lockheed Martin IMS was selected by the Illinois Commerce Commission SMS/RFP
Subcommittee to develop an NPAC SMS and provide supporting NPAC services

 

45

 

for Chicago LATA 358.  In Chicago, the six member carriers of the
SMS/RFP Subcommittee—Ameritech, AT&T, MCI, Sprint, MFS Communications, and
Teleport Communications Group—released the ICC NPAC/SMS RFP and unanimously
selected Lockheed Martin IMS to develop and administer the NPAC/SMS.

 

The Lockheed Martin Team is currently
implementing the NPAC/SMS and supporting operations for Chicago.  Just weeks ago, the Interoperable Interface
Specification and the Functional Requirements Specification of the NPAC SMS
developed by Lockheed Martin were approved by the Illinois LNP, L.L.C. members.  We have also begun an extraordinary amount of
work on the external and internal NPAC SMS design.  The Chicago NPAC SMS (Release 1) and
supporting NPAC operations are scheduled to be up and operational, ready for
turn-up testing, in March 1997.

 

For the NYCAC NPAC/SMS, the Lockheed Martin
Team will draw on our Chicago NPAC/SMS experience, as appropriate.  We will commit a group of experience
professionals with directly relevant experience and provide them with the
latest tools for accomplishing their mission, thus satisfying not only our
performance metrics but carrier expectations. With our acknowledged NASC and
Illinois NPAC/SMS background, we envision a smooth, timely, and problem-free
implementation of the NPAC/SMS for the NYCAC.

 

Write-ups of additional Lockheed Martin
projects that are similar in complexity and scope to the NYCAC NPAC/SMS are
provided in Appendix A of our response.

 

46

 

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

 

47

 

•                  Development of the Interactive Voice Response (IVR)
systems, including screen synchronization of caller data with voice call
arrival, and preview, progressive, and predictive dialing.

 

•                  Development of the Evolving Systems, Inc.
Environment (ESIEâ). ESI developed an application layer
that rides on top of UNIX to provide system operators and developers with a
robust set of tools for remote reporting, analysis, and control. ESIEâ is
used in virtually all ESI projects. ESI also developed an SNMP Management
Information Base (MIB) that allows systems based on the ESIEâ to
be remotely monitored and controlled.

 

•                  Development of the ESI Voice/Data Integration System
(VDIS), an API based on ESIEâ. 
VDIS combines the power of an Automatic Call Distributor (ACD), IVR,
data communications with mainframes or other external systems, sophisticated
agent interfaces, and a predictive dialing mechanism to produce significant
efficiencies in both inbound and outbound call processing.

 

In addition, four projects particularly
demonstrate ESI’s capabilities to support the NPAC/SMS effort.  In its Advanced Intelligent Network (AIN)
Project for GTE, ESI is designing, implementing, and servicing a Local Service
Management System (SMS) for a variety of Intelligent Network Services.  Both the system and software architecture for
this Local SMS are parallel to that of a Regional SMS for LNP.  The GTE Local SMS consists of three major
subcomponents: sales order entry, order processing, and system management.  System functions include customer number
allocation, order validation, updating of customer information, and
provisioning data on SCPs.

 

48

 

For another customer, ESI developed a CDPD
MD-IS (Mobile Data Intermediate System) network infrastructure.  The firm designed, developed, implemented,
and is servicing an application for transmission of advanced cellular digital
data packets over existing phone channels. 
Network management tasks performed here are directly applicable to
regional SMS requirements.

 

GTE commissioned ESI to design a Provisioning
Analysis and Control System (PACS). 
These software modules were used to automate complex phone service
provisioning. Phone service orders are programmed in the switch using an
ESI-Developed Interface.

 

ESI designed a Benefits Eligibility
Verification System utilizing a web server host and interface for US WEST.  The current pilot system will eventually
provide the infrastructure necessary to support many health care
transactions.  The user interface
proposed for NYCAC NPAC/SMS is based on the design and development completed
for this project.

 

Write-ups of other ESI projects that are
similar in complexity and scope to the NYCAC NPAC/SMS are provided in Appendix
A of our response.

 

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

 

49

 

In 1989 and 1990, DSET developed its own
development platform, called DSG, the Distributed Systems Generator.  DSG provides: 1) a powerful object oriented
development methodology, ideally suited to develop object oriented CMIP
applications, and 2) a communications infrastructure critical to real-time
embedded and distributed applications.

 

With its native support for ASN.1 and OSI,
the DSG platform quickly became the backbone of the DSET TMN
(Telecommunications Management Network) tools. 
All of the DSET TMN tools are built on top of this platform.  Included are CMIP, TMN Agent Toolkit, TMN
Manager Tools, CMIP Agent Tester, CMIP Agent Emulator, etc.  The platform architecture provides the DSET
TMN tools with a number of industry competitive distinctions.  For example, cross platform development is
facilitated.  Applications developed on a
UNIX platform can be easily migrated to a real-time operating system
platform.  An element manager comprising
both TMN agent and manager roles is simplified in the DSET architecture because
the DSG platform underlies both agent and manager components.  Communications between the agent and the
manager are easily handled by the DSG platform.

 

With five years of development enhancements,
the DSG platform is a heavy-duty, well-tested, industrial- strength platform
effective for UNIX and real-time embedded systems applications.  DSET invests significantly in new development.  The DSET tools are regularly updated and
enhanced to meet customers’ needs.

 

Currently, DSET and its tools play an
important part in the development of the NPAC SMS for Chicago.  DSET has been used to review the NPAC SMS
Interoperable Interface Specification. 
DSET’s tools have been used to ensure that the GDMO object code and
ASN.1 source compile.  As implementation
proceeds in Chicago, DSET will assist in the interoperability testing of the
NPAC SMS interfaces with the carriers’ local SMSs and SOAs.  Lockheed Martin will use the DSET suite of
tools for the NPAC

 

 

265

 

 

SMS deployed in New York and in the
surrounding region, and it is anticipated that DSET will also support
interoperability testing.

 

DSET plays an active role in industry core standards
committees to be aware of and influence new standards that impact the DSET
software tools.  Some of the key
standards committees are:

 

•                  The
Network Management Forum

 

•                  OSE
(Open Systems Environment) Implementors Workshop (OIW)

 

•                  The
ANSI T1M1.5 Committees.

 

As shown in Exhibit 1.3-7, DSET’s
experience spans many industry-related fields and applications, including:

 

•                  Electronic
bonding

 

•                  AIN
Service Management Systems

 

•                  TR-303

 

•                  Wireless
CDPD

 

•                  Network
traffic (GR-495).

 

Electronic Bonding

 

DSET’s CMIP tools are used extensively for
electronic bonding.  Both local telephone
companies (LECs) and interexchange carriers (IXCs), maintain trouble
administration systems.  When telephone
company customers call their local telephone company to report a problem on the
telephone line, the LEC enters this as a trouble ticket into one of their
database systems to manage resolution. 
If, for example, the LEC dispatches a repair person to a customer’s
location to work on the problem, this is

 

51

 

recorded in the trouble administration
system.  The status of the outstanding
trouble ticket is updated regularly. 
When the trouble is cleared, this is entered into the system as well.

 

Many troubles will also impact the IXC
serving the customer.  To manage this,
the IXC maintains its own trouble administration systems and manually enters
information it obtains from the customer or from the LEC into their system.  In 1993, a better way to manage the
resolution of problems across carrier domains was developed by an industry
committee, which agreed to electronically bond the trouble administration
system of the LECs to those of the IXCs utilizing a CMIP gateway
architecture.  The IXC would build a CMIP
manager functionality to send messages from its trouble administration systems
to the LECs over a full 7-layer OSI stack. 
The LECs would build a CMIP Agent functionality to connect messages from
the IXC Manager to its trouble administration systems.  The carriers worked together in the TIM1.5
Committee of ANSI to build a managed object model, ultimately under the
specifications T1.227 and T1.228, to handle the management functionality.

 

To date, four of the carriers have selected
the DSET CMIP Agent and Manager tools to build their own CMIP Gateway.  This application provided DSET with a number
of new challenges.  For example, the CMIP
stack had to undergo full compliance testing under the CTS-3 Conformance
Testing Suite provided under the auspices of the Corporation for Open
Systems and the International Consortium for Conformance Testing.  In 1994, DSET completed this multi-month
process on several UNIX platforms.

 

With stack conformance testing accomplished,
the carriers integrated the CMIP Gateways into their trouble administration
systems.  Once completed, their systems
underwent comprehensive interoperability testing between carriers.  DSET assisted its customers through this
rigorous effort, which was followed by managed object conformance testing for
each of the carriers.  AT&T,
BellSouth, Southwestern Bell, and Pacific Bell have utilized the DSET CMIP
Agent and Manager tools to build

 

52

 

their CMIP Gateways.  With DSET’s software and consulting support,
all four have successfully implemented their systems and have had them in
commercial service since late 1994.

 

A second electronic bonding application, for
Preferred Interexchange Carrier (PIC), is under standardization and in early
development at this point by some of the carriers.  All four of the carriers mentioned in the
previous paragraph have selected the DSET tools for PIC.  Other telephone companies, including
Ameritech, Bell Atlantic, NYNEX, Cincinnati Bell Telephone, and Southern New
England Telephone, are exploring the use of the DSET CMIP tools for PIC.

 

SMS for AIN Services Interfacing to SCPs

 

Bellcore selected the DSET software for
several aspects of its Integrated Service Control Point (ISCP).  The DSG software was used as the
communications infrastructure internally to the ISCP, and DSET ASN.1 tools were
used as the basis for two of the ISCP interfaces.  These are the provisioning interface called
the Service Provisioning and Creation Environment (SPACE) Server, and the
Billing interface.  Both of these interfaces
use an RFC 1006 OSI stack from OSET and a message set and context definitions
built with the DSET tools.  Bellcore
delivered DSET software in its ISCP 3.0 and is now developing its third
generation of ISCP (ISCP 5.0) based on the DSET software.  This has been successful both for Bellcore
and DSET.  The interface work with
Bellcore led DSET to many vendors and companies building service management
systems (SMS) to communicate with service control point (SCP) systems and
service order systems.  Other companies
using the DSET AIN Service Order software tools include:  DSC Communications for their SMS; Bell
Atlantic for their SMS and billing systems; Southwestern Bell for their AIN
interfaces; Pacific Bell for an intelligent peripheral processor to their
Service Order systems; US West for their AIN billing systems interface; and
Stentor in Canada for their SMS interface and the IBM SCP interface.

 

53

 

1.3.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 IDSTM228 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-1

 

(a)  If the NPAC/SMS receives an
indication from a User SOA/LSMS that it is unable to receive any more messages;

(b)  If the NPAC/SMS’s retry timer
expires for an outstanding operation (download or other message) previously
transmitted to a User SOA/LSMS.

(c)  If a User SOA/LSMS causes
substantial latencies in message flows from the NPAC/SMS as a result of chronic
delays in sending responses to the NPAC/SMS that are nevertheless sent in such
time as the timers in the NPAC/SMS do not expire.  (For example, congestion must address the
effect of chronic slow SOA/LSMS responses which are expected on a 3 second
basis but for which the timer doesn’t go off until 2 minutes have passed.)

 

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

 

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

 

1

 

PROPOSED
STATEMENT OF WORK

PORTING IN ERROR AND FAILURE TO PORT

(under Agreement for NPAC/SMS Services)

 

1.                                      INTRODUCTION;
PARTIES.  This Statement of Work
(this “SOW”) is entered into pursuant to Article 13
of, and on execution shall be a 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

 

	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
  [* * *](4)

  	
   

  	
  [* * *]

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](5)

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

(4) [* * *]

(5) [* * *]

 

42

 

	
  Amendment No.42-NPAM(NE)

  	
   

  	
  October 22,2003

  

Sow:       No

                _ Yes

 

	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
  [* * *](6)

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](7)

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

Billable NPAC User Support Manual Request
Table

 

	
  Category

  	
   

  	
  Description of Request

  
	
  Create SV

  	
   

  	
  New SP asks
  Help Desk to issue new SP Create, for single TN or range of TNs

  
	
  Create SV

  	
   

  	
  Old SP asks
  Help Desk to issue old SP Create, for single TN or range of TNs

  
	
  Prevent SV
  Activation

  	
   

  	
  Old SP asks
  Help Desk to change concur flag to “false” on pending SV (or SVs, for range
  of TNs)

  
	
  Activate SV

  	
   

  	
  New SP asks
  Help Desk to activate a pending SV for a single TN (or SVs, for a range of
  TNs)

  
	
  Remove
  Prevention of SV

  Activation

  	
   

  	
  Old SP (or
  New SP, after due date or t2 timer’s expiration) asks Help Desk to change
  concur flag to “true” on pending SV (or SVs, for range of TNs)

  
	
  Modify
  Pending SV

  	
   

  	
  New SP asks
  Help Desk to modify single SV (or SVs, for a range of TNs)

  
	
  Disconnect
  TN

  	
   

  	
  Current SP
  asks Help Desk to issue disconnect for TN (or range of TNs)

  
	
  Cancel
  Pending SV

  	
   

  	
  Old SP or
  New SP asks Help Desk to issue its cancel for pending SV (or SVs, for range
  of TNs)

  
	
  Look Up SV

  	
   

  	
  SP asks Help
  Desk to look up active SV for a TN (or SVs for range of TNs)

  
	
  Modify
  Active SV

  	
   

  	
  Current SP
  asks Help Desk to modify single active SV

  
	
  Audit SV

  	
   

  	
  SP asks Help
  Desk to issue audit request for a TN, or range of TNs, with SV(s) in active
  state

  
	
  Look Up
  Network Data

  	
   

  	
  SP asks Help
  Desk to look up NPA-NXX, NPA-NXX ID, LRN, or LRN ID to determine associated
  SPID and/or ID

  
	
  Change
  Network Data

  	
   

  	
  SP asks Help
  Desk to add to or to delete from the NPAC’s network data an NPA-NXX(s) or
  LRN(s). Requests to delete these data can be accommodated only if the SP
  making the request is the SP that originally entered the data. This
  limitation does not apply in the case where the SP asks Help Desk to delete
  an NPA-NXX (but not an LRN) where the NPA is not associated with the NPAC
  Service Area in which the NPA-NXX is open.

  
	
  Change GUI
  Password

  	
   

  	
  SP asks Help
  Desk to change its GUI Password

  
	
  Re-enter GUI
  Logon

  	
   

  	
  SP asks Help
  Desk to re-enter its GUI Logon which SP has allowed to expire

  

 

(6) The one-time Log-on [*
* *]

(7) The Mechanized
Interface [* * *]

 

43

 

	
  Amendment No.42-NPAM(NE)

  	
   

  	
  October 22,2003

  

Sow:       No

                _ Yes

 

Schedule 2

Training Charges

 

	
  Service Element

  	
   

  	
  Unit

  	
   

  	
  Cost Per Participant

  	
   

  
	
  [* * *](8)

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]  

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *](9)

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

 

Schedule 3

Interoperability Testing

 

	
  Category & Service Element

  	
   

  	
  Unit

  	
   

  	
  Price

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  

 

(8) [ * *  *]

(9) [* * * ]

 

44

 

	
  Amendment No.42-NPAM(NE)

  	
   

  	
  October 22,2003

  

Sow:       No

                _ Yes

 

Schedule 4

 

Schedule of Representative Hourly Labor
Charges

Applicable to Statements of Work

For Contract Years 1 Through End

 

	
  Labor Category

  	
   

  	
  Year 1

  	
   

  	
  Year 2

  	
   

  	
  Year 3

  	
   

  	
  Year 4

  	
   

  	
  Year 5*

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
																				

 

*Amounts after Year 5 for each Labor Category
shall be increased by 5% annually from the prior year.

 

Schedule 5

 

Schedule of Target Amounts

 

	
  Target Options

  	
   

  	
  Monthly

  Targets for 

  Nov/Dec

  1997(2)  

  	
   

  	
  Monthly

  Targets for

  1Q 1998 (2)

  	
   

  	
  Monthly

  Targets for

  2Q 1998

  through 4Q

  2001 (2)

  	
   

  	
  Monthly

  Targets for 1Q

  2002 through

  2Q 2002 (2)

  	
   

  	
  Monthly

  Target for

  July

  2002

  	
   

  	
  Total Contract

  Targets

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

Notes:

(2)          The target schedule depends on the service
term selected by the Customer.  If the
service term begins on 10/1/97, then Option A applies.  Likewise, if the service term begins on
1/1/98, then Option B applies.

(2)          The targets are listed in monthly amounts for
each of the respective calendar periods outlined above.  The targets are calculated and applied on a
monthly basis as described in Section 6.6 of the Agreement.

 

45

 

	
  Amendment No.42-NPAM(NE)

  	
   

  	
  October 22,2003

  

Sow:       No

                _ Yes

 

Schedule 6

 

Sample Annual Target and Allocable Target Shortfall/Credit Calculation

 

The following is an example of
how Allocable Target Shortfalls and Allocable Targets are determined in
connection

with the Quarterly
Targets.  A description of the
methodology (including defined terms used below) is set forth in

Section 6.6 of the Agreement.

 

	
   

  	
   

  	
  Jan-98

  	
   

  	
  Feb-98

  	
   

  	
  Mar-98

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *] *

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *] *

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  * [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  

 

46

 

	
  Amendment No.43-NPAM(NE)

  	
   

  	
  December 3,2003

  

Sow:       No

                _ Yes

 

 

AMENDMENT

OF

AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION CENTER / 

SERVICE MANAGEMENT SYSTEM

 

47

 

	
  Amendment No.43-NPAM(NE)

  	
   

  	
  December 3,2003

  

Sow:       No

                _ Yes

 

AMENDMENT

OF

AGREEMENT FOR NUMBER PORTABILITY
ADMINISTRATION

CENTER/SERVICE MANAGEMENT SYSTEM

 

1.              PARTIES 

 

This amendment (this “Amendment”) is entered into pursuant to Article
30 of, and upon execution shall be a part of, the Agreement for Number
Portability Administration Center/Service Management System, as amended and in
effect immediately prior to the Amendment Effective Date (the “Master Agreement”),
by and between NeuStar, Inc., a Delaware corporation (“Contractor”), and the
North American Portability Management LLC, a Delaware limited liability company
(the “Customer”), as the successor in interest to and on behalf of Northeast
Carrier Acquisition Company, LLC ( the “Subscribing Customer”).  

 

2.              EFFECTIVENESS AND
DEFINED TERMS

 

This Amendment shall be
effective as of the 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

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  < 100,000,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  Tier 1 Volume Range:

  100,000,000 – 126,591,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

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

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  Tier 2 Volume Range:

  126,591,001 – 153,182,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

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

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  >153,182,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  >160,195,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

	
   

  	
   

  	
  2007

  	
   

  	
   

  	
   

  	
  2008

  	
   

  
	
   

  	
   

  	
  Annual

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  ANNUAL TN PORTING

  	
   

  	
  Volume

  	
   

  	
  Maximum

  	
   

  	
  ANNUAL TN PORTING

  	
   

  	
  Annual Volume

  	
   

  	
  Maximum

  	
   

  
	
  EVENT VOLUMES FOR

  	
   

  	
  Dependent TN

  	
   

  	
  Equivalent

  	
   

  	
  EVENT VOLUMES FOR

  	
   

  	
  Dependent TN

  	
   

  	
  Equivalent 

  	
   

  
	
  ALL UNITED STATES

  	
   

  	
  Porting Price

  	
   

  	
  National

  	
   

  	
  ALL UNITED STATES

  	
   

  	
  Porting Price

  	
   

  	
  National

  	
   

  
	
  SERVICE AREAS

  	
   

  	
  Reduction

  	
   

  	
  Reduction

  	
   

  	
  SERVICE AREAS

  	
   

  	
  Reduction

  	
   

  	
  Reduction

  	
   

  
	
  < 100,000,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  < 100,000,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  Tier 1 Volume Range:

  100,000,000 – 129,994,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

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

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  Tier 2 Volume Range:

  129,994,001 – 159,987,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

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

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  >159,987,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  >154,787,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

60

 

	
  Amendment No.43-NPAM(NE)

  	
   

  	
  December
  3,2003

  

Sow:       No

                _ Yes

 

	
   

  	
   

  	
  2009

  	
   

  	
   

  	
   

  	
  2010

  	
   

  
	
   

  	
   

  	
  Annual

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  ANNUAL TN PORTING

  	
   

  	
  Volume

  	
   

  	
  Maximum

  	
   

  	
  ANNUAL TN PORTING

  	
   

  	
  Annual Volume

  	
   

  	
  Maximum

  	
   

  
	
  EVENT VOLUMES FOR

  	
   

  	
  Dependent TN

  	
   

  	
  Equivalent

  	
   

  	
  EVENT VOLUMES FOR

  	
   

  	
  Dependent TN

  	
   

  	
  Equivalent 

  	
   

  
	
  ALL UNITED STATES

  	
   

  	
  Porting Price

  	
   

  	
  National

  	
   

  	
  ALL UNITED STATES

  	
   

  	
  Porting Price

  	
   

  	
  National

  	
   

  
	
  SERVICE AREAS

  	
   

  	
  Reduction

  	
   

  	
  Reduction

  	
   

  	
  SERVICE AREAS

  	
   

  	
  Reduction

  	
   

  	
  Reduction

  	
   

  
	
  < 100,000,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  < 100,000,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  Tier 1 Volume Range:

  100,000,000 – 126,120,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

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

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  Tier 2 Volume Range:

  126,120,001 – 152,240,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

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

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  >152,240,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  >149,717,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

61

 

	
  Amendment No.43-NPAM(NE)

  	
   

  	
  December
  3,2003

  

Sow:       No

                _ Yes

 

	
   

  	
   

  	
  2011

  	
   

  
	
   

  	
   

  	
  Annual

  	
   

  	
   

  	
   

  
	
  ANNUAL TN PORTING

  	
   

  	
  Volume

  	
   

  	
  Maximum

  	
   

  
	
  EVENT VOLUMES FOR

  	
   

  	
  Dependent TN

  	
   

  	
  Equivalent

  	
   

  
	
  ALL UNITED STATES

  	
   

  	
  Porting Price

  	
   

  	
  National

  	
   

  
	
  SERVICE AREAS

  	
   

  	
  Reduction

  	
   

  	
  Reduction

  	
   

  
	
  < 100,000,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  Tier 1 Volume Range:

  100,000,000 –123,610,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  Tier 2 Volume Range:

  123,610,001 –147,220,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  >147,220,000

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

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

  	
   

  
	
   

  	
   

  	
  [* * *](4)

  	
   

  	
  [* * *]

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](5)

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](6)

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](7)

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  

 

(4) [* * *]

(5) [* * *]

(6) [* * *]

(7) [* * *]

 

75

 

	
  Amendment No.47-NAPM(NE)

  	
   

  	
  February
  20, 2004

  

Sow:       No

                _ Yes

 

	
   

  	
   

  	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](8)

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
  [* * *](9)

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  
	
   

  	
   

  	
  [* * *](10)

  	
   

  	
  [* * *]

  	
   

  	
  $[* * *]

  	
   

  

 

Billable
NPAC User Support Manual Request Table

 

	
  Category

  	
   

  	
  Description of Request

  
	
  Create SV

  	
   

  	
  New SP asks Help Desk
  to issue new SP Create, for single TN or range of TNs

  
	
  Create SV

  	
   

  	
  Old SP asks Help Desk
  to issue old SP Create, for single TN or range of TNs

  
	
  Prevent SV Activation

  	
   

  	
  Old SP asks Help Desk
  to change concur flag to “false” on pending SV (or SVs, for range of TNs)

  
	
  Activate SV

  	
   

  	
  New SP asks Help Desk
  to activate a pending SV for a single TN (or SVs, for a range of TNs)

  
	
  Remove Prevention of SV
  Activation

  	
   

  	
  Old SP (or New SP,
  after due date or t2 timer’s expiration) asks Help Desk to change concur flag
  to “true” on pending SV (or SVs, for range of TNs)

  
	
  Modify Pending SV

  	
   

  	
  New SP asks Help Desk
  to modify single SV (or SVs, for a range of TNs)

  
	
  Disconnect TN

  	
   

  	
  Current SP asks Help
  Desk to issue disconnect for TN (or range of TNs)

  
	
  Cancel Pending SV

  	
   

  	
  Old SP or New SP asks
  Help Desk to issue its cancel for pending SV (or SVs, for range of TNs)

  
	
  Look Up SV

  	
   

  	
  SP asks Help Desk to
  look up active SV for a TN (or SVs for range of TNs)

  
	
  Modify Active SV

  	
   

  	
  Current SP asks Help
  Desk to modify single active SV

  
	
  Audit SV

  	
   

  	
  SP asks Help Desk to
  issue audit request for a TN, or range of TNs, with SV(s) in active state

  
	
  Look Up Network Data

  	
   

  	
  SP asks Help Desk to
  look up NPA-NXX, NPA-NXX ID, LRN, or LRN ID to determine associated SPID
  and/or ID

  
	
  Change Network Data

  	
   

  	
  SP asks Help Desk to
  add to or to delete from the NPAC’s network data an NPA-NXX(s) or LRN(s).
  Requests to delete these data can be accommodated only if the SP making the
  request is the SP that originally entered the data. This limitation does not
  apply in the case where the SP asks Help Desk to delete an NPA-NXX (but not
  an LRN) where the NPA is not associated with the NPAC Service Area in which
  the NPA-NXX is open.

  
	
  Change GUI Password

  	
   

  	
  SP asks Help Desk to
  change its GUI Password

  
	
  Re-enter GUI Logon

  	
   

  	
  SP asks Help Desk to
  re-enter its GUI Logon which SP has allowed to expire

  

 

(8) [* * *]

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

(10) The Mechanized interface [* * *]

 

76

 

	
  Amendment No.47-NAPM(NE)

  	
   

  	
  February
  20, 2004

  

Sow:       No

                _ Yes

 

Schedule
2

Training
Charges

 

	
  Service Element

  	
   

  	
  Unit

  	
   

  	
  Cost Per Participant

  	
   

  
	
  [* * *]

  	
  (11)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
  (12) (13)

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *] 

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *] 

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

Schedule
3

Interoperability
Testing

 

	
  Category & Service Element

  	
   

  	
  Unit

  	
   

  	
  Price

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

(11) [* * *]

(12) [* * *]

(13) [* * *]

 

77

 

	
  Amendment No.47-NAPM(NE)

  	
   

  	
  February
  20, 2004

  

Sow:       No

                _ Yes

 

Schedule
4

 

Schedule
of Representative Hourly Labor Charges

Applicable
to Statements of Work

For
Contract Years 1 Through End

 

	
  Labor Category

  	
   

  	
  Year 1

  	
   

  	
  Year 2

  	
   

  	
  Year 3

  	
   

  	
  Year 4

  	
   

  	
  Year 5*

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

*
Amounts after Year 5 for each Labor Category shall
be increased by 5% annually from the prior year.

 

Schedule
5

 

Schedule
of Target Amounts

 

	
  Target Options

  	
   

  	
  Monthly

  Targets for

  Nov/Dec 

  1997 (2)

  	
   

  	
  Monthly

  Targets for

  1Q 1998 (2)

  	
   

  	
  Monthly

  Targets for

  2Q 1998

  through 4Q

  2001 (2)

  	
   

  	
  Monthly

  Targets for 1Q

  2002 through

  2Q 2002 (2)

  	
   

  	
  Monthly

  Target for

  July

  2002

  	
   

  	
  Total Contract

  Targets

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

Notes:

 

(1)          The
target schedule depends on the service term selected by the Customer.  If the service term begins on 10/1/97, then
Option A applies.  Likewise, if the
service term begins on 1/1/98, then Option B applies.

 

(2)          The
targets are listed in monthly amounts for each of the respective calendar
periods outlined above.  The targets are
calculated and applied on a monthly basis as described in Section 6.6 of the
Agreement.

 

Schedule
6

 

Sample
Annual Target and Allocable Target Shortfall/Credit Calculation

 

The following is an
example of how Allocable Target Shortfalls and Allocable Targets are determined
in connection with the Quarterly Targets. 
A description of the methodology (including defined terms used below) is
set forth in Section 6.6 of the Agreement.

 

78

 

	
  Amendment No.47-NAPM(NE)

  	
   

  	
  February
  20, 2004

  

Sow:       No

                _ Yes

 

	
   

  	
   

  	
  Jan-98

  	
   

  	
  Feb-98

  	
   

  	
  Mar-98

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
    [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
    [* * *]

  	
   

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
    [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]*

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
  [* * *]*

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  
	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  
	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  	
  $

  	
  [* * *]

  	
   

  

 

	
  * [* * *]

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  	
   

  

 

 

79

 

	
  Amendment No.48-NAPM(NE)

  	
   

  	
  April
  2, 2004

  

Sow:       No

                _ Yes

 

 

AMENDMENT

OF

AGREEMENT FOR NUMBER PORTABILITY
ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM

FOR

INTERMODAL PORTED TELEPHONE NUMBER
IDENTIFICATION SERVICE

 

80

 

	
  Amendment No.48-NAPM(NE)

  	
   

  	
  April
  2, 2004

  

Sow:       No

                _ Yes

 

AMENDMENT

OF

AGREEMENT
FOR NUMBER PORTABILITY ADMINISTRATION

CENTER/SERVICE MANAGEMENT SYSTEM

FOR

INTERMODAL
PORTED TELEPHONE NUMBER IDENTIFICATION SERVICE

 

1.              PARTIES

 

This amendment (this “Amendment”)
is entered into pursuant to Article 30 of, and upon execution shall be a part
of, the Agreement for Number Portability Administration Center/Service
Management System, as amended and in effect immediately prior to the Amendment
Effective Date (the “Master Agreement”), by and between NeuStar, Inc., a
Delaware corporation (“Contractor”), and the North American Portability
Management LLC, a Delaware limited liability company (the “Customer”), as the
successor in interest to and on behalf of Northeast Carrier Acquisition
Company, LLC ( the “Subscribing Customer”).

 

2.              EFFECTIVENESS
AND DEFINED TERMS

 

This
Amendment shall be effective as of the 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

Source: [{"source": "alea-institute/alea-institute/kl3m-data-edgar-agreements/train-00086-of-00352.parquet"}, [{"source": "alea-institute/alea-institute/kl3m-data-edgar-agreements/train-00086-of-00352.parquet"}]]